RFC4222 日本語訳
4222 Prioritized Treatment of Specific OSPF Version 2 Packets andCongestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT=34132 bytes) (Also BCP0112) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Choudhury, Ed. Request for Comments: 4222 AT&T BCP: 112 October 2005 Category: Best Current Practice
ワーキンググループのG.チョウドリ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4222AT&T BCP: 112 2005年10月のカテゴリ: 最も良い現在の習慣
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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはオープンShortest Path First(OSPF)バージョン2プロトコルを使用することで大きいネットワークのスケーラビリティと安定性を改良することを意図する方法を推薦します。 方法は、他のOSPFパケット、および他の輻輳回避手順と比べて、より高い優先度でOSPFハローズとLink州Advertisement(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. 序論…2 2. 推薦…3 3. セキュリティ問題…6 4. 承認…6 5. 標準の参照…6 6. 有益な参照…7 付録A.LSAはどなります: 原因と衝撃…変数と値の8付録B.リスト…10の付録C.他の推薦と提案…11
Choudhury, Ed. Best Current Practice [Page 1] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[1ページ]RFC4222
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プロトコルは時折多くのリンク州の広告、またはLSAsの同時の、または、近く同時のアップデートになるかもしれません。 使用されるかなりそうするかもしれないOSPF交通工学拡張子[Ref3]がネットワークにおける、LSAsの数を増加させるなら、これは特に本当です。 私たちは、この出来事を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秒です、そして、ルータ死んでいる間隔のものは40秒です。 しかしながら、最近、かなり減少しているOSPF集合時間には多くの関心がありました。 そして、はるかに短い(サブ2番目の)そのプランの一部、こんにちは、ルータ死んでいる間隔は提案されました[Ref4]。 そのようなシナリオでは、それはルータ死んでいる間隔にLSA嵐によって引き起こされたネットワークの混雑の間、Helloパケットが、より遅れそうでしょう。
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で明らかにされます。 シミュレーション研究は混雑現象とその衝撃を定量化する[Ref13]で報告されます。 それは、また、いくつかの推薦を研究して、本当に、それらがOSPFプロトコルを使用することでネットワークのスケーラビリティと安定性を改良するのを示します。 [Ref13]は、エディタか作者のひとりに連絡することによって、要求に応じて利用可能です。
Choudhury, Ed. Best Current Practice [Page 2] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[2ページ]RFC4222
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プロトコルを使用することで大きいネットワークのスケーラビリティと安定性を改良することを意図します。 ネットワークの混雑の期間、それらは、「再-トランスミッション」を減少させて、RouterDeadIntervalを超えて遅れるHelloパケットのため宣言されるために隣接番組を避けて、他の輻輳回避方法を採るでしょう。 Recommendation1が実行されない場合にだけRecommendation2が実行されることになっているのを除いて、推薦は順不同のです。
(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) 2つのクラスにおけるすべてのOSPFパケットを分類してください: OSPF HelloパケットとLink州Acknowledgementパケットを包括する「高い優先度」のクラス、および他のすべてのパケットを包括する「低い優先度」のクラス。 分類は、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パケットを受け取るかもしれません。 Cryptographic Authentication(AuType=2)が使用されているなら([Ref1]で指定されるように)、そして、非減少している「暗号の一連番号」を持つ隣人の必要性からの連続した容認された有効なOSPFパケットです。 この要件に従うために、私たちは、使用されるケースCryptographic Authentication(AuType=2)[Ref1]、最優先する処理におけるそれを送信機にしないことを勧めます。 これは順序が狂って受信機に到着するパケットを避けるでしょう。 しかしながら、受信機(一連番号の照合を含んでいる)でのセキュリティ処理が完全になった後にOSPFパケットが「高い優先度」待ち行列で保たれるかもしれないか、「低い優先度」待ち行列は、それらのクラスを基礎づけて、それに従って、処理されました。 最優先する処理の恩恵は、その場合送信機において受信機で優先順位づけを実行できるので、Cryptographic Authenticationが不在のとき明確に高いです。Cryptographic Authenticationさえあるので、しかしながら、受信機(次のセキュリティ処理)だけに優先順位づけを持っているのは有益でしょう。
(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
(2) Recommendation1を実行できないなら、ポイントからポイントへのリンクの上のAllSPFRoutersに送られたどんなOSPFユニキャストパケットかどんなOSPFパケットもリセットの代わりにその隣接番組の上に受け取るときはいつも、隣接番組のために不活発タイマをリセットしてください。
Choudhury, Ed. Best Current Practice [Page 3] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[3ページ]RFC4222
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.
単にHelloパケットを受け取り次第不活発タイマ。 それで、しばらくポイントツーポイント接続の上のAllSPFRoutersに送られなかったどんなOSPFユニキャストパケットもどんなOSPFパケットもその隣接番組の上に受け取らない場合にだけ、OSPFは、RouterDeadIntervalを等しい、または超えながら、隣接番組が下がっていると宣言するでしょう。 Recommendation1に関連してこの提案を推薦しない理由は潜在的望ましくない副作用を避けることです。 そのような効果の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)の値を決定するのに指数のbackoffアルゴリズムを使用してください。 R(i)に使用されていた状態でRxmtInterval値を表させてください、i、-、LSAの第「再-トランスミッション」。 以下のアルゴリズムを使用して、R(i)を計算してください。
R(1) = Rmin
R(i+1) = Min(KR(i),Rmax) for i>=1
i>=1のためのR(1)=Rmin R(i+1)=分(KR(i)、Rmax)
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.
コントロールメッセージによって引き起こされたネットワークの混雑出来事の間混雑を支えるための主要なソースがLSAsの繰り返された「再-トランスミッション」であるという観測でこの推薦は動機づけられています。 ネットワークは混雑(同じLSAの複数の「再-トランスミッション」が起こるのが、おそらくである)を経験しますが、指数のbackoffアルゴリズムのLSA再送信間隔の使用はLSA retransmissionsのレートを低下させます。 これは、ネットワークが混雑している状態を出るのを順番に助けます。
(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
(4) 暗黙の混雑検出とそれに基づく動作: ルータにコントロールメッセージ混雑があれば、隣人はそんなにおよそ明らかに知りません。 しかしながら、彼らは不承認のLSAsの数に基づいてそれとなくこのルータにそれを検出できます。 この数が、ある「最高水位線」を超えているなら、LSAsがこのルータに送られるレートは、次第に指数のbackoffメカニズムを使用することで減少するべきですが、ある最低料率より下で減少するというわけではありません。 将来の時間に、このルータへの不承認のLSAsの数が、ある「低ウォーター・マーク」の下まで下がるなら、送付LSAs対このルータのレートはそうするべきです。
Choudhury, Ed. Best Current Practice [Page 4] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[4ページ]RFC4222
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.
再び指数のbackoffメカニズムを使用して、次第に増加しますが、ある最高率より上で増加するというわけではなくなってください。 全体のアルゴリズムを以下に与えます。 このアルゴリズムが各隣人と隣人に送られたユニキャストLSAsかAllSPFRoutersに送られたLSAsのためだけに独自にポイントへのポイントリンクの上に付けられることであることに注意してください。
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に隣人への不承認のLSAsの数と等しいです。 Hは最高水位線と等しいです(不承認のLSAsのユニットの数で)。 Lは干潮標と等しいです(不承認のLSAsのユニットの数で)。 G(t)は時tに連続したLSAsを隣人に送るところのギャップと等しいです。 混雑の間、増加して、混雑から出て来た後に減少される上のギャップがことである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
|_
以下の方程式はギャップが最後の変化以来時間Tが経過している後にどう変えるかことであることを示しています: _ | | 分(FG(t)、Gmax)、U(t+T)>H G(t+T)=です。| H>がU(t+T)>と等しいなら、G(t)はLと等しいです。| U(t+T)<Lであるなら(G(t)/F、Gmin)に最大限にしてください。|_
Min(.,.) and Max(.,.) represent the minimum and maximum values of
the two arguments, respectively.
分、()、マックス、()、それぞれ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と等しいです、1T=秒、20Gmin=ms、1Gmax=秒。
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はともにLSAsを混雑している隣人に減速させますが、彼らには、重要な違いがあります。 または、推薦3が次第に同じLSAの連続した「再-トランスミッション」を減速させますが、Recommendation4が次第にすべてのLSAsを減速させる、(新しさ、「再-トランスミッション」) 混雑している隣人に。
(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"
(5) 同時に持って来られるために隣接番組を阻止します: ルータが同時に多くの隣接番組を隣人に持って来ようとするなら、それはデータベース同期とLSA氾濫活動による厳しい混雑を引き起こすかもしれません。 それはそのような状況の間、それに「n」ほどもう少しでない推薦されます。
Choudhury, Ed. Best Current Practice [Page 5] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[5ページ]RFC4222
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.
隣接番組は同時に、持って来られるべきです。 隣接番組の部分集合がいったん首尾よく持って来られると、持って来られる同時の隣接番組の数が「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 Served(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]
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、およびジョンMoyからサポートと役に立つコメントを承諾したいと思います。 アレックス・ジニンとルート設定Areaビル・フェナーディレクター。 そして、IESG評論家。 私たちはドキュメントの旧バージョンのコメントのためにVivekデュベ、ミッチェルErblich、マイクフォックス、トニーPrzygienda、およびクリシュナ・ラオを承認します。 また、私たちはLinkの州のプロトコルを拠点とするネットワークのために私たちのスケーラビリティ改良の努力における共同と奨励のためのマーガレットChiosi、エリー・フランシス、ジェフ・ハン、ベス・ムンソン、Roshanラオ、モシェSegal、マイクWardlow、およびパット・ワースを承認します。
5. Normative References
5. 引用規格
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[Ref2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[Ref2] ColtunとR.とファーガソン、D.とJ.Moy、「IPv6"、RFC2740、1999年12月のためのOSPF。」
Choudhury, Ed. Best Current Practice [Page 6] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[6ページ]RFC4222
6. Informative References
6. 有益な参照
[Ref3] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[Ref3] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[Ref4] C. Alaettinoglu, V. Jacobson and H. Yu, "Towards Millisecond
IGP Convergence", Work in Progress.
[Ref4] 「ミリセカンドIGP集合」というC.Alaettinoglu、V.ジェーコブソン、および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.YuanとA.ジニンとR.ホワイトとS.Previdi、「LinkState方式プロトコルのLANの上の二地点間操作」、ProgressのWork。
[Ref6] Pappalardo, D., "AT&T, customers grapple with ATM net
outage", Network World, February 26, 2001.
[Ref6] Pappalardo、D.、「AT&T、顧客はATMのネットの供給停止と格闘する」Network World、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 Press Release、1998年4月22日。
[Ref8] Cholewka, K., "MCI Outage Has Domino Effect", Inter@ctive
Week, August 20, 1999.
[Ref8] Cholewka、K.、「MCI供給停止には、ドミノ効果がある」 Inter@ctive 週、1999年8月20日。
[Ref9] Jander, M., "In Qwest Outage, ATM Takes Some Heat", Light
Reading, April 6, 2001.
2001年4月6日に読んで、M.、「Qwest供給停止では、気圧はいくらかの熱を取る」という[Ref9]Janderは火が付きます。
[Ref10] A. Zinin and M. Shand, "Flooding Optimizations in Link-State
Routing Protocols", Work in Progress.
[Ref10] 「LinkState方式プロトコルにおける氾濫最適化」というA.ジニンとM.シャンドは進行中で働いています。
[Ref11] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in
Stable Topologies", RFC 4136, July 2005.
[Ref11] Pillay-Esnault、P.、「安定したTopologiesにリフレッシュして、減少をあふれさせるOSPF」、RFC4136、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、「OSPFネットワークのための輻輳回避とコントロール」と、M.シェリフ、A.はManralに対してだらだらしゃべります、処理中の作業。
[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.がだらだらしゃべって、Sapozhnikovaに対してそうする、「特定のOSPFパケットと輻輳回避の最優先する処理:」 「アルゴリズムとシミュレーション」、AT&T技術報告書、8月2003
[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分野)の定義」、RFC2474(1998年12月)。
Choudhury, Ed. Best Current Practice [Page 7] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[7ページ]RFC4222
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)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) 2分の1800の周期的なLSAの近い同期はLSAsの部分集合をリフレッシュします。
(f) refresh of all LSAs in the system during a change in software
version,
(f) ソフトウェアバージョンにおける変化の間、システムのすべてのLSAsをリフレッシュしてください。
(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) Router 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.
リンク/ルータ失敗の直接の結果として溯源されたLSAsに加えて、また、他の間接的なLSAsがあるかもしれません。 MPLSネットワークにおける1つの例がLSAs[Ref3]が予約された帯域幅の著しい変化の結果、他のリンクで溯源した交通工学です。 これらはリンク/ルータ失敗の間に落ちたLabel Switched Paths(LSPs)についてコースを変更することから生じます。 入って来るパケットが遅らせられるか、または落とされることを引き起こしながら、LSA嵐はルータプロセッサで高いCPUとメモリ使用量をもたらします。 「再-トランスミッション」で承認(再送信タイマー値を超えた)結果を遅らせて、下がっていると申告されるリンクでHelloパケット(Router死んでいる間隔の)結果を遅らせました。 下にトランク出来事はエンドポイントルータでルータLSA創作を引き起こします。 交通工学LSAsが失敗によって引き起こされた他のリンクの予約された帯域幅の著しい変化のため各リンクにほかの場所でまた、LSAのタイプがエンドポイントルータによって溯源されるだろうその時、潜在的にまた、使用されて、元々失敗したトランクを使用するLSPsのコースを変更するなら。 また、結局、リンクが回収されると、それは追加ルータLSAsと交通工学LSAsの引き金となるでしょう。
Choudhury, Ed. Best Current Practice [Page 8] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[8ページ]RFC4222
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とメモリ使用量をもたらして、本質的には正のフィードバック・ループを引き起こします。 私たちはオリジナルの嵐における、LSAsの数とLSA嵐のサイズを定義します、上で説明されたフィードバックループから生じる少しの追加LSAsも数えないで。 LSA嵐が大き過ぎるなら、前記のように正のフィードバック・ループはネットワークにおける多くのルータで大きいCPUとメモリ使用量を無期限に支えることができるくらい大きいかもしれません、その結果、不安定な状態にネットワークを動かします。 過去にネットワーク供給停止イベントはOSPFなどのリンク州のプロトコルを使用しながら、IPとATMネットワークで報告されました、Intermediate SystemへのIntermediate System、(-、)、兵士のNetworkはInterface(PNNI)、またはいくつかの独占異形をネットワークでつなぎます。 例えば、[Ref6-Ref9]を見てください。 または、これらの例の多くでは、LSAsか他の同様のコントロールの大規模な氾濫が通信する、(どちらか、自然である、いくつかのバグで引き起こされたか不適当な手順)、ネットワークの不安定性と供給停止に一部か完全に責任感が強かったです。
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]では、シミュレーションモデルは、ネットワークが多くの「再-トランスミッション」によって引き起こされた、不安定な振舞い、逃されたHelloパケットによるリンクの故障を示しているかもしれないあるLSA嵐のサイズ敷居とその後のリンク回復があるのを示すのに使用されます。 それはまた、不安定性を引き起こすLSA嵐のサイズがHelloとLSA Acknowledgmentパケットに最優先する処理を供給して、LSAを決定するのに指数のbackoffアルゴリズムを使用することによってかなり増加するかもしれないのが示された再送信間隔です。 また、Helloパケットを最優先させるのが可能でないなら、どんな有効なOSPFパケットも受けるとき不活発タイマをリセットすると、同じ利益を提供できます。 その上、私たちがHelloパケットを最優先させるなら、ネットワークがいくらか安定性敷居を超えて作動する場合、リンクは逃されたハローズのため申告されません。 オリジナルの嵐におけるもの以外にこれが、多くの「再-トランスミッション」によるコントロール飛行機混雑がありますが、データ飛行機が寝ずに起きていて、どんな新しいLSAsも溯源されないのを含意する、(そして、リフレッシュ、) これらの観測はセクション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
1つが、大きいネットワークのスケーラビリティ問題が唯一階層的でネットワークを複数の領域に分割することによって解決されるべきであると主張するかもしれないので、LSAsの氾濫は領域の中で局所化されたままで残っています。 しかしながら、このアプローチは、ネットワークマネージメントとデザインの複雑さを増加させて、領域の間の、より少ない最適ルーティングをもたらすかもしれません。 また、Autonomous System External(ASE)LSAsもAS中で水につかっています、そして、多くのそれらがあれば、それは問題であるかもしれません。 その上、多くの概要LSAsは、領域の向こう側にあふれる必要があるかもしれません、そして、それらの番号はかなり増加するでしょう。
Choudhury, Ed. Best Current Practice [Page 9] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[9ページ]RFC4222
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.
複数のArea Border Routersが信頼性の目的に使われます。 したがって、ネットワークがただ一つの領域の下でできるだけ大きいサイズに向かって成長するのを許容するのは重要です。
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]は、1つ以上のインタフェースが同じ隣人のものになるといけないので頭上の減少をあふれさせるよう提案します。 LSAを大いに減少させるのが安定したtopologiesでリフレッシュするので、[Ref11]はメカニズムを提案します。
[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.
混雑の間、増加して、混雑から出て来た後に減少される(Recommendation4では、使用されます)連続したLSAsを隣人に送るところのギャップがことであるF=要素。 例の値は2です。
G(t) = Gap between sending successive LSAs to a neighbor at time t
(used in Recommendation 4).
G(t)は時t(Recommendation4では、使用されます)に連続したLSAsを隣人に送るところのギャップと等しいです。
Gmax = Maximum allowed value of gap between sending successive LSAs
to a neighbor (used in Recommendation 4). Example value is 1
second.
Gmaxは隣人(Recommendation4では、使用される)に連続したLSAsを送るところのギャップの最大の許容値と等しいです。 例の値は1秒です。
Gmin = Minimum allowed value of gap between sending successive LSAs
to a neighbor (used in Recommendation 4). Example value is 20
ms.
Gminは隣人(Recommendation4では、使用される)に連続したLSAsを送るところのギャップの最小の許容値と等しいです。 例の値は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は最高水位線と等しいです(不承認のLSAsのユニットの数で)。 このマークを超えていると、送付の連続したLSAsのギャップの潜在的増加は隣人に引き金となるでしょう。 (推薦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.
乗法的な定数がRxmtInterval値を増加させる際に使用したK=は連続する間、同じLSAの「再-トランスミッション」を使用しました(Recommendation3では、使用されます)。 例の値は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=干潮標(不承認のLSAsのユニットの数における)は送付の連続したLSAsのギャップの潜在的減少の隣人に引き金となるでしょう。 (推薦4では、使用されます。) 例の値は10です。
n = Upper limit on the number of adjacencies to be brought up
simultaneously (used in Recommendation 5).
nは、同時(Recommendation5では、使用される)に持って来られるために隣接番組の数で上限と等しいです。
Choudhury, Ed. Best Current Practice [Page 10] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[10ページ]RFC4222
R(i) = RxmtInterval value used during the i-th retransmission of an
LSA (used in Recommendation 3).
R(i)がRxmtInterval値と使用されていた状態で等しい、i、-、LSA(Recommendation3では、使用される)の第「再-トランスミッション」。
Rmax = The maximum allowed value of RxmtInterval (used in
Recommendation 3). Example value is 40 seconds.
RmaxはRxmtInterval(Recommendation3では、使用される)の値が許容された最大と等しいです。 例の値は40秒です。
Rmin = The minimum allowed value of RxmtInterval (used in
Recommendation 3). Example value is 5 seconds.
RminはRxmtInterval(Recommendation3では、使用される)の値が許容された最小限と等しいです。 例の値は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.
最小の時間の送付の連続したLSAsの既存のギャップの前に隣人に経過しなければならないT=は変化(Recommendation4では、使用される)のために考えられます。 例の値は1秒です。
U(t) = Number of unacknowledged LSAs to a neighbor at time t (used in
Recommendation 4).
U(t)は時t(Recommendation4では、使用されます)に隣人への不承認のLSAsの数と等しいです。
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/先行分野設定の2つの優先権のクラスの使用でしょう。 [Ref1]は、すべてのOSPFパケットのために0とPrecedence分野にTOS分野を設定することを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.
例1: 「低い」優先権パケットには、TOS分野を0に設定してください。そうすれば、Precedenceは6、および「高い」優先権のためにセットTOSが4としてさばいて、Precedenceが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に設定してください。そうすれば、Precedenceは6、および「高い」優先権のためにセットTOSが0としてさばいて、Precedenceが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(RFC2474、[Ref14])によって再定義されたことに注意してください。 また、異なったTOS/先行が必要性だけを超えてリンクの上にシステムで中同意されるべきである示された設定をさばくことに注意してください。 OSPFパケットのヘッダーを調べて、その結果、別々に「高く」て「低い」優先権パケットを分類するのが簡単であるなら、この推薦は、続かれるのに必要ではありません。
Choudhury, Ed. Best Current Practice [Page 11] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[11ページ]RFC4222
(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のRecommendation1で「高い」優先権を任じて、「低い」優先権OSPFパケットの中にさらなる優先権分離の必要があるかもしれません。 私たちは3つの優先権のクラスの使用を推薦します: 「高く」、「中型で」「低いです」。 隣人からパケットを受けている間、パケットを隣人に伝えている間、「低い優先度」パケットの前で「中型」の、そして、「低い」優先権パケットと「中型」の優先権パケットの前で「高い優先度」パケットを処理するようにしてください。 「高い」優先権パケットがセクション2のRecommendation1で指定されるようにあります。 私たちは「中型」の優先権パケットのための2つ未満の候補の例を提供します。 「高い」か「中型」の優先権として指定されたというわけではないすべてのOSPFパケットが「低い」優先権です。 Cryptographic Authentication(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つの例が承認として使用される奴隷(データベース同期の過程の間の)からのDatabase記述(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(これはLabel Switched PathsについてSPF計算とコースを変更することの引き金となるかもしれません、このパケットの処理がOSPF/ラベルDistributionプロトコル(自由民主党)集合回数を改良できるように、とても速い)です。 しかしながら、別々に特定する加工費であるなら、この例のLSAが次に、高値、implementerであると考えられる待ち行列は、それをしないと決めるかもしれません。
(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パージでLSAsを処理すると考えるかもしれません。 しかしながら、私たちはいくつかの理由で不適切なLSA処理を推薦しません。 まず最初に、待ち行列の前にLSAタイプを検出するのは計算上高価であるかもしれません。 また、不適切な処理は微妙なバグを引き起こすかもしれません。 ルータID変化などの比較的まれな出来事のためにLSA処理パラダイムにおける大きな変化を推薦したいと思いません。 しかしながら、波乱を巻き起こさないで、変化IDがあるルータは徐々に古いLSAsを洗い流すかもしれません。
Choudhury, Ed. Best Current Practice [Page 12] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[12ページ]RFC4222
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.がだらだらしゃべる、アーラン技術2880スコット・Boulevardカリフォルニア95052サンタクララ(米国)
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米国
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大使館アイコン別館、歩兵道路、バンガロール560 001インド
Phone: +91-(805)-137-7023 EMail: vishwas@sinett.com
以下に電話をしてください。 +91(805)137-7023メール: 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ローレルアベニューミドルタウン、ニュージャージー、07748米国
Phone: (732) 420-2653 EMail: sapozhnikova@att.com
以下に電話をしてください。 (732) 420-2653 メールしてください: sapozhnikova@att.com
Choudhury, Ed. Best Current Practice [Page 13] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[13ページ]RFC4222
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ローレルアベニューミドルタウン、ニュージャージー、07748米国
Phone: (732) 420-3721 EMail: gchoudhury@att.com
以下に電話をしてください。 (732) 420-3721 メールしてください: gchoudhury@att.com
Choudhury, Ed. Best Current Practice [Page 14] RFC 4222 Prioritized Treatment October 2005
エドチョウドリ、処理2005年10月に最優先した最も良い現在の習慣[14ページ]RFC4222
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Choudhury, Ed. Best Current Practice [Page 15]
エドチョウドリ、最も良い現在の習慣[15ページ]
一覧
スポンサーリンク
