RFC 4222 - Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance 日本語訳

URL : https://tools.ietf.org/html/rfc4222
タイトル : RFC 4222 - 特定のOSPFバージョン2つのパケットと輻輳回避の優先順位付け治療
翻訳編集 : 自動生成

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

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.

このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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.

この文書では、オープンショーテストパスファースト（OSPF）バージョン2プロトコルを使用して、大規模ネットワークの拡張性と安定性を改善することが意図されている方法をお勧めします。方法は、他のOSPFパケット、および他の輻輳回避手順と比較して、より高い優先度で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

1. Introduction

1. はじめに

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の多数の同時またはほぼ同時更新を経験し得ます。 OSPFトラフィックエンジニアリングの拡張[REF3]が有意にネットワーク内のLSAの数を増加させることができるが使用される場合、これは特に当てはまります。私たちは、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とメモリの使用率を引き起こします。（再送タイマ値を超えた）遅延確認応答は、再送信につながる、とネイバールータとの隣接関係の結果はダウンと宣言されている（ルータ・デッドインターバルを超えた）Helloパケットを遅らせます。再送信および追加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秒で、ルータ-deadインターバルのそれは40秒です。しかし、最近になって大幅にOSPF収束時間を短縮することに多くの関心がありました。こんにちは（サブ秒）その計画の一環として、はるかに短いとルータデッド間隔は、[REF4]を提案されています。 Helloパケットは、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パケットを優先し、輻輳を回避するための手順をお勧めします。お薦めの詳細は、シミュレーション研究は、[Ref13]渋滞現象とその影響を定量化することに報告されているセクション2に記載されています。また、提言のいくつかの研究と、彼らは実際にOSPFプロトコルを使用して、ネットワークの拡張性と安定性を改善することを示しています。 [Ref13]エディタや著者の一人を接触させることによって、リクエストに応じて利用可能です。

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は、同様の目標を持ついくつかの更なる提言や提案を提供します。

2. Recommendations

2.勧告

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プロトコルを使用して、大規模ネットワークの拡張性と安定性を改善することを意図しています。ネットワークの輻輳の期間中、彼らは、再送信を減らすため、HelloパケットがRouterDeadIntervalを超えて遅延されるまで宣言するための隣接関係を避け、他の輻輳回避手順を実行します。勧告は、その推奨2以外順不同である勧告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.

OSPF Helloパケットおよびリンクステート確認応答パケットを含む「優先度の高い」クラス、および他のすべてのパケットを含む「低優先度」クラス：（1）二つのクラス内のすべての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).

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

勧告1を実装することができない場合（2）、次いで、ポイントツーポイントリンクを介しAllSPFRoutersに送信されたOSPFユニキャストパケットまたは任意のOSPFパケットが非アクティブタイマーをリセットするのではなく、その隣接を通じて受信されたときに隣接するためのインアクティビティタイマーをリセットのみHelloパケットを受信すると。そうOSPFは、ポイントツーポイントリンクを介しAllSPFRoutersに送らないOSPFユニキャストパケット又は全くOSPFパケットが等しい又はRouterDeadIntervalを超える期間、その隣接を通じて受信されない場合にのみ、ダウンして隣接関係を宣言する。提言1と一緒にこの提案を推奨しない理由は、潜在的に望ましくない副作用を避けるためです。そのような効果には、高い優先順位のHelloパケットを受信していないされているが、非活動タイマは、低プライオリティキュー内の他の陳腐パケットによってリセットされている場合には隣接のダウンステータスを発見における遅延です。

(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のi番目の再送信時に使用される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が定数と機能最小である場合（。、。）その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に送信隣人又はのLSAに送信されるユニキャストの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.

Min(.,.) and Max(.,.) represent the minimum and maximum values of the two arguments, respectively.

MIN（。、。）及びMaxは（。、。）は、それぞれ、二つの引数の最小値と最大値を表します。

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ミリ秒、1秒= Gmaxの次のようなアルゴリズムの様々なパラメータの値の例です。

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をスローダウンの両方が、彼らは重要な違いがあります。推奨4は徐々にダウン輻輳隣接するすべてのLSA（新規又は再送）を遅くする一方、推奨3を徐々に、同じ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.

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]を含むべきです

3. Security Considerations

3.セキュリティの考慮事項

This memo does not create any new security issues for the OSPF protocol.

このメモはOSPFプロトコルのための新たなセキュリティ問題を作成しません。

4. Acknowledgments

4.謝辞

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デュベ、ACEE Lindem、そしてジョン・モイの議長を務める承認したいと思います。ルーティングエリアディレクター、アレックスジニンとビルフェナー。そして、IESGの審査。私たちは、ドキュメントの以前のバージョンへのコメントのためのVivekデュベ、ミッチェルErblich、マイク・フォックス、トニーPrzygienda、とクリシュナ・ラオを認めます。また、リンク状態プロトコルベースのネットワークのための私たちのスケーラビリティの改善努力におけるコラボレーションと激励のためにマーガレットChiosi、エリー・フランシス、ジェフ・ハン、ベス・マンソン、ロシャンラオ、モシェ・シーガル、マイクWardlow、そしてパットワースを認めます。

5. Normative References

5.引用規格

[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[Ref1の】モイ、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.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。

6. Informative References

6.参考文献

[Ref3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

、RFC 3630、2003年9月[REF3]カッツ、D.、Kompella、K.、およびD.ヨン、 "OSPFバージョン2へのトラフィックエンジニアリング（TE）の拡張"。

[Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Millisecond IGP Convergence", Work in Progress.

"ミリ秒IGPコンバージェンスに向けて" [REF4] C. Alaettinoglu、V. Jacobson氏およびH.ユー、進行中で働いて。

[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.シェン、A. Lindem、J.元、A.ジニン、R.ホワイト及びS. Previdi、「リンクステートルーティングプロトコルにおけるLAN経由ポイントツーポイント操作」、ProgressのWork。

[Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net outage", Network World, February 26, 2001.

[Ref6] Pappalardo、D.、ネットワークの世界、2001年2月26日には、 "AT＆Tは、顧客がATMネット停電に取り組みます"。

[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.は、インター@ ctiveウィーク、1999年8月20日 "MCIの停止は、ドミノ効果があります"。

[Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat", Light Reading, April 6, 2001.

"クエストの停止で、ATMは、いくつかの熱を奪う" [Ref9] Jander、M.、光読書、2001年4月6日。

[Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State Routing Protocols", Work in Progress.

[Ref10] A.ジニンとM.シャンド、「リンクステートルーティングプロトコルにおける洪水の最適化」が進行中で働いています。

[Ref11] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in Stable Topologies", RFC 4136, July 2005.

[Ref11] Pillay-Esnault、P.、 "OSPFリフレッシュと安定したトポロジでのフラッディング削減"、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.アッシュ、G.チョードリー、V。Sapozhnikova、M.シェリフ、A. Maunder、V. Manral、 "OSPFネットワークの輻輳回避とコントロール"、ProgressのWork。

[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.チョードリー、G.アッシュ、V. Manral、A. Maunderと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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。

Appendix A. LSA Storm: Causes and Impact

付録A. LSAの嵐：原因と影響

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）は、繊維切断による一つ以上のリンク障害を、

(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）リンク/ルータのフラッピング、

(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,

LSAのサブセットの定期1800秒のLSAリフレッシュの同期周辺（E）、

(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).

LSA再オリジネーションの多数を引き起こす（H）ルータIDの変更は、（おそらく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ネットワークの一例は、トラフィックエンジニアリングのLSA [REF3]です。ラベルの再ルーティングからのこれらの結果は、リンク/ルータの障害時にダウンしたスイッチパス（LSP）。 LSAストームは、着信パケットが遅延またはドロップさせるルータのプロセッサで高いCPUとメモリの使用率を引き起こします。遅延確認応答（再送タイマ値を超えた）の再送信をもたらし、（ルータ・デッドインターバルを超えた）Helloパケットダウンと宣言されているリンクで結果を遅らせます。トランクダウンイベントは、そのエンドポイントルータによって、ルータLSAの発信を引き起こします。トラフィックエンジニアリングのLSAは、各リンクのために使用されている場合は、LSAのタイプは、エンドポイント・ルータによって発信されるだろうし、潜在的に他の場所にも起因する故障による他のリンクで予約された帯域幅の大幅な変化にして使用して元々のLSPの再ルーティング失敗したトランク。最終的には、リンクが回復したときには、追加ルータ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ストームサイズ閾値が存在することを示すために使用されます。また、不安定性を引き起こすLSAストームサイズが実質的にハローおよびLSA確認応答パケットに優先処理を提供することによって、およびLSA再送間隔を決定するための指数バックオフアルゴリズムを使用することによって増加され得ることが示されています。それはHelloパケットに優先順位をつけることができない場合は、任意の有効なOSPFパケットを受信すると、非アクティブタイマーをリセットしても同じ利益を提供することができます。私たちは、Helloパケットに優先順位を付けた場合、ネットワークがやや安定性のしきい値を超えて動作してもなお、その後、リンクが原因逃したハローズまでに宣言されていません。これは、多くの再送信への制御プレーン輻輳があるにもかかわらず、データプレーンは、（元嵐とリフレッシュ中のもの以外の）アップ状態のままと新しいのLSAが発信されていないことを意味します。これらの観察は、この文書の著者はまた、他の第2節のヘルプ回避の混雑の推奨事項とは、輻輳状態から正常な終了を許可することを確認するためにシミュレーションを行っている第2の最初の3件の勧告をサポートしています。

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]ここで説明されていない他のアイデアを持っている）の広い範囲を提案しています。

Appendix B. List of Variables and Values

変数と値の付録B.一覧

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）は（勧告4で使用される）時刻tにおけるネイバーに連続LSAを送信間のギャップを=。

Gmax = Maximum allowed value of gap between sending successive LSAs to a neighbor (used in Recommendation 4). Example value is 1 second.

GMAX =最大は（勧告4で使用）ネイバーに連続するLSAを送信間のギャップの値を可能にしました。値の例は1秒です。

Gmin = Minimum allowed value of gap between sending successive LSAs to a neighbor (used in Recommendation 4). Example value is 20 ms.

GMIN =最小（勧告4で使用）ネイバーに連続するLSAを送信間のギャップの値を可能にしました。値の例は、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は（勧告3に使用される）同じLSAの連続再送信の間に使用されるRxmtInterval値を増加させることに使用される乗法定数=。値の例は、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).

（勧告5で使用される）を同時に起動されるべき隣接の数にN =上限。

R(i) = RxmtInterval value used during the i-th retransmission of an LSA (used in Recommendation 3).

R（勧告3で使用）LSAのi番目の再送信時に使用される式（I）= RxmtInterval値。

Rmax = The maximum allowed value of RxmtInterval (used in Recommendation 3). Example value is 40 seconds.

Rmaxが（勧告3で使用）RxmtIntervalの最大許容値を=。値の例は、40秒です。

Rmin = The minimum allowed value of RxmtInterval (used in Recommendation 3). Example value is 5 seconds.

RMINは（勧告3で使用）RxmtIntervalの最小許容値を=。値の例は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）=（勧告4で使用される）は、時刻tにおける隣接する未確認LSAの数。

Appendix C. Other Recommendations and Suggestions

付録C.その他の推奨事項と提案

(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パケットヘッダを検査に基づいて「高」と「低」優先クラスに分類することを推奨。（特に、受信機で）いくつかのケースでは、この検査は、計算コストがかかるかもしれません。代替は、二つの優先度クラスごとに異なるTOS / Precedenceフィールドの設定を使用することであろう。 [Ref1の全てのOSPFパケットのTOSフィールド0へと優先順位フィールドに6を設定することをお勧めします。私たちは、OSPFパケットのヘッダーを調べることなく、それらを別々に分類することができるようにするために「高」優先度の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.

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：「低」優先順位のパケットの場合、0~6と優先順位フィールドにTOSフィールドを設定し、「高」優先度のパケットが0〜7と優先順位フィールドにTOSフィールドを設定するため。

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 / Precedenceフィールドの設定は、リンクだけでシステム間で合意する必要があることに注意してください。 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つの候補例を下に提供する第2の勧告1で指定される「高」優先度パケットです。「高」または「中」の優先順位として指定されていないすべてのOSPFパケットは、「低」の優先順位です。（[Ref1の]で指定されるように）暗号化認証（AuType = 2）が使用される場合、優先順位処理は、受信機でセキュリティ処理後に提供されるべきではなく、送信時とは、パケットが順序が狂って到着する可能性がありのでそして「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.

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.

第二の例は、エリア内のトポロジ変化情報を搬送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.

LSAパージ多数の処理（3）：時々を、そのようなルータ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

アヌラーグS. Maunderアーランテクノロジー2880スコット大通りサンタクララ、CA 95052 USA

Phone: (408) 420-7617 EMail: anuragm@erlangtech.com

電話：（408）420-7617 Eメール：anuragm@erlangtech.com

Gerald R. Ash AT&T Room D5-2A01 200 Laurel Avenue Middletown, NJ, 07748 USA

ジェラルドR.アッシュAT＆TルームD5-2A01 200ローレルアベニューミドルタウン、NJ、USA 07748

Phone: (732) 420-4578 EMail: gash@att.com

電話：（732）420-4578 Eメール：gash@att.com

Vishwas Manral Sinett Corp, 2/1 Embassy Icon Annex, Infantry Road, Bangalore 560 001 India

Vishwas Manral Sinett社、2/1大使館アイコン別館、歩兵ロード、バンガロール560 001インド

Phone: +91-(805)-137-7023 EMail: vishwas@sinett.com

電話：+ 91-（805）-137-7023 Eメール：vishwas@sinett.com

Vera D. Sapozhnikova AT&T Room C5-2C29 200 Laurel Avenue Middletown, NJ, 07748 USA

ヴェラ・D. Sapozhnikova AT＆TルームC5-2C29 200ローレルアベニューミドルタウン、NJ、USA 07748

Phone: (732) 420-2653 EMail: sapozhnikova@att.com

電話：（732）420-2653 Eメール：sapozhnikova@att.com

Editor's Address

編集者の住所

Gagan L. Choudhury AT&T Room D5-3C21 200 Laurel Avenue Middletown, NJ, 07748 USA

GAGAN L.チョードリーAT＆TルームD5-3C21 200ローレルアベニューミドルタウン、NJ、USA 07748

Phone: (732) 420-3721 EMail: gchoudhury@att.com

電話：（732）420-3721 Eメール：gchoudhury@att.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.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 Editor機能のための基金は現在、インターネット協会によって提供されます。