[要約] RFC 9049は、パスアウェアネットワーキングの展開における障害を議論し、未採用のアプローチを紹介します。この文書の目的は、過去の教訓を共有し、将来の技術開発の方向性を案内することです。利用場面としては、ネットワーク設計者が過去の試みから学び、新しいネットワーク技術やプロトコルを開発する際の参考にすることが挙げられます。
Internet Research Task Force (IRTF) S. Dawkins, Ed.
Request for Comments: 9049 Tencent America
Category: Informational June 2021
ISSN: 2070-1721
Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
パス対応ネットワーク：展開への障害物（行われていない道路の吉林）
Abstract
概要
This document is a product of the Path Aware Networking Research Group (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy Path Aware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons for Path Aware networking researchers.
この文書はPath Aware Networking Research Group（Panrg）の製品です。PANRGの最初の会議で、研究グループは、経路対応ネットワーキング研究者のための洞察やレッスンを抽出するために、経路対応技術の開発と展開のための過去の努力をカタログし、分析することに合意しました。
This document contains that catalog and analysis.
この文書にはカタログと分析が含まれています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Path Aware Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットリサーチタスクフォース（IRTF）の製品です。IRTFはインターネット関連の研究開発活動の結果を発行しています。これらの結果は展開には適していない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）のPath Aware Networking Researchグループのコンセンサスを表しています。IRSGによる出版が承認された文書は、インターネット規格のレベルレベルの候補者ではありません。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/rfc9049.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/frfc9049で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
1.1. What Do "Path" and "Path Awareness" Mean in This Document?
2. A Perspective on This Document
2.1. Notes for the Reader
2.2. A Note about Path Aware Techniques Included in This
Document
2.3. Architectural Guidance
2.4. Terminology Used in This Document
2.5. Methodology for Contributions
3. Applying the Lessons We've Learned
4. Summary of Lessons Learned
4.1. Justifying Deployment
4.2. Providing Benefits for Early Adopters
4.3. Providing Benefits during Partial Deployment
4.4. Outperforming End-to-End Protocol Mechanisms
4.5. Paying for Path Aware Techniques
4.6. Impact on Operational Practices
4.7. Per-Connection State
4.8. Keeping Traffic on Fast Paths
4.9. Endpoints Trusting Intermediate Nodes
4.10. Intermediate Nodes Trusting Endpoints
4.11. Reacting to Distant Signals
4.12. Support in Endpoint Protocol Stacks
4.13. Planning for Failure
5. Future Work
6. Contributions
6.1. Stream Transport (ST, ST2, ST2+)
6.1.1. Reasons for Non-deployment
6.1.2. Lessons Learned
6.2. Integrated Services (IntServ)
6.2.1. Reasons for Non-deployment
6.2.2. Lessons Learned
6.3. Quick-Start TCP
6.3.1. Reasons for Non-deployment
6.3.2. Lessons Learned
6.4. ICMP Source Quench
6.4.1. Reasons for Non-deployment
6.4.2. Lessons Learned
6.5. Triggers for Transport (TRIGTRAN)
6.5.1. Reasons for Non-deployment
6.5.2. Lessons Learned
6.6. Shim6
6.6.1. Reasons for Non-deployment
6.6.2. Lessons Learned
6.6.3. Addendum on Multipath TCP
6.7. Next Steps in Signaling (NSIS)
6.7.1. Reasons for Non-deployment
6.7.2. Lessons Learned
6.8. IPv6 Flow Labels
6.8.1. Reasons for Non-deployment
6.8.2. Lessons Learned
6.9. Explicit Congestion Notification (ECN)
6.9.1. Reasons for Non-deployment
6.9.2. Lessons Learned
7. Security Considerations
8. IANA Considerations
9. Informative References
Acknowledgments
Author's Address
This document describes the lessons that IETF participants have learned (and learned the hard way) about Path Aware networking over a period of several decades. It also provides an analysis of reasons why various Path Aware techniques have seen limited or no deployment.
この文書では、IETF参加者が数十年にわたる経路認識ネットワーキングについて学んだ（そしてハードウェイを学んだ）レッスンについて説明します。それはまた、さまざまなパス対応技術が限られた展開を見た理由の分析を提供します。
This document represents the consensus of the Path Aware Networking Research Group (PANRG).
このドキュメントは、Path Aware Networking Research Group（Panrg）の合意を表しています。
One of the first questions reviewers of this document have asked is "What's the definition of a Path, and what's the definition of Path Awareness?" That is not an easy question to answer for this document.
この文書の最初の質問レビューアーの1つは、「パスの定義は何ですか、そしてパス認識の定義は何ですか？」です。それはこの文書のために答えるのは簡単な質問ではありません。
These terms have definitions in other PANRG documents [PANRG] and are still the subject of some discussion in the Research Group, as of the date of this document. But because this document reflects work performed over several decades, the technologies described in Section 6 significantly predate the current definitions of "Path" and "Path Aware" in use in the Path Aware Networking Research Group, and it is unlikely that all the contributors to Section 6 would have had the same understanding of these terms. Those technologies were considered "Path Aware" in early PANRG discussions and so are included in this retrospective document.
これらの用語は、他のPANRG文書の定義[Panrg]を持ち、この文書の日付現在の研究グループではまだいくつかの議論の対象です。しかし、この文書は数十年以上にわたる作業を反映しているため、6節で説明されているテクノロジは、Path Aware Networking Research Research Groupで使用されている「PATH」と「パス対応」の現在の定義を大幅に述べています。セクション6はこれらの条件について同じ理解を得たでしょう。これらの技術は、初期のPANRGディスカッションで「パス対応」と見なされ、この遡及文書に含まれています。
It is worth noting that the definitions of "Path" and "Path Aware" in [PANRG-PATH-PROPERTIES] would apply to Path Aware techniques at a number of levels of the Internet protocol architecture ([RFC1122], plus several decades of refinements), but the contributions received for this document tended to target the transport layer and to treat a "Path" constructed by routers as opaque. It would be useful to consider how applicable the Lessons Learned cataloged in this document are, at other layers, and that would be a fine topic for follow-on research.
[PANRG-PATH-Properties]の[PATH "と" PATH AWARE "の定義が、インターネットプロトコルアーキテクチャのレベルでPATH対応テクニックに適用されることに注意する価値があります（[RFC1122]、数十年の洗練さ）しかし、この文書に対して受信された寄付金は輸送層を標的とし、ルータによって構築された「経路」を不透明として扱う傾向があった。この文書でカタログ化されているレッスンが他の層である授業がどれほど該当するかを検討すると便利です。
The current definition of "Path" in the Path Aware Networking Research Group appears in Section 2 ("Terminology") in [PANRG-PATH-PROPERTIES]. That definition is included here as a convenience to the reader.
PATH対応ネットワーキング研究グループの「PATH」の現在の定義は、[Panrg-Path-Properties]のセクション2（「用語」）に表示されます。その定義は読者の利便性としてここに含まれています。
| Path: A sequence of adjacent path elements over which a packet can
| be transmitted, starting and ending with a node. A path is
| unidirectional. Paths are time-dependent, i.e., the sequence of
| path elements over which packets are sent from one node to another
| may change. A path is defined between two nodes. For multicast
| or broadcast, a packet may be sent by one node and received by
| multiple nodes. In this case, the packet is sent over multiple
| paths at once, one path for each combination of sending and
| receiving node; these paths do not have to be disjoint. Note that
| an entity may have only partial visibility of the path elements
| that comprise a path and visibility may change over time.
| Different entities may have different visibility of a path and/or
| treat path elements at different levels of abstraction.
The current definition of Path Awareness, used by the Path Aware Networking Research Group, appears in Section 1.1 ("Definition") in [PANRG-QUESTIONS]. That definition is included here as a convenience to the reader.
PATH対応ネットワーキング研究グループで使用されている経路認識の現在の定義は、[Panrg-Quessition]のセクション1.1（「定義」）に表示されます。その定義は読者の利便性としてここに含まれています。
| For purposes of this document, "path aware networking" describes
| endpoint discovery of the properties of paths they use for
| communication across an internetwork, and endpoint reaction to
| these properties that affects routing and/or data transfer. Note
| that this can and already does happen to some extent in the
| current Internet architecture; this definition expands current
| techniques of path discovery and manipulation to cross
| administrative domain boundaries and up to the transport and
| application layers at the endpoints.
|
| Expanding on this definition, a "path aware internetwork" is one
| in which endpoint discovery of path properties and endpoint
| selection of paths used by traffic exchanged by the endpoint are
| explicitly supported, regardless of the specific design of the
| protocol features which enable this discovery and selection.
At the first meeting of the Path Aware Networking Research Group [PANRG], at IETF 99 [PANRG-99], Olivier Bonaventure led a discussion of "A Decade of Path Awareness" [PATH-Decade], on attempts, which were mostly unsuccessful for a variety of reasons, to exploit Path Aware techniques and achieve a variety of goals over the past decade. At the end of that discussion, two things were abundantly clear.
Path Aware Networking Research Groupの最初の会議で、IETF 99 [Panrg-99]、Olivier Bonaventureでは、「PATE DECADEの10年間」（Path-Deende]、ほとんど失敗しました。さまざまな理由で、パスを認識し、過去10年間でさまざまな目標を達成するために。その議論の終わりには、2つのことが豊富に明確になりました。
* The Internet community has accumulated considerable experience with many Path Aware techniques over a long period of time, and
* インターネットコミュニティは、長期間にわたって多くの経路認識技術でかなりの経験を積んできました。
* Although some Path Aware techniques have been deployed (for example, Differentiated Services, or Diffserv [RFC2475]), most of these techniques haven't seen widespread adoption and deployment. Even "successful" techniques like Diffserv can face obstacles that prevent wider usage. The reasons for non-adoption and limited adoption and deployment are many and are worthy of study.
* 一部のパス対応のテクニックが展開されていますが（差別化サービス、またはDIFFSERV [RFC2475]など）、これらの技術のほとんどは広範囲の採用と展開を見ていません。DiffServのような「成功した」技術でさえ、より広い使用を防ぐ障害物に直面することがあります。非採用と限定された採用および展開の理由は多くのものであり、研究に値する。
The meta-lessons from that experience were as follows:
その経験からのメタレッスンは次のとおりです。
* Path Aware networking has been more Research than Engineering, so establishing an IRTF Research Group for Path Aware networking was the right thing to do [RFC7418].
* Path Aware Networkingはエンジニアリングよりも多くの研究を行っているので、経路対応ネットワーキングのためのIRTF研究グループを確立することが、RFC7418をやるべきことでした。
* Analyzing a catalog of past experience to learn the reasons for non-adoption would be a great first step for the Research Group.
* 過去の経験のカタログを分析して、非採用の理由を学ぶことは、研究グループのための優れた最初のステップです。
Allison Mankin, as IRTF Chair, officially chartered the Path Aware Networking Research Group in July 2018.
Allison Mankinは、IRTF議長として、2018年7月にPath Aware Networking Research Groupを正式にチャーターしました。
This document contains the analysis performed by that Research Group (Section 4), based on that catalog (Section 6).
この文書には、そのカタログに基づくその研究グループ（セクション4）によって実行される分析が含まれています（第6節）。
This Informational document discusses Path Aware protocol mechanisms considered, and in some cases standardized, by the Internet Engineering Task Force (IETF), and it considers Lessons Learned from those mechanisms. The intention is to inform the work of protocol designers, whether in the IRTF, the IETF, or elsewhere in the Internet ecosystem.
この情報文書は、検討されたパス対応プロトコルメカニズム、および場合によってはインターネットエンジニアリングタスクフォース（IETF）によって標準化され、そしてそれらのメカニズムから学んだ教訓を考慮しています。その意図は、IRTF、IETF、またはインターネットエコシステムの他の場所であろうと、プロトコル設計者の作業に知らせることです。
As an Informational document published in the IRTF Stream, this document has no authority beyond the quality of the analysis it contains.
IRTFストリームに公開されている情報文書として、この文書はそれが含む分析の質を超えて権限はありません。
This document does not catalog every proposed Path Aware technique that was not adopted and deployed. Instead, we limited our focus to technologies that passed through the IETF community and still identified enough techniques to provide background for the lessons included in Section 4 to inform researchers and protocol engineers in their work.
この文書は、採用され展開されていない提案されたパス対応技術をカタログ化しません。代わりに、IETFコミュニティを通過した技術に焦点を当て、それでもセクション4に含まれるレッスンの背景を背景のための十分な技術を特定し、研究者やプロトコルエンジニアに彼らの仕事に情報を提供しました。
No shame is intended for the techniques included in this document. As shown in Section 4, the quality of specific techniques had little to do with whether they were deployed or not. Based on the techniques cataloged in this document, it is likely that when these techniques were put forward, the proponents were trying to engineer something that could not be engineered without first carrying out research. Actual shame would be failing to learn from experience and failing to share that experience with other networking researchers and engineers.
この文書に含まれるテクニックを対象としていません。セクション4に示すように、特定の技術の品質は、それらが展開されているかどうかとほとんど関係がありませんでした。この文書でカタログ化されている技術に基づいて、これらの技術が前進されたとき、提案者は最初に研究を実行せずに設計できなかったものを設計しようとしていました。実際の恥は経験から学び、他のネットワーキングの研究者やエンジニアとの経験を共有することに失敗します。
As background for understanding the Lessons Learned contained in this document, the reader is encouraged to become familiar with the Internet Architecture Board's documents on "What Makes for a Successful Protocol?" [RFC5218] and "Planning for Protocol Adoption and Subsequent Transitions" [RFC8170].
この文書に含まれているレッスンを理解するための背景として、読者はインターネットアーキテクチャボードの文書に「何が成功したプロトコルをもたらすのでしょうか」という情報をよく把握することをお勧めします。[RFC5218]および「プロトコル採用とその後の遷移の計画」[RFC8170]。
Although these two documents do not specifically target Path Aware networking protocols, they are helpful resources for readers seeking to improve their understanding of considerations for successful adoption and deployment of any protocol. For example, the basic success factors described in Section 2.1 of [RFC5218] are helpful for readers of this document.
これら2つの文書は特にパス対応ネットワークプロトコルをターゲットにしていませんが、任意のプロトコルの採用と展開の成功と展開のための考慮事項の理解の向上を求めているリーダーのための役立つリソースです。たとえば、[RFC5218]のセクション2.1に記載されている基本的な成功要因は、この文書の読者に役立ちます。
Because there is an economic aspect to decisions about deployment, the IAB Workshop on Internet Technology Adoption and Transition [ITAT] report [RFC7305] also provides food for thought.
展開についての決定には経済的な側面があるため、インターネット技術採用に関するIABワークショップとトランジション[RFC7305]も、思考のための食べ物を提供しています。
Several of the Lessons Learned in Section 4 reflect considerations described in [RFC5218], [RFC7305], and [RFC8170].
セクション4で学んだ教訓は、[RFC5218]、[RFC7305]、[RFC8170]に記載されている考慮事項を反映しています。
The terms "node" and "element" in this document have the meaning defined in [PANRG-PATH-PROPERTIES].
この文書の「ノード」および「要素」という用語は、[Panrg-Path-Properties]で定義されている意味を持ちます。
This document grew out of contributions by various IETF participants with experience with one or more Path Aware techniques.
この文書は、1つ以上のパス対応技術を経験した様々なIETF参加者による貢献から成長しました。
There are many things that could be said about the Path Aware techniques that have been developed. For the purposes of this document, contributors were requested to provide
開発されたパス対応技術について言われることができることがたくさんあります。この文書の目的のために、貢献者は提供するように要求されました
* the name of a technique, including an abbreviation if one was used.
* 使用されていれば、略語を含むテクニックの名前。
* if available, a long-term pointer to the best reference describing the technique.
* 利用可能であれば、この技術を記述する最良の参照への長期的なポインタ。
* a short description of the problem the technique was intended to solve.
* この技術の簡単な説明は解決することを意図していました。
* a short description of the reasons why the technique wasn't adopted.
* 技術が採用されなかった理由の簡単な説明。
* a short statement of the lessons that researchers can learn from our experience with this technique.
* 研究者がこの技術での経験から学ぶことができる授業の短い声明。
The initial scope for this document was roughly "What mistakes have we made in the decade prior to [PANRG-99], that we shouldn't make again?" Some of the contributions in Section 6 predate the initial scope. The earliest Path Aware technique referred to in Section 6 is [IEN-119], which was published in the late 1970s; see Section 6.1. Given that the networking ecosystem has evolved continuously, it seems reasonable to consider how to apply these lessons.
この文書の最初の範囲はおおよそ「私たちはPanrg-99の前に10年前に何十年もの間に作ったのですか？」セクション6の貢献のいくつかは最初の範囲を述べています。セクション6で参照されている最も初期のパス対応手法は、1970年代後半に発行された[IEN-119]です。セクション6.1を参照してください。ネットワーキングエコシステムが継続的に進化したことを考えると、これらのレッスンの適用方法を検討するのは合理的です。
The PANRG reviewed the Lessons Learned (Section 4) contained in the May 23, 2019 draft version of this document at IETF 105 [PANRG-105-Min] and carried out additional discussion at IETF 106 [PANRG-106-Min]. Table 1 provides the "sense of the room" about each lesson after those discussions. The intention was to capture whether a specific lesson seems to be
PANRGは、2019年5月23日のこの文書のドラフト版であるIETF 105 [Panrg-105-Min]に含まれており、IETF 106 [Panrg-106-min]で追加の議論を行ったレッスンを検討しました。表1は、これらの議論の後の各レッスンについての「部屋のセンス」を提供します。意図は、特定のレッスンがあるように思われるかどうかを捉えることでした。
* "Invariant" - well-understood and is likely to be applicable for any proposed Path Aware networking solution.
* 「不変」 - よく理解されており、提案されたパス対応ネットワーキングソリューションに適用可能である。
* "Variable" - has impeded deployment in the past but might not be applicable in a specific technique. Engineering analysis to understand whether the lesson is applicable is prudent.
* 「可変」 - 過去に展開を妨げてきましたが、特定の技術では適用できない場合があります。エンジニアリング分析レッスンが適用可能かどうかを理解することは慎重です。
* "Not Now" - a characteristic that tends to turn up a minefield full of dragons. Prudent network engineers will wish to avoid gambling on a technique that relies on this, until something significant changes.
* 「今ではない」 - ドラゴンでいっぱいの鉱山フィールドを上げる傾向がある特徴。慎重なネットワークエンジニアは、これに依存する技術でギャンブルを避け、大きな変化があるまで求めていきます。
Section 6.9 on Explicit Congestion Notification (ECN) was added during the review and approval process, based on a question from Martin Duke. Section 6.9, as contained in the March 8, 2021 draft version of this document, was discussed at [PANRG-110] and is summarized in Section 4.13, describing a new Lesson Learned.
明示的輻輳通知（ECN）の第6.9項は、マーティンデュークからの質問に基づいて、レビューおよび承認プロセス中に追加されました。この文書の2021年3月8日のドラフト版で含まれているように、セクション6.9は[Panrg-110]で議論され、4.13節にまとめられ、学習された新規教訓について説明します。
+=====================================================+===========+
| Lesson | Category |
+=====================================================+===========+
| Justifying Deployment (Section 4.1) | Invariant |
+-----------------------------------------------------+-----------+
| Providing Benefits for Early Adopters (Section 4.2) | Invariant |
+-----------------------------------------------------+-----------+
| Providing Benefits during Partial Deployment | Invariant |
| (Section 4.3) | |
+-----------------------------------------------------+-----------+
| Outperforming End-to-End Protocol Mechanisms | Variable |
| (Section 4.4) | |
+-----------------------------------------------------+-----------+
| Paying for Path Aware Techniques (Section 4.5) | Invariant |
+-----------------------------------------------------+-----------+
| Impact on Operational Practices (Section 4.6) | Invariant |
+-----------------------------------------------------+-----------+
| Per-Connection State (Section 4.7) | Variable |
+-----------------------------------------------------+-----------+
| Keeping Traffic on Fast Paths (Section 4.8) | Variable |
+-----------------------------------------------------+-----------+
| Endpoints Trusting Intermediate Nodes (Section 4.9) | Not Now |
+-----------------------------------------------------+-----------+
| Intermediate Nodes Trusting Endpoints | Not Now |
| (Section 4.10) | |
+-----------------------------------------------------+-----------+
| Reacting to Distant Signals (Section 4.11) | Variable |
+-----------------------------------------------------+-----------+
| Support in Endpoint Protocol Stacks (Section 4.12) | Variable |
+-----------------------------------------------------+-----------+
| Planning for Failure (Section 4.13) | Invariant |
+-----------------------------------------------------+-----------+
Table 1
表1
"Justifying Deployment", "Providing Benefits for Early Adopters", "Paying for Path Aware Techniques", "Impact on Operational Practices", and "Planning for Failure" were considered to be Invariant -- the sense of the room was that these would always be considerations for any proposed Path Aware technique.
「展開」、「早期採用者にとっての利益の提供」、「経路対応技術への支払い」、「運用慣行への影響」、および「失敗の計画」は不変であると考えられていました - 部屋の感覚はこれらがあるということです。提案されたパス対応技術については常に考慮してください。
"Providing Benefits during Partial Deployment" was added after IETF 105, during Research Group Last Call, and is also considered to be Invariant.
リサーチグループの最後の呼び出し中に、IETF 105の後に「部分的な展開中に利点を提供する」が追加され、不変と見なされます。
For "Outperforming End-to-End Protocol Mechanisms", there is a trade-off between improved performance from Path Aware techniques and additional complexity required by some Path Aware techniques.
「優先的なエンドツーエンドプロトコルメカニズム」の場合、パス認識技術からの改善されたパフォーマンスといくつかの経路認識技術によって必要とされる追加の複雑さとの間にトレードオフがある。
* For example, if you can obtain the same understanding of path characteristics from measurements obtained over a few more round trips, endpoint implementers are unlikely to be eager to add complexity, and many attributes can be measured from an endpoint, without assistance from intermediate nodes.
* たとえば、もう少し往復にわたって得られた測定値からのパス特性の同じ理解を得ることができれば、エンドポイントの実装者は複雑さを追加することが熱心である可能性は低くなり、中間ノードからの援助なしにエンドポイントから測定することができます。
For "Per-Connection State", the key questions discussed in the Research Group were "how much state" and "where state is maintained".
「接続ごとの状態」については、研究グループで議論されている主な質問は「様子」と「状態が維持されている」という「どのくらいの状態」であった。
* Integrated Services (IntServ) (Section 6.2) required state at every participating intermediate node for every connection between two endpoints. As the Internet ecosystem has evolved, carrying many connections in a tunnel that appears to intermediate nodes as a single connection has become more common, so that additional end-to-end connections don't add additional state to intermediate nodes between tunnel endpoints. If these tunnels are encrypted, intermediate nodes between tunnel endpoints can't distinguish between connections, even if that were desirable.
* 2つのエンドポイント間の接続ごとに、すべての参加中間ノードで統合サービス（intServ）（6.2項）必要な状態。インターネットの生態系が進化したので、単一の接続として中間ノードに表示されるトンネル内の多くの接続を持ち運ぶことで、追加のエンドツーエンド接続はトンネルエンドポイント間の中間ノードに追加の状態を追加しません。これらのトンネルが暗号化されている場合、トンネルエンドポイント間の中間ノードは接続を区別することはできません。
For "Keeping Traffic on Fast Paths", we noted that this was true for many platforms, but not for all.
「高速道路上のトラフィックを維持する」の場合は、これが多くのプラットフォームに対して当てはまりましたが、すべてのプラットフォームには当てはまりました。
* For backbone routers, this is likely an Invariant, but for platforms that rely more on general-purpose computers to make forwarding decisions, this may not be a fatal flaw for Path Aware techniques.
* バックボーンルータの場合、これは不変であるが、汎用のコンピュータに頼るプラットフォームの場合、これはパス対応技術の致命的な欠陥ではない可能性があります。
For "Endpoints Trusting Intermediate Nodes" and "Intermediate Nodes Trusting Endpoints", these lessons point to the broader need to revisit the Internet Threat Model.
「中間ノードの信頼性のあるエンドポイント」および「中間ノードの信頼性エンドポイント」の場合、これらのレッスンはインターネットの脅威モデルを再検討する必要があります。
* We noted with relief that discussions about this were already underway in the IETF community at IETF 105 (see the Security Area Open Meeting minutes [SAAG-105-Min] for discussion of [INTERNET-THREAT-MODEL] and [FARRELL-ETM]), and the Internet Architecture Board has created a mailing list for continued discussions [model-t], but we recognize that there are Path Aware networking aspects of this effort, requiring research.
* これに関する議論は、IETF 105のIETFコミュニティではすでに進行中であることを救済しました（インターネット脅威モデルづくりの議論のためのセキュリティエリアの開いた会議議事録[SAAG-105 - 分]と[Farrell-ETM]）。そしてインターネットアーキテクチャボードは継続的なディスカッション[MODEL-T]のためのメーリングリストを作成しましたが、この取り組みのネットワーキングの面があることを認識し、研究が必要です。
For "Reacting to Distant Signals", we noted that not all attributes are equal.
「遠方の信号への反応」については、すべての属性が等しいわけではないことに注意してください。
* If an attribute is stable over an extended period of time, is difficult to observe via end-to-end mechanisms, and is valuable, Path Aware techniques that rely on that attribute to provide a significant benefit become more attractive.
* 属性が長期間にわたって安定している場合は、エンドツーエンドのメカニズムを介して観察することは困難であり、価値がある、その属性に依存して重要な利益をもたらすために依存するPATH対応技術がより魅力的になる。
* Analysis to help identify attributes that are useful enough to justify deployment of Path Aware techniques that make use of those attributes would be helpful.
* これらの属性を利用するパス対応テクニックの展開を正当化するのに十分便利な属性を識別するための分析は役に立ちます。
For "Support in Endpoint Protocol Stacks", we noted that Path Aware applications must be able to identify and communicate requirements about path characteristics.
「エンドポイントプロトコルスタックでのサポート」の場合、パス対応アプリケーションはパス特性に関する要件を識別して通信できる必要があるとわかった。
* The de facto sockets API has no way of signaling application expectations for the network path to the protocol stack.
* Facketo Sockets APIは、プロトコルスタックへのネットワークパスに対するアプリケーションの期待をシグナリングする方法はありません。
This section summarizes the Lessons Learned from the contributed subsections in Section 6.
このセクションでは、セクション6の貢献されたサブセクションから学んだ教訓をまとめたものです。
Each Lesson Learned is tagged with one or more contributions that encountered this obstacle as a significant impediment to deployment. Other contributed techniques may have also encountered this obstacle, but this obstacle may not have been the biggest impediment to deployment for those techniques.
学習された各レッスンは、この障害が展開にかなりの障害として発生した1つ以上の貢献でタグ付けされています。他の寄稿された技術もこの障害物も遭遇するかもしれないが、この障害はそれらの技術のための展開の最大の障害ではなかったかもしれない。
It is useful to notice that sometimes an obstacle might impede deployment, while at other times, the same obstacle might prevent adoption and deployment entirely. The Research Group discussed distinguishing between obstacles that impede and obstacles that prevent, but it appears that the boundary between "impede" and "prevent" can shift over time -- some of the Lessons Learned are based on both a) Path Aware techniques that were not deployed and b) Path Aware techniques that were deployed but were not deployed widely or quickly. See Sections 6.6 and 6.6.3 for examples of this shifting boundary.
時には障害物が展開を妨げる可能性があることに気付くのは便利ですが、同じ障害物が採用と展開を完全に防止する可能性があります。研究グループは、妨害された障害物と障害物との間で区別したが、「インプレス」と「防止」の境界は経時的にシフトすることができると思われる - 学んだ教訓は両方の経路対応技術に基づいていると思われる。展開されていないとB）展開されたが広くまたは迅速に展開されていないPATH対応技術。このシフト境界の例については、6.6および6.6.3を参照してください。
The benefit of Path Awareness must be great enough to justify making changes in an operational network. The colloquial U.S. American English expression, "If it ain't broke, don't fix it" is a "best current practice" on today's Internet. (See Sections 6.3, 6.4, 6.5, and 6.9, in addition to [RFC5218].)
経路認識の利点は、運用ネットワークの変更を行うのに十分なほど大きくなければなりません。顧問米国アメリカ英語表現「それが壊れていない場合は、それを修正しないでください」は今日のインターネット上の「最高の現在の練習」です。（[RFC5218]に加えて、6.3,6.4,6.5、および6.9を参照してください。）
Providing benefits for early adopters can be key -- if everyone must deploy a technique in order for the technique to provide benefits, or even to work at all, the technique is unlikely to be adopted widely or quickly. (See Sections 6.2 and 6.3, in addition to [RFC5218].)
早期採用者にとっての利点を提供することは重要です。この技術が利益を提供するために、あるいは全く働くためにテクニックを展開しなければならない場合、この技術は広くまたは迅速に採用される可能性が低いです。（[RFC5218]に加えて、6.2と6.3の節を参照してください。）
Some proposals require that all path elements along the full length of the path must be upgraded to support a new technique, before any benefits can be seen. This is likely to require coordination between operators who control a subset of path elements, and between operators and end users if endpoint upgrades are required. If a technique provides benefits when only a part of the path has been upgraded, this is likely to encourage adoption and deployment. (See Sections 6.2, 6.3, and 6.9, in addition to [RFC5218].)
いくつかの提案は、利点が見られる前に、経路の全長に沿ったすべての経路要素を新しい技術をサポートするようにアップグレードされなければならないことを要求する。これは、パス要素のサブセットを制御する演算子、およびエンドポイントのアップグレードが必要な場合は、オペレータとエンドユーザーの間の調整を必要とする可能性があります。パスの一部のみがアップグレードされたときに手法が利点がある場合、これは採用と展開を促進する可能性があります。（[RFC5218]に加えて、6.2,6.3,6.9の節を参照してください。）
Adaptive end-to-end protocol mechanisms may respond to feedback quickly enough that the additional realizable benefit from a new Path Aware mechanism that tries to manipulate nodes along a path, or observe the attributes of nodes along a path, may be much smaller than anticipated. (See Sections 6.3 and 6.5.)
適応型エンドツーエンドプロトコルメカニズムは、パスに沿ってノードを操作しようとする新しいパス対応メカニズムからの追加の実現可能なメカニズムから、またはパスに沿ってノードの属性を観察することが予想よりもはるかに小さいかもしれないということを十分に速やかにフィードバックに応えるかもしれません。。（6.3と6.5の節を参照してください。）
"Follow the money." If operators can't charge for a Path Aware technique to recover the costs of deploying it, the benefits to the operator must be really significant. Corollary: if operators charge for a Path Aware technique, the benefits to users of that Path Aware technique must be significant enough to justify the cost. (See Sections 6.1, 6.2, 6.5, and 6.9.)
「お金に従ってください」展開するコストを回復するために経路対応技術のためにオペレータが課金できない場合、オペレータへの利点は本当に重要でなければなりません。COROLALLE：オペレータがパス対応技術に請求された場合、そのパス対応技術のユーザーへの利点は、コストを正当化するのに十分に大きくなければなりません。（6.1,6.2,6.5、および6.9を参照）。
The impact of a Path Aware technique requiring changes to operational practices can affect how quickly or widely a promising technique is deployed. The impacts of these changes may make deployment more likely, but they often discourage deployment. (See Section 6.6, including Section 6.6.3.)
運用慣行への変更を必要とする経路対応技術の影響は、有望な技術がどの程度迅速か広く展開されるかに影響を与える可能性がある。これらの変更の影響は、展開により可能性が高いが、展開を妨げることがよくあります。（6.6.3項を含む6.6項を参照）
Per-connection state in intermediate nodes has been an impediment to adoption and deployment in the past, because of added cost and complexity. Often, similar benefits can be achieved with much less finely grained state. This is especially true as we move from the edge of the network, further into the routing core. (See Sections 6.1 and 6.2.)
中間ノードの接続ごとの状態は、コストと複雑さを追加するため、過去の採用と展開に障害がありました。多くの場合、ほぼ粒状の状態で同様の利点を達成することができます。これは、ネットワークの端から、さらにルーティングコアに移動するため、特に当てはまります。（6.1と6.2の節を参照してください。）
Many modern platforms, especially high-end routers, have been designed with hardware that can make simple per-packet forwarding decisions ("fast paths") but have not been designed to make heavy use of in-band mechanisms such as IPv4 and IPv6 Router Alert Options (RAOs) that require more processing to make forwarding decisions. Packets carrying in-band mechanisms are diverted to other processors in the router with much lower packet-processing rates. Operators can be reluctant to deploy techniques that rely heavily on in-band mechanisms because they may significantly reduce packet throughput. (See Section 6.7.)
多くの現代のプラットフォーム、特にハイエンドルータは、単純なパケットごとの転送決定を行うことができるハードウェアで設計されていますが、IPv4やIPv6ルータなどのインバンドメカニズムを大量に使用するように設計されていません。転送の決定を下すためのより多くの処理が必要な警告オプション（RAO）。インバンドメカニズムを搬送するパケットは、より低いパケット処理レートを使用して、ルータ内の他のプロセッサに転送されます。オペレータは、パケットスループットを大幅に削減できるため、インバンドメカニズムに大きく依存するテクニックを展開することができます。（6.7節を参照してください。）
If intermediate nodes along the path can't be trusted, it's unlikely that endpoints will rely on signals from intermediate nodes to drive changes to endpoint behaviors. We note that "trust" is not binary -- one low level of trust applies when a node receiving a message can confirm that the sender of the message has visibility of the packets on the path it is seeking to control [RFC8085] (e.g., an ICMP Destination Unreachable message [RFC0792] that includes the Internet Header + 64 bits of Original Data Datagram payload from the source). A higher level of trust can arise when an endpoint has established a short-term, or even long-term, trust relationship with network nodes. (See Sections 6.4 and 6.5.)
パスに沿った中間ノードが信頼できない場合は、エンドポイントが中間ノードからの信号に依存してエンドポイントの動作を推進することはほとんどありません。「信頼」はバイナリではないことに注意しています - メッセージを受信したノードがメッセージの送信者がパケットの可視性を持つことを確認することができます。ソースからの元のデータデータグラムペイロードのインターネットヘッダー64ビットを含むICMP宛先到達不能メッセージ[RFC0792]。エンドポイントがネットワークノードとの短期間、または長期的な信頼関係を確立したときに、より高いレベルの信頼が発生する可能性があります。（6.4と6.5の節を参照してください。）
If the endpoints do not have any trust relationship with the intermediate nodes along a path, operators have been reluctant to deploy techniques that rely on endpoints sending unauthenticated control signals to routers. (See Sections 6.2 and 6.7.) (We also note that this still remains a factor hindering deployment of Diffserv.)
エンドポイントがパスに沿って中間ノードとの信頼関係を持たない場合、演算子は、未認証された制御信号をルータに送信するエンドポイントに依存するテクニックを展開することに消極的でした。（6.2と6.7の節を参照してください。）（これは依然としてDiffServの展開の妨げ降下率のままであることに注意してください。）
Because the Internet is a distributed system, if the distance that information from distant path elements travels to a Path Aware host is sufficiently large, the information may no longer accurately represent the state and situation at the distant host or elements along the path when it is received locally. In this case, the benefit that a Path Aware technique provides will be inconsistent and may not always be beneficial. (See Section 6.3.)
インターネットは分散システムであるため、遠方パス要素からの情報がパス対応ホストに通過する距離が十分に大きい場合、その情報は、そのパスに沿って遠方のホストまたは要素の状態と状況を正確に表すことができなくなる可能性がある。ローカルに受信しました。この場合、経路対応技術が提供するという利点は矛盾し、常に有益ではないかもしれない。（6.3項を参照）
Just because a protocol stack provides a new feature/signal does not mean that applications will use the feature/signal. Protocol stacks may not know how to effectively utilize Path Aware techniques, because the protocol stack may require information from applications to permit the technique to work effectively, but applications may not a priori know that information. Even if the application does know that information, the de facto sockets API has no way of signaling application expectations for the network path to the protocol stack. In order for applications to provide these expectations to protocol stacks, we need an API that signals more than the packets to be sent. (See Sections 6.1 and 6.2.)
プロトコルスタックが新しい機能/信号を提供するためだけで、アプリケーションが機能/信号を使用することを意味するわけではありません。プロトコルスタックは、プロトコルスタックがアプリケーションからの情報を効果的に機能させることを許可するためにアプリケーションからの情報を必要とする可能性があるため、PATH対応テクニックを効果的に利用する方法がわからないが、アプリケーションはその情報を知らない場合がある。アプリケーションがその情報を知っていても、DE FACTO Sockets APIは、プロトコルスタックへのネットワークパスに対するアプリケーションの期待をシグナリングする方法はありません。アプリケーションがプロトコルスタックにこれらの期待を提供するためには、送信されるパケットよりも多くの信号を通知するAPIが必要です。（6.1と6.2の節を参照してください。）
If early implementers discover severe problems with a new feature, that feature is likely to be disabled, and convincing implementers to re-enable that feature can be very difficult and can require years or decades. In addition to testing, partial deployment for a subset of users, implementing instrumentation that will detect degraded user experience, and even "failback" to a previous version or "failover" to an entirely different implementation are likely to be helpful. (See Section 6.9.)
早期実装者が新しい機能に関する深刻な問題を発見した場合、その機能は無効にされる可能性があり、その機能が非常に困難であり、何十年も必要となる可能性があることを再度有効にすることができます。テストに加えて、ユーザーのサブセットの部分的な展開、劣化したユーザーエクスペリエンスを検出し、以前のバージョンまたは「フェイルオーバー」または「フェイルオーバー」でさえ、完全に異なる実装になるようなインスツルメンテーションを実装することは、役立ちます。（6.9を参照）
By its nature, this document has been retrospective. In addition to considering how the Lessons Learned to date apply to current and future Path Aware networking proposals, it's also worth considering whether there is deeper investigation left to do.
その性質上、この文書は遡及的です。今日までに学んだ教訓が現在および将来の経路に適用される方法を考慮することに加えて、それはやるべきより深い調査があるかどうかを考慮する価値があります。
* We note that this work was based on contributions from experts on various Path Aware techniques, and all of the contributed techniques involved unicast protocols. We didn't consider how these lessons might apply to multicast, and, given anecdotal reports at the IETF 109 Media Operations (MOPS) Working Group meeting of IP multicast offerings within data centers at one or more cloud providers [MOPS-109-Min], it might be useful to think about Path Awareness in multicast, before we have a history of unsuccessful deployments to document.
* この作品は、さまざまなパス対応技術に関する専門家からの貢献に基づいていました。そして、すべての貢献された技術はユニキャストプロトコルを含みました。これらのレッスンがマルチキャストにどのように適用されるか、およびIETF 109メディアオペレーションズ（MOPS）のANECDOTALレポートがある場合は、1つまたは複数のクラウドプロバイダーでのデータセンター内のIPマルチキャストオファリングのワーキンググループ会議[MOPS-109-MIN]文書に失敗した展開の履歴がある前に、マルチキャストのパスの認識について考えるのは便利かもしれません。
* The question of whether a mechanism supports admission control, based on either endpoints or applications, is associated with Path Awareness. One of the motivations of IntServ and a number of other architectures (e.g., Deterministic Networking [RFC8655]) is the ability to "say no" to an application based on resource availability on a path, before the application tries to inject traffic onto that path and discovers the path does not have the capacity to sustain enough utility to meet the application's minimum needs. The question of whether admission control is needed comes up repeatedly, but we have learned a few useful lessons that, while covered implicitly in some of the Lessons Learned provided in this document, might be explained explicitly:
* エンドポイントまたはアプリケーションのいずれかに基づいて、メカニズムがアドミッションコントロールをサポートしているかどうかという問題は、パス認識に関連付けられています。INTSERVの動機と他の多くのアーキテクチャ（例：確定ネットワーキング[RFC8655]）は、アプリケーションがそのパスにトラフィックを挿入しようとする前に、パス上のリソースの可用性に基づいてアプリケーションに「いいえ」と言うことができます。パスを発見しても、アプリケーションの最低ニーズを満たすのに十分なユーティリティをサステリングする能力がありません。入学管理が必要かどうかという問題が繰り返し表示されますが、この文書で提供された学習されたレッスンのいくつかで暗黙のうちにカバーされているのは、明示的に説明される可能性があります。
- We have gained a lot of experience with application-based adaptation since the days where applications just injected traffic inelastically into the network. Such adaptations seem to work well enough that admission control is of less value to these applications.
- アプリケーションが実質的にネットワークにトラフィックを注入したばかりの日以降、アプリケーションベースの適応に関する経験がたくさんありました。そのような適応は、入場管理がこれらのアプリケーションにとってより少ない価値が低いという十分に機能するように思われます。
- There are end-to-end measurement techniques that can steer traffic at the application layer (Content Delivery Networks (CDNs), multi-CDNs like Conviva [Conviva], etc.).
- アプリケーション層でトラフィックを操縦することができるエンドツーエンドの測定技術（Content Delivery Networks（CDN）、Conviva [Conviva]などのマルチCDN）。
- We noted in Section 4.12 that applications often don't know how to utilize Path Aware techniques. This includes not knowing enough about their admission control threshold to be able to ask accurately for the resources they need, whether this is because the application itself doesn't know or because the application has no way to signal its expectations to the underlying protocol stack. To date, attempts to help them haven't gotten anywhere (e.g., the multiple-TSPEC (Traffic Specification) additions to RSVP to attempt to mirror codec selection by applications [INTSERV-MULTIPLE-TSPEC] expired in 2013).
- 私たちはセクション4.12で認識されていますが、アプリケーションはしばしばパス対応テクニックの利用方法がわからないことがわからない。これには、アプリケーション自体が知られていないため、またはアプリケーションが基礎となるプロトコルスタックへのその期待を知らせる方法がないため、必要なリソースに対して正確に尋ねることができるように、入場管理しきい値について十分なことを認識していません。今日まで、2013年には、アプリケーションによるコーデック選択をミラー化しようとするために、RSVPへのCodec Selectionをミラー化しようとするために、それらがどこにも取得されていない（例えば、複数のTSPEC（トラフィック仕様）。
* We note that this work took the then-current IP network architecture as given, at least at the time each technique was proposed. It might be useful to consider aspects of the now-current IP network architecture that ease, or impede, Path Aware techniques. For example, there is limited ability in IP to constrain bidirectional paths to be symmetric, and information-centric networking protocols such as Named Data Networking (NDN) and Content-Centric Networking (CCNx) [RFC8793] must force bidirectional path symmetry using protocol-specific mechanisms.
* この作業は、少なくとも各技術が提案された時点で、この作業では最新のIPネットワークアーキテクチャを与えられたところに取りました。現在のIPネットワークアーキテクチャの側面を簡単にする、または妨害し、PATH対応技術を考慮すると便利な場合があります。たとえば、双方向パスを対称にするためのIPで制限された能力があり、名前付きデータネットワーキング（NDN）やコンテンツ中心ネットワーキング（CCNX）[RFC8793]などの情報中心のネットワーキングプロトコル（RFC8793]は、プロトコルを使用して双方向パス対称を強制しなければなりません。特定のメカニズム
Contributions on these Path Aware techniques were analyzed to arrive at the Lessons Learned captured in Section 4.
これらの経路に関する寄付は、第4節で捕獲された学習された教訓に到達するために分析された。
Our expectation is that most readers will not need to read through this section carefully, but we wanted to record these hard-fought lessons as a service to others who may revisit this document, so they'll have the details close at hand.
私たちの期待は、ほとんどの読者はこのセクションを慎重に読む必要がないということですが、この文書を再検討できる他の人へのサービスとしてこれらの厳しい教訓を録音したいと思いました。
The suggested references for Stream Transport are:
ストリームトランスポートの提案された参照は次のとおりです。
* "ST - A Proposed Internet Stream Protocol" [IEN-119]
* 「ST - 提案されたインターネットストリームプロトコル」[IEN-119]
* "Experimental Internet Stream Protocol: Version 2 (ST-II)" [RFC1190]
* 「実験的なインターネットストリームプロトコル：バージョン2（ST-II）」[RFC1190]
* "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+" [RFC1819]
* "インターネットストリームプロトコルバージョン2（ST2）プロトコル仕様 - バージョンST2" [RFC1819]
The first version of Stream Transport, ST [IEN-119], was published in the late 1970s and was implemented and deployed on the ARPANET at small scale. It was used throughout the 1980s for experimental transmission of voice, video, and distributed simulation.
Stream Transport St [IEN-119]の最初のバージョンは、1970年代後半に発行され、アルパニットに小規模で実行されて展開されました。それは、音声、ビデオ、および分散シミュレーションの実験的な伝送のために1980年代に使用されました。
The second version of the ST specification (ST2) [RFC1190] [RFC1819] was an experimental connection-oriented internetworking protocol that operated at the same layer as connectionless IP. ST2 packets could be distinguished by their IP header version numbers (IP, at that time, used version number 4, while ST2 used version number 5).
ST仕様の第2版（ST2）[RFC1190] [RFC1819]は、コネクションレスIPと同じ層で動作する実験的な接続指向のインターネットワーキングプロトコルであった。ST2パケットは、IPヘッダのバージョン番号（その時点で、version Number 4）によって区別できます（ST2はバージョン番号5を使用します）。
ST2 used a control plane layered over IP to select routes and reserve capacity for real-time streams across a network path, based on a flow specification communicated by a separate protocol. The flow specification could be associated with QoS state in routers, producing an experimental resource reservation protocol. This allowed ST2 routers along a path to offer end-to-end guarantees, primarily to satisfy the QoS requirements for real-time services over the Internet.
ST2は、別のプロトコルによって通信されたフロー仕様に基づいて、ネットワーク経路を介してリアルタイムストリームのルートおよびリアルタイムストリームのためのリアルタイムストリームのためのルートおよび予約容量を選択するための制御プレーンを使用した。フロー仕様は、ルータ内のQoS状態に関連付けられ、実験的なリソース予約プロトコルを生成することができます。これにより、エンドツーエンド保証を提供するためのST2ルータが、主にインターネット上のリアルタイムサービスのQoS要件を満たすために、エンドツーエンド保証を提供しました。
Although implemented in a range of equipment, ST2 was not widely used after completion of the experiments. It did not offer the scalability and fate-sharing properties that have come to be desired by the Internet community.
様々な機器に実装されていますが、実験の完了後にST2は広く使用されていませんでした。インターネットコミュニティに望まれるようになったスケーラビリティと運命共有のプロパティを提供しませんでした。
The ST2 protocol is no longer in use.
ST2プロトコルは使用されなくなりました。
As time passed, the trade-off between router processing and link capacity changed. Links became faster, and the cost of router processing became comparatively more expensive.
時間が経過すると、ルータの処理とリンク容量の間のトレードオフが変更されました。リンクは速くなり、ルータ処理のコストは比較的高価になりました。
The ST2 control protocol used "hard state" -- once a route was established, and resources were reserved, routes and resources existed until they were explicitly released via signaling. A soft-state approach was thought superior to this hard-state approach and led to development of the IntServ model described in Section 6.2.
ST2制御プロトコルは「ハード状態」を使用した - 経路が確立された後、リソースが予約されていた、ルートとリソースはシグナリングを介して明示的に解放されるまで存在しました。ソフトステートアプローチは、このハード状態アプローチよりも優れており、セクション6.2に記載されているINTSERVモデルの開発をもたらしました。
The suggested references for IntServ are:
INTSERVの推奨参照は次のとおりです。
* "Integrated Services in the Internet Architecture: an Overview" [RFC1633]
* 「インターネットアーキテクチャの統合サービス：概要」[RFC1633]
* "Specification of the Controlled-Load Network Element Service" [RFC2211]
* 「制御ロードネットワーク要素サービスの指定」[RFC2211]
* "Specification of Guaranteed Quality of Service" [RFC2212]
* "保証されたサービス品質の仕様" [RFC2212]
* "General Characterization Parameters for Integrated Service Network Elements" [RFC2215]
* "統合サービスネットワーク要素の一般的な特性パラメータ" [RFC2215]
* "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification" [RFC2205]
* "リソース予約プロトコル（RSVP） - バージョン1機能仕様" [RFC2205]
In 1994, when the IntServ architecture document [RFC1633] was published, real-time traffic was first appearing on the Internet. At that time, bandwidth was still a scarce commodity. Internet Service Providers built networks over DS3 (45 Mbps) infrastructure, and sub-rate (< 1 Mbps) access was common. Therefore, the IETF anticipated a need for a fine-grained QoS mechanism.
1994年に、IntServアーキテクチャ文書[RFC1633]が公開されている場合、リアルタイムのトラフィックが最初にインターネットに表示されました。当時、帯域幅はまだ乏しい商品でした。インターネットサービスプロバイダDS3（45 Mbps）インフラストラクチャを介してネットワークを構築し、サブレート（<1 Mbps）アクセスが一般的でした。したがって、IETFは微細粒QoS機構の必要性を予想していた。
In the IntServ architecture, some applications can require service guarantees. Therefore, those applications use RSVP [RFC2205] to signal QoS reservations across network paths. Every router in the network that participates in IntServ maintains per-flow soft state to a) perform call admission control and b) deliver guaranteed service.
IntServアーキテクチャでは、一部のアプリケーションでサービス保証が必要になることがあります。したがって、これらのアプリケーションはRSVP [RFC2205]を使用してネットワークパス間でQoSの予約をシグナリングします。INTSERVに参加しているネットワーク内のすべてのルーターは、フローのソフト状態をA）コールアドミッションコントロールを実行し、B）保証サービスを提供します。
Applications use Flow Specifications (Flow Specs, or FLOWSPECs) [RFC2210] to describe the traffic that they emit. RSVP reserves capacity for traffic on a per-Flow-Spec basis.
アプリケーションは、発信されたトラフィックを説明するために、フロー仕様（フロースペック、またはフローペクス）[RFC2210]を使用します。RSVPは、フロースペックベースでトラフィックの容量を予約します。
Although IntServ has been used in enterprise and government networks, IntServ was never widely deployed on the Internet because of its cost. The following factors contributed to operational cost:
INTSERVは企業および政府のネットワークで使用されてきましたが、そのコストのため、IntServはインターネット上で広く展開されていませんでした。以下の要因は運用コストに貢献しました。
* IntServ must be deployed on every router that is on a path where IntServ is to be used. Although it is possible to include a router that does not participate in IntServ along the path being controlled, if that router is likely to become a bottleneck, IntServ cannot be used to avoid that bottleneck along the path.
* INTSERVは、INTSERVを使用するパス上にあるすべてのルーターにデプロイされている必要があります。制御されているパスに沿ってINTSERVに参加しないルータを含めることは可能ですが、そのルータがボトルネックになる可能性がある場合は、そのパスに沿ってそのボトルネックを回避するためにintServを使用できません。
* IntServ maintained per-flow state.
* INTSERVはフローごとの状態に維持されていました。
As IntServ was being discussed, the following occurred:
IntServが議論されていたので、次のようになりました。
* For many expected uses, it became more cost effective to solve the QoS problem by adding bandwidth. Between 1994 and 2000, Internet Service Providers upgraded their infrastructures from DS3 (45 Mbps) to OC-48 (2.4 Gbps). This meant that even if an endpoint was using IntServ in an IntServ-enabled network, its requests would rarely, if ever, be denied, so endpoints and Internet Service Providers had little reason to enable IntServ.
* 多くの予想される用途にとって、帯域幅を追加することによってQoS問題を解決するのに効果的になりました。1994年から2000年の間に、インターネットサービスプロバイダーは、インフラストラクチャをDS3（45 Mbps）からOC-48（2.4 Gbps）にアップグレードしました。これは、INTSERV対応ネットワークでINTSERVを使用していたとしても、その要求は拒否された場合、エンドポイントとインターネットサービスプロバイダがINTSERVを有効にする理由はほとんどありません。
* Diffserv [RFC2475] offered a more cost-effective, albeit less fine-grained, solution to the QoS problem.
* DIFFSERV [RFC2475]は、QoS問題に対する微細な粒度の低い、より費用対効果の高いものを提供しました。
The following lessons were learned:
次のレッスンが学ばれました。
* Any mechanism that requires every participating on-path router to maintain per-flow state is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.
* 特徴を提供するための追加費用をユーザから復元することができる限り、一流動状態を維持するために参加している経路経路をすべて必要とするメカニズムは、成功する可能性は低い。
* Any mechanism that requires an operator to upgrade all of its routers is not likely to succeed, unless the additional cost for offering the feature can be recovered from the user.
* そのすべてのルータをアップグレードするためにオペレータを必要とするメカニズムは、その機能を提供するための追加費用をユーザーから復旧できる限り成功する可能性があります。
In environments where IntServ has been deployed, trust relationships with endpoints are very different from trust relationships on the Internet itself. There are often clearly defined hierarchies in Service Level Agreements (SLAs) governing well-defined transport flows operating with predetermined capacity and latency requirements over paths where capacity or other attributes are constrained.
INTSERVが展開されている環境では、エンドポイントとの信頼関係はインターネット自体の信頼関係とは非常に異なります。容量または他の属性が制約されている経路にわたって所定の容量および待ち時間の要件を介して動作しているよく定義されたトランスポートフローを管理するサービスレベル契約（SLA）には、明確に定義された階層（SLA）があることが多い。
IntServ was never widely deployed to manage capacity across the Internet. However, the technique that it produced was deployed for reasons other than bandwidth management. RSVP is widely deployed as an MPLS signaling mechanism. BGP reuses the RSVP concept of Filter Specs to distribute firewall filters, although they are called "Flow Spec Component Types" in BGP [RFC5575].
インターネット全体で容量を管理するために、IntServは広く展開されませんでした。しかしながら、それが生成された技術は、帯域幅管理以外の理由で展開された。RSVPはMPLSシグナリングメカニズムとして広く展開されています。BGPは、BGP [RFC5575]の「フロースペックコンポーネントタイプ」と呼ばれます。
The suggested references for Quick-Start TCP are:
Quick-Start TCPの推奨参照は次のとおりです。
* "Quick-Start for TCP and IP" [RFC4782]
* "TCPとIPのクイックスタート" [RFC4782]
* "Determining an appropriate sending rate over an underutilized network path" [SAF07]
* 「低利用されたネットワーク経路に対する適切な送信レートの決定」[SAF07]
* "Fast Startup Internet Congestion Control for Broadband Interactive Applications" [Sch11]
* 「ブロードバンド対話型アプリケーションのための高速スタートアップインターネット輻輳制御」[SCH11]
* "Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks" [QS-SAT]
* 「双方向衛星ネットワークにおけるTCP対応率制御性能の向上」[QS-SAT]
Quick-Start is defined in an Experimental RFC [RFC4782] and is a TCP extension that leverages support from the routers on the path to determine an allowed initial sending rate for a path through the Internet, either at the start of data transfers or after idle periods. Without information about the path, a sender cannot easily determine an appropriate initial sending rate. The default TCP congestion control therefore uses the safe but time-consuming slow-start algorithm [RFC5681]. With Quick-Start, connections are allowed to use higher initial sending rates if there is significant unused bandwidth along the path and if the sender and all of the routers along the path approve the request.
クイックスタートは実験的なRFC [RFC4782]で定義されており、パス上のルータからのサポートを活用して、インターネットを介したパスの許可された初期送信レートをデータ転送の開始またはアイドル後に決定します。期間パスに関する情報がないと、送信者は適切な初期送信レートを簡単に判断できません。したがって、デフォルトのTCP輻輳制御は、安全だが時間がかかるスロースタートアルゴリズム[RFC5681]を使用します。クイックスタートでは、パスに沿って使用されていない未使用の帯域幅が大きい場合、およびパスに沿ったすべてのルータが要求を承認した場合、接続はより高い初期送信レートを使用できます。
By examining the Time To Live (TTL) field in Quick-Start packets, a sender can determine if routers on the path have approved the Quick-Start request. However, this method is unable to take into account the routers hidden by tunnels or other network nodes invisible at the IP layer.
クイックスタートパケットのLive（TTL）フィールドを調べることで、送信者はパス上のルータがクイックスタート要求を承認したかどうかを判断できます。ただし、このメソッドは、TunnelsまたはIP層では見えない他のネットワークノードによって隠されたルータを考慮に入れることができません。
The protocol also includes a nonce that provides protection against cheating routers and receivers. If the Quick-Start request is explicitly approved by all routers along the path, the TCP host can send at up to the approved rate; otherwise, TCP would use the default congestion control. Quick-Start requires modifications in the involved end systems as well as in routers. Due to the resulting deployment challenges, Quick-Start was only proposed in [RFC4782] for controlled environments.
このプロトコルには、不正行為ルータや受信者に対する保護を提供するNonceも含まれています。Quick-Startリクエストがパスに沿ってすべてのルータによって明示的に承認されている場合、TCPホストは承認されたレートで送信できます。それ以外の場合、TCPはデフォルトの輻輳制御を使用します。クイックスタートには、コントロールエンドシステムとルータと同様に変更が必要です。展開の課題の結果、Quick-Startは、管理環境の[RFC4782]で提案されています。
The Quick-Start mechanism is a lightweight, coarse-grained, in-band, network-assisted fast startup mechanism. The benefits are studied by simulation in a research paper [SAF07] that complements the protocol specification. The study confirms that Quick-Start can significantly speed up mid-sized data transfers. That paper also presents router algorithms that do not require keeping per-flow state. Later studies [Sch11] comprehensively analyze Quick-Start with a full Linux implementation and with a router fast-path prototype using a network processor. In both cases, Quick-Start could be implemented with limited additional complexity.
クイックスタートメカニズムは、軽量、粗粒状の、帯域内のネットワーク支援高速スタートアップメカニズムです。この利点は、プロトコル仕様を補完する研究論文[SAF07]のシミュレーションによって研究されています。この調査では、クイックスタートが中規模のデータ転送を大幅にスピードアップできることを確認します。その論文はまた、フローごとの状態を維持する必要がないルータアルゴリズムを提示します。後の研究[SCH11]は、フルLinuxの実装とネットワークプロセッサを使用してルータの高速パスプロトタイプを使用して、クイックスタートを包括的に分析します。どちらの場合も、Quick-Startは追加の複雑さが限られています。
However, experiments with Quick-Start in [Sch11] revealed several challenges:
しかし、[SCH11]でクイックスタートを伴う実験はいくつかの課題を明らかにしました：
* Having information from the routers along the path can reduce the risk of congestion but cannot avoid it entirely. Determining whether there is unused capacity is not trivial in actual router and host implementations. Data about available capacity visible at the IP layer may be imprecise, and due to the propagation delay, information can already be outdated when it reaches a sender. There is a trade-off between the speedup of data transfers and the risk of congestion even with Quick-Start. This could be mitigated by only allowing Quick-Start to access a proportion of the unused capacity along a path.
* 経路に沿ってルータから情報を持つことは渋滞の危険性を減らすことができますが、完全にそれを回避することはできません。未使用の容量があるかどうかを判断すると、実際のルータやホストの実装では簡単ではありません。IP層で表示可能な容量に関するデータは不正確である可能性があり、伝播遅延により、情報が送信者に到達するとすでに古くなっています。データ転送のスピードアップと迅速なスタートでも輻輳のリスクの間にトレードオフがあります。これは、迅速スタートを経路に沿って未使用容量の割合にアクセスすることを可能にすることによって軽減することができます。
* For scalable router fast-path implementations, it is important to enable parallel processing of packets, as this is a widely used method, e.g., in network processors. One challenge is synchronization of information between packets that are processed in parallel, which should be avoided as much as possible.
* スケーラブルルータの高速経路実装のためには、これが広く使用されている方法、例えばネットワークプロセッサであるので、パケットの並列処理を可能にすることが重要である。1つの課題は、並列に処理されるパケット間の情報の同期であり、できるだけ回避する必要があります。
* Only some types of application traffic can benefit from Quick-Start. Capacity needs to be requested and discovered. The discovered capacity needs to be utilized by the flow, or it implicitly becomes available for other flows. Failing to use the requested capacity may have already reduced the pool of Quick-Start capacity that was made available to other competing Quick-Start requests. The benefit is greatest when senders use this only for bulk flows and avoid sending unnecessary Quick-Start requests, e.g., for flows that only send a small amount of data. Choosing an appropriate request size requires application-internal knowledge that is not commonly expressed by the transport API. How a sender can determine the rate for an initial Quick-Start request is still a largely unsolved problem.
* Quick-Startから恩恵を受けることができるアプリケーショントラフィックの種類のみがいくつかの種類だけです。容量を要求して発見する必要があります。発見された容量はフローによって利用される必要があるか、または暗黙的に他のフローに利用可能になります。要求された容量を使用することができない可能性がある可能性があるため、他の競合したクイックスタートリクエストが利用できるようにするクイックスタート容量のプールをすでに削減できます。送信者がバルクフローに対してのみこれを使用し、不要なクイックスタート要求を送信しないように、利点は最大であり、少量のデータを送信するためのフローについては不要なクイックスタートリクエストを送信しないでください。適切な要求サイズを選択するには、トランスポートAPIによって一般的に表現されていないアプリケーション内部の知識が必要です。送信者が最初のクイックスタート要求のレートを決定できる方法は、まだほとんど未解決の問題です。
There is no known deployment of Quick-Start for TCP or other IETF transports.
TCPまたは他のIETFトランスポートの迅速なスタートの既知の展開はありません。
Some lessons can be learned from Quick-Start. Despite being a very lightweight protocol, Quick-Start suffers from poor incremental deployment properties regarding both a) the required modifications in network infrastructure and b) its interactions with applications. Except for corner cases, congestion control can be quite efficiently performed end to end in the Internet, and in modern stacks there is not much room for significant improvement by additional network support.
クイックスタートから学ぶことができます。非常に軽量なプロトコルであるにもかかわらず、Quick-Startは、a）ネットワークインフラストラクチャの必要な修正に関する増加展開プロパティが損なわれ、そのアプリケーションとの相互作用があります。コーナーケースを除いて、輻輳制御はインターネットで終わる最後に、最新のスタックでは、追加のネットワークサポートによる大幅な改善の余地はあまりありません。
After publication of the Quick-Start specification, there have been large-scale experiments with an initial window of up to 10 segments [RFC6928]. This alternative "IW10" approach can also ramp up data transfers faster than the standard congestion control, but it only requires sender-side modifications. As a result, this approach can be easier and incrementally deployed in the Internet. While theoretically Quick-Start can outperform "IW10", the improvement in completion time for data transfer times can, in many cases, be small. After publication of [RFC6928], most modern TCP stacks have increased their default initial window.
クイックスタート仕様の公表後、最大10セグメントの初期窓を備えた大規模実験が行われています[RFC6928]。この代替の「IW10」アプローチはまた、標準の輻輳制御よりも速くデータ転送を上げることができますが、送信側の変更は必要とされます。その結果、この方法はインターネットに簡単かつ徐々に展開できます。理論的にクイックスタートが「IW10」になることはできますが、データ転送時間の完了時間の改善は多くの場合小さくなります。[RFC6928]の公表後、ほとんどの最新のTCPスタックはデフォルトの初期ウィンドウを増やしました。
The suggested reference for ICMP Source Quench is:
ICMPソースクエンチの推奨参照は次のとおりです。
* "Internet Control Message Protocol" [RFC0792]
* 「インターネット制御メッセージプロトコル」[RFC0792]
The ICMP Source Quench message [RFC0792] allowed an on-path router to request the source of a flow to reduce its sending rate. This method allowed a router to provide an early indication of impending congestion on a path to the sources that contribute to that congestion.
ICMPソースクエンチメッセージ[RFC0792]は、オンパスルータがフローの送信元を要求して送信レートを短縮できました。この方法では、ルータがその輻輳に貢献する情報源へのパスに差し迫った輻輳の早期兆候を提供できました。
This method was deployed in Internet routers over a period of time; the reaction of endpoints to receiving this signal has varied. For low-speed links, with low multiplexing of flows the method could be used to regulate (momentarily reduce) the transmission rate. However, the simple signal does not scale with link speed or with the number of flows sharing a link.
このメソッドは一定期間にわたってインターネットルータに展開されました。この信号の受信側の反応は変化した。低速リンクの場合、流れの多重化を伴う、この方法は伝送速度を調整する（瞬間的に減少させる）ために使用され得る。ただし、単純な信号はリンク速度またはリンクを共有するフロー数で拡大縮小されません。
The approach was overtaken by the evolution of congestion control methods in TCP [RFC2001], and later also by other IETF transports. Because these methods were based upon measurement of the end-to-end path and an algorithm in the endpoint, they were able to evolve and mature more rapidly than methods relying on interactions between operational routers and endpoint stacks.
このアプローチは、TCP [RFC2001]における輻輳制御方法の進化によって追い越され、その後他のIETF輸送によっても。これらの方法はエンドツーエンドパスとエンドポイント内のアルゴリズムの測定に基づいていたため、操作ルーターとエンドポイントスタック間の相互作用に依存する方法よりも迅速に進化し、成熟することができました。
After ICMP Source Quench was specified, the IETF began to recommend that transports provide end-to-end congestion control [RFC2001]. The Source Quench method has been obsoleted by the IETF [RFC6633], and both hosts and routers must now silently discard this message.
ICMPソースクエンチが指定された後、IETFはトランスポートがエンドツーエンドの輻輳制御を提供することを推奨し始めました[RFC2001]。ソースクイーンメソッドはIETF [RFC6633]によって廃止され、ホストとルータの両方がこのメッセージを静かに破棄しなければなりません。
This method had several problems.
この方法ではいくつかの問題がありました。
First, [RFC0792] did not sufficiently specify how the sender would react to the ICMP Source Quench signal from the path (e.g., [RFC1016]). There was ambiguity in how the sender should utilize this additional information. This could lead to unfairness in the way that receivers (or routers) responded to this message.
まず、[RFC0792]は、送信者が経路からのICMPソースクエンチ信号にどのように反応するかを十分に指定した（例えば、[RFC1016]）。送信者がこの追加情報をどのように利用するべきかにあいまいさがあった。これは、受信機（またはルーター）がこのメッセージに応答した方法で不公平になる可能性があります。
Second, while the message did provide additional information, the Explicit Congestion Notification (ECN) mechanism [RFC3168] provided a more robust and informative signal for network nodes to provide early indication that a path has become congested.
第二に、メッセージが追加情報を提供したが、明示的輻輳通知（ECN）メカニズム[RFC3168]は、パスが混雑しているという早期の指示を提供するために、ネットワークノードにとってより堅牢で有益な信号を提供した。
The mechanism originated at a time when the Internet trust model was very different. Most endpoint implementations did not attempt to verify that the message originated from an on-path node before they utilized the message. This made it vulnerable to Denial-of-Service (DoS) attacks. In theory, routers might have chosen to use the quoted packet contained in the ICMP payload to validate that the message originated from an on-path node, but this would have increased per-packet processing overhead for each router along the path and would have required transport functionality in the router to verify whether the quoted packet header corresponded to a packet the router had sent. In addition, Section 5.2 of [RFC4443] noted ICMPv6-based attacks on hosts that would also have threatened routers processing ICMPv6 Source Quench payloads. As time passed, it became increasingly obvious that the lack of validation of the messages exposed receivers to a security vulnerability where the messages could be forged to create a tangible DoS opportunity.
インターネット信頼モデルが非常に異なる時に発生したメカニズム。ほとんどのエンドポイント実装は、メッセージを使用する前にメッセージがオンパスノードから発生したことを確認しようとしませんでした。これはそれがサービス拒否（DOS）攻撃に対して脆弱になりました。理論的には、ルータは、ICMPペイロードに含まれる引用符付きパケットを使用して、メッセージがオンパスノードから発生したことを検証することを検証することができましたが、これはパスに沿って各ルータのパケットごとの処理オーバーヘッドを増やしていました。ルータのトランスポート機能は、引用符付きパケットヘッダーがルータが送信したパケットに対応しているかどうかを確認します。また、[RFC4443]のセクション5.2は、ICMPv6のソースクエンチペイロードを処理する絶滅のあるルータに対するICMPv6ベースの攻撃に注意してください。時間が経過するにつれて、メッセージが著名なDOSの機会を作成するためにメッセージが偽造される可能性があるセキュリティの脆弱性へのメッセージの検証の欠如がますます明らかになりました。
The suggested references for TRIGTRAN are:
Trigtranの推奨参照は次のとおりです。
* TRIGTRAN BOF at IETF 55 [TRIGTRAN-55]
* IETF 55 [TRIGTRAN-55]のTRIGTRAN BOF
* TRIGTRAN BOF at IETF 56 [TRIGTRAN-56]
* TRIGTRAN BOFのIETF 56 [TRIGTRAN-56]
TCP [RFC0793] has a well-known weakness -- the end-to-end flow control mechanism has only a single signal, the loss of a segment, detected when no acknowledgment for the lost segment is received at the sender. There are multiple reasons why the sender might not have received an acknowledgment for the segment. To name several, the segment could have been trapped in a routing loop, damaged in transmission and failed checksum verification at the receiver, or lost because some intermediate device discarded the packet, or any of a variety of other things could have happened to the acknowledgment on the way back from the receiver to the sender. TCP implementations since the late 1980s have made the "safe" decision and have interpreted the loss of a segment as evidence that the path between two endpoints may have become congested enough to exhaust buffers on intermediate hops, so that the TCP sender should "back off" -- reduce its sending rate until it knows that its segments are now being delivered without loss [RFC5681].
TCP [RFC0793]はよく知られている弱さをしています。エンドツーエンドのフロー制御メカニズムは単一の信号のみを持ち、失われたセグメントの承認が送信側で受信されない場合に検出されます。送信者がセグメントの確認応答を受信しなかった理由は複数の理由があります。いくつかの名前を付けるために、セグメントはルーティングループに閉じ込められており、受信機での送信と失敗したチェックサム検証で破損したか、またはいくつかの中間機器はパケットを破棄したり、他のさまざまなもののいずれかが承認に起こった可能性があるため、失敗しました。受信者から送信者に戻る途中。 1980年代後半以降のTCP実装は「安全な」決定を下し、2つのエンドポイント間の経路が中間ホップ上の排気するのに十分な輻輳になる可能性があるという証拠としてセグメントの損失を解釈したので、TCP送信者は「バックオフ」 「 - そのセグメントが損失なしで配信されていることを知っているまで送信率を下げる[RFC5681]。
The thinking behind TRIGTRAN was that if a path completely stopped working because a link along the path was "down", somehow something along the path could signal TCP when that link returned to service, and the sending TCP could retry immediately, without waiting for a full retransmission timeout (RTO) period.
Trigtranの背後にある考え方は、パスに沿ったリンクが "down"であるため、パスが完全に動作を停止した場合、そのリンクがサービスに戻ったときにパスに沿って何かがTCPに通知することができ、送信されたTCPはフル再送タイムアウト（RTO）期間。
The early dreams for TRIGTRAN were dashed because of an assumption that TRIGTRAN triggers would be unauthenticated. This meant that any "safe" TRIGTRAN mechanism would have relied on a mechanism such as setting the IPv4 TTL or IPv6 Hop Count to 255 at a sender and testing that it was 254 upon receipt, so that a receiver could verify that a signal was generated by an adjacent sender known to be on the path being used and not some unknown sender that might not even be on the path (e.g., "The Generalized TTL Security Mechanism (GTSM)" [RFC5082]). This situation is very similar to the case for ICMP Source Quench messages as described in Section 6.4, which were also unauthenticated and could be sent by an off-path attacker, resulting in deprecation of ICMP Source Quench message processing [RFC6633].
Trigtranのトリガーが認証されていないという仮定のため、Trigrranの早期夢は破線でした。これは、受信時にIPv4 TTLまたはIPv6ホップ数を255に設定し、受信時に254のテストをテストするなどのメカニズムに依存していることを意味しました。使用されている経路上にあることが知られている隣接送信者によって、経路上にさえいなくても一部の未知の送信者（例えば、一般化されたTTLセキュリティメカニズム（GTSM） "[RFC5082]）。この状況は、6.4項で説明されているICMPソースクエンチメッセージの場合と非常に似ています。
TRIGTRAN's scope shrunk from "the path is down" to "the first-hop link is down."
"Pathが停止している"から "最初のホップのリンクが停止しています。"からTrigtranのスコープの範囲が縮小しました。
But things got worse.
しかし物事は悪化しました。
Because TRIGTRAN triggers would only be provided when the first-hop link was "down", TRIGTRAN triggers couldn't replace normal TCP retransmission behavior if the path failed because some link further along the network path was "down". So TRIGTRAN triggers added complexity to an already-complex TCP state machine and did not allow any existing complexity to be removed.
最初のホップリンクが "down"しているときにのみトリガトリガは提供されるため、PathがNetwork Pathに沿ってさらにリンクに沿ったリンクが "down"であるため、TrainTranトリガは通常のTCP再送信動作を置き換えることができませんでした。そのため、Trigtranトリガはすでに複雑なTCPステートマシンに複雑さを追加し、既存の複雑さを削除することを許可しませんでした。
There was also an issue that the TRIGTRAN signal was not sent in response to a specific host that had been sending packets and was instead a signal that stimulated a response by any sender on the link. This needs to scale when there are multiple flows trying to use the same resource, yet the sender of a trigger has no understanding of how many of the potential traffic sources will respond by sending packets -- if recipients of the signal "back off" their responses to a trigger to improve scaling, then that immediately mitigates the benefit of the signal.
パケットを送信していた特定のホストに応答してTRIGTRAN信号が送信されず、その代わりにリンク上の送信者による応答を促進する信号もありました。同じリソースを使用しようとしている複数のフローがあると拡張する必要がありますが、トリガーの送信者はパケットを送信して潜在的なトラフィックソースの数を理解していません - 信号の受信者が「戻る」スケーリングを改善するためのトリガーに対する回答、それから直ちに信号の利点を軽減します。
Finally, intermediate forwarding nodes required modification to provide TRIGTRAN triggers, but operators couldn't charge for TRIGTRAN triggers, so there was no way to recover the cost of modifying, testing, and deploying updated intermediate nodes.
最後に、中間転送ノードはTrigtranトリガーを提供するために修正を必要としましたが、トリガトリガーのためにオペレータが請求できなかったので、更新された中間ノードの変更、テスト、および展開のコストを回復する方法はありませんでした。
Two TRIGTRAN BOFs were held, at IETF 55 [TRIGTRAN-55] and IETF 56 [TRIGTRAN-56], but this work was not chartered, and there was no interest in deploying TRIGTRAN unless it was chartered and standardized in the IETF.
IETF 55 [TRIGTRAN-55]およびIETF 56 [TRIGTRAN-56]で2つのTrigtran BOFSが開催されましたが、この作業はチャーターされていませんでした。
The reasons why this work was not chartered, much less deployed, provide several useful lessons for researchers.
この作品がチャーターされていない理由は、展開されていませんでした、研究者にとっていくつかの便利なレッスンを提供します。
* TRIGTRAN started with a plausible value proposition, but networking realities in the early 2000s forced reductions in scope that led directly to reductions in potential benefits but no corresponding reductions in costs and complexity.
* Trigtranはもっともらしい価値の提案を始めましたが、2000年代初頭のネットワーキングの現実は、潜在的な利益の減少に直接導かれた範囲の削減が強制されましたが、対応するコストや複雑さを抑制しません。
* These reductions in scope were the direct result of an inability for hosts to trust or authenticate TRIGTRAN signals they received from the network.
* スコープのこれらの削減は、ホストがネットワークから受信したTRIGTRAN信号を信頼または認証することができないという直接的な結果でした。
* Operators did not believe they could charge for TRIGTRAN signaling, because first-hop links didn't fail frequently and TRIGTRAN provided no reduction in operating expenses, so there was little incentive to purchase and deploy TRIGTRAN-capable network equipment.
* 最初のホップのリンクが頻繁に失敗していないため、営業費用が減少しなかったため、トリムのシグナリングのために費用がかかるとは考えていませんでした。
It is also worth noting that the targeted environment for TRIGTRAN in the late 1990s contained links with a relatively small number of directly connected hosts -- for instance, cellular or satellite links. The transport community was well aware of the dangers of sender synchronization based on multiple senders receiving the same stimulus at the same time, but the working assumption for TRIGTRAN was that there wouldn't be enough senders for this to be a meaningful problem. In the 2010s, it was common for a single "link" to support many senders and receivers, likely requiring TRIGTRAN senders to wait some random amount of time before sending after receiving a TRIGTRAN signal, which would have reduced the benefits of TRIGTRAN even more.
1990年後半のTrigrranのターゲット環境が、比較的少数の直接接続ホスト（例えば、セルラーまたは衛星リンク）とのリンクを含んでいたことも注目する価値があります。トランスポートコミュニティは、同時に同じ刺激を受けている複数の送信者に基づいて送信者同期の危険性をよく知っていましたが、Trigtranの実用的な仮定は、これが意味のある問題になるのに十分な送信者がないことでした。2010年代には、Trigtran信号を受信した後に送信前に送信前の数のランダムな時間を待つ可能性が高い、Trigtran信号を受信する前にTrigtran Senderが何らかのランダムな時間を待つことができます。
The suggested reference for Shim6 is:
Shim6の提案された参照は次のとおりです。
* "Shim6: Level 3 Multihoming Shim Protocol for IPv6" [RFC5533]
* "Shim6：IPv6のレベル3マルチホームシムプロトコル" [RFC5533]
The IPv6 routing architecture [RFC1887] assumed that most sites on the Internet would be identified by Provider Assigned IPv6 prefixes, so that Default-Free Zone routers only contained routes to other providers, resulting in a very small IPv6 global routing table.
IPv6ルーティングアーキテクチャ[RFC1887]は、インターネット上のほとんどのサイトがプロバイダ割り当てられたIPv6プレフィックスによって識別されることを前提としているため、デフォルトフリーゾーンルータは他のプロバイダへのルートだけを含み、非常に小さいIPv6グローバルルーティングテーブルになります。
For a single-homed site, this could work well. A multihomed site with only one upstream provider could also work well, although BGP multihoming from a single upstream provider was often a premium service (costing more than twice as much as two single-homed sites), and if the single upstream provider went out of service, all of the multihomed paths could fail simultaneously.
単一住宅サイトのために、これはうまくいくかもしれません。1つのアップストリームプロバイダのみを持つマルチホームサイトはまたうまく機能しますが、単一のアップストリームプロバイダーからのBGPマルチホームはプレミアムサービス（2倍以上のシングルホームサイトを超える費用）であり、単一の上流プロバイダが外に出た場合サービス、すべてのマルチホームパスが同時に失敗する可能性があります。
IPv4 sites often multihomed by obtaining Provider Independent prefixes and advertising these prefixes through multiple upstream providers. With the assumption that any multihomed IPv4 site would also multihome in IPv6, it seemed likely that IPv6 routing would be subject to the same pressures to announce Provider Independent prefixes, resulting in an IPv6 global routing table that exhibited the same explosive growth as the IPv4 global routing table. During the early 2000s, work began on a protocol that would provide multihoming for IPv6 sites without requiring sites to advertise Provider Independent prefixes into the IPv6 global routing table.
IPv4サイトは、プロバイダーに依存しないプレフィックスを入手し、これらのプレフィックスを複数のアップストリームプロバイダを宣伝することによってマルチホーム化します。マルチホームIPv4サイトがIPv6でマルチホームすると仮定して、IPv6ルーティングがプロバイダ独立プレフィックスをアナウンスするための同じ圧力の対象となる可能性が高いようです。その結果、IPv4グローバルと同じ爆発的な成長を示したIPv6グローバルルーティングテーブルが得られます。ルーティングテーブル2000年代初頭にかけて、IPv6グローバルルーティングテーブルにプロバイダ独立プレフィックスをアドバタイズすることなく、IPv6サイトのマルチホームを提供するプロトコルで作業が開始されました。
This protocol, called "Shim6", allowed two endpoints to exchange multiple addresses ("Locators") that all mapped to the same endpoint ("Identity"). After an endpoint learned multiple Locators for the other endpoint, it could send to any of those Locators with the expectation that those packets would all be delivered to the endpoint with the same Identity. Shim6 was an example of an "Identity/Locator Split" protocol.
このプロトコルは、「Shim6」と呼ばれる、2つのエンドポイントを許可して、すべて同じエンドポイントにマッピングされた複数のアドレス（「ロケータ」）を交換できます（「ID」）。エンドポイントが他のエンドポイントに対して複数のロケーターを学んだ後、それらのパケットがすべて同じIDを持つエンドポイントに配信されることを期待して、それらのロケータのいずれかに送信できます。Shim6は、「Identity / Locator Split」プロトコルの例でした。
Shim6, as defined in [RFC5533] and related RFCs, provided a workable solution for IPv6 multihoming using Provider Assigned prefixes, including capability discovery and negotiation, and allowing end-to-end application communication to continue even in the face of path failure, because applications don't see Locator failures and continue to communicate with the same Identity using a different Locator.
[RFC5533]および関連RFCで定義されているShim6は、能力の発見とネゴシエーションを含むプロバイダーが割り当てられたプレフィックスを使用したIPv6マルチホームのための作業可能なソリューションを提供し、パス失敗の直面でもエンドツーエンドのアプリケーション通信を続けることを可能にしました。アプリケーションはロケータ障害が発生し、異なるロケータを使用して同じIDと通信し続けません。
Note that the problem being addressed was "site multihoming", but Shim6 was providing "host multihoming". That meant that the decision about what path would be used was under host control, not under edge router control.
対処されている問題は「サイトマルチホーム」でしたが、Shim6は「ホストマルチホーム」を提供していました。つまり、エッジルータコントロールの下ではなく、どのパスが使用されるかについての決定がホスト制御下にあることを意味しました。
Although more work could have been done to provide a better technical solution, the biggest impediments to Shim6 deployment were operational and business considerations. These impediments were discussed at multiple network operator group meetings, including [Shim6-35] at [NANOG-35].
より良い技術ソリューションを提供するためにもっと多くの作業が行われていましたが、Shim6展開への最大の障害は運用およびビジネス上の考慮事項でした。これらの障害は、[Nanog-35]の[SHIM6-35]を含む、複数のネットワーク事業者グループ会議で議論されました。
The technical issues centered around concerns that Shim6 relied on the host to track all the connections, while also tracking Identity/ Locator mappings in the kernel and tracking failures to recognize that an available path has failed.
Shim6がすべての接続を追跡するためにShim6がホストに依存しているという技術的な問題は、カーネル内のID /ロケータのマッピングを追跡し、利用可能なパスが失敗したことを認識していることを認識しています。
The operational issues centered around concerns that operators were performing traffic engineering on traffic aggregates. With Shim6, these operator traffic engineering policies must be pushed down to individual hosts.
運用上の問題は、オペレータがトラフィックアグリゲートでトラフィックエンジニアリングを実行していたという懸念を懸念しています。SHIM6では、これらのオペレータトラフィックエンジニアリングポリシーを個々のホストに押し下げる必要があります。
In addition, operators would have no visibility or control over the decision of hosts choosing to switch to another path. They expressed concerns that relying on hosts to steer traffic exposed operator networks to oscillation based on feedback loops, if hosts moved from path to path frequently. Given that Shim6 was intended to support multihoming across operators, operators providing only one of the paths would have even less visibility as traffic suddenly appeared and disappeared on their networks.
さらに、オペレータは、別のパスに切り替えることを選択したホストの決定を視認性または制御することはできません。それらは、ホストからパスへのパスへのパスからパスへの移行された場合、フィードバックループに基づいてトラフィック露出オペレータネットワークを発振させるためのホストに頼る懸念を表明しました。Shim6がオペレータ間でマルチホームをサポートすることを目的としていたことを考えると、経路の1つだけを提供するオペレータは、トラフィックが突然現れ、ネットワーク上で消えたため、さらには表示されません。
In addition, firewalls that expected to find a TCP or UDP transport-level protocol header in the IP payload would see a Shim6 Identity header instead, and they would not perform transport-protocol-based firewalling functions because the firewall's normal processing logic would not look past the Identity header. The firewall would perform its default action, which would most likely be to drop packets that don't match any processing rule.
さらに、IPペイロード内のTCPまたはUDPトランスポートレベルプロトコルヘッダーを見つけると予想されるファイアウォールは、代わりにShim6 Identity Headerを表示し、ファイアウォールの通常の処理ロジックは見られないため、トランスポートプロトコルベースのファイアウォール機能を実行しません。アイデンティティヘッダーを越えて。ファイアウォールはデフォルトのアクションを実行します。これは、一致しないパケットを削除することができます。
The business issues centered on reducing or removing the ability to sell BGP multihoming service to their own customers, which is often more expensive than two single-homed connectivity services.
ビジネスの問題は、BGPマルチホームサービスを自分の顧客に販売する能力を削減または削除することを中心としており、これは2つの単一のホーム接続サービスよりも高価です。
It is extremely important to take operational concerns into account when a Path Aware protocol is making decisions about path selection that may conflict with existing operational practices and business considerations.
パス対応プロトコルが、既存の運用慣行およびビジネス上の考慮事項と矛盾する可能性があるパス選択に関する決定を下しているときに、運用上の懸念を考慮に入れることが非常に重要です。
During discussions in the PANRG session at IETF 103 [PANRG-103-Min], Lars Eggert, past Transport Area Director, pointed out that during charter discussions for the Multipath TCP Working Group [MP-TCP], operators expressed concerns that customers could use Multipath TCP to load-share TCP connections across operators simultaneously and compare passive performance measurements across network paths in real time, changing the balance of power in those business relationships. Although the Multipath TCP Working Group was chartered, this concern could have acted as an obstacle to deployment.
IETF 103 [Panrg-103-Min]、LARS Eggert、過去のトランスポートエリアディレクターのPanrgセッションでは、マルチパスTCPワーキンググループのチャーターディスカッション中に、顧客が使用できる懸念があることを指摘しました。マルチパスTCPは、オペレータ間でTCP接続を同時にロードし、リアルタイムでネットワークパス全体でパッシブ性能測定値を比較し、それらのビジネス関係の電力のバランスを変えます。マルチパスTCPワーキンググループはチャーターされていましたが、この懸念は展開の障害として機能している可能性があります。
Operator objections to Shim6 were focused on technical concerns, but this concern could have also been an obstacle to Shim6 deployment if the technical concerns had been overcome.
Shim6へのオペレータの異議は技術的な懸念に焦点を当てていましたが、技術的な懸念が克服された場合、この懸念もShim6展開の障害となっていました。
The suggested references for Next Steps in Signaling (NSIS) are:
シグナリング（NSIS）の次のステップの推奨参照は次のとおりです。
* the concluded working group charter [NSIS-CHARTER-2001]
* ワーキンググループチャーター[NSIS-CHARTER-2001]
* "GIST: General Internet Signalling Transport" [RFC5971]
* "GIST：一般インターネットシグナリングトランスポート" [RFC5971]
* "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)" [RFC5973]
* 「NAT /ファイアウォールNSIシグナリングレイヤプロトコル（NSLP）」[RFC5973]
* "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling" [RFC5974]
* "サービス品質シグナリングのためのNSISシグナリングレイヤプロトコル（NSLP）] [RFC5974]
* "Authorization for NSIS Signaling Layer Protocols" [RFC5981]
* 「NSISシグナリングレイヤプロトコルの承認」[RFC5981]
The NSIS Working Group worked on signaling techniques for network-layer resources (e.g., QoS resource reservations, Firewall and NAT traversal).
NSISワーキンググループは、ネットワーク層リソース（例えば、QoSリソース予約、ファイアウォール、およびNATトラバーサル）のシグナリング技術に取り組みました。
When RSVP [RFC2205] was used in deployments, a number of questions came up about its perceived limitations and potential missing features. The issues noted in the NSIS Working Group charter [NSIS-CHARTER-2001] include interworking between domains with different QoS architectures, mobility and roaming for IP interfaces, and complexity. Later, the lack of security in RSVP was also recognized [RFC4094].
RSVP [RFC2205]が展開で使用されていた場合、多くの質問がその認識された制限と潜在的な機能の潜在的な機能について始まった。NSISワーキンググループCharter [NSIS-Charter-2001]に記載されている問題には、異なるQoSアーキテクチャ、モビリティ、およびIPインターフェイスのローミング、複雑さのあるドメイン間のインターワーキングが含まれます。その後、RSVPのセキュリティ不足も認識されました[RFC4094]。
The NSIS Working Group was chartered to tackle those issues and initially focused on QoS signaling as its primary use case. However, over time a new approach evolved that introduced a modular architecture using two application-specific signaling protocols: a) the NSIS Signaling Layer Protocol (NSLP) on top of b) a generic signaling transport protocol (the NSIS Transport Layer Protocol (NTLP)).
NSISワーキンググループは、これらの問題に取り組み、最初にQoSシグナリングに初期使用例として焦点を当てました。ただし、2つのアプリケーション固有のシグナリングプロトコルを使用してモジュラーアーキテクチャを導入した新しいアプローチが進化しました.a）B）Genericシグナリングトランスポートプロトコル（NSISトランスポートレイヤプロトコル（NTLP））のNSISシグナリングレイヤプロトコル（NSLP））。
NTLP is defined in [RFC5971]. Two types of NSLPs are defined: an NSLP for QoS signaling [RFC5974] and an NSLP for NATs/firewalls [RFC5973].
NTLPは[RFC5971]で定義されています。2種類のNSLPが定義されています.XISシグナリング[RFC5974]のNSLPとNATS / Firewalls [RFC5973]のNSLP。
The obstacles for deployment can be grouped into implementation-related aspects and operational aspects.
展開のための障害は、実装関連の側面および運用面にグループ化することができます。
* Implementation-related aspects:
* 実装関連の側面：
Although NSIS provides benefits with respect to flexibility, mobility, and security compared to other network signaling techniques, hardware vendors were reluctant to deploy this solution, because it would require additional implementation effort and would result in additional complexity for router implementations.
NSIは他のネットワークシグナリング技術と比較して柔軟性、モビリティ、およびセキュリティに関して利点を提供しますが、ハードウェアベンダーは追加の実装努力を必要とし、ルータの実装にさらなる複雑さをもたらすため、このソリューションを展開することに消極的でした。
NTLP mainly operates as a path-coupled signaling protocol, i.e., its messages are processed at the control plane of each intermediate node that is also forwarding the data flows. This requires a mechanism to intercept signaling packets while they are forwarded in the same manner (especially along the same path) as data packets. NSIS uses the IPv4 and IPv6 Router Alert Option (RAO) to allow for interception of those path-coupled signaling messages, and this technique requires router implementations to correctly understand and implement the handling of RAOs, e.g., to only process packets with RAOs of interest and to leave packets with irrelevant RAOs in the fast forwarding processing path (a comprehensive discussion of these issues can be found in [RFC6398]). The latter was an issue with some router implementations at the time of standardization.
NTLPは主に経路結合シグナリングプロトコルとして動作し、すなわちそのメッセージはデータフローを転送している各中間ノードの制御プレーンで処理される。これは、データパケットと同じ方法で（特に同じ経路に沿って）転送されている間にシグナリングパケットを傍受するメカニズムが必要です。NSISは、IPv4とIPv6 Router Alertオプション（RAO）を使用して、それらのパス結合シグナリングメッセージの傍受を可能にし、このテクニックではRAOSの処理を正しく理解し実装するためにルータの実装が必要であり、関心のあるRaosを使用したプロセスパケットのみを必要とします。そして、急速な転送処理経路で無関係なRAOでパケットを残すこと（これらの問題についての包括的な議論は[RFC6398]にあります）。後者は、標準化時のいくつかのルータ実装に関する問題でした。
Another reason is that path-coupled signaling protocols that interact with routers and request manipulation of state at these routers (or any other network element in general) are under scrutiny: a packet (or sequence of packets) out of the mainly untrusted data path is requesting creation and manipulation of network state. This is seen as potentially dangerous (e.g., opens up a DoS threat to a router's control plane) and difficult for an operator to control. Path-coupled signaling approaches were considered problematic (see also Section 3 of [RFC6398]). There are recommendations on how to secure NSIS nodes and deployments (e.g., [RFC5981]).
もう1つの理由は、ルータと対話し、これらのルータ（または一般に他の任意のネットワーク要素）での状態の状態の依頼の操作を要求するパス結合シグナリングプロトコルが精査されています。主に信頼されていないデータパスからのパケット（またはパケットのシーケンス）はネットワーク状態の作成と操作を要求します。これは潜在的に危険な（例えば、ルータの制御面に対するDOS脅威を開く）と見られ、オペレータが制御するのが困難である。経路結合シグナリングアプローチは問題と考えられた（[RFC6398のセクション3も参照）。NSISノードと展開を保護する方法（例えば、[RFC5981]）についての推奨事項があります。
* Operational Aspects:
* 運用面：
NSIS not only required trust between customers and their provider, but also among different providers. In particular, QoS signaling techniques would require some kind of dynamic SLA support that would imply (potentially quite complex) bilateral negotiations between different Internet Service Providers. This complexity was not considered to be justified, and increasing the bandwidth (and thus avoiding bottlenecks) was cheaper than actively managing network resource bottlenecks by using path-coupled QoS signaling techniques. Furthermore, an end-to-end path typically involves several provider domains, and these providers need to closely cooperate in cases of failures.
NSISは、顧客とそのプロバイダ間でだけでなく、さまざまなプロバイダーの間でも必要な信頼だけでなく。特に、QoSシグナリング技術は、異なるインターネットサービスプロバイダ間の二国間交渉を意味する（潜在的に複雑な）二国間交渉をすることがある種の動的SLAサポートを必要とするであろう。この複雑さは正当化されておらず、経路結合QoSシグナリング技術を用いてネットワークリソースのボトルネックを積極的に管理するよりも安価であった。さらに、エンドツーエンドのパスは通常、いくつかのプロバイダドメインを含み、これらのプロバイダは失敗の場合に密接に協力する必要があります。
One goal of NSIS was to decrease the complexity of the signaling protocol, but a path-coupled signaling protocol comes with the intrinsic complexity of IP-based networks, beyond the complexity of the signaling protocol itself. Sources of intrinsic complexity include:
NSIの1つの目標はシグナリングプロトコルの複雑さを減らすことでしたが、パス結合シグナリングプロトコルには、シグナリングプロトコル自体の複雑さを超えて、IPベースのネットワークの組み込み型の複雑さがあります。固有の複雑さの原因は次のとおりです。
* the presence of asymmetric routes between endpoints and routers.
* エンドポイントとルータ間の非対称経路の存在
* the lack of security and trust at large in the Internet infrastructure.
* インターネットインフラストラクチャの大規模でのセキュリティと信頼の欠如。
* the presence of different trust boundaries.
* さまざまな信頼境界の存在
* the effects of best-effort networks (e.g., robustness to packet loss).
* ベストエフォートネットワーク（例えば、パケット損失に対する堅牢性）の影響
* divergence from the fate-sharing principle (e.g., state within the network).
* 運命共有原理（例えば、ネットワーク内の状態）からの発散。
Any path-coupled signaling protocol has to deal with these realities.
どの経路結合シグナリングプロトコルはこれらの現実に対処しなければならない。
Operators view the use of IPv4 and IPv6 Router Alert Options (RAOs) to signal routers along the path from end systems with suspicion, because these end systems are usually not authenticated and heavy use of RAOs can easily increase the CPU load on routers that are designed to process most packets using a hardware "fast path" and diverting packets containing RAOs to a slower, more capable processor.
演算子は、疑わしいエンドシステムからのパスに沿った経路に沿った信号ルータへの信号ルータへのIPv4とIPv6ルータ警告オプション（RAOS）の使用を見ます。ハードウェアの「高速経路」を使用してほとんどのパケットを処理するために、RAOSを含むパケットをより遅く、より高いプロセッサに転送します。
The suggested reference for IPv6 Flow Labels is:
IPv6フローラベルの推奨参照は次のとおりです。
* "IPv6 Flow Label Specification" [RFC6437]
* "IPv6フローラベル仕様" [RFC6437]
IPv6 specifies a 20-bit Flow Label field [RFC6437], included in the fixed part of the IPv6 header and hence present in every IPv6 packet. An endpoint sets the value in this field to one of a set of pseudorandomly assigned values. If a packet is not part of any flow, the flow label value is set to zero [RFC3697]. A number of Standards Track and Best Current Practice RFCs (e.g., [RFC8085], [RFC6437], [RFC6438]) encourage IPv6 endpoints to set a non-zero value in this field. A multiplexing transport could choose to use multiple flow labels to allow the network to either independently forward its subflows or use one common value for the traffic aggregate. The flow label is present in all fragments. IPsec was originally put forward as one important use case for this mechanism and does encrypt the field [RFC6438].
IPv6は、IPv6ヘッダーの固定部分に含まれ、したがってすべてのIPv6パケットに存在する20ビットフローラベルフィールド[RFC6437]を指定します。エンドポイントは、このフィールドの値を疑似的に割り当てられた値のセットのいずれかに設定します。パケットがフローの一部ではない場合、フローラベル値はゼロ[RFC3697]に設定されます。多くの標準トラックと最良の現在の実践RFC（例えば、[RFC8085]、[RFC6437]、[RFC6438]）がこのフィールドにゼロ以外の値を設定するようにIPv6エンドポイントを奨励します。多重化トランスポートは、ネットワークがそのサブフローを独立して転送するか、トラフィック集計に対して1つの共通値を使用することを可能にするために複数のフローラベルを使用することを選択できます。フローラベルはすべての断片に存在します。IPsecはもともとこのメカニズムの1つの重要なユースケースとして転送され、フィールド[RFC6438]を暗号化します。
Once set, the flow label can provide information that can help inform network nodes about subflows present at the transport layer, without needing to interpret the setting of upper-layer protocol fields [RFC6294]. This information can also be used to coordinate how aggregates of transport subflows are grouped when queued in the network and to select appropriate per-flow forwarding when choosing between alternate paths [RFC6438] (e.g., for Equal-Cost Multipath (ECMP) routing and Link Aggregation Groups (LAGs)).
一旦設定されると、フローラベルは、上位プロトコルフィールド[RFC6294]の設定を解釈することなく、トランスポート層に存在するサブフラフに関するネットワークノードに通知することができる情報を提供することができる。この情報は、ネットワーク内でキューに入れられたときにトランスポートサブフローの集合体がグループ化され、代替パス（RFC6438]（例えば、等価マルチパス（ECMP）ルーティングおよびリンクの場合は適切なフロー転送を選択する方法を調整するためにも使用できます。集約グループ（LAGS））。
Despite the field being present in every IPv6 packet, the mechanism did not receive as much use as originally envisioned. One reason is that to be useful it requires engagement by two different stakeholders:
フィールドがすべてのIPv6パケットに存在するにもかかわらず、メカニズムは最初に想定されているのと同じくらい多くの使用を受け取りませんでした。1つの理由は、2つの異なるステークホルダーによるエンゲージメントを必要とするということです。
* Endpoint Implementation:
* エンドポイントの実装：
For network nodes along a path to utilize the flow label, there needs to be a non-zero value inserted in the field [RFC6437] at the sending endpoint. There needs to be an incentive for an endpoint to set an appropriate non-zero value. The value should appropriately reflect the level of aggregation the traffic expects to be provided by the network. However, this requires the stack to know granularity at which flows should be identified (or, conversely, which flows should receive aggregated treatment), i.e., which packets carry the same flow label. Therefore, setting a non-zero value may result in additional choices that need to be made by an application developer.
フローラベルを利用するためのパスに沿ったネットワークノードの場合、送信エンドポイントでフィールド[RFC6437]に挿入されていないゼロ以外の値が必要です。エンドポイントが適切なゼロ以外の値を設定するためのインセンティブが必要です。この値は、トラフィックがネットワークによって提供されることを期待する集約のレベルを適切に反映する必要があります。しかしながら、これは、フローが識別されるべきである（または逆に、逆流を受けるべきである）、すなわち、どのパケットが同じフローラベルを搬送することを知るためにスタックを知ることが必要である。したがって、ゼロ以外の値を設定すると、アプリケーション開発者によって行われる必要がある追加の選択肢が発生する可能性があります。
Although the original flow label standard [RFC3697] forbids any encoding of meaning into the flow label value, the opportunity to use the flow label as a covert channel or to signal other meta-information may have raised concerns about setting a non-zero value [RFC6437].
元のフローラベル標準[RFC3697]は、フローラベル値への意味の符号化を禁止していますが、フローラベルをCovertチャネルとして使用するか、他のメタ情報をシグリックにする機会は、ゼロ以外の値を設定することについての懸念が発生する可能性があります。RFC6437]。
Before methods are widely deployed to use this method, there could be no incentive for an endpoint to set the field.
このメソッドを使用するためにメソッドが広く展開される前に、エンドポイントにフィールドを設定するためのインセンティブがない可能性があります。
* Operational support in network nodes:
* ネットワークノードでの運用上のサポート
A benefit can only be realized when a network node along the path also uses this information to inform its decisions. Network equipment (routers and/or middleboxes) need to include appropriate support in order to utilize the field when making decisions about how to classify flows or forward packets. The use of any optional feature in a network node also requires corresponding updates to operational procedures and therefore is normally only introduced when the cost can be justified.
この情報に沿ったネットワークノードもこの情報を使用してその決定を知らせる場合にのみ利点があります。ネットワーク機器（ルータおよび/またはミドルボックス）は、フローまたは転送パケットを分類する方法についての決定を下すときに、フィールドを利用するために適切なサポートを含める必要があります。ネットワークノード内の任意のオプション機能を使用するには、演算手順に対する対応する更新も必要であり、したがって通常、コストを正当化できるときにのみ導入されます。
A benefit from utilizing the flow label is expected to be increased quality of experience for applications -- but this comes at some operational cost to an operator and requires endpoints to set the field.
フローラベルを利用することからの利点は、アプリケーションの経験の質の向上であると予想されていますが、これはオペレーターにいくつかの運用コストで提供され、エンドポイントをフィールドに設定する必要があります。
The flow label is a general-purpose header field for use by the path. Multiple uses have been proposed. One candidate use was to reduce the complexity of forwarding decisions. However, modern routers can use a "fast path", often taking advantage of hardware to accelerate processing. The method can assist in more complex forwarding, such as ECMP routing and load balancing.
フローラベルは、パスで使用するための汎用ヘッダフィールドです。複数の用途が提案されている。1つの候補者の使用は、転送決定の複雑さを減らすことでした。しかしながら、現代のルータは、しばしばハードウェアを利用して処理を加速させることが多い「高速道路」を使用することができる。この方法は、ECMPルーティングや負荷分散など、より複雑な転送を支援することができます。
Although [RFC6437] recommended that endpoints should by default choose uniformly distributed labels for their traffic, the specification permitted an endpoint to choose to set a zero value. This ability of endpoints to choose to set a flow label of zero has had consequences on deployability:
[RFC6437]は、エンドポイントがデフォルトでトラフィックの均一に分散ラベルを選択する必要があることをお勧めします。仕様はエンドポイントがゼロ値を設定することを選択できます。エンドポイントのフローラベルを設定することを選択するためのこの能力は、デプロイ可能性に影響を与えました。
* Before wide-scale support by endpoints, it would be impossible to rely on a non-zero flow label being set. Network nodes therefore would need to also employ other techniques to realize equivalent functions. An example of a method is one assuming semantics of the source port field to provide entropy input to a network-layer hash. This use of a 5-tuple to classify a packet represents a layering violation [RFC6294]. When other methods have been deployed, they increase the cost of deploying standards-based methods, even though they may offer less control to endpoints and result in potential interaction with other uses/interpretation of the field.
* エンドポイントによる広範囲のサポートの前に、設定されていないフローラベルを設定することは不可能です。したがって、ネットワークノードは、同等の機能を実現するために他の技術を採用する必要があるであろう。方法の例は、ネットワーク層ハッシュへのエントロピー入力を提供するための送信元ポートフィールドのセマンティクスを一つである。パケットを分類するための5タプルのこの使用は、階層化違反[RFC6294]を表します。他の方法が展開されている場合、それらは標準ベースのメソッドを展開するコストを増やし、たとえそれらがエンドポイントを少なくし、そのフィールドの他の使用/解釈との潜在的な相互作用をもたらすかもしれません。
* Even though the flow label is specified as an end-to-end field, some network paths have been observed to not transparently forward the flow label. This could result from non-conformant equipment or could indicate that some operational networks have chosen to reuse the protocol field for other (e.g., internal) purposes. This results in lack of transparency, and a deployment hurdle to endpoints expecting that they can set a flow label that is utilized by the network. The more recent practice of "greasing" [GREASE] would suggest that a different outcome could have been achieved if endpoints were always required to set a non-zero value.
* フローラベルがエンドツーエンドフィールドとして指定されていても、フローラベルを透過的に転送しない場合のネットワークパスがいくつか観察されています。これは、不適合機器から生じ、一部の運用ネットワークが他の（例えば、内部）目的のためにプロトコルフィールドを再利用することを選択したことを示している可能性がある。これにより、透明性が不足しており、ネットワークによって利用されるフローラベルを設定できることを期待するエンドポイントへの展開ハードル。「グリース」の「グリース」の最近の練習は、エンドポイントが常にゼロ以外の値を設定するために必要とされた場合、異なる結果が達成されたことを示唆しているでしょう。
* [RFC1809] noted that setting the choice of the flow label value can depend on the expectations of the traffic generated by an application, which suggests that an API should be presented to control the setting or policy that is used. However, many currently available APIs do not have this support.
* [RFC1809]フローラベル値の選択を設定することは、アプリケーションによって生成されたトラフィックの期待に依存します。これは、使用される設定またはポリシーを制御するためにAPIを表示する必要があることを示唆しています。ただし、現在利用可能な多くのAPIにはこのサポートがありません。
A growth in the use of encrypted transports (e.g., QUIC [RFC9000]) seems likely to raise issues similar to those discussed above and could motivate renewed interest in utilizing the flow label.
暗号化されたトランスポート（例えば、QUIC [RFC9000]）の使用における成長は、上述のものと同様の問題を引き上げ、フローラベルを利用することにリニューアルされた関心を動機付けることができるように思われる。
The suggested references for Explicit Congestion Notification (ECN) are:
明示的な輻輳通知（ECN）の提案された参照は次のとおりです。
* "Recommendations on Queue Management and Congestion Avoidance in the Internet" [RFC2309]
* 「インターネットにおけるキュー管理と輻輳回避に関する推奨事項」[RFC2309]
* "A Proposal to add Explicit Congestion Notification (ECN) to IP" [RFC2481]
* 「明示的な輻輳通知（ECN）への明示的な輻輳通知を追加すること」[RFC2481]
* "The Addition of Explicit Congestion Notification (ECN) to IP" [RFC3168]
* 「明示的輻輳通知（ECN）への追加」[RFC3168]
* "Implementation Report on Experiences with Various TCP RFCs" [vista-impl], slides 6 and 7
* 「さまざまなTCP RFCの経験に関する実装報告」[Vista-Infl]、スライド6および7
* "Implementation and Deployment of ECN" (at [SallyFloyd])
* 「ECNの実装と展開」（[SallyFloyd]）
In the early 1990s, the large majority of Internet traffic used TCP as its transport protocol, but TCP had no way to detect path congestion before the path was so congested that packets were being dropped. These congestion events could affect all senders using a path, either by "lockout", where long-lived flows monopolized the queues along a path, or by "full queues", where queues remain full, or almost full, for a long period of time.
1990年代初頭には、インターネットトラフィックの大多数のインターネットトラフィックがそのトランスポートプロトコルとして使用されていましたが、TCPはパスが削除されていたのでパスが非常に混雑している前にパスの輻輳を検出する方法はありませんでした。これらの輻輳イベントは、パスに沿ってキューを独占した場合、または「フルキュー」とのどちらか、または「フルキュー」とのどちらか、またはほぼいっぱいになっています。時間。
In response to this situation, "Active Queue Management" (AQM) was deployed in the network. A number of AQM disciplines have been deployed, but one common approach was that routers dropped packets when a threshold buffer length was reached, so that transport protocols like TCP that were responsive to loss would detect this loss and reduce their sending rates. Random Early Detection (RED) was one such proposal in the IETF. As the name suggests, a router using RED as its AQM discipline that detected time-averaged queue lengths passing a threshold would choose incoming packets probabilistically to be dropped [RFC2309].
この状況に応答して、「アクティブキュー管理」（AQM）がネットワーク内に展開されました。多くのAQMの分野が展開されていますが、1つの一般的なアプローチは、しきい値バッファの長さに達したときにパケットをドロップしたため、TCPのようなトランスポートプロトコルはこの損失を検出し、送信レートを削減します。ランダム早期検出（赤）は、IETFにおけるそのような提案の1つでした。その名前が示唆するように、閾値を渡した時間平均キュー長を検出したAQM規律としてREDを使用しているルータは、プロバの着信パケットを選択することができます[RFC2309]。
Researchers suggested providing "explicit congestion notifications" to senders when routers along the path detected that their queues were building, giving senders an opportunity to "slow down" as if a loss had occurred, giving path queues time to drain, while the path still had sufficient buffer capacity to accommodate bursty arrivals of packets from other senders. This was proposed as an experiment in [RFC2481] and standardized in [RFC3168].
研究者は、経路に沿ったルーターが建物であることを検出したときに発送者に「明示的な輻輳通知」を提供し、損失が発生したかのように「遅く」する機会を与えて、パスがまだ排水する時間を与えることを検出しました。他の送信者からのパケットのバースト到着に対応するのに十分なバッファ容量。これは[RFC2481]の実験として提案され、[RFC3168]で標準化されています。
A key aspect of ECN was the use of IP header fields rather than IP options to carry explicit congestion notifications, since the proponents recognized that
ECNの重要な側面は、プロポネントがそれを認識しているため、明示的な輻輳通知を伝えるためのIPオプションではなくIPヘッダーフィールドの使用でした。
Many routers process the "regular" headers in IP packets more efficiently than they process the header information in IP options.
多くのルータは、IPオプションのヘッダー情報を処理するよりも効率的にIPパケット内の「通常の」ヘッダーを処理します。
Unlike most of the Path Aware technologies included in this document, the story of ECN continues to the present day and encountered a large number of Lessons Learned during that time. The early history of ECN (non-)deployment provides Lessons Learned that were not captured by other contributions in Section 6, so that is the emphasis in this section of the document.
この文書に含まれているPATH対応テクノロジのほとんどとは異なり、ECNのストーリーは現在の日に続き、その間に学んだ多数のレッスンが発生しました。ECN（非）展開の初期の歴史は、セクション6の他の貢献によってキャプチャされなかったレッスンを提供します。そのため、この文書のこのセクションでは強調されています。
ECN deployment relied on three factors -- support in client implementations, support in router implementations, and deployment decisions in operational networks.
ECNの展開は、クライアントの実装でのサポート、ルータの実装のサポート、および運用ネットワークでの展開の決定をサポートしました。
The proponents of ECN did so much right, anticipating many of the Lessons Learned now recognized in Section 4. They recognized the need to support incremental deployment (Section 4.2). They considered the impact on router throughput (Section 4.8). They even considered trust issues between end nodes and the network, for both non-compliant end nodes (Section 4.10) and non-compliant routers (Section 4.9).
ECNの提案は非常に多くの権利を示していましたが、今学んだ教訓の多くはセクション4で認識されていると予想しています。それらはルータスループットへの影響を考慮しました（セクション4.8）。それらは、エンドノードとネットワーク間の信頼の問題を検討していました（セクション4.10）、非準拠のルータ（セクション4.9）。
They were rewarded with ECN being implemented in major operating systems, for both end nodes and routers. A number of implementations are listed under "Implementation and Deployment of ECN" at [SallyFloyd].
ECNが主要なオペレーティングシステムとルータの両方で、ECNが主要なオペレーティングシステムで実装されています。[SallyFloyd]で、いくつかの実装が「ECNの実装と展開」の下にリストされています。
What they did not anticipate was routers that would crash when they saw bits 6 and 7 in the IPv4 Type of Service (TOS) octet [RFC0791] / IPv6 Traffic Class field [RFC2460], which [RFC2481] redefined to be "Currently Unused", being set to a non-zero value.
彼らがIPv4タイプのサービス（TOS）オクテット[RFC0791] / IPv6トラフィッククラスフィールド[RFC2460]でビット6と7を見たときにクラッシュするルーターは、[RFC2481]を「現在未使用」に再定義されているルーターであった。、ゼロ以外の値に設定されています。
As described in [vista-impl] ("IGD" stands for "Intermediate Gateway Device"),
[Vista-Inpl]（ "IGD"は "中間ゲートウェイデバイス"を表しています）
| IGD problem #1: one of the most popular versions from one of the
| most popular vendors. When a data packet arrives with either
| ECT(0) or ECT(1) (indicating successful ECN capability
| negotiation) indicated, router crashed. Cannot be recovered at
| TCP layer [sic]
This implementation, which would be run on a significant percentage of Internet end nodes, was shipped with ECN disabled, as was true for several of the other implementations listed under "Implementation and Deployment of ECN" at [SallyFloyd]. Even if subsequent router vendors fixed these implementations, ECN was still disabled on end nodes, and given the trade-off between the benefits of enabling ECN (somewhat better behavior during congestion) and the risks of enabling ECN (possibly crashing a router somewhere along the path), ECN tended to stay disabled on implementations that supported ECN for decades afterwards.
この実装は、インターネットエンドノードの有効割合で実行されるであろう、[SallyFloyd]の「実装とECNの展開」に記載されている他の実装のいくつかについては、ECNを無効にしました。後続のルータベンダがこれらの実装を修正しても、ECNは依然としてエンドノードで無効にされ、ECNを有効にすることの利点（輻輳時のややより良い行動）とECNを有効にするリスク（おそらくどこかに衝突する可能性があります）パス）、ECNはその後数十年にわたってECNをサポートしている実装で無効になっていました。
Of the contributions included in Section 6, ECN may be unique in providing these lessons:
セクション6に含まれる貢献のうち、ECNはこれらの教訓を提供する際にユニークかもしれません：
* Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your Path Aware technology.
* あなたがすべてを正しく行っても、あなたが何も知らないデバイスの実装バグを旅行することができます、それはあなたのパス対応技術の展開が成功したことを防ぐ深刻な問題を引き起こすでしょう。
* After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default.
* 実装後のPATH対応テクノロジを無効にした後、デフォルトで実装者を再度有効にするように、何十年もかかることがあります。
These two lessons, taken together, could be summarized as "you get one chance to get it right."
これら2つのレッスンが一緒になって、「あなたはそれを正しく入るチャンスを得る」と要約することができました。
During discussion of ECN at [PANRG-110], we noted that "you get one chance to get it right" isn't quite correct today, because operating systems on so many host systems are frequently updated, and transport protocols like QUIC [RFC9000] are being implemented in user space and can be updated without touching installed operating systems. Neither of these factors were true in the early 2000s.
[Panrg-110]でのECNの議論中、「あなたはそれを正しく得る機会を得る」ことは今日、今日は非常に正しいことではありません。・インストールされたオペレーティングシステムに触れずに更新することができます。2000年代初頭には、これらの要因のどちらも当てはまりませんでした。
We think that these restatements of the ECN Lessons Learned are more useful for current implementers:
学んだECNレッスンのこれらの修復は現在の実装者にとってより役立ちます。
* Even if you do everything right, you may trip over implementation bugs in devices you know nothing about, that will cause severe problems that prevent successful deployment of your Path Aware technology. Testing before deployment isn't enough to ensure successful deployment. It is also necessary to "deploy gently", which often means deploying for a small subset of users to gain experience and implementing feedback mechanisms to detect that user experience is being degraded.
* あなたがすべてを正しく行っても、あなたが何も知らないデバイスの実装バグを旅行することができます、それはあなたのパス対応技術の展開が成功したことを防ぐ深刻な問題を引き起こすでしょう。展開の前にテストを実行すると、展開が成功したことを確認するのに十分ではありません。それはまた、ユーザーの経験が低下していることを検出するために経験を得るために、ユーザーの小さなサブセットを展開し、フィードバックメカニズムを実装することを意味します。
* After implementations disable your Path Aware technology, it may take years, or even decades, to convince implementers to re-enable it by default. This might be based on the difficulty of distributing implementations that enable it by default, but it is just as likely to be based on the "bad taste in the mouth" that implementers have after an unsuccessful deployment attempt that degraded user experience.
* 実装後のPATH対応テクノロジを無効にした後、デフォルトで実装者を再度有効にするように、何十年もかかることがあります。これは、デフォルトでそれを可能にする実装を分配することの難しさに基づいているかもしれませんが、ユーザーエクスペリエンスが低下した展開試行が失敗した後に実装者が持っている「口の中の悪い味」に基づいている可能性があります。
With these expansions, the two lessons, taken together, could be more helpfully summarized as "plan for failure" -- anticipate what your next step will be, if initial deployment is unsuccessful.
これらの拡張では、2つのレッスンが一緒になって、「障害の計画」として、より有用に要約されている可能性があります - 最初の展開が失敗した場合は、次のステップが次のステップになることを予想しています。
ECN deployment was also hindered by non-deployment of AQM in many devices, because of operator interest in QoS features provided in the network, rather than using the network to assist end systems in providing for themselves. But that's another story, and the AQM Lessons Learned are already covered in other contributions in Section 6.
ECN展開はまた、ネットワークを使用するのではなく、ネットワーク内で提供されるQoS機能に対するオペレータの関心があるため、多くのデバイスの非展開によって妨げられました。しかし、それは別の物語であり、学んだAQMのレッスンはすでにセクション6の他の貢献でカバーされています。
This document describes Path Aware techniques that were not adopted and widely deployed on the Internet, so it doesn't affect the security of the Internet.
このドキュメントでは、インターネット上で採用されていませんが広く展開されていないパス対応テクニックについて説明します。そのため、インターネットのセキュリティには影響しません。
If this document meets its goals, we may develop new techniques for Path Aware networking that would affect the security of the Internet, but security considerations for those techniques will be described in the corresponding RFCs that specify them.
この文書が目標を達成した場合、インターネットのセキュリティに影響を与えるであろうパス対応ネットワーキングのための新しいテクニックを開発するかもしれませんが、それらのテクニックに関するセキュリティ上の考慮事項はそれらを指定する対応するRFCで説明されます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[Colossal-Cave] Wikipedia, "Colossal Cave Adventure", June 2021, <https://en.wikipedia.org/w/ index.php?title=Colossal_Cave_Adventure&oldid=1027119625>.
[Colossal-Cave]ウィキペディア、「Colossal Cave Adventure」、2021年6月、<https：//en.wikipedia.org/w/ index.php？title = colossal_cave_adventure＆oldid = 1027119625>。
[Conviva] "Conviva Precision : Data Sheet", January 2021, <https://www.conviva.com/datasheets/precision-delivery-intelligence/>.
[Conviva]「Conviva Precision：データシート」、2021年1月、<https：//www.conviva.com/datasheets/precision-delivery-intelligence/>。
[FARRELL-ETM] Farrell, S., "We're gonna need a bigger threat model", Work in Progress, Internet-Draft, draft-farrell-etm-03, 6 July 2019, <https://datatracker.ietf.org/doc/html/draft-farrell-etm-03>.
[Farrell-ETM] Farrell、S。、「私たちはより大きな脅威モデルを必要とする」、進行中の作業、インターネットドラフト、ドラフトFarrell-ETM-03,2019,06,6,6 <https：//datatracker.ietf.org / doc / html / farrell-etm-03>。
[GREASE] Thomson, M., "Long-term Viability of Protocol Extension Mechanisms", Work in Progress, Internet-Draft, draft-iab-use-it-or-lose-it-00, 7 August 2019, <https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-00>.
[グリース]トムソン、M。、「プロトコル拡張メカニズムの長期的な実行可能性」、進行中の作業、インターネットドラフト、ドラフトIAB-IT-OR-LOST-IT-00、2019年8月7日、<https：//datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-00>。
[IEN-119] Forgie, J., "ST - A Proposed Internet Stream Protocol", September 1979, <https://www.rfc-editor.org/ien/ien119.txt>.
[IEN-119]は、1979年9月、<https://www.rfc-editor.org/ien/ien119.txt>。
[INTERNET-THREAT-MODEL] Arkko, J., "Changes in the Internet Threat Model", Work in Progress, Internet-Draft, draft-arkko-arch-internet-threat-model-01, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-arkko-arch-internet-threat-model-01>.
[インターネット脅威モデル] Arkko、J.、「インターネット脅威モデルの変化」、進行中の作業、インターネットドラフト、ドラフトアーキコアーチインターネット脅威 - Model-01,77月8日、<https：//datatracker.ietf.org/doc/html/draft-arkko-arch-internet-threat-model-01>
[INTSERV-MULTIPLE-TSPEC] Polk, J. and S. Dhesikan, "Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1", Work in Progress, Internet-Draft, draft-ietf-tsvwg-intserv-multiple-tspec-02, 25 February 2013, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-intserv-multiple-tspec-02>.
[INTSERV-MULTERY-TSPEC] Polk、J.およびS.およびS.S.S.S.S.S.S.S.S.S.SVESICAN、RSVPV1における複数のトラフィック仕様のシグナリングおよび複数のフロー仕様のシグナリングを可能にするための統合サービス（INTSERV）拡張、進行中の作業、インターネットドラフト、ドラフト - IETF-TSVWG-INTSERV-MULTERY-TSPEC-02,2013、<https：//datatracker.ietf.org/doc/html/draft-ietf-tsvwg-intserv-multiple-tspec-02>。
[ITAT] "IAB Workshop on Internet Technology Adoption and Transition (ITAT) 2013", December 2013, <https://www.iab.org/activities/workshops/itat/>.
[ITAT] 2013年12月、<https://www.iab.org/activities/workshops/itat/>。
[model-t] "Model-t -- Discussions of changes in Internet deployment patterns and their impact on the Internet threat model", model-t mailing list, <https://www.iab.org/mailman/listinfo/model-t>.
[MODEL-T] "MODEL-T - インターネット展開パターンの変更の議論とインターネット脅威モデルへの影響"、Model-Tメーリングリスト、<https://www.iab.org/mailman/listinfo/model-t>。
[MOPS-109-Min] "Media Operations Working Group - IETF 109 Minutes", November 2020, <https://datatracker.ietf.org/meeting/109/materials/ minutes-109-mops-00>.
[MOPS-109-MIN] "メディアオペレーションワーキンググループ - IETF 109分"、2020年11月、<https：//datatracker.ietf.org/meeting/109/109/materials/ minutes-109-MOPS-00>。
[MP-TCP] "Multipath TCP Working Group Home Page", <https://datatracker.ietf.org/wg/mptcp/>.
[MP-TCP] "マルチパスTCPワーキンググループのホームページ"、<https://datatracker.ietf.org/wg/mptcp/>。
[NANOG-35] "NANOG 35 Agenda", North American Network Operators' Group (NANOG), October 2005, <https://archive.nanog.org/meetings/nanog35/agenda>.
[Nanog-35]「Nanog 35議題」、北米ネットワーク事業者のグループ（Nanog）、2005年10月、<https：//artive.nanog.org/meetings/nanog35/agenda>。
[NSIS-CHARTER-2001] "Next Steps In Signaling Working Group Charter", March 2011, <https://datatracker.ietf.org/doc/charter-ietf-nsis/>.
[NSIS-CHARTER-2001]「シグナリングワーキンググループチャーターの次のステップ」、2011年3月、<https：//datatracker.ietf.org/doc/charter-ietf-nsis/>。
[PANRG] "Path Aware Networking Research Group Home Page", <https://irtf.org/panrg>.
[Panrg] "Path Aware Networking Research Groupのホームページ"、<https://irtf.org/panrg>。
[PANRG-103-Min] "Path Aware Networking Research Group - IETF 103 Minutes", November 2018, <https://datatracker.ietf.org/doc/minutes-103-panrg/>.
[Panrg-103 - min] "Path Aware Networking Research Group - 2018年11月、2018年11月、https://datatracker.ietf.org/doc/minutes-103-panrg/>。
[PANRG-105-Min] "Path Aware Networking Research Group - IETF 105 Minutes", July 2019, <https://datatracker.ietf.org/doc/minutes-105-panrg/>.
[Panrg-105 - min] "PATH Aware Networking Research Group - IETF 105分"、<https://datatracker.ietf.org/doc/minutes-105-panrg/>。
[PANRG-106-Min] "Path Aware Networking Research Group - IETF 106 Minutes", November 2019, <https://datatracker.ietf.org/doc/minutes-106-panrg/>.
[Panrg-106 - min] "Path Aware Networking Research Group - IETF 106分"、2019年11月、<https：//datatracker.ietf.org/doc/minutes-106-panrg/>
[PANRG-110] "Path Aware Networking Research Group - IETF 110", March 2021, <https://datatracker.ietf.org/meeting/110/session/panrg>.
[PANRG-110]「PANRG-110」「PATH AWARE NetWorking Research Group - 2021年3月、https://datatracker.ietf.org/meeting/110/session/panrg>。
[PANRG-99] "Path Aware Networking Research Group - IETF 99", July 2017, <https://datatracker.ietf.org/meeting/99/session/panrg>.
[Panrg-99]「PANRG-99」2017年7月、<https://datatracker.ietf.org/meeting/99/session/panrg>。
[PANRG-PATH-PROPERTIES] Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path Properties", Work in Progress, Internet-Draft, draft-irtf-panrg-path-properties-02, 22 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-path-properties-02>.
[Panrg-Path-Properties] enghardt、T.およびC.Krähenbühl、 "Path Propertiesの語彙"、進行中の作業、インターネットドラフト、ドラフト - IRTF-PANRG-PATH-PROPESTION-02,22,22,22,22,22,22,202,22：//datatracker.ietf.org/doc/html/draft-irtf-panrg-path-properties-02>。
[PANRG-QUESTIONS] Trammell, B., "Current Open Questions in Path Aware Networking", Work in Progress, Internet-Draft, draft-irtf-panrg-questions-09, 16 April 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-questions-09>.
[Panrg-Quession] Trammell、B.、「Path Aware Networkingの現在の開いた質問」、進行中の作業、インターネットドラフト、ドラフト - IRTF-Panrg-Question-09,2021、<https：//datatracker.ietf.org / doc / html / draft-irtf-panrg-question-09>。
[PATH-Decade] Bonaventure, O., "A Decade of Path Awareness", July 2017, <https://datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/>.
[Path-Decade] Bonaventure、O.、「Peaty Of Path Awareness」、2017年7月、<https：//datatracker.ietf.org/doc/slides-99-panrg-a-decade-of-path-awareness/>。
[QS-SAT] Secchi, R., Sathiaseelan, A., Potortì, F., Gotta, A., and G. Fairhurst, "Using Quick-Start to enhance TCP-friendly rate control performance in bidirectional satellite networks", DOI 10.1002/sat.929, May 2009, <https://dl.acm.org/citation.cfm?id=3160304.3160305>.
[QS-SAT] Sechi、R.、SathiaseLan、A.、PotoRtò、F.、Gotta、A.、G. FairHurst、「双方向衛星ネットワークにおけるTCP対応率制御性能の向上」、DOI2009年5月、<https：//dl.acm.org/catute.cfm?id=3160304.3160305>
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1016] Prue, W. and J. Postel, "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)", RFC 1016, DOI 10.17487/RFC1016, July 1987, <https://www.rfc-editor.org/info/rfc1016>.
[RFC1016] PRUE、W。およびJ. POSTEL、「ホストがソースクエンチでできること：ソースクエンチは遅延（Squid）」、RFC 1016、DOI 10.17487 / RFC1016、1987年7月、<https：// www。rfc-editor.org/info/rfc1016>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[RFC1190] Topolcic, C., "Experimental Internet Stream Protocol: Version 2 (ST-II)", RFC 1190, DOI 10.17487/RFC1190, October 1990, <https://www.rfc-editor.org/info/rfc1190>.
[RFC1190] Topolcic、C.、「実験的なインターネットストリームプロトコル：バージョン2（ST-II）」、RFC 1190、DOI 10.17487 / RFC1190、1990年10月、<https：//www.rfc-editor.org/info/rfc1190>。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, <https://www.rfc-editor.org/info/rfc1633>.
[RFC1633] Braden、R.、Clark、D.、S. Shenker、「インターネットアーキテクチャにおける統合サービス：概要」、RFC 1633、DOI 10.17487 / RFC1633、1994年6月、<https：//www.rfc-editor.org/info/rfc1633>。
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, DOI 10.17487/RFC1809, June 1995, <https://www.rfc-editor.org/info/rfc1809>.
[RFC1809]パートリッジ、C、「IPv6のフローラベルフィールドの使用」、RFC 1809、DOI 10.17487 / RFC1809、1995年6月、<https://www.rfc-editor.org/info/rfc1809>。
[RFC1819] Delgrossi, L., Ed. and L. Berger, Ed., "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, DOI 10.17487/RFC1819, August 1995, <https://www.rfc-editor.org/info/rfc1819>.
[RFC1819] Delgrossi、L.、ED。1995年8月、<https://www.rfc-editor.org/info/RFC1819>。
[RFC1887] Rekhter, Y., Ed. and T. Li, Ed., "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, DOI 10.17487/RFC1887, December 1995, <https://www.rfc-editor.org/info/rfc1887>.
[RFC1887] REKHTER、Y、ED。そして、「IPv6ユニキャストアドレス割り当てのためのアーキテクチャ」、RFC 1887、DOI 10.17487 / RFC1887、1995年12月、<https：//www.rfc-editor.org/info/rfc1887>。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, DOI 10.17487/RFC2001, January 1997, <https://www.rfc-editor.org/info/rfc2001>.
[RFC2001] Stevens、W。、「TCPスロースタート、輻輳回避、高速再送アルゴリズム」、RFC 2001、DOI 10.17487 / RFC2001、1997年1月、<https：//www.rfc-editor.org/info/ RFC2001>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、DOI10.17487 / RFC2205、1997年9月、<https：//www.rfc-editor.org/info/rfc2205>。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, <https://www.rfc-editor.org/info/rfc2210>.
[RFC2210] Wroclawski、J。、「IETF統合サービスを使用したRSVPの使用」、RFC 2210、DOI 10.17487 / RFC2210、1997年9月、<https：//www.rfc-editor.org/info/rfc2210>。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, DOI 10.17487/RFC2211, September 1997, <https://www.rfc-editor.org/info/rfc2211>.
[RFC2211] wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC 2211、DOI 10.17487 / RFC2211、1997年9月、<https：//www.rfc-editor.org/info/rfc2211>。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, DOI 10.17487/RFC2212, September 1997, <https://www.rfc-editor.org/info/rfc2212>.
[RFC2212] Shenker、S.、Partridge、C、C、およびR.Guerin、「保証されたサービス品質の仕様」、RFC 2212、DOI 10.17487 / RFC2212、1997年9月、<https：//www.rfc-editor.org/ info / rfc2212>。
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, DOI 10.17487/RFC2215, September 1997, <https://www.rfc-editor.org/info/rfc2215>.
[RFC2215] Shenker、S.およびJ.Wroclawski、「統合サービスネットワーク要素の一般的な特性パラメータ」、RFC 2215、DOI 10.17487 / RFC2215、1997年9月、<https：//www.rfc-editor.org/info/rfc2215>。
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, <https://www.rfc-editor.org/info/rfc2309>.
[RFC2309] Braden、B.、Clark、D.、Crowcroft、J.、Davie、B.、The、S.、Estrin、D.、Floyd、S.、Jacobson、V.、Minshall、G.、Partridge、C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J.、およびL. Zhang、「インターネットにおけるキュー管理および輻輳回避に関する推奨事項」、RFC 2309、DOI 10.17487 / RFC2309、4月1998年、<https：//www.rfc-editor.org/info/rfc2309>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2460]「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<https://www.rfc-editor.org/info/RFC2460>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW.Weiss、「差別化サービスのためのアーキテクチャ」、RFC 2475、DOI 10.17487 / RFC2475、12月1998年、<https：//www.rfc-editor.org/info/rfc2475>。
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, DOI 10.17487/RFC2481, January 1999, <https://www.rfc-editor.org/info/rfc2481>.
[RFC2481] Ramakrishnan、K.およびS.フロイド、「明示的輻輳通知（ECN）への明示的な輻輳通知（ECN）を追加することの提案、RFC 2481、DOI 10.17487 / RFC2481、1999年1月、<https：//www.rfc-editor.org/ info / rfc2481>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168] Ramakrishnan、K.、Floyd、S.、およびD. Black、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。rfc-editor.org/info/rfc3168>。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, DOI 10.17487/RFC3697, March 2004, <https://www.rfc-editor.org/info/rfc3697>.
[RFC3697] Rajahalme、J.、Conta、A.、Carpenter、B.、およびS.THERERE、「IPv6フローラベル仕様」、RFC 3697、DOI 10.17487 / RFC3697、2004年3月、<https：//www.rfc-editor.org/info/rfc3697>。
[RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of-Service Signaling Protocols", RFC 4094, DOI 10.17487/RFC4094, May 2005, <https://www.rfc-editor.org/info/rfc4094>.
[RFC4094]マナー、J.およびX.FU、「既存のサービス品質シグナリングプロトコルの分析」、RFC 4094、DOI 10.17487 / RFC4094、2005年5月、<https：//www.rfc-editor.org/info/ RFC4094>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, January 2007, <https://www.rfc-editor.org/info/rfc4782>.
[RFC4782] Floyd、S.、Allman、M.、Jain、A.、およびP.Sarolahti、「TCPおよびIPのクイックスタート」、RFC 4782、DOI 10.17487 / RFC4782、2007年1月、<HTTPS：// WWW.rfc-editor.org / info / rfc4782>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <https://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、C. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、2007年10月、<https：//www.rfc-editor.org/info/rfc5082>。
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.
[RFC5218] Thaler、D.およびB. Aboba、「正常なプロトコルのために何が成功させるのか」、RFC 5218、DOI 10.17487 / RFC5218、2008年7月、<https：//www.rfc-editor.org/info/rfc5218>。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5533] Nordmark、E.およびM. Bagnulo、「Shim6：Level 3マルチホームシムプロトコル」、RFC 5533、DOI 10.17487 / RFC5533、2009年6月、<https：//www.rfc-editor.org/info/RFC5533>。
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>.
[RFC5575] Marques、P.、Sheth、N.、Raszuk、R.、Greene、B.、Mauch、J.、およびD. McPherson、「フロー仕様規則の普及」、RFC 5575、DOI 10.17487 / RFC5575、8月2009年、<https://www.rfc-editor.org/info/rfc5575>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https：//www.rfc-editor.org/info/RFC5681>。
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <https://www.rfc-editor.org/info/rfc5971>.
[RFC5971] Schulzrinne、H.およびR.Hancock、 "Gist：General Internet Signaling Transport"、RFC 5971、DOI 10.17487 / RFC 5971、2010年10月、<https：//www.rfc-editor.org/info/rfc5971>。
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, DOI 10.17487/RFC5973, October 2010, <https://www.rfc-editor.org/info/rfc5973>.
[RFC5973] Stiemerling、M.、Tschofenig、H.、ON、C.、E. Davies、 "NAT / Firewall NSIシグナリング層プロトコル（NSLP）"、RFC 5973、DOI 10.17487 / RFC5973、2010年10月、<https：//www.rfc-editor.org/info/rfc5973>。
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, <https://www.rfc-editor.org/info/rfc5974>.
[RFC5974] MAY、J.、Karagiannis、G.、およびA.McDonald、「サービス品質シグナリング用NSIシグナリング層プロトコル（NSLP）」、RFC 5974、DOI 10.17487 / RFC5974、2010年10月、<https：//www.rfc-editor.org/info/rfc5974>。
[RFC5981] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, Ed., "Authorization for NSIS Signaling Layer Protocols", RFC 5981, DOI 10.17487/RFC5981, February 2011, <https://www.rfc-editor.org/info/rfc5981>.
[RFC5981] Many、J.、Stiemerling、M.、Tschofenig、H.、およびR.bless、ed。、「NSIシグナリング層プロトコルの承認」、RFC 5981、DOI 10.17487 / RFC5981、2011年2月、<https：//www.rfc-editor.org/info/rfc5981>。
[RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 2011, <https://www.rfc-editor.org/info/rfc6294>.
[RFC6294] HU、Q.およびB. Carpenter、RFC 6294、DOI 10.17487 / RFC6294、2011年6月、<https：//ww.rfc-editor.org/info/ RFC6294>。
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6398] Le Faucheur、F.、ED。、「IPルータアラートの考慮事項と使用方法」、BCP 168、RFC 6398、DOI 10.17487 / RFC6398、2011年10月、<https：//www.rfc-editor.org/info/RFC6398>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ.Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B.およびS. Amante、「トンネルの同等のコストマルチパスルーティングのためのIPv6フローラベルの使用」、RFC 6438、DOI 10.17487 / RFC6438、2011年11月、<https：//www.rfc-editor.org/info/rfc6438>
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.
[RFC6633] gont、f。、「ICMPソースクエンチメッセージの非推奨」、RFC 6633、DOI 10.17487 / RFC6633、2012年5月、<https://www.rfc-editor.org/info/rfc6633>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y.、およびM. Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<https：//www.rfc-editor.org/info/rfc6928>。
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, <https://www.rfc-editor.org/info/rfc7305>.
[RFC7305]「IABワークショップからのIABワークショップからのIABワークショップからの報告」、RFC 7305、DOI 10.17487 / RFC7305、2014年7月、<https：//www.rfc-編集者。ORG / INFO / RFC7305>。
[RFC7418] Dawkins, S., Ed., "An IRTF Primer for IETF Participants", RFC 7418, DOI 10.17487/RFC7418, December 2014, <https://www.rfc-editor.org/info/rfc7418>.
[RFC7418] Dawkins、S。、「IETF参加者用のIRTFプライマー」、RFC 7418、DOI 10.17487 / RFC7418、2014年12月、<https://www.rfc-editor.org/info/rfc7418>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、およびG.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/ info / rfc8085>。
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8170] Thaler、D.、ED。、「プロトコル採用とその後の移行の計画」、RFC 8170、DOI 10.17487 / RFC8170、<https：//www.rfc-editor.org/info/rfc8170>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
[RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology", RFC 8793, DOI 10.17487/RFC8793, June 2020, <https://www.rfc-editor.org/info/rfc8793>.
[RFC8793] Wissingh、B.、Wood、C.、Afanasyev、A.、Zhang、L.、Oran、D.、およびC.Tschudin、C.Tschudin、「情報中心のネットワーキング（ICN）：Content-Centric Networking（CCNX）名前付きデータネットワーキング（NDN）用語 "、RFC 8793、DOI 10.17487 / RFC8793、2020年6月、<https://www.rfc-editor.org/info/rfc8793>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ED。そして、「Q. Thomson」、「QUIC：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487 / RFC9000、<https：//www.rfc-editor.org/info/rfc9000>。
[SAAG-105-Min] "Security Area Open Meeting - IETF 105 Minutes", July 2019, <https://datatracker.ietf.org/meeting/105/materials/ minutes-105-saag-00>.
[SAAG-105 - 分]「セキュリティエリアオープンミーティング - 2019年7月、https://datatracker.ietf.org/meeting/105/Materials/ minutes-105-Saag-00>。
[SAF07] Sarolahti, P., Allman, M., and S. Floyd, "Determining an appropriate sending rate over an underutilized network path", Computer Networks: The International Journal of Computer and Telecommunications Networking, Volume 51, Number 7, DOI 10.1016/j.comnet.2006.11.006, May 2007, <https://dl.acm.org/doi/10.1016/j.comnet.2006.11.006>.
[SAF07] Sarolahti、P.、Allman、M.、およびS. Floyd、「低されていたネットワーク経路に対する適切な送信速度の決定」、コンピュータネットワーク：コンピュータと電気通信ネットワーキング、ボリューム51、Number 7、DOI2007年5月、<https：//dl.acm.org/doi/10.1016/j.comnet.2006.11.006>。
[SallyFloyd] Floyd, S., "ECN (Explicit Congestion Notification) in TCP/ IP", June 2009, <https://www.icir.org/floyd/ecn.html>.
[SallyFloyd] Floyd、S.、TCP / IPの「ECN（明示的な輻輳通知）」、2009年6月、<https：//www.icir.org/floyd/ecn.html>。
[Sch11] Scharf, M., "Fast Startup Internet Congestion Control for Broadband Interactive Applications", Ph.D. Thesis, University of Stuttgart, April 2011.
[SCH11] Scharf、M。、「ブロードバンド対話型アプリケーションのための高速スタートアップインターネット輻輳制御」、PH.D。Stuttgart大学、2011年4月。
[Shim6-35] Meyer, D., Huston, G., Schiller, J., and V. Gill, "IAB IPv6 Multihoming Panel at NANOG 35", North American Network Operators' Group (NANOG), October 2005, <https://www.youtube.com/watch?v=ji6Y_rYHAQs>.
[Shim6-35] Meyer、D.、Huston、G.、Schiller、J.、およびV. Gill、2005年10月、2005年10月、<HTTPS）：//www.youtube.com/watch？v = ji6y_ryhaqs>。
[TRIGTRAN-55] "Triggers for Transport BOF at IETF 55", November 2002, <https://www.ietf.org/proceedings/55/239.htm>.
[TRIGTRAN-55]「Transport BofのTriggers for IETF 55」、2002年11月、<https：//www.ietf.org/proceedings/55/239.htm>。
[TRIGTRAN-56] "Triggers for Transport BOF at IETF 56", March 2003, <https://www.ietf.org/proceedings/56/251.htm>.
[TRIGTRAN-56]「AT Transport BofのIETF 56」、<https://www.ietf.org/proceedings/56/251.htm>。
[vista-impl] Sridharan, M., Bansal, D., and D. Thaler, "Implementation Report on Experiences with Various TCP RFCs", March 2007, <https://www.ietf.org/proceedings/68/slides/tsvarea-3/ sld1.htm>.
[Vista-Incl] Sridharan、M.、Bansal、D.、D. Thaler、2007年3月、<https：//www.ietf.org/proceedings/68/Slides/ TSVAREA-3 / SLD1.HTM>。
Acknowledgments
謝辞
Initial material for Section 6.1 on ST2 was provided by Gorry Fairhurst.
ST2のセクション6.1の初期材料は、Gorry Fairhurstによって提供されました。
Initial material for Section 6.2 on IntServ was provided by Ron Bonica.
INTSERVのセクション6.2の初期材料はRON BONINAによって提供されました。
Initial material for Section 6.3 on Quick-Start TCP was provided by Michael Scharf, who also provided suggestions to improve this section after it was edited.
Quick-Start TCPのセクション6.3の初期資料は、編集後にこのセクションを改善するための提案を提供したMichael Scharfによって提供されました。
Initial material for Section 6.4 on ICMP Source Quench was provided by Gorry Fairhurst.
ICMPソースクエンチのセクション6.4の初期素材は、Gorry Fairhurstによって提供されました。
Initial material for Section 6.5 on Triggers for Transport (TRIGTRAN) was provided by Spencer Dawkins.
輸送用トリガ（TRIGTRAN）の節6.5の初期材料は、Spencer Dawkinsによって提供されました。
Section 6.6 on Shim6 builds on initial material describing obstacles, which was provided by Erik Nordmark, with background added by Spencer Dawkins.
Shim6のセクション6.6は、Spencer Dawkinsによって追加された背景を持つ、エリックノルドマークによって提供された障害物を記述した初期資料に基づいて構築されています。
Initial material for Section 6.7 on Next Steps in Signaling (NSIS) was provided by Roland Bless and Martin Stiemerling.
シグナリング（NSI）の次のステップについてのセクション6.7の初期資料は、ROLAND BRESSTとMARTIN STIIEMERLINGによって提供されました。
Initial material for Section 6.8 on IPv6 Flow Labels was provided by Gorry Fairhurst.
IPv6フローラベルでのセクション6.8の初期素材は、Gorry Fairhurstによって提供されました。
Initial material for Section 6.9 on Explicit Congestion Notification was provided by Spencer Dawkins.
明示的な輻輳通知に関する第6.9節の初期資料は、スペンサーDawkinsによって提供されました。
Our thanks to Adrian Farrel, Bob Briscoe, C.M. Heard, David Black, Eric Kinnear, Erik Auerswald, Gorry Fairhurst, Jake Holland, Joe Touch, Joeri de Ruiter, Kireeti Kompella, Mohamed Boucadair, Randy Presuhn, Roland Bless, Ruediger Geib, Theresa Enghardt, and Wes Eddy, who provided review comments on this document as a "work in process".
Adrian Farrel、Bob Briscoe、C.M.ジェイクオランダ、ジョータッチ、ジョリーデュクッラ、ジェリーデュクッラ、ジョリードゥルナ、ジョリードゥリューダー、ジョリードゥリューダー、ジェリーデュクッエラ、Randy Presuhn、Randy Presuhn、Redy Presuhn、Rasy Presuhn、Redy Presuhn、Redy Presuhn、Redy Presunn、Rediiger Geib、Theresa enghardt、およびレビューコメントを提供したWes Eddyこの文書では「処理中の作業」として。
Mallory Knodel reviewed this document for the Internet Research Steering Group and provided many helpful suggestions.
Mallory Knodelこの文書をインターネットリサーチステアリンググループのためにレビューし、多くの有用な提案を提供しました。
David Oran also provided helpful comments and text suggestions on this document during Internet Research Steering Group balloting. In particular, Section 5 reflects his review.
David Oranは、インターネットリサーチステアリンググループの投票中に、この文書に関する役立つコメントやテキストの提案も提供しました。特に、セクション5は彼のレビューを反映しています。
Benjamin Kaduk, Martin Duke, and Rob Wilton provided helpful comments during Internet Engineering Steering Group conflict review.
Benjamin Kaduk、Martin Duke、Rob Wiltonは、インターネットエンジニアリングステアリンググループの競合レビュー中に役立つコメントを提供しました。
Special thanks to Adrian Farrel for helping Spencer navigate the twisty little passages of Flow Specs and Filter Specs in IntServ, RSVP, MPLS, and BGP. They are all alike, except when they are different [Colossal-Cave].
スペンサーを支援するためのAdrian Farrelに感謝します。彼らは違う[コロサル洞窟]を除いて、それらはすべて似ています。
Author's Address
著者の住所
Spencer Dawkins (editor) Tencent America United States of America
Spencer Dawkins（編集）Tencent Americaアメリカ
Email: spencerdawkins.ietf@gmail.com