RFC789 日本語訳

0789 Vulnerabilities of network control protocols: An example. E.C.Rosen. July 1981. (Format: TXT=25541 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

                                                          RFC 789

RFC789

    Vulnerabilities of Network Control Protocols: An Example

ネットワーク制御プロトコルの脆弱性: 例

                          Eric C. Rosen

エリック・C.ローゼン

                  Bolt Beranek and Newman Inc.

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

ボルトBeranek、ニューマン株式会社RFC789ボルトBeranek、およびニューマン・株式会社のエリック・C.ローゼン

     This paper has appeared in the January 1981 edition  of  the

この紙は1981年1月の版に載っていました。

SIGSOFT  Software  Engineering Notes, and will soon appear in the

SIGSOFT Software Engineering Notes、すぐ、中に現れるために望んでください。

SIGCOMM Computer Communications Review.  It is  being  circulated

SIGCOMMコンピュータコミュニケーションは再検討されます。 それは循環しています。

as  an  RFC because it is thought that it may be of interest to a

それがあるのでRFCが、それはaに興味があるかもしれないと思ったので

wider audience, particularly to the internet community.  It is  a

特にインターネット共同体への、より広い聴衆。 それはaです。

case  study  of  a  particular  kind of problem that can arise in

それが起こることができる特定の種類の問題のケーススタディ

large distributed systems,  and  of  the  approach  used  in  the

大きい分散システム、中でアプローチについて使用されます。

ARPANET to deal with one such problem.

そのような問題の1つに対処するアルパネット。

     On  October 27, 1980, there was an unusual occurrence on the

1980年10月27日に、オンである珍しい出来事がありました。

ARPANET.  For a period of several hours, the network appeared  to

アルパネット。 数時間、しばらく現れたネットワークについて

be  unusable,  due to what was later diagnosed as a high priority

使用不可能であることで、支払われるべきものが後で何に高い優先度と診断されたかということになってください。

software  process   running   out   of   control.    Network-wide

制御しきれないほど走るソフトウェア処理。 ネットワーク全体です。

disturbances  are  extremely  unusual  in  the  ARPANET (none has

騒動がアルパネットで非常に珍しい、(なにも持っていません。

occurred in several years), and as a  result,  many  people  have

起こった同じくらい結果の、そして、同じくらい多くの数年で人々

expressed  interest  in  learning more about the etiology of this

この病因に関してもう少し学ぶことへの言い表された関心

particular incident.  The purpose of this note is to explain what

特定の事件。 この注意の目的はなにかを説明するかことです。

the symptoms of the problem  were,  what  the  underlying  causes

問題の兆候がそうであった、基礎となるのが引き起こすこと

were,  and  what  lessons  can  be  drawn.   As we shall see, the

あった、そして、どんなレッスンを引き起こすことができますか? 私たちが見るように

immediate cause of the problem was  a  rather  freakish  hardware

問題の近因はかなり奇抜なハードウェアでした。

malfunction  (which is not likely to recur) which caused a faulty

不完全な状態でaを引き起こした不調(再発しそうにはありません)

sequence of network control packets to be generated.  This faulty

発生するべきネットワーク制御パケットの系列。 これほど不完全です。

sequence of control packets in turn affected the apportionment of

パケットが順番に配分に影響したコントロールの系列

software resources in the IMPs, causing one of the IMP  processes

IMPの過程の1つを引き起こすIMPsのソフトウェア・リソース

to  use  an  excessive  amount  of resources, to the detriment of

損傷への過量に関するリソースを使用します。

other  IMP  processes.   Restoring  the  network  to  operational

他のIMPは処理します。 ネットワークを操作上に回復します。

                              - 1 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 1--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

condition  was  a  relatively straightforward task.  There was no

状態は比較的簡単なタスクでした。 いいえがありました。

damage other than the outage itself,  and  no  residual  problems

供給停止自体以外の損害にもかかわらず、残っている問題がありません。

once  the  network  was  restored.   Nevertheless,  it  is  quite

一度、ネットワークは回復しました。 それにもかかわらず、それはかなり、そうです。

interesting to see the way  in  which  unusual  (indeed,  unique)

入口を見るためにおもしろい、どれ、まれ(本当に、ユニークである、)

circumstances  can  bring  out vulnerabilities in network control

事情はネットワーク制御における脆弱性を持ち出すことができます。

protocols, and that shall be the focus of this paper.

プロトコル、およびそれはそうでしょう。この紙の焦点。

     The problem began suddenly when  we  discovered  that,  with

私たちがそれを発見したとき、問題は突然始まりました。

very few exceptions, no IMP was able to communicate reliably with

ほんのわずかな例外、いいえIMPが確かに交信させることができた

any other IMP.  Attempts to go from a TIP to a host on some other

いかなる他のIMP。 TIPからホストまで行く試み、ある他の

IMP   only   brought  forth  the  "net  trouble"  error  message,

IMPは「ネットの問題」エラーメッセージを生産しただけです。

indicating that no physical path  existed  between  the  pair  of

どんな物理的な経路も組の間に存在しなかった表示

IMPs.   Connections  which already existed were summarily broken.

悪童。 既に存在したコネクションズは要約して壊れていました。

A flood of phone calls to the Network Control Center  (NCC)  from

AはNetwork Controlセンター(NCC)への電話を浸水させます。

all  around  the  country  indicated  that  the  problem  was not

全体に、国は、問題がそうでないことを示しました。

localized, but rather seemed to be affecting virtually every IMP.

集中していましたが、実際にはあらゆるIMPに影響しているようにむしろ思えました。

     As a first step towards trying to find out what the state of

ことから状態を見つけようとすることに向かった第一歩

the network actually was, we dialed up a number  of  TIPs  around

ネットワークが実際にあって、私たちは上に多くのおよそTIPsにダイヤルしました。

the  country.  What we generally found was that the TIPs were up,

国。 一般に、私たちが見つけたものはTIPsが上がっていたということでした。

but  that  their  lines  were  down.   That  is,  the  TIPs  were

しかし、それらの線は下がっていました。 すなわち、TIPsはそうでした。

communicating  properly  with the user over the dial-up line, but

適切にダイヤルアップ線でユーザとコミュニケートすることだけ。

no connections to other IMPs were possible.

他のIMPsとのどんな接続も可能ではありませんでした。

     We tried manually restarting a number of IMPs which  are  in

私たちは手動でそうする多くのIMPsを再開してみました。

our own building (after taking dumps, of course).  This procedure

私たち自身のビル(憂鬱を取った後にもちろん)。 この手順

initializes  all  of  the IMPs' dynamic data structures, and will

IMPsのダイナミックなデータ構造、および意志のすべてを初期化します。

                              - 2 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 2--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

often clear up problems which arise when, as sometimes happens in

しばしば起こる問題を解決してください、いつ、中で時々起こるか。

most complex software systems, the IMPs'  software  gets  into  a

ほとんどの複雑なソフトウェア・システムであり、IMPsのソフトウェアはaに入ります。

"funny"  state.   The IMPs which were restarted worked well until

「おかしい」状態。 再開されたIMPsはうまくいきました。

they were connected to the rest of  the  net,  after  which  they

それらが後にネットの残りに接続された、どれ、それら

exhibited  the same complex of symptoms as the IMPs which had not

同じように、そうしていないIMPsとして兆候で複雑な状態で、展示会に出品します。

been restarted.

再開されます。

     From the facts so far presented, we  were  able  to  draw  a

今までのところ提示されている事実から、私たちはaを描くことができました。

number  of  conclusions.   Any  problem  which  affects  all IMPs

結論の数。 すべてのIMPsに影響するどんな問題

throughout the network is usually a routing problem.   Restarting

ネットワーク中に、通常ルーティング問題があります。 再開します。

an  IMP  re-initializes  the routing data structures, so the fact

IMPはルーティングデータ構造を再初期化して、そうは事実です。

that restarting an IMP did not alleviate the problem in that  IMP

IMPを再開する場合、そのIMPの問題は軽減しませんでした。

suggested  that  the problem was due to one or more "bad" routing

問題が1か、より「悪い」ルーティングのためであったと示唆します。

updates circulating in the network.  IMPs  which  were  restarted

ネットワークで循環するアップデート。 再開されたIMPs

would  just receive the bad updates from those of their neighbors

ただ、彼らの隣人のものから悪いアップデートを受けるでしょう。

which were not restarted.  The fact that IMPs  seemed  unable  to

再開されませんでした。 IMPsが思えたという事実

keep  their lines up was also a significant clue as to the nature

また、それらの線が上げる生活費は自然に関する重要な手がかりでした。

of the problem.  Each  pair  of  neighboring  IMPs  runs  a  line

問題について。 各組の隣接しているIMPsは言葉巧みに誘います。

up/down protocol to determine whether the line connecting them is

それらを接続する線がそうであるか否かに関係なく、決定する/下にプロトコルに

of  sufficient  quality  to be put into operation.  This protocol

操作に入れることができるくらいの品質について。 このプロトコル

involves the sending of HELLO and I-HEARD-YOU messages.  We  have

そして、HELLOの発信にかかわる、I-HEARD、-、あなた、メッセージ。 私たちはそうしました。

noted  in  the  past that under conditions of extremely heavy CPU

下が条件とさせる非常に重いCPUの過去に注意されます。

utilization, so many buffers can pile up waiting to be served  by

バッファが役立たれる待ちを重ねることができるようにとても多くの利用

the  bottleneck  CPU process, that the IMPs are unable to acquire

ボトルネックCPUが処理されて、IMPsであることができない、取得します。

the  buffers  needed  for  receiving  the  HELLO  or  I-HEARD-YOU

または、バッファがHELLOを受けるのに必要であった、I-HEARD、-、あなた

messages.  If a condition like this lasts for any length of time,

メッセージ。 このような状態がどんな長さの時間も続くなら

                              - 3 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 3--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

the  IMPs  may  not be able to run the line up/down protocol, and

そしてIMPsが線上/下にプロトコルを走らせることができないかもしれない。

lines will be declared down by the IMPs' software.  On the  basis

台詞はIMPsのソフトウェアによって宣言されるでしょう。 ベースで

of  all  these  facts,  our  tentative  conclusion  was that some

これらのすべての事実では、私たちの一時的な結論はいくつかそれでした。

malformed update was causing the routing process in the  IMPs  to

奇形のアップデートはルーティングがIMPsで処理する引き起こすことでした。

use  an excessive amount of CPU time, possibly even to be running

ことによると走るのさえ過量のCPU時間を費やしてください。

in an infinite loop.  (This would be  quite  a  surprise  though,

無限では、輪にしてください。 (もっとも、これはかなりの驚きでしょう。

since  we  tried very hard to protect ourselves against malformed

私たちが非常に一生懸命奇形に対して我が身をかばおうとしたので

updates when we designed the routing process.)  As we shall  see,

私たちがルーティングを設計したとき、アップデートは処理されます。) 私たちが見るように

this  tentative  conclusion, although on the right track, was not

正しい軌道の上でこの一時的な結論

quite correct, and the actual situation turned  out  to  be  much

かなり修正する、実際の状況は多くであると判明しました。

more complex.

より複雑。

     When we examined core dumps from several IMPs, we noted that

数個のIMPsからコア・ダンプを調べたとき、私たちはそれに注意しました。

most,  in  some cases all, of the IMPs' buffers contained routing

大部分、いくつかの場合掘りながら含まれたIMPsのバッファのすべて

updates  waiting  to  be  processed.   Before   describing   this

処理されるのを待つアップデート。 これについて説明する前に

situation further, it is necessary to explain some of the details

さらに、それが必要である状況で、詳細のいくつかがわかります。

of  the  routing  algorithm's  updating  scheme.   (The following

ルーティング・アルゴリズムのアップデートでは、計画してください。 (以下

explanation will of course be very brief and incomplete.  Readers

説明は、もちろん非常に簡潔であって、不完全になるでしょう。 読者

with a greater  level  of  interest  are  urged  to  consult  the

より大きいレベルは興味があった状態で、相談するよう促されます。

references.)  Every so often, each IMP generates a routing update

参照。) 時々、各IMPはルーティングアップデートを発生させます。

indicating  which  other  IMPs  are  its immediate neighbors over

他のIMPsがどれのすぐ隣の人であるかを示します。

operational  lines,  and  the  average   per-packet   delay   (in

中戦闘用回線、および1パケットあたりの平均した遅れ、(。

milliseconds)  over that line.  Every IMP is required to generate

ミリセカンド) それの上では、立ち並んでください。 あらゆるIMPが、発生するのに必要です。

such an update at least once per minute, and no IMP is  permitted

少なくとも1分に一度そのようなアップデートを受入れますが、どんなIMPも受入れられません。

to  generate  more than a dozen such updates over the course of a

そのようなものがaの過程の上でアップデートする1ダース以上を発生させるように

minute.  Each  update  has  a  6-bit  sequence  number  which  is

微小。 各アップデートには、6ビットのそうする一連番号があります。

                              - 4 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 4--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

advanced by 1 (modulo 64) for each successive update generated by

それぞれの連続したアップデートあたり1(法64)時までには、発生していた状態で、進みます。

a  particular IMP.  If two updates generated by the same IMP have

特定のIMP。 同じIMPによって発生した2つのアップデートがそうしたなら

sequence numbers n and m, update n  is  considered  to  be  LATER

一連番号nとm、nがLATERであると考えられるアップデート

(i.e.,  more recently generated) than update m if and only if one

(すなわち、最近、より発生する)です。 アップデートm、単に1です。

of the following two conditions hold:

以下の2つの条件では、成立してください:

         (a) n > m, and n - m <= 32

(a)n>m、およびn--m<=32

         (b) n < m, and m - n > 32

(b) n<m、およびm--、n>32

(where the comparisons and subtractions treat n and m as unsigned

(比較と引き算は無記名としてnとmを扱います。

6-bit numbers, with  no  modulus).   When  an  IMP  generates  an

係数のない6ビットの数、) IMPが発生させるいつ

update,  it sends a copy of the update to each neighbor.  When an

アップデート、それはアップデートのコピーを各隣人に送ります。 いつ

IMP A receives an update u1 which was generated  by  a  different

IMP Aはa異なることで発生したアップデートu1を受けます。

IMP  B,  it  first  compares  the  sequence number of u1 with the

IMP B、それは最初に、u1の一連番号を比較します。

sequence number of the last update, u2, that it accepted from  B.

アップデートの一連番号、u2、それはBから受け入れました。

If  this  comparison  indicates  that  u2 is LATER than u1, u1 is

この比較が、u2がu1、u1よりLATERであることを示すなら

simply discarded.  If, on the other hand, u1 appears  to  be  the

単に捨てられます。 他方では、u1が、見える

LATER  update, IMP A will send u1 to all its neighbors (including

LATERアップデート、IMP Aがすべての隣人にu1を送る、(包含

the one from which it was received).  The sequence number  of  u1

それが受け取られたもの) u1の一連番号

will be retained in A's tables as the LATEST received update from

LATESTとしてのAのテーブルがアップデートを受けた保有されたコネであるために望んでください。

B.   Of  course,  u1 is always accepted if A has seen no previous

B。 もちろん、Aが、ノーが前であることを見たなら、いつもu1を受け入れます。

update from B.  Note that this procedure is  designed  to  ensure

B.から、この手順が確実にするように設計されているNoteをアップデートしてください。

that  an  update  generated  by  a  particular  IMP  is received,

特定のIMPによって発生したアップデートは受け取られています。

unchanged, by all other  IMPs  in  the  network,  IN  THE  PROPER

ネットワークにおける他のすべてのIMPs、IN THE PROPERで、変わりがありません。

SEQUENCE.    Each routing update is broadcast (or flooded) to all

系列。 それぞれのルーティングアップデートはすべてに放送されます(または、浸水します)。

IMPs, not just to immediate neighbors of the IMP which  generated

IMPのすぐ隣の人だけでないことへのIMPs、どれ、発生

                              - 5 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 5--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

the update (as in some other routing algorithms).  The purpose of

アップデート(ある他のルーティング・アルゴリズムのように)。 目的

the  sequence numbers is to ensure that all IMPs will agree as to

一連番号はすべてのIMPsが同意するために望んでいるのを保証することです。

which update from a given IMP  is  the  most  recently  generated

与えられたIMPからのどのアップデートが最も最近、発生しますか。

update from that IMP.

そのIMPから、アップデートします。

     For  reliability,  there  is  a  protocol for retransmitting

信頼性のために、再送するためのプロトコルがあります。

updates over individual links.  Let X and Y be neighboring  IMPs,

個々のリンクの上にアップデートします。 XとYが隣接しているIMPsであることをさせてください。

and let A be a third IMP.  Suppose X receives an update which was

そして、Aが第3のIMPであることをさせてください。 Xがそうするアップデートを受けると仮定してください。

generated by A, and transmits it to Y.  Now if in the next 100 ms

次の100msでAを発生させて、現在、それをY.に伝えます。

or  so, X does not receive from Y an update which originated at A

または、したがって、XはYからAで由来したアップデートを受けません。

and whose sequence number is at least as recent as  that  of  the

だれのものでは、一連番号はそれと少なくとも同じくらい最近です。

update  X  sent  to  Y,  X concludes that its transmission of the

Yに送られたアップデートX、Xがそれを結論づける、そのトランスミッション

update did not get through to Y, and  that  a  retransmission  is

アップデートはYに通じませんでした、そして、「再-トランスミッション」はそうです。

required.   (This  conclusion is warranted, since an update which

必要。 (アップデート以来この結論が保証される、どれ

is  received  and  adjudged  to  be  the  most  recent  from  its

受け取られて、最新の状態で宣告される、それ

originating  IMP is sent to all neighbors, including the one from

IMPがすべての隣人に送られて、ものを含んでいる由来

which it was received.)  The IMPs do not keep the original update

どれ、それを受け取ったか、) IMPsはオリジナルのアップデートを保ちません。

packets  buffered  pending  retransmission.   Rather,   all   the

パケットは未定の「再-トランスミッション」をバッファリングしました。 むしろすべて

information  in  the  update  packet  is  kept in tables, and the

そしてアップデートパケットの情報がテーブルに保たれる。

packet  is  re-created  from  the  tables  if  necessary  for   a

パケットは必要ならaのためにテーブルから作り直されます。

retransmission.

「再-トランスミッション」。

     This  transmission  protocol  ("flooding")  distributes  the

このトランスミッションプロトコル(「氾濫」)は分配します。

routing updates  in a  very  rapid  and  reliable  manner.   Once

非常に急速で信頼できる方法でアップデートを発送します。 一度

generated by an IMP, an update will almost always reach all other

IMPによって発生して、アップデートはほとんどいつもすべてのもう一方に達するでしょう。

IMPs  in  a time period on the order of 100 ms.  Since an IMP can

100原稿Sinceの注文での期間のIMPsはIMP缶です。

generate no more than a dozen updates per minute, and  there  are

1ダースだけを1分あたりのアップデートに発生させてください。そうすれば、あります。

                              - 6 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 6--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

64  possible sequence numbers, sequence number wrap-around is not

64 可能な一連番号であり、一連番号巻きつけて着るドレスはそうではありません。

a problem.  There is only one exception  to  this.   Suppose  two

問題。 これへの1つの例外しかありません。 2を仮定してください。

IMPs  A  and  B  are  out  of  communication for a period of time

IMPs AとBはしばらく、コミュニケーションを使い果たしました。

because there is no physical path between them.  (This may be due

それらの間には、どんな物理的な経路もないので。 (これは当然であるかもしれません。

either to a network partition, or to a more  mundane  occurrence,

ネットワークパーティション、または、より世俗的な発生に

such  as  one  of  the  IMPs  being down.)  When communication is

下がっているIMPsの1つなどのように。) コミュニケーションはいつですか。

re-established, A and B have no way of knowing how long they have

AとBには、復職していて、それらがどれくらい長い間そうしているかを知る方法が全くありません。

been out of communication, or how many times the other's sequence

コミュニケーションかそれとも何回他による系列であるかから脱しています。

numbers may have wrapped around.  Comparing the  sequence  number

数は巻きつけられたかもしれません。 一連番号を比較します。

of  a newly received update with the sequence number of an update

アップデートの一連番号がある新たに受け取られたアップデートについて

received before the outage may give an incorrect result.  To deal

供給停止が不正確な結果を与えるかもしれない前に受信しました。 取引に

with this problem, the following scheme is adopted.   Let  t0  be

この問題で、以下の計画は採用されます。 t0をあってください。

the time at which IMP A receives update number n generated by IMP

IMP AがIMPによって発生した更新番号nを受ける時

B.   Let  t1 be t0 plus 1 minute.  If by t1, A receives no update

B。 t1がt0と1分であることをさせてください。 t1で、Aがアップデートを全く受けないなら

generated by B with a LATER sequence number than n, A will accept

LATER一連番号があるBによって発生される、n、Aは受け入れるでしょう。

any update from B as being more recent than n.  So  if  two  IMPs

nより最近としてのBからのどんなアップデート。 そのように2IMPsであるなら

are  out  of  communication  for  a  period of time which is long

しばらくコミュニケーションから、どれがあるかが切望されるということです。

enough for the sequence numbers  to  have  wrapped  around,  this

一連番号が巻きつけられることができたくらいのこれ

procedure  ensures  that  proper  resynchronization  of  sequence

手順は系列のその適切な再同期を確実にします。

numbers is effected when communication is re-established.

コミュニケーションが復職するとき、数は作用しています。

     There is just one more facet of the updating  process  which

そこ、まさしくアップデートの1つの、より多くの一面がどれを処理するかということです。

needs  to  be  discussed.   Because  of  the way the line up/down

議論するのが必要です。 道による顔触れ/下

protocol works, a line cannot be  brought  up  until  60  seconds

作品について議定書の中で述べてください、そして、60秒まで線は持って来ることができません。

after  its performance becomes good enough to warrant operational

性能が操作上であることを保証できるくらい良くなった後に

use.  (Roughly speaking, this is the time it takes  to  determine

使用。 (大まかに言えば、これはわざわざですそれが決定する。

                              - 7 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 7--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

that  the  line's  performance  is  good  enough.)   During  this

行性能は十分良いです)。 これの間

60-second period, no data is sent  over  the  line,  but  routing

60第2ピリオドであり、データは、全く線で送りますが、掘られていません。

updates are transmitted.  Remember that every node is required to

アップデートは伝えられます。 あらゆるノードが必要であったのを覚えていてください。

generate  a  routing update at least once per minute.  Therefore,

1分単位でルーティングアップデートを少なくとも一度発生させてください。 したがって

this procedure ensures that if two IMPs are out of  communication

2IMPsがコミュニケーションを使い果たしたなら、この手順はそれを確実にします。

because  of  the  failure  of some line, each has the most recent

何らかの線の失敗のために、それぞれがそうした、最新

update  from   the   other   by   the   time   communication   is

もう片方からのコミュニケーションがそうであるまでにアップデート

re-established.

復職。

     This  very  short  introduction  to  the routing algorithm's

ルーティング・アルゴリズムのものへのこの非常に短い序論

updating protocol should provide enough background to enable  the

プロトコルをアップデートすると、可能にすることができるくらいのバックグラウンドは提供されるべきです。

reader  to  understand  the  particular problem under discussion;

議論で特定の問題を理解する読者。

further justification and detail can be found in the  references.

参照でさらなる正当化と詳細を見つけることができます。

     Let  us  return now to the discussion of the network outage.

もう、ネットワーク供給停止の議論に戻りましょう。

I have already mentioned that the core dumps  showed  almost  all

私は、コア・ダンプがほとんどすべてを示したと既に言及しました。

buffers   holding  routing  updates  which  were  waiting  to  be

そうするルーティングアップデートを保持するバッファは、待っています。

processed.  Close inspection showed that  all  the  updates  were

処理にされる。 厳重な検査は、すべてのアップデートがそうであることを示しました。

from  a  single  IMP, IMP 50.  By a strange "coincidence," IMP 50

独身のIMP、IMP50から。 奇妙な「偶然の一致」、IMP50

had been  malfunctioning  just  before  the  network-wide  outage

ネットワーク全体の供給停止のすぐ前に誤動作し続けていました。

occurred,  and  was  off the net during the period of the outage.

起こって、供給停止の期間、ネットにありました。

Hence it was not generating any updates during the period of  the

したがって、それは期間のどんなアップデートも発生させていませんでした。

outage.   In  addition,  IMP 29, an immediate neighbor of IMP 50,

供給停止。 添加、IMP29、IMP50のすぐ隣の人で

was also suffering hardware malfunctions (in particular, dropping

苦しみもハードウェアの不良であった、(特に低下

bits), but was up (though somewhat flakey) while the network  was

ビット)、ネットワークは上がりましたが、上がりました(もっとも、いくらかflakey)。

in  bad  shape.  Furthermore, the malfunction in IMP 50 had to do

体調が悪い。 その上、IMP50の不調はしなければなりませんでした。

with its ability to communicate properly with the neighboring IMP

適切に隣接しているIMPとコミュニケートする性能で

                              - 8 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 8--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

29.  Although we did not yet understand how it was  possible  for

29. 私たちはまだそれがどう可能であったかを理解していませんでした。

so  many updates from one IMP to be extant simultaneously, we did

とても多くが同時に実在であるために1からIMPをアップデートして、私たちはそうしました。

understand enough to be able to get the network to recover.   All

十分がネットワークに. すべてを回復させることができるのを理解してください。

that was necessary was to patch the IMPs to disregard any updates

それによる必要であるのが、IMPsを修理するどんなアップデートも無視するためにことであったということでした。

from  IMP  50, which after all was down anyway.  When the network

IMP50から。(IMPは結局とにかく下がっていました)。 時はネットワークです。

is operating normally, broadcasting a patch to all  IMPs  can  be

通常、作動していて、すべてのIMPsにパッチを放送するのは、そうであることができます。

done  in  a  matter of minutes.  With the network operating as it

ものの数分で、します。 それとして作動するネットワークと共に

was during the period of the outage, this can take as much  as  3

供給停止の期間、これが最大3を取ることができるということでした。

or  4 hours.  (Remember that the IMPs are generally unmanned, and

または、4時間。 そして(一般に、IMPsが無人であることを覚えていてください。

that the only way of controlling them from the  NCC  is  via  the

NCCからそれらを制御する唯一の方法でいるそれ

network  itself.   This  is perfectly satisfactory when an outage

それ自体をネットワークでつないでください。 供給停止であるときに、これは完全に満足できます。

affects only a small group of IMPs, but  is  an  obvious  problem

IMPsの小さいグループだけに影響しますが、明白な問題です。

when  the  outage  has network-wide effects.)  This procedure was

供給停止にネットワーク全体の効果があるとき。) この手順はそうでした。

fully successful in bringing the network back up.

ネットワークを持って来て戻すのに完全に成功しています。

     When we looked closely at the dumps, we saw  that  not  only

しっかり憂鬱を調べたとき、私たちがそれを見た、唯一でない

were  all  the updates on the queue from IMP 50, but they all had

IMP50からの待ち行列にすべてのアップデートがありましたが、それらは皆、ありました。

one of three sequence numbers (either 8, 40,  or  44),  and  were

3つの一連番号(8、40、または44)の1つ、存在だった

ordered        in        the        queue       as       follows:

以下の待ち行列で命令される:

8, 40, 44, 8, 40, 44, 8, 40, 44, ...  Note that by the definition

8, 40, 44, 8, 40, 44, 8, 40, 44, ... 定義でそれに注意してください。

of LATER, 44 is LATER than 40 (44 > 40 and 44 - 40 <= 32), 40  is

LATERでは、44が40(44>40と44--40<=32)よりLATERである、40はそうです。

LATER  than  8  (40 > 8 and 40 - 8 <= 32), and 8 is LATER than 44

LATER、8(40>8と40--8<=32)、および8、LATERである、44

(8 < 44 and 44 - 8 > 32).  Given the presence  of  three  updates

(8<44と44--8>32。) 3つのアップデートの存在に与えます。

from the same IMP with these three sequence numbers, this is what

これがこれらの3つの一連番号がある同じIMPからの、そうである、何

would  be  expected.   Since each update is LATER than one of the

予想されるでしょう。 以来、各アップデートは1よりLATERです。

others, a cycle is formed which keeps the three updates  floating

他のもの、3つのアップデートを浮かせ続ける1サイクルが形成されます。

                              - 9 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 9--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

around  the  network  indefinitely.   Thus the IMPs spend most of

周囲で無期限にネットワークでつなぎます。 このようにして、IMPsは最も費やします。

their CPU time and buffer space in processing these updates.  The

これらのアップデートを処理することにおけるそれらのCPU時間とバッファ領域。 The

problem was to figure out how these three updates could  possibly

これらの3つのアップデートがそうすることができるだろう問題は見積もることでした。

have  existed at the same time.  After all, getting from update 8

同時に、存在しました。 アップデート8からの得る後に

to update 40  should  require  2  or  3  full  minutes,  plus  31

40をアップデートするのは2分か完全な3分、および31を必要とするべきです。

intervening  sequence  numbers.   So  how could 8 still be around

一連番号に介入します。 8が周囲にどのようにまだあるかもしれなくて

when  40  was  generated,  especially  since  no   updates   with

いつで、特にどんなアップデート以来も40は発生しませんでしたか。

intervening sequence numbers were present?

介入している一連番号は存在していましたか?

     Our  first thought was that maybe the real-time clock in IMP

私たちの最初の考えは多分リアルタイムでがIMPの仕事を始めるということでした。

50 was running one or two orders of magnitude faster than normal,

50 1か2を走らせるのは標準より何桁も速かったです。

invalidating our assumptions about the maximum number of  updates

アップデートの最大数に関する私たちの仮定を無効にします。

which  could  be  generated  in  a  given  time.   An alternative

与えられた時間で発生できました。 代替手段

hypothesis suggested itself however when we looked at the  binary

しかしながら、私たちがバイナリーを見たとき、仮説は連想されました。

representations of the three sequence numbers:

3つの一連番号の表現:

          8 - 001000

8 - 001000

         40 - 101000

40 - 101000

         44 - 101100

44 - 101100

Note  that  44  has only one more bit than 40, which has only one

44にはもうひとつのビットしか40ほどないというメモ。(そのメモには、1つしかありません)。

more bit than 8.  Furthermore, the three different  updates  were

以上に8より噛み付きました。 その上、3つの異なったアップデートがそうでした。

completely  identical,  except  for their sequence numbers.  This

それらの一連番号を除いて、完全に同じです。 これ

suggests that  there  was  really  only  one  update,  44,  whose

1つのアップデート、44しか本当になかったと示唆する、だれのもの

sequence number was twice corrupted by dropped bits.  (Of course,

一連番号は二度低下しているビットで崩壊しました。 (もちろん

it's  also  possible  that  the  "real"  update  was  8,  and was

また、「本当」のアップデートは8であり、あったのも、可能です。

corrupted by added bits.  However, bit-dropping has proven itself

加えられたビットで、崩壊します。 しかしながら、ビット低下はそれ自体に判明しました。

                             - 10 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 10--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

to be a much  more  common  sort  of  hardware  malfunction  than

はるかに一般的な種類のハードウェアの不良です。

bit-adding,  although  spontaneously  dropped  bits may sometimes

自然に低下しているビットは時々加えますが、ビット加えます。

come back on spontaneously.)

自然に来返してください。)

     Surely, the reader will object,  there  must  be  protection

読者は、保護が確実にあるに違いないのを反対するでしょう。

against  dropped  bits.   Yes there is protection, but apparently

低下しているビットに対して。 はいはそこで明らかに保護です。

not enough.  The update packets themselves are checksummed, so  a

十分でない。 アップデートパケット自体はchecksummedされて、そうはaです。

dropped  bit  in  an update packet is readily detected.  Remember

アップデートパケットの低下しているビットは容易に検出されます。 覚えていてください。

though that if  an  update  needs  to  be  retransmitted,  it  is

もっとも、アップデートが、再送される必要があるなら、それは必要があります。

recreated  from tabled information.  For maximal reliability, the

見送られた情報から、休養させられます。 最大限度の信頼性のために

tables must  be  checksummed  also,  and  the  checksum  must  be

また、テーブルをchecksummedしなければなりません、そして、チェックサムはchecksummedするに違いありません。

recomputed every time the table is accessed.  However, this would

テーブルがアクセスされているときはいつも、再計算しました。 しかしながら、これはそうするでしょう。

require  either  a  large  number  of  CPU  cycles  (for frequent

CPU何サイクルも必要としてください、(頻繁

checksumming of a large area of memory)  or  a  large  amount  of

または、メモリの広い地域のchecksumming)、多量

memory  (to store the checksums for a lot of small areas).  Since

メモリ(多くの狭い面積にチェックサムを格納する)。 以来

CPU cycles and memory are both potentially scarce resources, this

CPUサイクルとメモリが両方の潜在的に不十分なリソースである、これ

did not seem to us to  be  a  cost-effective  way  to  deal  with

私たちにとって、ずっと対処するために費用対効果に優れたaになるように見えませんでした。

problems  that  arise, say, once per year (this is the first such

たとえば1年に一度起こる問題、(最初に、これはそのようなものです。

problem encountered in a year and a half of running this  routing

このルーティングを走らせる1年半で行きあたる問題

algorithm).   Time  and  space  can  be  saved by recomputing the

アルゴリズム) 再計算することによって、時間と空間を節約できます。

checksum at  a  somewhat  slower  frequency,  but  this  is  less

しかし、いくらか遅い頻度におけるチェックサム、これは、より少ないです。

reliable,  in  that it allows a certain number of dropped bits to

信頼できる、それが、ある数の低下しているビットを許容するコネ

"fall between the cracks."  It seems likely then that one of  the

「ひびの間の秋。」 それがその時ありそうに見える、その1つ

malfunctioning  IMPs  had to retransmit update 44 at least twice,

誤動作IMPsは少なくとも二度アップデート44を再送しなければなりませんでした。

(recreating it each time from tabled information), retransmitting

(その都度、見送られた情報からそれを再作成します), 再送します。

it at least once with the corrupted sequence number  40,  and  at

そしてそれ、崩壊した一連番号40による少なくとも一度。

                             - 11 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 11--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

least  once  with  the  corrupted  sequence number 8.  This would

最も一度崩壊した一連番号8で これはそうするでしょう。

cause those three sequence numbers to be extant  in  the  network

それらの3つの一連番号がネットワークで実在であることを引き起こしてください。

simultaneously,  even  though protocol is supposed to ensure that

同時に、プロトコルは思われますが、それを確実にしてください。

this is impossible.

これは不可能です。

     Actually, the detection of dropped bits is most  properly  a

実際に、低下しているビットの検出は最も適切にそうです。

hardware function.  The next generation of IMP hardware (the "C30

ハード性能。 IMPハードウェアの次世代、("C30"

IMP")  will  be able to detect and correct all single-bit errors,

"IMP") すべての単一のビット誤りを検出して、修正できるでしょう。

and will detect all other bit errors.  Uncorrectable  bit  errors

そして、他のすべての噛み付いている誤りを検出するでしょう。 Uncorrectableは誤りに噛み付きました。

will  cause  the  IMP to go into its "loader/dumper."  (An IMP in

IMPが「荷物を積む人/ごみ捨て人夫」に入ることを引き起こすでしょう。 (中の悪童

its loader/dumper is not usable for  transferring  data,  and  is

荷物を積む人/ごみ捨て人夫は、データを移すには使用可能でなく、います。

officially   in  the  "down"  state.   However,  an  IMP  in  its

公式に“down"状態で。 しかしながら、中のIMP、それ

loader/dumper is easily controllable from the  NCC,  and  can  be

荷物を積む人/ごみ捨て人夫は、NCCから容易に制御可能であり、いることができます。

restarted  or  reloaded  without  on-site intervention.)  Current

現場の介入なしで再開されるか、または再び積まれます。) 電流

hardware does have parity checking (which  should  detect  single

ハードウェアにはパリティの照合がある、(どれがシングルを検出するべきであるか。

dropped  bits),  but  this feature has had to be turned off since

低下しているビット)、この特徴は以来にオフにされなければなりませんでした。

(a) there are too many spurious parity "errors,"  i.e.,  most  of

(a) そこでは、あまりに多くの偽りのパリティ「誤り」で、すなわち、だいたいです。

the  time when the machines complain of parity errors there don't

マシンがそこでパリティエラーについて不平を言う時はそうしません。

really seem to be any, and (b) parity errors cause  the  machines

(b) 本当にいずれでもあるように思えてください。そうすれば、パリティエラーはマシンを引き起こします。

to  simply  halt, rather than go into their loader/dumpers, which

彼らの荷物を積む人/ごみ捨て人夫に入るより単にむしろ停止するためにどれ

means that on-site intervention is required to restart them.

現場の介入がそうである手段がそれらを再開するのが必要です。

     Pending the introduction of improved hardware, what  can  be

改良されたハードウェアの導入まで、何があることができますか?

done  to prevent problems like this from recurring in the future?

このような問題が将来再発するのを防ぐために、しますか?

It is easy to think of many  ways  of  avoiding  this  particular

特定の状態でこれを避ける多くの方法を考えるのは簡単です。

problem,  especially  if  one does not consider the problems that

人が、問題がそれであると特に考えない問題

may arise from the "fixes."  For example, we  might  be  able  to

「フィックス」から起こるかもしれません。 例えば、私たちはできるかもしれません。

                             - 12 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 12--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

avoid  this  sort of problem by spending a lot more CPU cycles on

ずっと多くのCPUサイクルの後の間の支出でこの種類の問題を避けてください。

checksumming, but this may be too expensive because of  the  side

しかし、checksumming、これは側のために高価過ぎるかもしれません。

effects  it  would  introduce.   (Also,  it is not clear that any

それが導入する効果。 (また、それがそれをクリアしないことである、いくらか。

memory checksumming strategy can be totally free of "cracks.")  A

メモリchecksumming戦略は完全に「ひび」を持つことができるというわけではありません。) A

very  simple  and  conservative  fix  to  prevent this particular

特定の状態でこれを防ぐ非常に簡単で保守的なフィックス

problem from recurring is to modify clause (a) of the  definition

再発するのからの問題は定義の節(a)を変更することです。

of  LATER  so  that  the  "<="  is replaced by "<" (strictly less

LATER、「<=」を"<"に取り替える、(厳密により少ない

than).  We will implement this fix, but it cannot  be  guaranteed

) 私たちはこのフィックスを実行するつもりですが、それを保証できません。

that no related problems will ever arise.

どんな関連する問題も起こらないでしょう。

     What  is  really  needed  is  not some particular fix to the

本当に必要であるものは事項が修理するいくつかではありません。

routing algorithm, but a more general fix.  In  some  sense,  the

アルゴリズム、しかし、より一般的なフィックスを発送します。 何らかの意味で

problem  we  saw  was  not really a routing problem.  The routing

私たちが認めた問題は本当にルーティング問題ではありませんでした。 ルーティング

code was working correctly, and the routes  that  were  generated

コードは、正しく働いて、発生したルートでした。

were correct and consistent.  The real problem is that a freakish

正しくて、一貫しています。 実際の問題はaそんなに奇抜です。

hardware  malfunction caused a high priority process to run wild,

ハードウェアの不良で、高い優先権の過程ははびこりました。

devouring resources needed by other processes, thereby making the

その結果、他の過程、作成で必要であるリソースをむさぼり食うこと。

network unusable.  The fact that the wild process was the routing

ネットワーク使用不可能です。 ワイルドな過程がルーティングであったという事実

process is incidental.  In  designing  the  routing  process,  we

過程は付帯的です。 ルーティングを設計する際に、処理してください、私たち

carefully  considered the amount of resource utilization it would

それがそうするリソース利用の量であると慎重に考えられます。

require.  By strictly controlling and limiting the rate at  which

必要です。 厳密にレートを制御して、制限する、どれ

updates  can  be  generated, we tried to prevent any situation in

アップデートは発生できて、私たちは中でどんな状況も防ごうとしました。

which the routing process would make  excessive  demands  on  the

ルーティングの過程は過剰需要をします。

system.   As  we  have  seen  though, even our carefully designed

システム。 私たち、さえ入念に設計されています。

mechanisms were unable to protect against every possible sort  of

メカニズムはあらゆる可能な種類から守ることができませんでした。

hardware  failure.  We need a better means of detecting that some

ハードウェアの故障。 私たちはそれをいくつか検出するより良い手段を必要とします。

                             - 13 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 13--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

high priority process in the IMP, despite all the  safeguards  we

高い優先度はIMPで処理されて、すべてにもかかわらず、安全装置は私たちです。

have  built in, is still consuming too many resources.  Once this

中に建てて、それでも、あまりに多くのリソースを消費すること。 一度これ

is  detected,  the  IMP  can  be  automatically  placed  in   its

検出されていて、IMPで自動的に入賞できるということである、それ

loader/dumper.  In the case under discussion, we would have liked

荷物を積む人/ごみ捨て人夫。 議論している場合では、私たちは好きだったでしょう。

to  have  all  the  IMPs  go  into  their loader/dumpers when the

すべてのIMPsを彼らの荷物を積む人/ごみ捨て人夫に入らせる、いつ

problem arose.  This would have enabled us to  re-initialize  and

問題は起こりました。 そしてこれが、私たちが再初期化するのを可能にしただろう。

restart  all  the  IMPs  much more quickly.  (Although restarting

はるかにすぐにすべてのIMPsを再開してください。 (再開します。

individual  IMPs  did  little  good,  restarting  all  the   IMPs

すべてのIMPsを再開して、個々のIMPsは役に立ちませんでした。

simultaneously would have cleared up the problem instantly, since

同時に、以来、即座にその問題を解決したでしょう。

all  routing  tables  in  all  IMPs  would  have been initialized

すべてのIMPsのすべての経路指定テーブルが初期化されたでしょう。

simultaneously.)  It took us no more than an hour to  figure  out

同時)。 見積もるには私たちに1時間だけかかりました。

how  to  restore  the  network;  several  additional  hours  were

どうネットワークを回復するか。 追加数時間はそうでした。

required because it took so long for us to gain  control  of  the

私たちがコントロールを獲得するほど長い状態で取ったので、必要です。

misbehaving  IMPs  and  get  them  back  to  normal.   A built-in

そして、ふらちな事するIMPs、彼らを標準に取り戻してください。 A内蔵です。

software alarm system (assuming,  of  course,  that  it  was  not

ソフトウェアアラームシステム、(もちろんそれはそれを仮定しなかったことです。

subject  to  false  alarms)  might have enabled us to restore the

間違い警報への対象) 力は、私たちが回復するのを可能にしました。

network more quickly, significantly reducing the duration of  the

よりはやくネットワークでつないで、持続時間をかなり減少させます。

outage.   This  is  not  to  say  that a better alarm and control

供給停止。 これはそのaより良いアラームとコントロールでとは言わないまでもあります。

system could ever be a replacement for careful study  and  design

かつて、システムは慎重な研究とデザインへの交換品であるかもしれません。

which   attempts   to  properly  distribute  the  utilization  of

どの試みについて適切に利用を広げますか。

important resources, but only that it is a necessary adjunct,  to

重要なリソースそれが必要な付属物であっただけではないなら

handle  the cases that will inevitably fall between the cracks of

それがひびの間で必然的に低下する場合を扱ってください。

even the most careful design.

最も慎重なデザインさえ。

                             - 14 -

RFC 789                              Bolt Beranek and Newman Inc.
                                                    Eric C. Rosen

- 14--RFC789ボルトBeranekとニューマン・株式会社のエリック・C.ローゼン

                           REFERENCES

参照

"The New Routing Algorithm for the ARPANET," IEEE TRANSACTIONS ON

「アルパネットのための新しいルーティング・アルゴリズム」、IEEE取引、オン

COMMUNICATIONS, May 1980, J.M. McQuillan, I. Richer, E.C.  Rosen.

コミュニケーション、1980年5月、J.M.マッキラン、I.リシェ、E.C.ローゼン。

"The  Updating  Protocol  of  ARPANET's  New  Routing Algorithm,"

「アルパネットの新しいルーティング・アルゴリズムのアップデートプロトコル」

COMPUTER NETWORKS, February 1980, E.C. Rosen.

コンピュータネットワーク、1980年2月、E.C.ローゼン。

                             - 15 -


- 15 -

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ABSVAL関数 絶対値

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る