[要約] RFC 4222は、特定のOSPFバージョン2パケットの優先処理と過負荷回避に関するガイドラインです。このRFCの目的は、ネットワークのパフォーマンスを向上させ、過負荷状態でのパケットの喪失を防ぐことです。
Network Working Group G. Choudhury, Ed.
Request for Comments: 4222 AT&T
BCP: 112 October 2005
Category: Best Current Practice
Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
特定のOSPFバージョン2パケットの優先順位のある扱いと混雑回避
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures.
このドキュメントでは、Open Shortest Path First（OSPF）バージョン2プロトコルを使用して、大規模ネットワークのスケーラビリティと安定性を改善することを目的とした方法を推奨しています。この方法には、OSPF Hellosを処理し、他のOSPFパケットと比較してより高い優先度で状態広告（LSA）の謝辞をリンクし、その他の混雑回避手順が含まれます。
Table of Contents
目次
1. Introduction...................................................2
2. Recommendations................................................3
3. Security Considerations........................................6
4. Acknowledgments................................................6
5. Normative References...........................................6
6. Informative References.........................................7
Appendix A. LSA Storm: Causes and Impact..........................8
Appendix B. List of Variables and Values.........................10
Appendix C. Other Recommendations and Suggestions................11
In this document, OSPF refers to OSPFv2 [Ref1]. The scalability and stability improvement techniques described here may also apply to OSPFv3 [Ref2], but that will require further study and operational experience.
このドキュメントでは、OSPFはOSPFv2 [Ref1]を指します。ここで説明するスケーラビリティと安定性の改善技術は、OSPFV3 [Ref2]にも適用される場合がありますが、さらなる研究と運用の経験が必要になります。
A large network running OSPF protocol may occasionally experience the simultaneous or near-simultaneous update of a large number of link state advertisements, or LSAs. This is particularly true if OSPF traffic engineering extension [Ref3] is used that may significantly increase the number of LSAs in the network. We call this event an LSA storm and it may be initiated by an unscheduled failure or a scheduled maintenance event. The failure may be hardware, software, or procedural in nature.
OSPFプロトコルを実行している大規模なネットワークでは、多数のリンク状態広告またはLSAの同時またはほぼ同時に更新される場合があります。これは、ネットワーク内のLSAの数を大幅に増加させる可能性のあるOSPFトラフィックエンジニアリング拡張[Ref3]を使用する場合に特に当てはまります。このイベントをLSAストームと呼び、予定外の障害またはスケジュールされたメンテナンスイベントによって開始される場合があります。障害は、本質的にハードウェア、ソフトウェア、または手続き上の手続きです。
The LSA storm causes high CPU and memory utilization at the router causing incoming packets to be delayed or dropped. Delayed acknowledgments (beyond the retransmission timer value) result in retransmissions, and delayed Hello packets (beyond the router-dead interval) result in neighbor adjacencies being declared down. The retransmissions and additional LSA originations result in further CPU and memory usage, essentially causing a positive feedback loop, which, in the extreme case, may drive the network to an unstable state.
LSAストームは、ルーターで高いCPUとメモリの利用を引き起こし、着信パケットを遅延またはドロップします。遅延承認（再送信タイマーの値を超えて）は、再送信をもたらし、ハローパケットを遅らせる（ルーターデッド間隔を超えて）隣接する隣接が宣言されます。再送信と追加のLSAの起源により、さらにCPUとメモリの使用が得られ、本質的に肯定的なフィードバックループが発生します。
The default value of the retransmission timer is 5 seconds and that of the router-dead interval is 40 seconds. However, recently there has been a lot of interest in significantly reducing OSPF convergence time. As part of that plan, much shorter (sub-second) Hello and router-dead intervals have been proposed [Ref4]. In such a scenario, it will be more likely for Hello packets to be delayed beyond the router-dead interval during network congestion caused by an LSA storm.
再送信タイマーのデフォルト値は5秒で、ルーターデッド間隔の値は40秒です。しかし、最近、OSPF収束時間を大幅に短縮することに多くの関心がありました。その計画の一環として、はるかに短い（サブ秒）ハローとルーターのデッド間隔が提案されています[Ref4]。このようなシナリオでは、LSAストームによって引き起こされるネットワーク輻輳中に、ハローパケットがルーターデッド間隔を超えて遅延する可能性が高くなります。
In order to improve the scalability and stability of networks, we recommend steps for prioritizing critical OSPF packets and avoiding congestion. The details of the recommendations are given in Section 2. A simulation study is reported in [Ref13] that quantifies the congestion phenomenon and its impact. It also studies several of the recommendations and shows that they indeed improve the scalability and stability of networks using OSPF protocol. [Ref13] is available on request by contacting the editor or one of the authors.
ネットワークのスケーラビリティと安定性を向上させるために、重要なOSPFパケットに優先順位を付け、混雑を回避するための手順をお勧めします。推奨事項の詳細は、セクション2に記載されています。SimulationSyutionは、輻輳現象とその影響を定量化する[Ref13]に報告されています。また、いくつかの推奨事項を研究し、OSPFプロトコルを使用してネットワークのスケーラビリティと安定性を実際に改善することを示しています。[Ref13]は、編集者または著者の1人に連絡して、リクエストに応じて利用できます。
Appendix A explains in more detail LSA storm scenarios, their impact, and points out a few real-life examples of control-message storms. Appendix B provides a list of variables used in the recommendations and their example values. Appendix C provides some further recommendations and suggestions with similar goals.
付録Aでは、LSAストームシナリオ、その影響を詳細に説明し、コントロールメサージストームのいくつかの実生活の例を指摘しています。付録Bでは、推奨事項とその例の値で使用される変数のリストを提供します。付録Cは、同様の目標を持ついくつかのさらなる推奨事項と提案を提供します。
The recommendations below are intended to improve the scalability and stability of large networks using OSPF protocol. During periods of network congestion, they would reduce retransmissions, avoid an adjacency to be declared down due to Hello packets being delayed beyond the RouterDeadInterval, and take other congestion avoidance steps. The recommendations are unordered except that Recommendation 2 is to be implemented only if Recommendation 1 is not implemented.
以下の推奨事項は、OSPFプロトコルを使用した大規模ネットワークのスケーラビリティと安定性を改善することを目的としています。ネットワークの輻輳の期間中、彼らは再送信を減らし、routerdeadedIntervalを超えてハローパケットが遅れているため宣言される隣接性を回避し、他の輻輳回避の手順を実行します。推奨事項は、推奨事項1が実装されていない場合にのみ実装されることを除いて、推奨事項が順序付けられていません。
(1) Classify all OSPF packets in two classes: a "high priority" class comprising OSPF Hello packets and Link State Acknowledgement packets, and a "low priority" class comprising all other packets. The classification is accomplished by examining the OSPF packet header. While receiving a packet from a neighbor and while transmitting a packet to a neighbor, try to process a "high priority" packet ahead of a "low priority" packet.
(1) すべてのOSPFパケットを2つのクラスで分類します。OSPFハローパケットとリンク状態確認パケットを含む「高優先度」クラスと、他のすべてのパケットを含む「優先度の低い」クラス。分類は、OSPFパケットヘッダーを調べることで実現されます。隣人からパケットを受け取り、隣人にパケットを送信している間、「優先度の低い」パケットよりも先に「優先度の高い」パケットを処理してみてください。
The prioritized processing while transmitting may cause OSPF packets from a neighbor to be received out of sequence. If Cryptographic Authentication (AuType = 2) is used (as specified in [Ref1]), then successive received valid OSPF packets from a neighbor need to have a non-decreasing "Cryptographic sequence number". To comply with this requirement, we recommend that in case Cryptographic Authentication (AuType = 2) is used [Ref1], prioritized processing not be done at the transmitter. This will avoid packets arriving at the receiver out of sequence. However, after security processing at the receiver (including sequence number checking) is complete, the OSPF packets may be kept in a "high priority" queue or a "low priority" queue based on their class and processed accordingly. The benefit of prioritized processing is clearly higher in the absence of Cryptographic Authentication since in that case prioritization can be implemented both at the transmitter and at the receiver. However, even with Cryptographic Authentication it will be beneficial to have prioritization only at the receiver (following security processing).
送信中の優先処理により、隣人からのOSPFパケットが順番から受信される可能性があります。暗号化認証（Autype = 2）が使用されている場合（[Ref1]で指定されているように）、隣人から連続して受信した有効なOSPFパケットは、非断続的な「暗号化シーケンス番号」を持つ必要があります。この要件に準拠するために、暗号化（Autype = 2）が[Ref1]を使用する場合、Transmitterで優先処理を行わない場合をお勧めします。これにより、受信機にシーケンスから到着するパケットが到着しません。ただし、受信機でのセキュリティ処理（シーケンス番号チェックを含む）が完了した後、OSPFパケットは「優先度の高い」キューまたはクラスに基づいて「低い優先度」キューに保持され、それに応じて処理されます。優先順位付けされた処理の利点は、その場合、優先順位付けを送信機と受信機の両方で実装できるため、暗号化認証の存在下では明らかに高くなっています。ただし、暗号化認証があっても、受信機でのみ優先順位付けを行うことが有益です（セキュリティ処理後）。
(2) If Recommendation 1 cannot be implemented, then reset the inactivity timer for an adjacency whenever any OSPF unicast packet or any OSPF packet sent to AllSPFRouters over a point-to-point link is received over that adjacency instead of resetting the inactivity timer only on receipt of the Hello packet. So OSPF would declare the adjacency to be down only if no OSPF unicast packets or no OSPF packets sent to AllSPFRouters over a point-to-point link are received over that adjacency for a period equaling or exceeding the RouterDeadInterval. The reason for not recommending this proposal in conjunction with Recommendation 1 is to avoid potential undesirable side effects. One such effect is the delay in discovering the down status of an adjacency in a case where no high priority Hello packets are being received but the inactivity timer is being reset by other stale packets in the low priority queue.
(2) 推奨事項1を実装できない場合は、OSPFユニキャストパケットまたはポイントツーポイントリンクを介してAllSPFRouterに送信されるOSPFユニキャストパケットまたはOSPFパケットがいつでも隣接する場合には、隣接する隣接する場合には、不活性タイマーをリセットした場合にのみ、不活性タイマーをリセットした場合にのみ、隣接する不活性タイマーをリセットします。ハローパケット。したがって、OSPFは、OSPFユニキャストパケットまたはポイントツーポイントリンクを介してAllSPFRouterに送信されたOSPFパケットがない場合にのみ、隣接性が低下していると宣言します。この提案を推奨1と併せて推奨しない理由は、潜在的な望ましくない副作用を避けるためです。そのような効果の1つは、優先度の高いハローパケットが受信されていないが、不活性タイマーが低優先度キューの他の古いパケットによってリセットされている場合、隣接のダウンステータスを発見する遅延です。
(3) Use an exponential backoff algorithm for determining the value of the LSA retransmission interval (RxmtInterval). Let R(i) represent the RxmtInterval value used during the i-th retransmission of an LSA. Use the following algorithm to compute R(i).
(3) LSA再送信間隔（RXMTINTERVAL）の値を決定するために、指数バックオフアルゴリズムを使用します。r（i）は、LSAのith再送信中に使用されるrxmtinterval値を表します。次のアルゴリズムを使用して、r（i）を計算します。
R(1) = Rmin
R(i+1) = Min(KR(i),Rmax) for i>=1
where K, Rmin, and Rmax are constants and the function Min(.,.) represents the minimum value of its two arguments. Example values for K, Rmin, and Rmax may be 2, 5, and 40 seconds, respectively. Note that the example value for Rmin, the initial retransmission interval, is the same as the sample value of RxmtInterval in [Ref1].
ここで、k、rmin、およびrmaxは定数であり、関数min（。、。）はその2つの引数の最小値を表します。K、RMIN、およびRMAXの例の例は、それぞれ2、5、および40秒である場合があります。最初の再送信間隔であるRMINの例の値は、[ref1]のrxmtintervalのサンプル値と同じであることに注意してください。
This recommendation is motivated by the observation that during a network congestion event caused by control messages, a major source for sustaining the congestion is the repeated retransmission of LSAs. The use of an exponential backoff algorithm for the LSA retransmission interval reduces the rate of LSA retransmissions while the network experiences congestion (during which it is more likely that multiple retransmissions of the same LSA would happen). This in turn helps the network get out of the congested state.
この推奨事項は、コントロールメッセージによって引き起こされるネットワーク輻輳イベント中に、混雑を維持するための主要な情報源がLSAの繰り返しの再送信であるという観察によって動機付けられています。LSA再送信間隔に指数バックオフアルゴリズムを使用すると、ネットワークが混雑を発生している間、LSA再送信の速度が低下します（同じLSAの複数の再送信が発生する可能性が高くなります）。これにより、ネットワークが混雑した状態から抜け出すのに役立ちます。
(4) Implicit Congestion Detection and Action Based on That: If there is control message congestion at a router, its neighbors do not know about that explicitly. However, they can implicitly detect it based on the number of unacknowledged LSAs to this router. If this number exceeds a certain "high-water mark", then the rate at which LSAs are sent to this router should be reduced progressively using an exponential backoff mechanism but not below a certain minimum rate. At a future time, if the number of unacknowledged LSAs to this router falls below a certain "low-water mark", then the rate of sending LSAs to this router should be increased progressively, again using an exponential backoff mechanism but not above a certain maximum rate. The whole algorithm is given below. Note that this algorithm is to be applied independently to each neighbor and only for unicast LSAs sent to a neighbor or LSAs sent to AllSPFRouters over a point-to-point link.
(4) それに基づく暗黙のうっ血の検出とアクション：ルーターにコントロールメッセージの混雑がある場合、その隣人はそれについて明示的に知りません。ただし、このルーターへの未承認のLSAの数に基づいて、暗黙的に検出できます。この数値が特定の「高水マーク」を超える場合、LSAがこのルーターに送信される速度を、指数関数的なバックオフメカニズムを使用して徐々に減らす必要がありますが、特定の最小レートを下回る必要はありません。将来、このルーターへの未吸合のLSAの数が特定の「低水マーク」を下回る場合、このルーターにLSAを送信する速度は、指数関数的バックオフメカニズムを使用して、特定のバックオフメカニズムを使用して徐々に増加させる必要があります。最大レート。アルゴリズム全体を以下に示します。このアルゴリズムは、各近隣に独立して適用され、隣人またはポイントツーポイントリンクを介してAllSPFRoutersに送信されるUnicast LSAにのみ適用されることに注意してください。
Let, U(t) = Number of unacknowledged LSAs to neighbor at time t. H = A high-water mark (in units of number of unacknowledged LSAs). L = A low-water mark (in units of number of unacknowledged LSAs). G(t) = Gap between sending successive LSAs to neighbor at time t. F = The factor by which the above gap is to be increased during congestion and decreased after coming out of congestion. T = Minimum time that has to elapse before the existing gap is considered for change. Gmin = Minimum allowed value of gap. Gmax = Maximum allowed value of gap.
u（t）=時刻tで隣接する未充填のLSAの数。H =高水マーク（未吸収のLSAの数の単位）。L =低水マーク（未吸収のLSAの数の単位）。g（t）=時刻tで隣のLSAを送信する間のギャップ。f =混雑中に上記のギャップを増加させ、混雑から抜け出した後に減少する因子。t =既存のギャップが変化のために検討される前に経過しなければならない最小時間。gmin =ギャップの最小許容値。gmax =ギャップの最大許容値。
The equation below shows how the gap is to be changed after a
time T has elapsed since the last change:
_
|
| Min(FG(t),Gmax) if U(t+T) > H
G(t+T) = | G(t) if H >= U(t+T) >= L
| Max(G(t)/F,Gmin) if U(t+T) < L
|_
Min(.,.) and Max(.,.) represent the minimum and maximum values of the two arguments, respectively.
min（。、。）およびmax（。、。）は、それぞれ2つの引数の最小値と最大値を表します。
Example values for the various parameters of the algorithm are as follows: H = 20, L = 10, F = 2, T = 1 second, Gmin = 20 ms, Gmax = 1 second.
アルゴリズムのさまざまなパラメーターの例の例は次のとおりです。H= 20、L = 10、F = 2、T = 1秒、GMIN = 20 ms、GMAX = 1秒。
Recommendations 3 and 4 both slow down LSAs to congested neighbors based on implicitly detecting the congestion, but they have important differences. Recommendation 3 progressively slows down successive retransmissions of the same LSA, whereas Recommendation 4 progressively slows down all LSAs (new or retransmission) to a congested neighbor.
推奨事項3と4はどちらも、混雑を暗黙的に検出することに基づいて、混雑した隣人にLSAを遅くしますが、重要な違いがあります。推奨事項3は、同じLSAの連続的な再送信を徐々に遅くしますが、推奨4はすべてのLSA（新規または再送信）を混雑した隣人に徐々に遅くします。
(5) Throttling Adjacencies to Be Brought Up Simultaneously: If a router tries to bring up a large number of adjacencies to its neighbors simultaneously, then that may cause severe congestion due to database synchronization and LSA flooding activities. It is recommended that during such a situation no more than "n" adjacencies should be brought up simultaneously. Once a subset of adjacencies has been brought up successfully, newer adjacencies may be brought up as long as the number of simultaneous adjacencies being brought up does not exceed "n". The appropriate value of "n" would depend on the router processing power, total bandwidth available for control plane traffic, and propagation delay. The value of "n" should be configurable.
(5) 隣接する隣接を同時に育てる：ルーターが同時に隣人に多数の隣接を育てようとしようとすると、データベースの同期とLSA洪水活動のために深刻な輻輳を引き起こす可能性があります。そのような状況では、「n」隣接を同時に育てるべきではないことをお勧めします。隣接のサブセットが成功すると、育てられている同時隣接の数が「n」を超えない限り、新しい隣接が育てられる可能性があります。「n」の適切な値は、ルーター処理能力、制御プレーントラフィックに利用可能な総帯域幅、および伝播遅延に依存します。「n」の値は構成可能である必要があります。
In the presence of throttling, an important issue is the order in which adjacencies are to be formed. We recommend a First Come First Served (FCFS) policy based on the order in which the request for adjacency formation arrives. Requests may either be from neighbors or self-generated. Among the self-generated requests, a priority list may be used to decide the order in which the requests are to be made. However, once an adjacency formation process starts it is not to be preempted except for unusual circumstances such as errors or time-outs.
スロットリングの存在下では、重要な問題は、隣接が形成される順序です。隣接するフォーメーションの要求が届く順序に基づいて、First Come First Serve（FCFS）ポリシーをお勧めします。リクエストは、隣人または自己生成のいずれかです。自己生成リクエストの中で、優先リストを使用して、リクエストを行う順序を決定することができます。ただし、隣接するフォーメーションプロセスが開始されると、エラーやタイムアウトなどの異常な状況を除いて、先制することはありません。
In some of the recommendations above, we refer to point-to-point links. Those references should also include cases where a broadcast network is to be treated as a point-to-point connection from the standpoint of IP routing [Ref5]
上記の推奨事項の一部では、ポイントツーポイントリンクを参照してください。これらの参照には、IPルーティングの観点からの放送ネットワークがポイントツーポイント接続として扱われる場合も含まれている必要があります[Ref5]
This memo does not create any new security issues for the OSPF protocol.
このメモは、OSPFプロトコルの新しいセキュリティ問題を作成しません。
We would like to acknowledge the support and helpful comments from OSPF WG chairs Rohit Dube, Acee Lindem, and John Moy; Routing Area directors Alex Zinin and Bill Fenner; and IESG reviewers. We acknowledge Vivek Dube, Mitchell Erblich, Mike Fox, Tony Przygienda, and Krishna Rao for comments on previous versions of the document. We also acknowledge Margaret Chiosi, Elie Francis, Jeff Han, Beth Munson, Roshan Rao, Moshe Segal, Mike Wardlow, and Pat Wirth for collaboration and encouragement in our scalability improvement efforts for Link State Protocol-based networks.
OSPF WGチェアのRohit Dube、Acee Lindem、およびJohn Moyからのサポートと有益なコメントを認めたいと思います。ルーティングエリアディレクターのアレックスジニンとビルフェナー。およびIESGレビュアー。Vivek Dube、Mitchell Erblich、Mike Fox、Tony Przygienda、Krishna Raoに、以前のバージョンのドキュメントに関するコメントについて認めています。また、リンク状態のプロトコルベースのネットワークのためのスケーラビリティ改善の取り組みにおけるコラボレーションと励ましのために、マーガレット・キオシ、エリー・フランシス、ジェフ・ハン、ベス・マンソン、ロシャン・ラオ、モシェ・シーガル、マイク・ワードロー、パット・ワースを認めています。
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref1] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[Ref2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[Ref2] Coltun、R.、Ferguson、D。、およびJ. Moy、「IPv6のOSPF」、RFC 2740、1999年12月。
[Ref3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[Ref3] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。
[Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Millisecond IGP Convergence", Work in Progress.
[Ref4] C. Alaettinoglu、V。JacobsonおよびH. Yu、「Millisecond IGP Convergence」に向けて、進行中の作業。
[Ref5] N. Shen, A. Lindem, J. Yuan, A. Zinin, R. White and S. Previdi, "Point-to-point operation over LAN in link-state routing protocols", Work in Progress.
[Ref5] N. Shen、A。Lindem、J。Yuan、A。Zinin、R。WhiteおよびS. Previdi、「リンクステートルーティングプロトコルのLAN上のポイントツーポイント操作」、進行中の作業。
[Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net outage", Network World, February 26, 2001.
[Ref6] Pappalardo、D。、「AT＆T、顧客はATMネット停止に取り組む」、ネットワークワールド、2001年2月26日。
[Ref7] "AT&T announces cause of frame-relay network outage," AT&T Press Release, April 22, 1998.
[Ref7]「AT＆Tは、フレームレレーネットワークの停止の原因を発表します」AT＆Tプレスリリース、1998年4月22日。
[Ref8] Cholewka, K., "MCI Outage Has Domino Effect", Inter@ctive Week, August 20, 1999.
[Ref8] Cholewka、K。、「MCIの停止にはドミノ効果があります」、Inter@Ctive Week、1999年8月20日。
[Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat", Light Reading, April 6, 2001.
[Ref9] Jander、M。、「Qwest Outageでは、ATMが熱を取ります」、Light Reading、2001年4月6日。
[Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State Routing Protocols", Work in Progress.
[Ref10] A. ZininおよびM. Shand、「リンク状態のルーティングプロトコルにおける洪水の最適化」、進行中の作業。
[Ref11] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in Stable Topologies", RFC 4136, July 2005.
[Ref11] Pillay-Esnault、P。、「OSPF Refresh and Stable Topologiesの洪水削減」、RFC 4136、2005年7月。
[Ref12] G. Ash, G. Choudhury, V. Sapozhnikova, M. Sherif, A. Maunder, V. Manral, "Congestion Avoidance & Control for OSPF Networks", Work in Progress.
[Ref12] G. Ash、G。Choudhury、V。Sapozhnikova、M。Sherif、A。Maunder、V。Manral、「OSPFネットワークの混雑の回避と制御」、進行中の作業。
[Ref13] G. Choudhury, G. Ash, V. Manral, A. Maunder and V. Sapozhnikova, "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance: Algorithms and Simulations", AT&T Technical Report, August 2003.
[Ref13] G. Choudhury、G。Ash、V。Manral、A。Maunder and V. Sapozhnikova、「特定のOSPFパケットと混雑回避の治療：アルゴリズムとシミュレーション」、AT＆Tテクニカルレポート、2003年8月。
[Ref14] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[Ref14] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
An LSA storm may be initiated due to many reasons. Here are some examples:
多くの理由により、LSAストームが開始される場合があります。ここではいくつかの例を示します。
(a) one or more link failures due to fiber cuts,
(a) ファイバーカットによる1つ以上のリンク障害、
(b) one or more router failures for some reason, e.g., software crash or some type of disaster (including power outage) in an office complex hosting many routers,
(b) 何らかの理由で1つ以上のルーターの障害、例えば、多くのルーターをホストするオフィスコンプレックスでのソフトウェアクラッシュまたは何らかの災害（停電を含む）、
(c) link/router flapping,
(c) リンク/ルーターの羽ばたき、
(d) requirement of taking down and later bringing back many routers during a software/hardware upgrade,
(d) ソフトウェア/ハードウェアのアップグレード中に、削除して後で多くのルーターを取り戻すことの要件、
(e) near synchronization of the periodic 1800-second LSA refreshes of a subset of LSAs,
(e) LSAのサブセットの周期的な1800秒のLSAリフレッシュのほぼ同期、
(f) refresh of all LSAs in the system during a change in software version,
(f) ソフトウェアバージョンの変更中にシステム内のすべてのLSAの更新、
(g) injecting a large number of external routes to OSPF due to a procedural error,
(g) 手続き上のエラーにより、多数の外部ルートをOSPFに注入すると、
(h) Router ID changes causing a large number of LSA re-originations (possibly LSA purges as well depending on the implementation).
(h) ルーターIDが変更され、多数のLSAの再配置が発生します（実装に応じてLSAパージも可能性があります）。
In addition to the LSAs originated as a direct result of link/router failures, there may be other indirect LSAs as well. One example in MPLS networks is traffic engineering LSAs [Ref3] originated at other links as a result of significant changes in reserved bandwidth. These result from rerouting of Label Switched Paths (LSPs) that went down during the link/router failure. The LSA storm causes high CPU and memory utilization at the router processor causing incoming packets to be delayed or dropped. Delayed acknowledgments (beyond the retransmission timer value) results in retransmissions, and delayed Hello packets (beyond the Router-Dead interval) results in links being declared down. A trunk-down event causes router LSA origination by its end-point routers. If traffic engineering LSAs are used for each link, then that type of LSA would also be originated by the end-point routers and potentially elsewhere as well due to significant changes in reserved bandwidths at other links caused by the failure and reroute of LSPs originally using the failed trunk. Eventually, when the link recovers that would also trigger additional router LSAs and traffic engineering LSAs.
リンク/ルーターの障害の直接的な結果として生まれたLSAに加えて、他の間接LSAも存在する可能性があります。MPLSネットワークの1つの例は、予約帯域幅の大幅な変化の結果として他のリンクで発生したトラフィックエンジニアリングLSA [Ref3]です。これらは、リンク/ルーターの障害中にダウンしたラベルスイッチ付きパス（LSP）の再ルーティングに起因します。LSAストームは、ルータープロセッサで高いCPUとメモリの利用を引き起こし、着信パケットを遅延または削除します。承認の遅延（再送信タイマーの値を超えて）は、再送信をもたらし、遅延したハローパケット（ルーターデッド間隔を超えて）がリンクが宣言されるようになります。トランクダウンイベントにより、エンドポイントルーターによるルーターLSAのオリジネーションが発生します。トラフィックエンジニアリングLSAが各リンクに使用されている場合、そのタイプのLSAは、エンドポイントルーター、および他の場所でも潜在的に他の場所で発信されます。失敗したトランク。最終的に、リンクが回復すると、追加のルーターLSAとトラフィックエンジニアリングLSAもトリガーされます。
The retransmissions and additional LSA originations result in further CPU and memory usage, essentially causing a positive feedback loop. We define the LSA storm size as the number of LSAs in the original storm, not counting any additional LSAs resulting from the feedback loop described above. If the LSA storm is too large, then the positive feedback loop mentioned above may be large enough to indefinitely sustain a large CPU and memory utilization at many routers in the network, thereby driving the network to an unstable state. In the past, network outage events have been reported in IP and ATM networks using link-state protocols such as OSPF, Intermediate System to Intermediate System (IS-IS), Private Network-Network Interface (PNNI), or some proprietary variants. See for example [Ref6-Ref9]. In many of these examples, large-scale flooding of LSAs or other similar control messages (either naturally or triggered by some bug or inappropriate procedure) have been partly or fully responsible for network instability and outage.
再送信と追加のLSA発信により、さらにCPUとメモリ使用が使用され、本質的に肯定的なフィードバックループが発生します。LSAストームサイズは、上記のフィードバックループから生じる追加のLSAをカウントすることなく、元のストームのLSAの数として定義します。LSAストームが大きすぎる場合、上記の肯定的なフィードバックループは、ネットワーク内の多くのルーターで大きなCPUとメモリの利用を無期限に維持するのに十分な大きさであり、それによりネットワークを不安定な状態に駆り立てることができます。過去には、OSPF、中間システムから中間システム（IS-IS）、プライベートネットワークネットワークインターフェイス（PNNI）、または一部の独自のバリエーションなどのリンク状態プロトコルを使用して、IPおよびATMネットワークでネットワーク停止イベントが報告されてきました。たとえば[Ref6-Ref9]を参照してください。これらの例の多くでは、LSAまたはその他の同様の制御メッセージの大規模な洪水（自然またはいくつかのバグまたは不適切な手順によってトリガーされる）の大規模な洪水は、ネットワークの不安定性と停止の一部または完全に責任があります。
In [Ref13], a simulation model is used to show that there is a certain LSA storm size threshold above which the network may show unstable behavior caused by a large number of retransmissions, link failures due to missed Hello packets, and subsequent link recoveries. It is also shown that the LSA storm size causing instability may be substantially increased by providing prioritized treatment to Hello and LSA Acknowledgment packets and by using an exponential backoff algorithm for determining the LSA retransmission interval. If it is not possible to prioritize Hello packets, then resetting the inactivity timer on receiving any valid OSPF packets can also provide the same benefit. Furthermore, if we prioritize Hello packets, then even when the network operates somewhat above the stability threshold, links are not declared down due to missed Hellos. This implies that even though there is control plane congestion due to many retransmissions, the data plane stays up and no new LSAs are originated (besides the ones in the original storm and the refreshes). These observations support the first three recommendations in Section 2. The authors of this document have also done simulations to verify that the other recommendations in Section 2 help avoid congestion and allow a graceful exit from a congested state.
[Ref13]では、シミュレーションモデルを使用して、ネットワークが多数の再送信、ハローパケットの逃したためのリンク障害、およびその後のリンク回復によって引き起こされる不安定な動作を示す可能性がある特定のLSAストームサイズのしきい値があることを示します。また、HelloおよびLSAの確認パケットに優先順位付けされた治療を提供し、LSAの再送信間隔を決定するための指数的バックオフアルゴリズムを使用することにより、不安定性を引き起こすLSAストームサイズが大幅に増加する可能性があることも示されています。ハローパケットに優先順位を付けることができない場合は、有効なOSPFパケットを受信して不活性タイマーをリセットすることも同じ利点を提供できます。さらに、ハローパケットに優先順位を付けると、ネットワークが安定性のしきい値をある程度上回る場合でも、Hellosを逃したためにリンクが宣言されません。これは、多くの再送信のためにコントロールプレーンの混雑があるにもかかわらず、データプレーンが維持され、新しいLSAが発信されないことを意味します（元の嵐とリフレッシュのものを除く）。これらの観察結果は、セクション2の最初の3つの推奨事項をサポートしています。このドキュメントの著者は、セクション2の他の推奨事項がうっ血を避け、混雑状態からの優雅な出口を可能にするのに役立つことを確認するためにシミュレーションを行っています。
One might argue that the scalability issue of large networks should be solved solely by dividing the network hierarchically into multiple areas so that flooding of LSAs remains localized within areas. However, this approach increases the network management and design complexity and may result in less optimal routing between areas. Also, Autonomous System External (ASE) LSAs are flooded throughout the AS, and it may be a problem if there are large numbers of them. Furthermore, a large number of summary LSAs may need to be flooded across areas, and their numbers would increase significantly if multiple Area Border Routers are employed for the purpose of reliability. Thus, it is important to allow the network to grow towards as large a size as possible under a single area.
LSAの洪水がエリア内に局所化されたままであるように、ネットワークを階層的に複数の領域に分割することにより、大規模なネットワークのスケーラビリティの問題を解決する必要があると主張するかもしれません。ただし、このアプローチにより、ネットワーク管理と設計の複雑さが向上し、エリア間の最適なルーティングが低下する可能性があります。また、自律システムの外部（ASE）LSAはAS全体に浸水しており、それらが多数ある場合は問題になる可能性があります。さらに、多数の要約LSAをエリア全体に浸水させる必要があり、信頼性を目的として複数のエリアボーダールーターを使用すると、その数は大幅に増加します。したがって、ネットワークが単一の領域の下で可能な限り大きなサイズに向かって成長することが重要です。
The recommendations in the document are synergistic with a broader set of scalability and stability improvement proposals. [Ref10] proposes flooding overhead reduction in case more than one interface goes to the same neighbor. [Ref11] proposes a mechanism for greatly reducing LSA refreshes in stable topologies.
ドキュメントの推奨事項は、より広範なスケーラビリティと安定性の改善提案と相乗的です。[Ref10]は、複数のインターフェイスが同じ隣人に届く場合の洪水オーバーヘッド減少を提案しています。[Ref11]は、安定したトポロジーのLSAリフレッシュを大幅に削減するためのメカニズムを提案しています。
[Ref12] proposes a wide range of congestion control and failure recovery mechanisms (some of those ideas are covered in this document, but [Ref12] has other ideas not covered here).
[Ref12]は、幅広い混雑制御と障害回復メカニズムを提案しています（これらのアイデアの一部はこのドキュメントで説明されていますが、[Ref12]はここではカバーされていない他のアイデアがあります）。
F = The factor by which the gap between sending successive LSAs to a neighbor is to be increased during congestion and decreased after coming out of congestion (used in Recommendation 4). Example value is 2.
f =隣人に連続したLSAを送信することの間のギャップは、うっ血中に増加し、うっ血から抜け出した後に減少する要因（推奨4で使用）。値の値は2です。
G(t) = Gap between sending successive LSAs to a neighbor at time t (used in Recommendation 4).
g（t）=時刻t（推奨4で使用）で隣人に連続したLSAを送信する間のギャップ。
Gmax = Maximum allowed value of gap between sending successive LSAs to a neighbor (used in Recommendation 4). Example value is 1 second.
gmax =隣人に連続したLSAを送信する間のギャップの最大値（推奨4で使用）。例の値は1秒です。
Gmin = Minimum allowed value of gap between sending successive LSAs to a neighbor (used in Recommendation 4). Example value is 20 ms.
gmin =隣人に連続したLSAを送信する間のギャップの最小値（推奨4で使用）。例の例は20ミリ秒です。
H = A high-water mark (in units of number of unacknowledged LSAs). Exceeding this mark would trigger a potential increase in the gap between sending successive LSAs to a neighbor. (used in Recommendation 4). Example value is 20.
H =高水マーク（未吸収のLSAの数の単位）。このマークを超えると、隣人に連続したLSAを送信する間のギャップが潜在的に増加する可能性があります。（推奨4で使用）。例の値は20です。
K = A multiplicative constant used in increasing the RxmtInterval value used during successive retransmissions of the same LSA (used in Recommendation 3). Example value is 2.
k =同じLSAの連続した再送信中に使用されるRXMTINTERVAL値の増加に使用される乗法定数（推奨3で使用）。値の値は2です。
L = A low-water mark (in units of number of unacknowledged LSAs) Dropping below this mark would trigger a potential decrease in the gap between sending successive LSAs to a neighbor. (used in Recommendation 4). Example value is 10.
L =低水マーク（未吸収のLSAの数の単位単位）がこのマークの下にドロップすると、隣人に連続するLSAを送信することの間のギャップの潜在的な減少が引き起こされます。（推奨4で使用）。例の値は10です。
n = Upper limit on the number of adjacencies to be brought up simultaneously (used in Recommendation 5).
n =同時に育てる隣接の数の上限（推奨5で使用）。
R(i) = RxmtInterval value used during the i-th retransmission of an LSA (used in Recommendation 3).
r（i）= rxmtInterval値LSAのIth再送信中に使用される（推奨3で使用）。
Rmax = The maximum allowed value of RxmtInterval (used in Recommendation 3). Example value is 40 seconds.
rmax = rxmtintervalの最大許容値（推奨3で使用）。例の値は40秒です。
Rmin = The minimum allowed value of RxmtInterval (used in Recommendation 3). Example value is 5 seconds.
rmin = rxmtintervalの最小許容値（推奨3で使用）。例の値は5秒です。
T = Minimum time that has to elapse before the existing gap between sending successive LSAs to a neighbor is considered for change (used in Recommendation 4). Example value is 1 second.
T =隣接するLSAを送信する間の既存のギャップの前に経過しなければならない最小時間は、変化のために考慮されます（推奨4で使用）。例の値は1秒です。
U(t) = Number of unacknowledged LSAs to a neighbor at time t (used in Recommendation 4).
u（t）=時刻tの隣人への未吸収のLSAの数（推奨4で使用）。
(1) Explicit Marking: In Section 2, we recommended that OSPF packets be classified to "high" and "low" priority classes based on examining the OSPF packet header. In some cases (particularly in the receiver), this examination may be computationally costly. An alternative would be the use of different TOS/Precedence field settings for the two priority classes. [Ref1] recommends setting the TOS field to 0 and the Precedence field to 6 for all OSPF packets. We recommend this same setting for the "low" priority OSPF packets and a different setting for the "high" priority OSPF packets in order to be able to classify them separately without having to examine the OSPF packet header. Two examples are given below:
(1) 明示的なマーキング：セクション2では、OSPFパケットヘッダーの調査に基づいて、OSPFパケットを「高」および「低」優先度クラスに分類することを推奨しました。場合によっては（特にレシーバーで）、この試験は計算的にコストがかかる場合があります。別の方法は、2つの優先度クラスに異なるTOS/PREDENCEフィールド設定を使用することです。[Ref1]は、すべてのOSPFパケットのTOSフィールドを0に、および優先順位フィールドを6に設定することをお勧めします。OSPFパケットヘッダーを調べずに個別に分類できるように、「低い」優先順位OSPFパケットと「高」優先オスプパケットの別の設定をお勧めします。2つの例を以下に示します。
Example 1: For "low" priority packets, set TOS field to 0 and Precedence field to 6, and for "high" priority packets set TOS field to 4 and Precedence field to 6.
例1：「低」優先パケットの場合、TOSフィールドを0に、優先順位フィールドを6に設定し、「高」優先パケットの場合はTOSフィールドを4に設定し、プライナンスフィールドを6に設定します。
Example 2: For "low" priority packets, set TOS field to 0 and Precedence field to 6, and for "high" priority packets set TOS field to 0 and Precedence field to 7.
例2：「低」優先パケットの場合、TOSフィールドを0に、優先順位フィールドを6に設定し、「高」優先パケットの場合、TOSフィールドを0に、プライナンスフィールドを7に設定します。
Note that the TOS/Precedence bits have been redefined by Diffserv (RFC 2474, [Ref14]). Also note that the different TOS/Precedence field settings suggested above only need to be agreed among the systems on the link. This recommendation is not needed to be followed if it is easy to examine the OSPF packet header and thereby separately classify "high" and "low" priority packets.
TOS/優先順位ビットはDiffServ（RFC 2474、[Ref14]）によって再定義されていることに注意してください。また、上記で提案されているさまざまなTOS/優先順位のフィールド設定は、リンク上のシステム間で合意する必要があることに注意してください。この推奨事項は、OSPFパケットヘッダーを簡単に調べて、「高」および「低い」優先度パケットを個別に分類できる場合は、従う必要はありません。
(2) Further Prioritization of OSPF Packets: Besides the packets designated as "high" priority in Recommendation 1 of Section 2, there may be a need for further priority separation among the "low" priority OSPF packets. We recommend the use of three priority classes: "high", "medium" and "low". While receiving a packet from a neighbor and while transmitting a packet to a neighbor, try to process a "high priority" packet ahead of "medium" and "low" priority packets and a "medium" priority packet ahead of "low priority" packets. The "high" priority packets are as designated in Recommendation 1 of Section 2. We provide below two candidate examples for "medium" priority packets. All OSPF packets not designated as "high" or "medium" priority are "low" priority. If Cryptographic Authentication (AuType = 2) is used (as specified in [Ref1]), then prioritized treatment is to be provided only at the receiver and after security processing, but not at the transmitter since that may cause packets to arrive out of sequence and violate the requirements of "Autype = 2".
(2) OSPFパケットのさらなる優先順位付け：セクション2の推奨1で「高い」優先度として指定されたパケットに加えて、「低い」優先順位OSPFパケット間のさらに優先度分離が必要になる場合があります。「高」、「中」、「低」の3つの優先クラスの使用をお勧めします。隣人からパケットを受信し、隣人にパケットを送信しながら、「中程度」および「低い」優先度パケットの前に「優先度の高い」パケットを処理し、「低優先度」パケットの前に「中程度」の優先パケットを処理してみてください。。「高」優先パケットは、セクション2の推奨1で指定されているとおりです。「中」優先パケットの2つの候補例を以下に示します。「高」または「中程度」の優先度として指定されていないすべてのOSPFパケットは、「低い」優先度です。暗号化認証（Autype = 2）が使用されている場合（[Ref1]で指定されている）、優先順位付けされた治療は受信機およびセキュリティ処理後にのみ提供されますが、それはパケットがシーケンスから到着する可能性があるため、送信機では提供されません。「Autype = 2」の要件に違反します。
One example of "medium" priority packet is the Database Description (DBD) packet from a slave (during the database synchronization process) that is used as an acknowledgment.
「中」優先度パケットの1つの例は、確認として使用されるスレーブ（データベース同期プロセス中）からのデータベース説明（DBD）パケットです。
A second example is an LSA carrying intra-area topology change information (this may trigger SPF calculation and rerouting of Label Switched Paths, so fast processing of this packet may improve OSPF/Label Distribution Protocol (LDP) convergence times). However, if the processing cost of identifying and separately queueing the LSA in this example is deemed to be high, then the implementer may decide not to do it.
2番目の例は、エリア内トポロジの変更情報を運ぶLSAです（これにより、SPFの計算とラベルスイッチパスの再ルーティングがトリガーされる可能性があるため、このパケットの迅速な処理により、OSPF/ラベル分布プロトコル（LDP）収束時間が改善される可能性があります）。ただし、この例でLSAを識別して個別にキューする処理コストが高いとみなされる場合、実装者はそれを行わないことを決定する場合があります。
(3) Processing a Large Number of LSA Purges: Occasionally, some events in the network, such as router ID changes, may result in a large number of LSA re-originations and LSA purges. In such a scenario, one may consider processing LSAs in different order, e.g., processing LSA purges ahead of LSA originations. We, however, do not recommend out-of-order LSA processing for several reasons. First, detecting the LSA type ahead of queueing may be computationally expensive. Out-of-order processing may also cause subtle bugs. We do not want to recommend a major change in the LSA processing paradigm for a relatively rare event such as router ID change. However, a router with a changing ID may flush the old LSAs gradually without causing a storm.
(3) 多数のLSAパージを処理する：時には、ルーターIDの変更など、ネットワーク内のいくつかのイベントにより、多数のLSA再構成とLSAパージが発生する可能性があります。このようなシナリオでは、LSAの発信元よりもLSAパージを処理するなど、LSAを異なる順序で処理することを検討する場合があります。ただし、いくつかの理由で、注文不足のLSA処理をお勧めしません。まず、キューイングの前にLSAタイプを検出することは、計算的に高価な場合があります。秩序外の処理は、微妙なバグを引き起こす可能性もあります。ルーターIDの変更など、比較的まれなイベントについて、LSA処理パラダイムの大きな変更を推奨したくありません。ただし、IDが変更されたルーターは、嵐を引き起こすことなく、古いLSAを徐々にフラッシュする場合があります。
Contributing Authors and Their Addresses
著者とその住所を寄付します
In addition to the editor, several people contributed to this document. The names and contact information of all authors are given below.
編集者に加えて、このドキュメントに貢献しました。すべての著者の名前と連絡先情報を以下に示します。
Anurag S. Maunder Erlang Technology 2880 Scott Boulevard Santa Clara, CA 95052 USA
Anurag S. Maunder Erlang Technology 2880 Scott Boulevard Santa Clara、CA 95052 USA
Phone: (408) 420-7617 EMail: anuragm@erlangtech.com
電話：（408）420-7617メール：anuragm@erlangtech.com
Gerald R. Ash AT&T Room D5-2A01 200 Laurel Avenue Middletown, NJ, 07748 USA
ジェラルドR.アッシュAT＆TルームD5-2A01 200ローレルアベニューミドルタウン、ニュージャージー州、07748 USA
Phone: (732) 420-4578 EMail: gash@att.com
電話：（732）420-4578メール：gash@att.com
Vishwas Manral Sinett Corp, 2/1 Embassy Icon Annex, Infantry Road, Bangalore 560 001 India
Vishwas Manral Sinett Corp、2/1 Embassy Icon Annex、Infantry Road、Bangalore 560 001 India
Phone: +91-(805)-137-7023
EMail: vishwas@sinett.com
Vera D. Sapozhnikova AT&T Room C5-2C29 200 Laurel Avenue Middletown, NJ, 07748 USA
Vera D. Sapozhnikova AT＆TルームC5-2C29 200ローレルアベニューミドルタウン、ニュージャージー州、07748 USA
Phone: (732) 420-2653 EMail: sapozhnikova@att.com
電話：（732）420-2653メール：sapozhnikova@att.com
Editor's Address
編集者のアドレス
Gagan L. Choudhury AT&T Room D5-3C21 200 Laurel Avenue Middletown, NJ, 07748 USA
Gagan L. Choudhury AT＆TルームD5-3C21 200ローレルアベニューミドルタウン、ニュージャージー州、07748 USA
Phone: (732) 420-3721 EMail: gchoudhury@att.com
電話：（732）420-3721メール：gchoudhury@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用、またはそのような権利に基づくライセンスに基づくライセンスが利用可能である可能性がある範囲に関連すると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。