RFC904 日本語訳
0904 Exterior Gateway Protocol formal specification. D.L. Mills. April 1 1984. (Format: TXT=65226 bytes) (Updates RFC0827, RFC0888) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D.L. Mills Request for Comments: 904 April 1984
L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 904 1984年4月
Exterior Gateway Protocol Formal Specification
外のゲートウェイプロトコル形式仕様
0. Status of this Memo
0. このMemoの状態
This RFC is the specification of the Exterior Gateway Protocol
(EGP). This document updates RFCs 827 and 888. This RFC specifies a
standard for the DARPA community. Interactions between gateways of
different autonomous systems in the ARPA-Internet must follow this
protocol.
このRFCはExteriorゲートウェイプロトコル(EGP)の仕様です。 このドキュメントはRFCs827と888をアップデートします。 このRFCはDARPA共同体の規格を指定します。 ARPA-インターネットの異なった自律システムのゲートウェイの間の相互作用はこのプロトコルに続いて起こらなければなりません。
1. Introduction
1. 序論
This document is a formal specification of the Exterior Gateway
Protocol (EGP), which is used to exchange net-reachability information
between Internet gateways belonging to the same or different autonomous
systems. The specification is intended as a reference guide for
implementation, testing and verification and includes suggested
algorithmic parameters suitable for operation over a wide set of
configurations, including the ARPANET and many local-network
technologies now part of the Internet system.
仕様は、実装、テスト、および検証のための参照ガイドとして意図して、広いセットの構成で操作に適した提案されたアルゴリズムのパラメタを含んでいます、インターネット・システムの現在のアルパネットと多くのローカルネットワーク技術部分を含んでいて。このドキュメントはExteriorゲートウェイプロトコル(EGP)に関する形式仕様です。(プロトコルは、同じであるか異なった自律システムに属しながらインターネット・ゲートウェイの間でネットの可到達性情報を交換するのに使用されます)。
Specifically excluded in this document is discussion on the
background, application and limitations of EGP, which have been
discussed elsewhere (RFC-827, RFC-888). If, as expected, EGP evolves to
include topologies not restricted to tree-structures and to incorporate
full routing capabilities, this specification will be amended or
obsoleted accordingly. However, it is expected that, as new features
are added to EGP, the basic protocol mechanisms described here will
remain substantially unchanged, with only the format and interpretation
of the Update message (see below) changed.
明確に本書では除かれているのは、EGP(RFC-827、RFC-888)のバックグラウンド、アプリケーション、および限界が議論です。(ほかの場所でEGPについて議論しました)。 EGPが木構造に制限されなかったtopologiesを含んで、完全なルーティング能力を取り入れるために予想されるように発展すると、この仕様は、それに従って、修正されるか、または時代遅れにされるでしょう。 しかしながら、新機能がEGPに加えられるときここで説明された基本プロトコルメカニズムは実質的に変わりがないと予想されます、Updateメッセージ(以下を見る)の形式と解釈だけを変えていて。
Section 2 of this document describes the nomenclature used, while
Section 3 describes the state-machine model, including events, actions,
parameters and state transitions. Section 4 contains a functional
description of the operation of the machine, together with specific
procedures and algorithms. Appendix A describes the EGP message
formats, while Appendix B contains a summary of the minor differences
between these and the formats described in RFC-888. Appendix C presents
a reachability analysis including a table of composite state transitions
for a system of two communicating EGP gateways.
このドキュメントのセクション2はセクション3が州マシンモデルについて説明しますが、イベント、動作、パラメタ、および状態遷移を含んでいて、使用される用語体系について説明します。 セクション4はマシンの操作の機能的な記述を含みます、特定の手順とアルゴリズムと共に。付録AはEGPメッセージ・フォーマットについて説明します、Appendix BはRFC-888で説明されたこれらと形式の間に小異の概要を含んでいますが。 付録CはEGPゲートウェイを伝える2のシステムのための合成状態遷移のテーブルを含む可到達性分析を提示します。
1.1. Summary and Overview
1.1. 概要と概要
EGP exists in order to convey net-reachability information between
neighboring gateways, possibly in different autonomous systems. The
protocol includes mechanisms to acquire neighbors, monitor neighbor
reachability and exchange net-reachability information in the form of
Update messages. The protocol is based on periodic polling using
Hello/I-Heard-You (I-H-U) message exchanges to monitor neighbor
reachability and Poll commands to solicit Update responses.
EGPはネットの可到達性情報を隣接しているゲートウェイの間に伝えるために存在しています、ことによると異なった自律システムで。プロトコルは、Updateメッセージの形で隣人、モニター隣人の可到達性、および交換ネットの可到達性情報を取得するためにメカニズムを含んでいます。 プロトコルは、隣人の可到達性とUpdate応答に請求するPollコマンドをモニターするのに私があなたの声をHello/聞いている(I-H-U)交換処理を使用することで周期的な世論調査に基づいています。
Specification of EGP is based on a formal model consisting of a
Exterior Gateway Protocol Formal Specification Page 2
D.L. Mills
EGPの仕様はExteriorゲートウェイプロトコルFormal Specification2ページD.L.ミルズから成る形式モデルに基づいています。
finite-state automaton with defined events, state transitions and actions. The following diagram shows a simplified graphical representation of this machine (see Section 3.4 for a detailed state transition table).
定義されたイベント、状態遷移、および動作がある有限状態オートマトン。 以下のダイヤグラムはこのマシンの簡易型のグラフ表示を示しています(詳細な状態遷移テーブルのためにセクション3.4を見てください)。
+-------+
| |---------------+---------------+
+---->| Idle | A A
| | |-----------+ | |
| +-------+ | | |
| | A Request | | Cease | Cease
| Start | | Cease | | |
| V | Refuse V | |
| +-------+ Confirm +-------+ Up +-------+
| | |-------->| |-------->| |
| | Aqsn | | Down | Down | Up |
| | |----+ | |<--------| |
| +-------+ | +-------+ +-------+
| | | |
| Stop | | |
| Cease-ack | Stop | Stop | Stop
| +-------+ | | |
| | | V V V
+-----| Cease |<---+--------+-----------------+
| |
+-------+
+-------+ | |---------------+---------------+ +---->| 怠けてください。| A| | |-----------+ | | | +-------+ | | | | | 要求| | やんでください。| やんでください。| 始め| | やんでください。| | | | V| Vを拒否してください。| | | +-------+は+を確認します。-------+ +に-------+ | | |、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、--、>|、|、|、| Aqsn| | 下に| 下に| 上がる| | | |----+ | | <、-、-、-、-、-、-、--、|、|、| +-------+ | +-------+ +-------+ | | | | | 停止| | | | ackをやめます。| 停止| 停止| 停止| +-------+ | | | | | | +に対するV V-----| やんでください。| <、-、--+--------+-----------------+ | | +-------+
Following is a brief summary and overview of gateway operations by
state as determined by this model.
以下に、このモデルによって決定されるように状態によるゲートウェイ操作の簡潔な概要と概要があります。
Idle State (0)
活動していない状態(0)
In the Idle state the gateway has no resources (table space)
assigned to the neighbor and no protocol activity of any kind is in
progress. It responds only to a Request command or a Start event
(system or operator initiated) and ignores all other commands and
responses. The gateway may optionally return a Cease-ack response
to a Cease command in this state.
Idle状態では、ゲートウェイで、リソース(テーブルスペース)を全く隣人に割り当てません、そして、どんな種類のプロトコル活動も全く進行していません。 それは、RequestコマンドかStartイベント(システムか開始されたオペレータ)だけに応じて、他のすべてのコマンドと応答を無視します。 ゲートウェイは任意にこの状態のCeaseコマンドへのCease-ack応答を返すかもしれません。
Upon receipt of a Request command the gateway initializes the state
variables as described in Section 3.1, sends a Confirm response and
transitions to the Down state, if resource committments permit, or
sends a Refuse response and returns to the Idle state if not. Upon
receipt of a Start event it sends a Request command and transitions
to the Acquistion state.
応答をRefuseに送って、そうでなければ、Requestコマンドを受け取り次第、ゲートウェイは、セクション3.1で説明されるように州の変数を初期化するか、リソースcommittmentsが可能にするならDown状態への応答と変遷をConfirmに送るか、またはIdle状態に戻ります。 Startイベントを受け取り次第、それはRequestコマンドと変遷をAcquistion状態に送ります。
Acquisition State (1)
獲得状態(1)
In the Acquisition state the gateway periodically retransmits
Request commands. Upon receiving a Confirm response it initializes
Exterior Gateway Protocol Formal Specification Page 3
D.L. Mills
ゲートウェイが定期的に再送するAcquisition状態では、Requestは命令します。 Confirm応答を受けると、それはExteriorゲートウェイプロトコルFormal Specification3ページ D.L.ミルズを初期化します。
the state variables and transitions to the Down state. Upon
receiving a Refuse response it returns to the Idle state. The
gateway does not send any other commands or responses in this state,
since not all state variables have yet been initialized.
Down状態への州の変数と変遷。 Refuse応答を受けると、それはIdle状態に戻ります。 ゲートウェイはこの状態でいかなる他のコマンドか応答も送りません、すべての州の変数がまだ初期化されるというわけではなかったので。
Down State (2)
状態の下側に(2)
In the Down state the gateway has received a Request command or a
Confirm response has been received for a previously sent Request.
The neighbor-reachability protocol has declared the neighbor to be
down. In this state the gateway processes Request, Cease and Hello
commands and responds as required. It periodically retransmits
Hello commands if enabled. It does not process Poll commands and
does not send them, but may optionally process an unsolicited Update
indication.
ゲートウェイが受けたDown状態では、以前に送られたRequestのためにRequestコマンドかConfirm応答を受け取りました。 隣人可到達性プロトコルは、隣人が下がっていると宣言しました。 この状態では、ゲートウェイは、Request、Cease、およびHelloコマンドを処理して、必要に応じて応じます。 可能にされるなら、それは定期的にHelloコマンドを再送します。 それは、Pollコマンドを処理しないで、またそれらを送りませんが、任意に求められていないUpdate指示を処理するかもしれません。
Up State (3)
状態に(3)
In the Up state the neighbor-reachability protocol has declared the
neighbor to be up. In this state the gateway processes and responds
to all commands. It periodically retransmits Hello commands, if
enabled, and Poll commands.
Up状態では、隣人可到達性プロトコルは、隣人が起きていると宣言しました。 この状態では、ゲートウェイは、すべてのコマンドに処理して、応じます。 可能にされるなら、それは定期的にHelloコマンドを再送します、そして、Pollは命令します。
Cease State (4)
状態をやめてください。(4)
A Stop event causes a Cease command to be sent and a transition to
the Cease state. In this state the gateway periodically retransmits
the Cease command and returns to the Idle state upon receiving a
Cease-ack response or a another Stop event. The defined state
transitions are designed to ensure that the neighbor does with high
probability receive the Cease command and stop the protocol.
Stopイベントは送られるべきCeaseコマンドとCease状態への変遷を引き起こします。 ゲートウェイが定期的に再送するこの状態では、Cease-ack応答か別のStopを受けるとき、IdleへのCeaseコマンドとリターンはイベントを述べます。 定義された状態遷移は、隣人が高い確率でCeaseコマンドを受け取って、プロトコルを止めるのを保証するように設計されています。
In following sections of this document document a state machine
which can serve as a model for implementation is described. It may
happen that implementators may deviate from this model while conforming
to the protocol specification; however, in order to verify conformance
to the specification, the state-machine model is intended as the
reference model.
このドキュメントドキュメントの以下の章で、実装のために手本になることができる州のマシンは説明されます。 implementatorsがプロトコル仕様に従っている間このモデルから逸れるかもしれないのは起こるかもしれません。 しかしながら、仕様に順応について確かめるために、州マシンモデルは規範モデルとして意図します。
Although not mentioned specifically in this document, it should be
understood that all Internet gateways must include support for the
Internet Control Message Protocol (ICMP), specifically ICMP Redirect and
ICMP Destination Unreachable messages.
明確に本書では言及されませんが、すべてのインターネット・ゲートウェイがインターネット・コントロール・メッセージ・プロトコル(ICMP)、明確にICMP Redirect、およびICMP Destination Unreachableメッセージのサポートを含まなければならないのが理解されるべきです。
2. Nomenclature
2. 用語体系
The following EGP message types are recognized in this document.
The format of each of these messages is described in Appendix A.
Exterior Gateway Protocol Formal Specification Page 4
D.L. Mills
以下のEGPメッセージタイプは本書では見分けられます。 それぞれに関するこれらのメッセージの形式はAppendix A.ExteriorゲートウェイプロトコルFormal Specification4ページ D.L.ミルズで説明されます。
Name Function
------------------------------------------------------
Request request acquisition of neighbor and/or
initialize polling variables
Confirm confirm acquisition of neighbor and/or
initialize polling variables
Refuse refuse acquisition of neighbor
Cease request de-acquisition of neighbor
Cease-ack confirm de-acquisition of neighbor
Hello request neigbor reachability
I-H-U confirm neigbor reachability
Poll request net-reachability update
Update net-reachability update
Error error
名前機能------------------------------------------------------ 隣人の要求獲得を要求してください、初期化、世論調査変数Confirmは隣人の獲得を確認する、そして/または、Cease-ackが、隣人Helloの反-獲得要求neigborの可到達性I-H-Uが確認すると確認する隣人の隣人Cease要求反-獲得neigbor可到達性Poll要求ネットの可到達性アップデートUpdateネットの可到達性アップデートError誤りの世論調査変数Refuse廃物獲得を初期化します。
EGP messages are classed as commands which request some action,
responses, which are sent to indicate the status of that action, and
indications, which are similar to responses, but may be sent at any
time. Following is a list of commands along with their possible
responses.
応答は、その動作の状態を示すために送られます。(指摘は応答と同様です)。EGPメッセージを何らかの動作を要求するコマンドと応答と指摘として分類しますが、いつでも、送るかもしれません。 以下に、彼らの可能な応答に伴うコマンドのリストがあります。
Command Corresponding Responses
---------------------------------------
Request Confirm, Refuse, Error
Cease Cease-ack, Error
Hello I-H-U, Error
Poll Update, Error
対応する応答を命令してください。--------------------------------------- こんにちは、拒否するように確認するよう要求してください、誤りが-ackにやんだ状態でやんで、誤りがI-H-Uであり、誤りが投票アップデートである、誤り
The Update and Error messages are classed both as responses and
indications. When sent in reply to a previous command, either of these
messages is classed as a response. In some circumstances an unsolicited
Update message can be sent, in which case it is classed as an
indication. The use of the Error message other than as a response to a
previous command is a topic for further study.
UpdateとErrorメッセージは応答と指摘として分類されます。 前のコマンドに対して送ると、応答としてこれらのメッセージのどちらかを分類します。 いくつかの事情では、求められていないUpdateメッセージを送ることができます、その場合、指示としてそれを分類します。 前のコマンドへの応答以外のErrorメッセージの使用はさらなる研究への話題です。
3. State Machine
3. 州のマシン
This section describes the state-machine model for EGP, including
the variables and constants which establish the state at any time, the
events which cause the state transitions, the actions which result from
these transitions and the state-transition table which defines the
behavior.
このセクションはEGPのために州マシンモデルについて説明します、いつでも状態を設置する変数と定数を含んでいて、変遷(これらの変遷と振舞いを定義する状態遷移テーブルから生じる動作)を状態に引き起こすイベント。
3.1. State Variables
3.1. 州の変数
The state-machine model includes a number of state variables which
establish the state of the protocol between the gateway and each of its
neighbors. Thus, a gateway maintaining EGP with a number of neighbors
must maintain a separate set of these state variables for each neighbor.
The current state, events and actions of the state machine apply to each
Exterior Gateway Protocol Formal Specification Page 5
D.L. Mills
州マシンモデルはゲートウェイとその隣人各人の間のプロトコルの事情を確立する多くの州の変数を入れます。 したがって、多くの隣人がいるEGPを維持するゲートウェイは各隣人のためにこれらの州の変数の別々のセットを維持しなければなりません。 州のマシンの現状、イベント、および機能はプロトコルFormal Specification5ページ それぞれのExteriorゲートウェイのD.L.ミルズに適用されます。
neighbor separately.
別々に、近所付き合いします。
The model assumes that system resources, including the set of state
variables, are allocated when the state machine leaves the Idle state,
either because of the arrival of a Request specifying a new neighbor
addreess, or because of a Start event specifying a new neighbor address.
When either of these events occur the values of the state variables are
initialized as indicated below. Upon return to the Idle state all
resources, including the set of state variables, are deallocated and
returned to the system. Implementators may, of course, elect to
dedicate resources and state variables permananently.
州のマシンが新しい隣人addreessを指定するRequestの到着のため新しい隣人アドレスを指定するStartイベントのでIdle状態を出るとき、モデルは、州の変数のセットを含むシステム資源が割り当てられると仮定します。 これらのイベントのどちらかが起こるとき、州の変数の値は以下に示すように初期化されます。 Idle状態へのリターンのときに、州の変数のセットを含むすべてのリソースを、システムに「反-割り当て」て、返します。 Implementatorsは、permananentlyにリソースと州の変数を捧げるのをもちろん選ぶかもしれません。
Included among the set of state variables are the following which
determine the state transitions of the model. Initial values for all of
the variables except the send sequence number S are set during the
initial Request/Confirm exchange. The initial value for S is arbitrary.
州の変数のセットの中に含まれているのは、モデルの状態遷移を決定する以下です。 Sが設定される一連番号に初期を送ってください。変数のすべてのための初期の値が除かれる、Request/は交換を確認します。 Sのための初期の値は任意です。
Name Function
--------------------------------------------------------------
R receive sequence number
S send sequence number
T1 interval between Hello command retransmissions
T2 interval between Poll command retransmissions
T3 interval during which neighbor-reachability
indications are counted
M hello polling mode
t1 timer 1 (used to control Request, Hello and Cease
command retransmissions)
t2 timer 2 (used to control Poll command retransmissions)
t3 timer 3 (abort timer)
名前機能-------------------------------------------------------------- Rが受信される、一連番号Sが間のHelloコマンドretransmissions T2間隔の間の間の一連番号T1間隔にこんにちは、M1(以前はよくRequest、Hello、およびCeaseコマンド「再-トランスミッション」を制御していた)t2の世論調査モードt1タイマタイマ2(以前はよくPollコマンド「再-トランスミッション」を制御していました)t3を隣人可到達性指摘が数えられるPollコマンドretransmissions T3間隔に送る、タイマ3(アボートタイマ)
Additional state variables may be necessary to support various timer and similar internal housekeeping functions. The function and management of the cited variables are discussed in Section 4.
追加州の変数が、様々なタイマと同様の内部の家事の機能をサポートするのに必要であるかもしれません。 セクション4で引用された変数の機能と管理について議論します。
3.2. Fixed Parameters
3.2. 固定パラメタ
This section defines several fixed parameters which characterize
the gateway functions. Included is a suggested value for each parameter
based on experimental implementations in the Internet system. These
values may or may not be appropriate for the individual configuration.
このセクションはゲートウェイ機能を特徴付けるいくつかの固定パラメタを定義します。 含まれているのは、インターネット・システムの実験的な実装に基づく各パラメタのための提案された値です。 個々の構成に、これらの値は適切であるかもしれません。
Following is a list of time-interval parameters which control
retransmissions and other time-dependent functions.
Exterior Gateway Protocol Formal Specification Page 6
D.L. Mills
以下に、「再-トランスミッション」を制御する時間間隔パラメータと他の時間依存する機能のリストがあります。 外のゲートウェイプロトコル形式仕様6ページ D.L.工場
Name Value Description
--------------------------------------------------------------
P1 30 sec minimum interval acceptable between successive
Hello commands received
P2 2 min minimum interval acceptable between successive
Poll commands recieved
P3 30 sec interval between Request or Cease command
retransmissions
P4 1 hr interval during which state variables are
maintained in the absence of commands or
responses in the Down and Up states.
P5 2 min interval during which state variables are
maintained in the absence of responses in the
Acquisition and Cease states
名前値の記述-------------------------------------------------------------- 連続したHelloコマンドの間で許容できるP1の30秒の最小間隔はCeaseコマンドretransmissions P4 1時間のRequestか州の変数がコマンドか応答がないときDownで維持される間隔とUpのrecieved P3の30秒の間隔が述べる連続したPollコマンドの間で許容できるP2 2分最小の間隔を受けました。 州の変数がAcquisitionの応答がないとき維持される間隔とCeaseが述べるP5 2分
Parameters P4 and P5 are used only if the abort-timer option is
implemented. Parameter P4 establishes how long the machine will remain
in the Down and Up states in the absence of commands or responses and
would ordinarily be set to sustain state information while the neighbor
is dumped and restarted, for example. Parameter P5 establishes how long
the machine will remain in the Acquisition or Cease states in the
absence of responses and would ordinarily be set in the same order as
the expected value of T3 variables.
アボートタイマオプションが実装される場合にだけ、パラメタのP4とP5は使用されています。 通常、パラメタP4はマシンがコマンドか応答がないときDownとUp州にどれくらい長いままで残るかを確証して、隣人が捨てられますが、州の情報を支えるように用意ができて、例えば、再開されるでしょう。 パラメタP5はマシンが応答がないときAcquisitionかCease州にどれくらい長いままで残るかを確証して、通常、T3変数の期待値として同次で用意ができているでしょう。
Following is a list of other parameters of interest.
以下に、興味がある他のパラメタのリストがあります。
Name Active Passive Description
-----------------------------------------------
j 3 1 neighbor-up threshold
k 1 4 neighbor-down threshold
活発な受け身の記述を命名してください。----------------------------------------------- j3 1の隣人上がっている敷居k1 4下に隣人敷居
The j and k parameters establish the "noise immunity" of the
neighbor-reachability protocol described later. The values in the
Active column are suggested if the gateway elects to do hello polling,
while the values in the Passive column are suggested otherwise.
jとkパラメタは後で説明された隣人可到達性プロトコルの「雑音余裕度」を設立します。 ゲートウェイが、するのを選ぶならActiveコラムの値が示される、こんにちは、Passiveコラムの値が別の方法で示される間の世論調査。
3.3. Events
3.3. イベント
Following is a list of events that can cause state transitions in
the model.
Exterior Gateway Protocol Formal Specification Page 7
D.L. Mills
以下に、モデルにおける状態遷移を引き起こす場合があるイベントのリストがあります。 外のゲートウェイプロトコル形式仕様7ページ D.L.工場
Name Event
----------------------------------------------------------------------
Up At least j neighbor-reachability indications have been
received within the last T3 seconds.
Down At most k neighbor-reachabilitiy indications have been
received within the last T3 seconds.
Request Request command has been received.
Confirm Confirm command has been received.
Refuse Refuse response has been received.
Cease Cease command has been received.
Cease-ack Cease-ack response has been received.
Hello Hello command has been received.
I-H-U I-H-U response has been received.
Poll Poll command has been received.
Update Update response has been received.
Start Start event has been recognized due to system or
operator intervention.
Stop/t3 Stop event has been recognized due to (a) system or
operator intervention or (b) expiration of the abort
timer t3.
t1 Timer t1 has counted down to zero.
t2 Timer t2 has counted down to zero.
名前イベント---------------------------------------------------------------------- At最少jに、最後のT3秒以内に隣人可到達性指摘を受けました。 Atの下側に、最後のT3秒以内にほとんどのk隣人-reachabilitiy指摘を受けました。 Requestコマンドが受け取られたよう要求してください。 Confirmコマンドが受け取られたと確認してください。 廃物Refuse応答を受けました。 Ceaseコマンドをやめてください。受け取りました。 ack Cease-ackをやめている応答を受けました。 受け取られましたこんにちは、Helloが、命令する。 I-H-U I-H-U応答を受けました。 投票Poll命令を受け取りました。 アップデートUpdate応答を受けました。 スタートStart出来事はシステムかオペレータ介入のため認識されました。 (b) 停止/t3 Stop出来事が(a) システムかオペレータ介入のため認識されたか、またはt3アボートタイマt1 Timer t1の満了はゼロまで重要でした。t2 Timer t2はゼロまで数えました。
There is one special event, called a neighbor-reachability
indication, which occurs when:
そこ、隣人可到達性指示と呼ばれる起こるある特別なイベントがいつです:
1. The gateway is operating in the active mode (hello polling enabled)
and either a Confirm, I-H-U or Update response is received.
1. ゲートウェイがアクティブなモードで作動している、(こんにちは、可能にされた世論調査) そして、a Confirm、I-H-Uか受けられたUpdate応答のどちらか。
2. The gateway is operating in the passive mode (hello polling
disabled) and either a Hello or Poll command is received with the
"Up state" code in the Status field.
2. ゲートウェイは受け身の形態で作動しています、そして、(こんにちは、世論調査身体障害者)「状態」コードがStatus分野にある状態で、HelloかPollコマンドのどちらかを受け取ります。
3.4. State Transition Table
3.4. 状態遷移テーブル
The following table summarizes the state transitions that can occur
in response to the events listed above. Transitions are shown in the
form n/a, where n is the next state and a represents the action.
Exterior Gateway Protocol Formal Specification Page 8
D.L. Mills
以下のテーブルは上に記載された出来事に対応して起こることができる状態遷移をまとめます。 変遷はなしというフォームに示されて、nが次の状態であり、aが動作を表すところでことです。 外のゲートウェイプロトコル形式仕様8ページ D.L.工場
0 Idle 1 Aqsn 2 Down 3 Up 4 Cease
+-----------+-----------+-----------+-----------+-----------+
Up |0 |1 |3/Poll |3 |4 |
Down |0 |1 |2 |2 |4 |
Request |2/Confirm *|2/Confirm |2/Confirm |2/Confirm |4/Cease |
Confirm |0/Cease **|2 |2 |3 |4 |
Refuse |0/Cease **|0 |2 |3 |4 |
Cease |0/Cease-ack|0/Cease-ack|0/Cease-ack|0/Cease-ack|0/Cease-ack|
Cease-ack |0 |1 |2 |3 |0 |
Hello |0/Cease **|1 |2/I-H-U |3/I-H-U |4 |
I-H-U |0/Cease **|1 |2/Process |3/Process |4 |
Poll |0/Cease **|1 |2 |3/Update |4 |
Update |0/Cease **|1 |2 |3/Process |4 |
Start |1/Request |1/Request |1/Request |1/Request |4 |
Stop/t3 |0 |0 |4/Cease |4/Cease |0 |
t1 |0 |1/Request |2/Hello |3/Hello |4/Cease |
t2 |0 |1 |2 |3/Poll |4 |
+-----------+-----------+-----------+-----------+-----------+
0 使用されていない1Aqsn2下3であるのは4に+をやめます。-----------+-----------+-----------+-----------+-----------+ 上に|0 |1 |3/投票|3 |4 | 下に|0 |1 |2 |2 |4 | 要求|2 /は*を確認します。|/が確認する2|/が確認する2|/が確認する2|4 /はやみます。| 確認します。|0 /は**をやめます。|2 |2 |3 |4 | 廃物|0 /は**をやめます。|0 |2 |3 |4 | やんでください。|ackを0/やめます。|ackを0/やめます。|ackを0/やめます。|ackを0/やめます。|ackを0/やめます。| ackをやめます。|0 |1 |2 |3 |0 | こんにちは|0 /は**をやめます。|1 |2/I-H-U|3/I-H-U|4 | I-H-U|0 /は**をやめます。|1 |2/過程|3/過程|4 | 投票|0 /は**をやめます。|1 |2 |3/アップデート|4 | アップデート|0 /は**をやめます。|1 |2 |3/過程|4 | 始め|1/要求|1/要求|1/要求|1/要求|4 | 停止/t3|0 |0 |4 /はやみます。|4 /はやみます。|0 | t1|0 |1/要求|2/、こんにちは。|3/、こんにちは。|4 /はやみます。| t2|0 |1 |2 |3/投票|4 | +-----------+-----------+-----------+-----------+-----------+
Note *: The transition shown applies to the case where the neighbor-acquisition request is accepted. The transition "0/Refuse" applies to the case where the request is rejected.
注意*: 示された変遷は隣人獲得要求が受け入れられるケースに適用されます。 変遷「0/廃物」は要求が拒絶されるケースに適用されます。
Note **: The Cease action shown is optional.
**に注意してください: 示されたCease動作は任意です。
3.5. State Transitions and Actions
3.5. 状態遷移と動作
The following table describes in detail the transitions of the
state machine and the actions evoked.
以下のテーブルは詳細に州のマシンの変遷と喚起された動作について説明します。
Next Message
Event State Sent Actions
------------------------------------------------------------------------
次のメッセージイベント州は動作を送りました。------------------------------------------------------------------------
Idle State (0)
活動していない状態(0)
Request 2 Confirm Initialize state variables and
Hello reset timer t1 to T1 seconds and
reset timer t3 to P5 seconds.
(or) 0 Refuse Return resources.
Cease 0 Cease-ack Return resources.
Start 1 Request Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
要求2Confirm Initialize州の変数とHelloはT1秒までタイマt1をリセットして、P5秒までタイマt3をリセットします。 (or) 0はReturnにリソースを拒否します。 0つのCease-ack Returnリソースをやめてください。 P5秒までP3秒とリセットタイマt3に1Request Resetのタイマt1を始動してください。
Acquisition State (1)
獲得状態(1)
Request 2 Confirm Initialize state variables and
Hello reset timer t1 to T1 seconds and
reset timer t3 to P5 seconds.
Confirm 2 Hello Initialize state variables and
Exterior Gateway Protocol Formal Specification Page 9
D.L. Mills
要求2Confirm Initialize州の変数とHelloはT1秒までタイマt1をリセットして、P5秒までタイマt3をリセットします。 2つのHello Initialize州の変数とExteriorゲートウェイプロトコルFormal Specification9ページ D.L.ミルズを確認してください。
reset timer t1 to T1 seconds and
reset timer t3 to P5 seconds.
Refuse 0 Stop timers and return
resources.
Cease 0 Cease-ack Stop timers and return
resources.
Start 1 Request Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
Stop/t3 0 Stop timers and return
resources.
t1 1 Request Reset timer t1 to P3 seconds.
P5秒までT1秒とリセットタイマt3にタイマt1をリセットしてください。 0つのStopタイマとリターンリソースを拒否してください。 0つのCease-ack Stopタイマとリターンリソースをやめてください。 P5秒までP3秒とリセットタイマt3に1Request Resetのタイマt1を始動してください。 停止/t3 0 StopタイマとリターンリソースP3秒までのt1 1 Request Resetタイマt1。
Down State (2) Note: Reset timer t3 to P4 seconds on receipt of a reachability indication.
状態(2)の下側に、以下に注意してください。 可到達性指示を受け取り次第P4秒までタイマt3をリセットしてください。
Up 3 Poll Reset timer t2 to T2 seconds.
Request 2 Confirm Reinitialize state variables and
Hello reset timer t1 to T1 seconds and
reset timer t3 to P5 seconds.
Cease 0 Cease-ack Stop timers and return
resources.
Hello 2 I-H-U
I-H-U 2 Process neighbor-reachability
info.
Start 1 Request Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
Stop/t3 4 Cease Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
t1 2 Hello Reset timer t1 to T1 seconds.
T2秒までの3Poll Resetタイマt2に。 要求2Confirm Reinitialize州の変数とHelloはT1秒までタイマt1をリセットして、P5秒までタイマt3をリセットします。 0つのCease-ack Stopタイマとリターンリソースをやめてください。 こんにちは、2I-H-U I-H-U2。Process隣人可到達性インフォメーション。 P5秒までP3秒とリセットタイマt3に1Request Resetのタイマt1を始動してください。 P3秒までの停止/t3 4 Cease Resetタイマt1とT1秒までのP5秒t1 2 Hello Resetタイマt1へのリセットタイマt3。
Up State (3) Note: Reset timer t3 to P4 seconds on receipt of a reachability indication.
状態(3)に、以下に注意してください。 可到達性指示を受け取り次第P4秒までタイマt3をリセットしてください。
Down 2 Stop timer t2.
Request 2 Confirm Renitialize state variables and
Hello reset timer t1 to T1 seconds and
reset timer t3 to P5 seconds.
Cease 0 Cease-ack Stop timers and return
resources.
Hello 3 I-H-U
I-H-U 3 Process neighbor-reachability
info.
Poll 3 Update
Update 3 Process net-reachability info.
Start 1 Request Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
Stop/t3 4 Cease Reset timer t1 to P3 seconds and
reset timer t3 to P5 seconds.
Exterior Gateway Protocol Formal Specification Page 10
D.L. Mills
下に2Stopタイマt2。 要求2Confirm Renitialize州の変数とHelloはT1秒までタイマt1をリセットして、P5秒までタイマt3をリセットします。 0つのCease-ack Stopタイマとリターンリソースをやめてください。 こんにちは、3I-H-U I-H-U3。Process隣人可到達性インフォメーション。 3Update Update3Processネットの可到達性インフォメーションに投票してください。 P5秒までP3秒とリセットタイマt3に1Request Resetのタイマt1を始動してください。 P3秒までの停止/t3 4 Cease Resetタイマt1とP5秒までのリセットタイマt3。 外のゲートウェイプロトコル形式仕様10ページ D.L.工場
t1 3 Hello Reset timer t1 to T1 seconds. t2 3 Poll Reset timer t2 to T2 seconds.
T2秒までのT1秒t2 3 Poll Resetタイマt2へのt1 3 Hello Resetタイマt1。
Cease State (4)
状態をやめてください。(4)
Request 4 Cease
Cease 0 Cease-ack Stop timers and return
resources.
Cease-ack 0 Stop timers and return
resources.
Stop/t3 0 Stop timers and return
resources.
t1 4 Cease Reset timer t1 to P3 seconds.
4つのCease Cease0Cease-ack Stopタイマとリターンリソースを要求してください。 0個のackをやめているStopタイマとリターンリソース。 停止/t3 0 StopタイマとリターンリソースP3秒までのt1 4 Cease Resetタイマt1。
4. Functional Description
4. 機能的な記述
This section contains detailed descriptions of the various
procedures and algorithms used to manage the protocol.
このセクションはプロトコルを管理するのに用いられた様々な手順とアルゴリズムの詳述を含みます。
4.1. Managing the State Variables
4.1. 州の変数を管理します。
The state variables which characterize the protocol are summarized
in Section 3.1. This section describes the detailed management of these
variables, including sequence numbers, polling intervals and timers.
プロトコルを特徴付ける州の変数はセクション3.1にまとめられます。 このセクションは一連番号、ポーリングインタバル、およびタイマを含むこれらの変数の詳細な管理について説明します。
4.1.1. Sequence Numbers
4.1.1. 一連番号
All EGP commands and replies carry a sequence number. The state
variable R records the last sequence number received in a command from
that neighbor. The current value of R is used as the sequence number
for all replies and indications sent to the neighbor until a command
with a different sequence number is received from that neighbor.
すべてのEGPコマンドと回答は一連番号を運びます。 州の変数Rはその隣人からコマンドで受け取られた最後の一連番号を記録します。 すべての回答と指摘のための一連番号がその隣人から異なった一連番号があるコマンドを受け取るまで隣人に発信したので、Rの現行価値は使用されています。
Implementors are free to manage the sequence numbers of the
commands sent; however, it is suggested that a separate send state
variable S be maintained for each EGP neighbor and that its value be
incremented just before the time an Poll command is sent and at no other
times. The actions upon receipt of a response or indication with
sequence number not equal to S is not specified; however, it is
recommended these be discarded.
作成者は自由に送られたコマンドの一連番号を管理できます。 aそんなに別々の状態で示されて、州の変数Sを送ります。しかしながら、それがそう、それぞれのEGP隣人のために維持されてください、送られ、Pollが命令するとき値がちょうど以前増加されるのは他のどんな時にも維持されません。 応答を受け取り次第動作かSと等しくない一連番号がある指示が指定されません。 しかしながら、捨てられて、これらはそれに推薦されます。
4.1.1. Polling Intervals
4.1.1. ポーリングインタバル
As part of the Request/Confirm exchange a set of polling intervals
are established including T1, which establishes the interval between
Hello command retransmissions, and T2, which establishes the interval
between Poll retransmissions.
Request/の一部が交換を確認するとき、T1(Helloコマンド「再-トランスミッション」の間で間隔を確立して、Poll retransmissionsの間で間隔を確立するT2を確立する)を含んでいて、1セットのポーリングインタバルは確立されます。
Each gateway configuration is characterized by a set of fixed
parameters, including P1, which specifies the minimum polling interval
Exterior Gateway Protocol Formal Specification Page 11
D.L. Mills
それぞれのゲートウェイ構成は1セットの固定パラメタによって特徴付けられます、P1(ExteriorゲートウェイプロトコルFormal Specification11ページ 最小のポーリングインタバルD.L.ミルズを指定する)を含んでいて
at which it will respond to Hello commands, and P2, which specifies the minimum polling interval at which it will respond to Poll commands. P1 and P2 are inserted in the Hello Interval (S1) and Poll Interval (S2) fields, respectively, of Request commands and Confirm responses.
それはHelloコマンド、およびP2に応じるでしょう。(P2はそれがPollコマンドに応じる最小のポーリングインタバルを指定します)。 P1とP2はRequestコマンドとConfirm応答についてそれぞれHello Interval(S1)とPoll Interval(S2)分野に挿入されます。
A gateway receiving a Request command or Confirm response uses the
S1 and S2 fields in the message to calculate its own T1 and T2 state
variables, respectively. Implementors are free to perform this
calculation in arbitrary ways; however, the following constraints must
be observed:
RequestコマンドかConfirm応答を受け取るゲートウェイはそれぞれそれ自身のT1とT2州の変数について計算するメッセージでS1とS2分野を使用します。 作成者は自由に任意の方法でこの計算を実行できます。 しかしながら、以下の規制を観測しなければなりません:
1. If T1 < S1 the neighbor may discard Hello commands. If T2 < S2 the
neighbor may discard Poll commands.
1. 隣人のT1<S1が捨てるかもしれないなら、Helloは命令します。 隣人のT2<S2が捨てるかもしれないなら、Pollは命令します。
2. The time window T3 in which neighbor-reachability indications are
counted is dependent on T1. In the case where two neighbors select
widely differing values for their T3 state variables, the
neighbor-reachability algorithm may not work properly. This can be
avoided if T1 > max(P1, S1).
2. 隣人可到達性指摘が数えられるタイムウィンドウT3はT1に依存しています。 2人の隣人がそれらのT3州の変数のためにはなはだしく異なった値を選択する場合では、隣人可到達性アルゴリズムは適切に利かないかもしれません。 T1>最大(P1、S1)であるならこれを避けることができます。
3. If either S1 or S2 or both are unacceptable for some reason (e.g.
exceed useful limits), the neighbor may either send a Refuse
response or declare a Stop event, depending on state.
3. S1かS2か両方のどちらかがある理由で容認できないなら(例えば、役に立つ限界を超えてください)、隣人は、Refuse応答を送るか、またはStop出来事を宣言するかもしれません、状態によって。
It is suggested that T3 be computed as four times the value of T1,
giving a window of four neighbor-reachability indications, which has
been found appropriate in the experimental implementations.
Implementors may choose to make T3 a fixed parameter in those cases
where the path between the neighbors has well-known characteristics.
T3がT1の値の4倍として計算されることが提案されます、4つの隣人可到達性指摘の実験的な実現で適切なわかった窓を与えて。 作成者は、T3を隣人の間の経路が周知の特性を持っているそれらのケースの中の固定パラメタにするのを選ぶかもしれません。
Note that, if a gateway attempts to send Hello commands near the
rate max(P1, S1) or Poll commands near the rate max(P2, S2), the
neighbor may observe their succeeding arrivals to violate the polling
restrictions due to bunching in the net. For this reason the gateway
should send at rates somewhat below these. Just how much below these
rates is appropriate depends on many factors beyond the scope of this
specification.
ゲートウェイが、レート最大(P1、S1)かほぼPollコマンドでコマンドをHelloにほぼレート最大(P2、S2)で送るのを試みるなら隣人がネットで束になるのによる世論調査制限に違反するために彼らの続く到着を観測するかもしれないことに注意してください。 この理由で、ゲートウェイはレートでこれらのいくらか下に発信するはずです。 まさしくいくらがこれらのレートより下で適切であるかはこの仕様の範囲を超えた多くの要素に依存します。
4.1.3. Hello Polling Mode
4.1.3. こんにちは、世論調査モード
The neighbor-reachability algorithm can be used in either the
active or passive mode. In the active mode Hello commands are sent
periodically along with Poll commands, with reachability determined by
the corresponding I-H-U and Update responses. In the passive mode Hello
commands are not sent and I-H-U responses are not expected.
Reachability is then determined from the Status field of received Hello
or Poll commands or Update responses.
アクティブであるか受け身のモードで隣人可到達性アルゴリズムを使用できます。 アクティブなモードで、Pollコマンドと共にHelloコマンドを定期的に送ります、対応するI-H-UとUpdate応答によって決定している可到達性で。 受け身の形態で、Helloコマンドは送られません、そして、I-H-U応答は予想されません。 可到達性はその時、容認されたHello、PollコマンドまたはUpdate応答のStatus分野から決定しています。
The M state variable specifies whether the gateway operates in the
active or passive mode. At least one of the two neighbors sharing the
Exterior Gateway Protocol Formal Specification Page 12
D.L. Mills
ゲートウェイがアクティブであるか受け身のモードで作動するか否かに関係なく、州の変数が指定するM。 少なくともプロトコルFormal Specification12ページ ExteriorゲートウェイのD.L.ミルズを共有している2人の隣人のひとり
protocol must operate in the active mode; however, the neighbor-reachability protocol is designed to work even if both neighbors operate in the active mode. The value of M is determined from the Status field of a Request command or Confirm response. The sender sets this field according to whether the implementation supports the active mode, passive mode or both:
プロトコルはアクティブなモードで作動しなければなりません。 しかしながら、両方の隣人がアクティブなモードで働いても、隣人可到達性プロトコルは、働くように設計されます。 Mの値はRequestコマンドかConfirm応答のStatus分野から決定しています。 実現がアクティブなモード、受け身の形態または両方を支持するかどうかに従って、送付者はこの分野を設定します:
Status Sender capabilities
--------------------------------
0 either active or passive
1 active only
2 passive only
状態Sender能力-------------------------------- 0、アクティブであるか受け身の1つの能動態だけ、2受動態専用
The receiver inspects this field and sets the value of M according
to its own capabilities as follows:
以下のそれ自身の能力に従って、受信機は、この分野を点検して、Mの値を設定します:
Status Receiver capabilites
field 0 1 2
-------------------------------
0 * active passive
1 passive active passive
2 active active **
状態Receiver capabilites分野0 1 2------------------------------- 0 受け身の*アクティブな受け身の1アクティブな受け身の2アクティブなアクティブな**
In the case of "*" the mode is determined by comparing the
autonomous system numbers of the neigbors. The neighbor with the
smallest such number assumes active mode, while the other neighbor
assumes passive mode. In the case of "**" the neighbor may either send
a Refuse response or declare a Stop event, depending on state.
「*」の場合では、モードは、neigborsの自律システム番号を比較することによって、決定します。 そのような最も少ない数をもっている隣人はアクティブなモードを仮定しますが、もう片方の隣人は受け身の形態を仮定します。 隣人は、「」 **に関するケース」では廃物応答を送るか、または停止出来事を宣言するかもしれません、状態によって。
4.1.4. Timers
4.1.4. タイマ
There are three timers defined in the state machine: t1, used to
control retransmission of Request, Hello and Cease messages, t2, used to
control retransmission of Poll commands, and t3, which serves as an
abort-timer mechanism should the protocol hang indefinately. The timers
are set to specified values upon entry to each state and count down to
zero.
州のマシンで定義された3個のタイマがあります: プロトコルがindefinatelyに掛かっているならRequest、Hello、およびCeaseメッセージの「再-トランスミッション」(t2)がPollコマンドの「再-トランスミッション」、およびアボートタイマメカニズムとして機能するt3を制御するのに使用したコントロールに使用されるt1。 エントリーのときに各状態に値を指定して、タイマがゼロまで数えるように設定されます。
In the case of t1 and t2 state-dependent events are declared when
the timer counts down to zero, after which the timer is reset to the
specified value and counts down again. In the case of t3 a Stop event
is declared when the timer counts down to zero. Implementors may choose
not to implement t3 or, if so, may choose to implement it only in
certain states, with the effect that Request, Hello and/or Cease
commands may be retransmitted indefinately.
t1とt2の場合では、タイマがタイマが再び規定値とカウントにリセットされるゼロまで数えられると、州の依存する出来事は宣言されます。 t3の場合では、タイマがゼロまで数えられると、Stop出来事は宣言されます。 作成者が、t3を実行しないのを選ぶかもしれませんか、またはそうだとすれば、ある州だけでそれを実行するのを選ぶかもしれません、Request、Hello、そして/または、Ceaseコマンドがindefinatelyに再送されるかもしれないという効果で。
The following table shows the initial values for each of the timers
in each state. A missing value indicates the timer is not used in that
state. Note that timer t3 is set to P4 upon receipt of a
neighbor-reachability indication when in either the Down or Up states.
Exterior Gateway Protocol Formal Specification Page 13
D.L. Mills
以下のテーブルは各状態のそれぞれのタイマのために初期の値を示しています。 欠測値は、タイマがその状態で使用されないのを示します。 DownかUpが述べるどちらかにあるときには、タイマt3が隣人可到達性指示を受け取り次第P4に用意ができていることに注意してください。 外のゲートウェイプロトコル形式仕様13ページ D.L.工場
Idle Aqsn Down Up Cease
Timer 0 1 2 3 4
---------------------------------------------
t1 P3 T1 P3
t2 T2
t3 P5 P5 P5
上の下側への使用されていないAqsnはタイマ0 1 2 3 4をやめます。--------------------------------------------- t1 P3 T1 P3 t2 T2 t3 P5 P5 P5
4.2. Starting and Stopping the Protocol
4.2. 始まって、プロトコルを止めます。
The Start and Stop events are intrinsic to the system environment
of the gateway. They can be declared as the result of the gateway
process being started and stopped by the operator, for example. A Start
event has meaning only in some states; however, a Stop event has
meaning in all states.
StartとStopイベントはゲートウェイのシステム環境に本質的です。 例えば、オペレータによって始められて、止められるゲートウェイプロセスの結果としてそれらを宣言できます。 Startイベントはいくつかの州だけに意味を持っています。 しかしながら、Stopイベントはすべての州に意味を持っています。
In all except the Idle state the abort timer t3 is presumed
running. This timer is initialized at P5 seconds upon entry to any
state and at P4 seconds upon receipt of a neighbor-reachability
indication in the Down and Up states. If it expires a Stop event is
declared. A Stop event can also be declared by an intrinsic system
action such as a resource problem or operator command.
Idle状態を除いて、全部で、アボートタイマt3は実行していると推定されます。 このタイマはDownとUp州での隣人可到達性指示を受け取り次第秒どんな状態へのエントリーとP4秒のP5でも初期化されます。 期限が切れるなら、Stopイベントは宣言されます。 また、リソース問題かオペレータコマンドなどの本質的なシステム動作でStopイベントを宣言できます。
If the abort timer is not implemented a manually-initiated Stop
event can be used to stop the protocol. If this is done in the Down or
Up states, the machine will transition to the Cease state and emit a
Cease command. If the neighbor does not respond to this command the
machine will stay in the Cease state indefinately; however, a second
Stop event can be used in this state to force a transition to the Idle
state.
アボートタイマが実装されないなら、プロトコルを止めるのに手動で開始しているStopイベントを使用できます。 これが完了していると、DownかUp州、マシンでは、Ceaseへの変遷は、Ceaseコマンドを述べて、放つでしょうか? 隣人がこのコマンドに応じないと、マシンはCease状態にindefinatelyなままでいるでしょう。 しかしながら、Idle状態への変遷を強制するのにこの状態で2番目のStopイベントを使用できます。
A Cease command received in any state will cause the gateway to
immediately send the Cease-ack response and transition to the Idle
state. This causes the protocol to be stopped and all system resources
committed to the gateway process to be released. The interval between
the time the gateway enters the Idle state as the result of receiving a
Cease command and the time when it next sends a Request command to
resume the protocol is not specified; however, it is recommended this
interval be at least P5 seconds.
どんな状態にも受け取られたCeaseコマンドで、ゲートウェイはすぐに、Cease-ack応答と変遷をIdle状態に送るでしょう。 これで、プロトコルを止めました、そして、すべてのシステム資源が、リリースされるためにゲートウェイプロセスに公約されました。 次にCeaseコマンドとそれであることの時間を得るという結果がプロトコルを再開するRequestコマンドを送るのに応じてゲートウェイがIdle状態に入る時の間隔は指定されません。 しかしながら、この間隔に少なくともP5秒がそうであることが推薦されます。
It may happen that the Cease-ack response is lost in the network,
causing the neighbor to retransmit the Cease response indefinately, at
least if it has not implemented the abort-timer option. In order to
reduce the likelihood of this happening, it is suggested that a gateway
in the Idle state be prepared to reply to a Cease command with a
Cease-ack response whenever possible.
Cease-ack応答がネットワークで失われているのは起こるかもしれません、隣人がindefinatelyにCease応答を再送することを引き起こしてアボートタイマオプションを実装していないなら少なくとも。 この出来事の見込みを減少させるために、Idle状態のゲートウェイが可能であるときはいつも、Cease-ack応答でCeaseコマンドに答えるように準備されることが提案されます。
4.3. Determining Neighbor Reachability
4.3. 隣人の可到達性を決定します。
The purpose of the neighbor-reachability algorithm is to confirm
that the neighbor can safely be considered operational and capable of
Exterior Gateway Protocol Formal Specification Page 14
D.L. Mills
隣人可到達性アルゴリズムの目的はExteriorゲートウェイプロトコルFormal Specification14ページ D.L.ミルズが操作上であってできると安全に隣人を考えることができると確認することです。
providing reliable net-reachability information. An equally important purpose is to filter noisy reachability information before sending it on to the remainder of the Internet gateway system, thus avoiding unneccesary reachability changes.
信頼できるネットの可到達性情報を提供します。 等しく重要な目的はインターネット・ゲートウェイシステムの残りにそれを送る前に騒がしい可到達性情報をフィルターにかけることです、その結果、unneccesary可到達性変化を避けます。
As described above, a gateway operating in the active mode sends
periodic Hello commands and listens for I-H-U responses in order to
determine neighbor-reachability indications. A gateway operating in the
passive mode determines reachability indications by means of the Status
field in received Hello commands. Poll commands and Update responses
can be used in lieu of Hello commands and I-H-U responses respectively,
since they contain the same Status-field information.
上で説明されるように、アクティブなモードで作動するゲートウェイは、隣人可到達性指摘を決定するために周期的なHelloコマンドを送って、I-H-U応答を聞こうとします。 受け身の形態で作動するゲートウェイは容認されたHelloコマンドにおけるStatus分野による可到達性指摘を決定します。 HelloコマンドとI-H-U応答の代わりにそれぞれ投票命令とUpdate応答を使用できます、同じStatus-分野情報を含んでいるので。
The neighbor-reachability algorithm runs continuously while the
gateway is in the Down and Up states and operates as follows. Define a
moving window in time starting at the present and extending backwards
for t seconds. Then count the number n of neighbor-reachability
indications which have occured in that window. If n increases to j,
then declare a Up event. If n decreases to k, then declare a Down
event. The number n is set to zero upon entering the Down state from
any state other than the Up state.
隣人可到達性アルゴリズムは、ゲートウェイがDownとUp州にある間、絶え間なく動いて、以下の通り作動します。 時間内に、プレゼントで始まって、t秒の間に後方に広がる動く窓を定義してください。 その時、その窓でoccuredされた隣人可到達性指摘のNo.nは重要です。 nがjに増加するなら、Upイベントを宣言してください。 nがkと減少するなら、Downイベントを宣言してください。 No.nはUp状態以外のどんな状態からもDown状態に入るときのゼロへのセットです。
The window t in this algorithm is defined as T3 seconds, the value
of which is suggested as four times T1, which itself is determined
during the Request/Confirm exchange. For proper operation of the
algorithm only one neighbor-reachability indication is significant in
any window of T1 seconds and additional ones are ignored. Note that the
only way n can increase is as the result of a new neighbor-reachability
indication and the only way it can decrease is as the result of an old
neighbor-reachability indication moving out of the window.
このアルゴリズムによる窓tは交換をそれの値が4回のRequestの間、それ自体で断固としたT1として示されるT3秒と定義されるか、または確認することです。 アルゴリズムの適切な操作だけに、1つの隣人可到達性の指示はT1秒のどんな窓でも重要です、そして、追加ものは無視されます。 新しい隣人可到達性指示の結果としてnが増加できる唯一の方法があって、窓から引っ越す古い隣人可到達性指示の結果として減少できる唯一の方法があることに注意してください。
The behavior of the algorithm described above and using the
suggested fixed parameters j and k differs depending on whether the
gateway is operating in the active or passive mode. In the active mode
(j = 3, k = 1 and T3/T1 = 4), once the neighbor has been declared down
it will be forced down for at least two T1 intervals and, once it has
been declared up it will be forced up for at least two T1 intervals. It
will not change state unless at least three of the last four
determinations of reachability have indicated that change.
ゲートウェイがアクティブであるか受け身のモードで作動しているかどうかによって、提案された固定パラメタjとkを上で説明されて、使用するアルゴリズムの振舞いは異なります。 アクティブなモード(jは3、k=1、およびT3/T1=4と等しい)で、隣人が下がっているといったん宣言されると、それは少なくとも2回のT1間隔の間、強制されるでしょう、そして、上がるといったん宣言されると、少なくとも2回のT1間隔の間、追いたてられるでしょう。 少なくとも可到達性の最後の4つの決断のうち3がその変化を示していないと、それは状態を変えないでしょう。
In the passive mode (j = 1, k = 4 and T3/T1 = 4), the neighbor will
be considered up from the first time the Status field of a Hello or Poll
command or Update response indicates "Up state" until four successive T1
intervals have passed without such indication. This design, suggested
by similar designs used in the ARPANET, has proven effective in the
experimental implementations, but may need to be adjusted for other
configurations.
受け身の形態(jは1、k=4、およびT3/T1=4と等しい)で、4回の連続したT1間隔がそのような指示なしで過ぎるまで、隣人はHello、PollコマンドまたはUpdate応答のStatus分野が「状態」に示す1回目から上がると考えられるでしょう。 アルパネットに使用される同様のデザインによって示されたこのデザインは、実験的な実装で実効を現しましたが、他の構成のために調整される必要があるかもしれません。
It is convenient for the active gateway to send Hello commands at a
rate of one every T1 seconds and substitute a Poll command for a Hello
Exterior Gateway Protocol Formal Specification Page 15
D.L. Mills
アクティブなゲートウェイに、あらゆるT1が後援する1つのレートでコマンドをHelloに送って、Pollコマンドをa Hello ExteriorゲートウェイプロトコルFormal Specification15ページ D.L.ミルズの代わりに用いるのは都合がよいです。
command approximately once every T2 seconds, with the neighbor-reachability indication generated by the corresponding I-H-U or Update responses. Its passive neighbor generates neighbor-reachability indications from the Status field of received Hello and Poll commands and Update responses.
およそかつてのあらゆるT2が隣人可到達性指示で後援するコマンドは、I-H-UかUpdateが応答であると対応で生成しました。 受け身の隣人は容認されたHello、Pollコマンド、およびUpdate応答のStatus分野から隣人可到達性指摘を生成します。
Implementors may find the following model useful in the
understanding and implementation of this algorithm. Consider an n-bit
shift register that shifts one bit to the right each T1-second interval.
If a neighbor-reachability indication was received during the preceeding
T1-second interval a one bit is shifted into the register at the end of
the interval; otherwise, a zero bit is shifted. A table of 2**n
entries indexed by the contents of the register can be used to calculate
the number of one bits, which can then be used to declare the
appropriate event to the state machine. A value of n equal to four has
been found useful in the experimental implementations.
作成者は、以下のモデルがこのアルゴリズムの理解と実装で役に立つのがわかるかもしれません。 各T1-第2間隔を右に1ビット移行させるn-ビットシフトレジスタを考えてください。 preceeding T1-第2間隔の間、隣人可到達性指示を受けたなら、間隔の終わりのレジスタに1ビットを移動させます。 さもなければ、ゼロ・ビットは移動します。 次に適切なイベントを州のマシンに宣言するのに使用できる1ビットの数について計算するのにレジスタの値によって索引をつけられた2**nエントリーのテーブルを使用できます。 4へのn同輩の値が実験的な実装で役に立つのがわかりました。
4.4. Determining Network Reachability
4.4. ネットワークの可到達性を決定します。
Network reachability information is encoded into Update messages in
the form of lists of nets and gateways. The IP Source Address field of
the Poll command is used to specify a network common to the autonomous
systems of each of the neighbors, which is usually, but not necessarily,
the one common to the neighbors themselves. The Update response
includes a list of gateways on the common net. Associated with each
gateway is a list of the networks reachable via that gateway together
with corresponding hop counts.
ネットワーク可到達性情報はネットとゲートウェイのリストの形でUpdateメッセージにコード化されます。 PollコマンドのIP Source Address分野は通常である必ずそうであるというわけではない隣人各人の自律システムに共通のネットワークを指定するのに使用されます、隣人自身にとって、一般的な方。 Update応答は一般的なネットのゲートウェイのリストを含んでいます。 各ゲートウェイに関連づけられているのは、対応するホップカウントに伴うそのゲートウェイを通して届いているネットワークのリストです。
It is important to understand that, at the present state of
development as described in RFC-827 and RFC-888, the EGP architectural
model restricts the interpretation of "reachable" in this context. This
consideration, as well as the implied topological restrictions, are
beyond the scope of discussion here. The reader is referred to the RFCs
for further discussion.
EGPの建築モデルがRFC-827とRFC-888で説明される開発の現状でこのような関係においては「届くこと」の解釈を制限するのを理解しているのは重要です。 この考慮、および暗示している位相的な制限はここに議論の範囲を超えています。 読者はさらなる議論についてRFCsを参照されます。
Two types of gateway lists can be included in the Update response,
the format of which is described in Appendix A. Both lists include only
those gateways directly connected to the net specified in the IP Source
Network field of the last-received Poll command. The internal list
includes some or all of the gateways in the same autonomous system as
the sender, together with the nets which are reachable via these
gateways, with the sending gateway listed first. A net is reachable in
this context if a path exists to that net including only gateways in the
system. The external list includes those gateways in other autonomous
systems known to the sender. It is important to realize that the hop
counts do not represent a routing metric and are comparable between
different gateways only if those gateways belong to the same autonomous
system; that is, are in the internal list.
Update応答に2つのタイプのゲートウェイリストを含むことができます。その形式はAppendix A.で説明されます。Bothリストは直接最後容認されたPollコマンドのIP Source Network分野で指定されたネットに接続されたそれらのゲートウェイだけを含んでいます。 内部のリストは送付者と同じ自律システムにゲートウェイのいくつかかすべてを含んでいます、これらのゲートウェイを通して届いているネットと共に、送付ゲートウェイが最初に記載されている状態で。 このような関係においては経路がシステムにゲートウェイだけを含むそのネットに存在しているなら、ネットは届いています。 外部のリストは送付者にとって知られている他の自律システムにそれらのゲートウェイを含んでいます。 それらのゲートウェイが同じ自律システムに属す場合にだけ、ホップカウントがメートル法でルーティングを表さないで、異なったゲートウェイの間で匹敵しているとわかるのは重要です。 すなわち、内部のリストに、あります。
Exterior Gateway Protocol Formal Specification Page 16 D.L. Mills
外のゲートウェイプロトコル形式仕様16ページ D.L.工場
According to the current system architectural model, only gateways
belonging to a designated system, called the core system, may include
the external list in their Update responses. All other gateways may
include only those gateways belonging to the same system and can claim
reachability for a particular net only if that net is reachable in the
same system.
現在のシステム建築モデルに従って、コア・システムと呼ばれる指定されたシステムに属すゲートウェイだけが彼らのUpdate応答に外部のリストを含むかもしれません。 他のすべてのゲートウェイが、同じシステムに属すそれらのゲートウェイだけを含むかもしれなくて、そのネットが同じシステムで届く場合にだけ、特定のネットに可到達性の代金を請求することができます。
The interval between successive Poll commands T2 is determined
during the Request/Confirm exchange. However, the specification permits
at most one unsolicited Update indication between succeeding Poll
commands received from the neighbor. It is the intent of the model here
that an Update indication is sent (a) upon entry to the Up state and (b)
when a change in the reachability data base is detected, subject to this
limitation.
連続したPollコマンドT2の間隔は交換をRequestの間、決定するか、または確認することです。 しかしながら、仕様は隣人から受け取られた続くPollコマンドの間の指示を1求められていないUpdateに高々可能にします。 (a) (b) Up状態へのエントリー、可到達性データベースにおける変化が検出されるとき、それはこの制限を条件としたここのUpdate指示が送られるモデルの意図です。
Occasionally it may happen that a Poll command or Update response
is lost in the network, with the effect that net-reachability
information may not be available until after another T2 interval. As an
implementation option, the gateway sending a Poll command and not
receiving an Update response after T1 seconds may send another Poll.
The gateway receiving this Poll may either (a) send an Update response
if it never received the original Poll for that interval, (b) send a
second Update response (which counts as the unsolicited Update
indication mentioned in the preceeding paragraph) or (c) send an Error
response or not respond at all in other cases.
時折、PollコマンドかUpdate応答がネットワークで失われているのは起こるかもしれません、ネットの可到達性情報が別のT2間隔の後まで利用可能でないかもしれないという効果で。 受信ではなく、実装オプション、Pollコマンドを送るゲートウェイとして、T1秒以降Update応答は別のPollを送るかもしれません。 このPollを受けるゲートウェイはその間隔の間、オリジナルのPollを決して受けないで、(b)がUpdate応答(preceedingパラグラフで言及された求められていないUpdate指示にみなす)か(c)が送る2番目にError応答を送るか、または他の場合で全く応じないなら(a)がUpdate応答を送るどちらかがそうするかもしれません。
4.5. Error Messages
4.5. エラーメッセージ
Error messages can be used to report problems such as described in
Appendix A in connection with the Error Response/Indication message
format. In general, an Error message is sent upon receipt of another
command or response with bad format, content or ordering, but never in
response to another Error message. Receipt of an Error message should
be considered advisory and not result in change of state, except
possibly to evoke a Stop event.
Exterior Gateway Protocol Formal Specification Page 17
D.L. Mills
Appendix AでError Response/指示メッセージ・フォーマットに関して説明されるように問題を報告するのにエラーメッセージを使用できます。 一般に、別のコマンドか応答を受け取り次第悪い形式、内容または注文にもかかわらず、決して別のErrorメッセージに対応してErrorメッセージを送りません。 Errorメッセージの領収書は、顧問であると考えられて、状態の変化をもたらすはずがありません、ことによるとStopイベントを喚起するのを除いて。 外のゲートウェイプロトコル形式仕様17ページ D.L.工場
Appendix A. EGP Message Formats
付録A.EGPメッセージ・フォーマット
The formats for the various EGP messages are described in this
section. All EGP messages include a ten-octet header of six fields,
which may be followed by additional fields depending on message type.
The format of the header is shown below along with a description of its
fields.
様々なEGPメッセージのための形式はこのセクションで説明されます。 すべてのEGPメッセージが6つの分野の10八重奏のヘッダーを含んでいます。(メッセージタイプに頼る追加分野は分野のあとに続くかもしれません)。 ヘッダーの書式は分野の記述と共に以下に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EGP Version # assigned number identifying the EGP version
(currently 2)
EGPバージョンを特定するEGPバージョン#規定番号(現在の2)
Type identifies the message type
タイプはメッセージタイプを特定します。
Code identifies the message code (subtype)
コードはメッセージコードを特定します。(「副-タイプ」)
Status contains message-dependent status information
状態はメッセージ依存する状態情報を含んでいます。
Checksum The EGP checksum is the 16-bit one's complement
of the one's complement sum of the EGP message
starting with the EGP version number field. When
computing the checksum the checksum field itself
should be zero.
チェックサム、EGPチェックサムはEGPバージョンナンバーフィールドから始まるEGPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するとき、チェックサム分野自体はゼロであるべきです。
Autonomous System # assigned number identifying the particular
autonomous system
特定の自律システムを特定する自治のSystem#規定番号
Sequence # send state variable (commands) or receive state
variable (responses and indications)
系列#は、州の変数(コマンド)を送るか、または州の変数を受け取ります。(応答と指摘)
Following is a description of each of the message formats. Note
that the above description applies to all formats and will not be
repeated.
Exterior Gateway Protocol Formal Specification Page 18
D.L. Mills
以下に、それぞれのメッセージ・フォーマットの記述があります。 上の記述がすべての形式に適用して、繰り返されないことに注意してください。 外のゲートウェイプロトコル形式仕様18ページ D.L.工場
A.1. Neighbor Acquisition Messages
A.1。 隣人獲得メッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Hello Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Poll Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| こんにちは、間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 投票間隔| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: the Hello Interval and Poll Interval fields are present only in Request and Confirm messages.
以下に注意してください。 Hello IntervalとPoll Interval分野はRequestとConfirmメッセージだけに存在しています。
Type 3
3をタイプしてください。
Code 0 Request command
1 Confirm response
2 Refuse response
3 Cease command
4 Cease-ack response
1Confirmのコード0Requestコマンド応答2Refuse応答3Cease命令4Cease-ack応答
Status (see below) 0 unspecified
1 active mode
2 passive mode
3 insufficient resources
4 administratively prohibited
5 going down
6 parameter problem
7 protocol violation
0つの状態(以下を見る)の1つの不特定のアクティブなモード2受け身の形態3の不十分なリソース4が行政上6パラメタ問題7プロトコル違反に行く5を禁止しました。
Hello Interval minimum Hello command polling interval (seconds)
こんにちは、Intervalの最小のHelloコマンドポーリングインタバル(秒)
Poll Interval minumum Poll command polling interval (seconds)
投票Interval minumum Pollコマンドポーリングインタバル(秒)
Following is a summary of the assigned Status codes along with a list of scenarios in which they might be used. Exterior Gateway Protocol Formal Specification Page 19 D.L. Mills
以下に、それらが使用されるかもしれないシナリオのリストに伴う割り当てられたStatusコードの概要があります。 外のゲートウェイプロトコル形式仕様19ページ D.L.工場
Code Status Scenarios ------------------------------------------------------------------- 0 unspecified when nothing else fits
コード状態シナリオ------------------------------------------------------------------- 0、不特定他に何もが合わないと
1 active mode Request/Confirm only
1 Request/が確認するアクティブなモード専用
2 passive mode Request/Confirm only
2 Request/が確認する受け身の形態専用
3 insufficient resources 1. out of table space
2. out of system resources
3 システム資源からのテーブルスペース2からの不十分なリソース1
4 administratively 1. unknown Autonomous System
prohibited 2. use another gateway
4 1 行政上、2に禁止された未知のAutonomous Systemはもう1門を使用します。
5 going down 1. operator initiated Stop
2. abort timeout
5 1人のオペレータを下ると、Stop2アボートタイムアウトは起こされました。
6 parameter problem 1. nonsense polling parameters
2. unable to assume compatible mode
6 コンパチブル・モードを仮定できないパラメタ問題1ナンセンス世論調査パラメタ2
7 protocol violation 1. Invalid command or response
received in this state
Exterior Gateway Protocol Formal Specification Page 20
D.L. Mills
7は違反1について議定書の中で述べます。 ExteriorゲートウェイプロトコルFormal Specification20ページ この州のD.L.ミルズに受け取られた無効のコマンドか応答
A.2. Neighbor Reachability Messages
A.2。 隣人可到達性メッセージ
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 5
5をタイプしてください。
Code 0 Hello command
1 I-H-U response
コード0のHelloのコマンドの1I-H-Uの応答
Status 0 indeterminate
1 Up state
2 Down state
Exterior Gateway Protocol Formal Specification Page 21
D.L. Mills
1不確定の状態0の州のExteriorゲートウェイプロトコルFormal Specification Up州の2Down21ページ D.L.ミルズ
A.3. Poll Command
A.3。 投票命令
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Source Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPソースネットワーク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
2をタイプしてください。
Code 0
コード0
Status 0 indeterminate
1 Up state
2 Down state
1つの状態0の不確定のUp州2のDown状態
IP Source Network IP network number of the network about which
reachability information is being requested
(coded as 1, 2 or 3 octets, left justified with
trailing zeros)
Exterior Gateway Protocol Formal Specification Page 22
D.L. Mills
可到達性情報が要求された(末尾のゼロで正当化されるように残っている1、2または3つの八重奏として、コード化される)外のゲートウェイプロトコルFormal Specification22ページD.L.ミルズであるネットワークのIP Source Network IPネットワーク・ナンバー
A.4. Update Response/Indication
A.4。 アップデート応答/指示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | # of Int Gwys | # of Ext Gwys |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Source Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway 1 IP address (without network #) | (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Distances |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance 1 | # Nets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net 1,1,1 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net 1,1,2 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance 2 | # Nets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net 1,2,1 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net 1,2,2 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gateway n IP address (without network #) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Distances |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance 1 | # Nets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net n,1,1 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net n,1,2 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance 2 | # Nets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net n,2,1 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| net n,2,2 ||||||||||||||||||||||||||||||||| (1-3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Exterior Gateway Protocol Formal Specification Page 23
D.L. Mills
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| # Int Gwysについて| # Ext Gwysについて| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPソースネットワーク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゲートウェイ1IPアドレス(ネットワーク#のない)| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 距離| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 距離1| # ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1、1、1を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1、1、2を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 距離2| # ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1、2、1を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1、2、2を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ゲートウェイn IPアドレス(ネットワーク#のない)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 距離| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 距離1| # ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n、1、1を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n、1、2を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 距離2| # ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n、2、1を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n、2、2を網で覆ってください。||||||||||||||||||||||||||||||||| (1-3 八重奏) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 外のゲートウェイプロトコル形式仕様23ページ D.L.工場
Type 1
1をタイプしてください。
Code 0
コード0
Status 0 indeterminate
1 Up state
2 Down state
128 unsolicited message bit
1つの状態0の不確定のUp州2のDownは128お節介なメッセージビットを述べます。
# of Int Gwys number of interior gateways appearing in this
message
# このメッセージに現れる内部のゲートウェイのInt Gwys番号について
# of Ext Gwys number of exterior gateways appearing in this
message
# このメッセージに現れる外のゲートウェイのExt Gwys番号について
IP Source Network IP network number of the network about which
reachability information is being supplied
(coded as 1, 2 or 3 octets, left justified with
trailing zeros)
可到達性情報が提供されているネットワークのIP Source Network IPネットワーク・ナンバー(末尾のゼロで正当化されるように残っている1、2または3つの八重奏として、コード化されます)
Gateway IP addresses IP address (without network number) of the
gateway block (coded as 1, 2 or 3 octets)
ゲートウェイIPはゲートウェイブロックのIPアドレス(ネットワーク・ナンバーのない)を扱います。(1、2または3つの八重奏として、コード化されます)
# of Distances number of distances in the gateway block
# ゲートウェイブロックの距離のDistances番号について
Distances numbers depending on autonomous system
architecture
自律システムアーキテクチャに依存する数を遠ざけます。
# of Nets number of nets at each distance
# 各距離のネットのネット番号について
Nets IP network number reachable via the gateway Exterior Gateway Protocol Formal Specification Page 24 D.L. Mills
プロトコルFormal Specification24ページ ゲートウェイExteriorゲートウェイのD.L.ミルズを通して届いているIPネットワーク・ナンバーを網で覆います。
A.5. Error Response/Indication
A.5。 誤り応答/指示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EGP Version # | Type | Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autonomous System # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Error Message Header |
| (first three 32-bit words of EGP header) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EGPバージョン#| タイプ| コード| 状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 自律システム#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | エラーメッセージヘッダー| | (最初に、EGPヘッダーの3つの32ビットの単語) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 8
8をタイプしてください。
Code 0
コード0
Status 0 indeterminate
1 Up state
2 Down state
128 unsolicited message bit
1つの状態0の不確定のUp州2のDownは128お節介なメッセージビットを述べます。
Reason (see below) 0 unspecified
1 bad EGP header format
2 bad EGP data field format
3 reachability info unavailable
4 excessive polling rate
5 no response
0の1つの不特定の悪いEGPヘッダー形式2の悪いEGPデータフィールド形式3可到達性インフォメーション入手できない4の過度の世論調査が、5ノー、が応答であると評定する理由(以下を見ます)
Error Message Header first three 32-bit words of EGP header
EGPヘッダーの誤りのMessage Header最初の3 32ビットの単語
Following is a summary of the assigned Reason codes along with a list of scenarios in which they might be used. Exterior Gateway Protocol Formal Specification Page 25 D.L. Mills
以下に、それらが使用されるかもしれないシナリオのリストに伴う割り当てられたReasonコードの概要があります。 外のゲートウェイプロトコル形式仕様25ページ D.L.工場
Code Reason Scenarios ------------------------------------------------------------------------ 0 unspecified when nothing else fits
コード理由シナリオ------------------------------------------------------------------------ 0、不特定他に何もが合わないと
1 bad EGP header format 1. bad message length
2. invalid Type, Code or Status fields
1 悪いEGP1つのヘッダー形式の悪いメッセージ長2無効のType、CodeまたはStatus分野
Notes: The recipient can determine which
of the above hold by inspecting the EGP
header included in the message. An
instance of a wrong EGP version or bad
checksum should not be reported, since
the original recipient can not trust the
header format. An instance of an unknown
autonomous system should be caught at
acquistion time.
注意: 受取人は、EGPヘッダーがメッセージで点検するのによる上の保持のどれを入れたかを決心できます。 間違ったEGPバージョンか悪いチェックサムのインスタンスを報告するべきではありません、オリジナルの受取人がヘッダー形式を信じることができないので。 未知の自律システムのインスタンスはacquistion時に捕らえられるべきです。
2 bad EGP data field 1. nonsense polling rates
format (Request/Confirm)
2. invalid Update message format
3. response IP Net Address field does
not match command (Update)
2 形式(要求するか、または確認する)2の無効のUpdateメッセージ・フォーマット3応答IPネットAddressがさばくレートに投票する悪いEGPデータ・フィールド1ナンセンスがコマンドに合っていません。(アップデート)
Notes: An instance of nonsense polling
intervals (e.g. too long to be useful)
specified in a Request or Confirm should
result in a Refuse or Cease with this
cause specified.
注意: この原因が指定されている状態で、RequestかConfirmで指定されたナンセンスポーリングインタバル(例えば、また、役に立つのを切望する)のインスタンスはRefuseかCeaseをもたらすべきです。
3 reachability info 1. no info available on net specified in
unavailable IP Net Address field (Poll)
3 Addressがさばく入手できないIPネットで指定されたネットで利用可能な1いいえのインフォメーションについて可到達性についてインフォメーション(投票)
4 excessive polling rate 1. two or more Hello commands received
within minimum specified polling
interval
2. two or more Poll commands received
within minimum specified polling
interval
3. two or more Request commands received
within some (reasonably short)
interval
4 2つ以上のHelloコマンドがいくつかの(適度に短い)の間隔以内に受け取られたポーリングインタバル3 2つ以上の最小の指定されたRequestコマンドの中に受け取られたポーリングインタバル2 2つ以上の最小の指定されたPollコマンドの中に受け取った過度の世論調査率1
Notes: The recipient can determine which
of the above hold by inspecting the EGP
header included in the message.
注意: 受取人は、EGPヘッダーがメッセージで点検するのによる上の保持のどれを入れたかを決心できます。
5 no response 1. no Update received for Poll within
some (reasonably long) interval
Exterior Gateway Protocol Formal Specification Page 26
D.L. Mills
5 どんなUpdateもPollのためにプロトコルFormal Specification26ページ いくらかの(適度に長い)間隔ExteriorゲートウェイのD.L.ミルズの中で受けなかった応答1全く
Appendix B. Comparison with RFC-888
RFC-888との付録B.比較
Minor functional enhancements are necessary in the RFC-888 message
formats to support certain features assumed of the state-machine model,
in particular the capability to request a neighbor to suppress Hello
commands. In addition, the model suggests a mapping between its states
and certain status and error indications which clarifies and generalizes
the interpretation.
小さい方の機能強化がRFC-888メッセージ・フォーマットで、ある特徴がHelloコマンドを抑圧するよう隣人に要求すると州マシンモデル、特に能力を仮定したサポートに必要です。 さらに、モデルは州と、ある状態と誤り指摘の間の解釈をはっきりさせて、広めるマッピングを勧めます。
All of the header fields except the Status field (called the
Information field at some places in RFC-888) remain unchanged. The
following table summarizes the suggested format changes in the Status
field for the various messages by (Type, Code) class.
Status分野(RFC-888のいくつかの場所に情報分野と呼ばれる)以外のヘッダーフィールドのすべてが変わりがありません。 以下のテーブルは様々なメッセージのために(Code、タイプしてください)クラスでStatus分野の提案された形式変化をまとめます。
Class Messages Status Codes
-------------------------------------------------------------------
3,0 Request 0 unspecified
3,1 Confirm 1 active mode
3,2 Refuse 2 passive mode
3,3 Cease 3 insufficient resources
3,4 Cease-ack 4 administratively prohibited
5 going down
6 parameter problem
クラスメッセージステータスコード------------------------------------------------------------------- 3、0Request0の不特定の3、1Confirm1のアクティブなモードの3、2Refuse2受け身の形態3、3Cease3不十分なリソース3、4Cease-ack4は行政上6パラメタ問題に行く5を禁止しました。
5,0 Hello 0 indeterminate 5,1 I-H-U 1 Up state 2,0 Poll 2 Down state 1,0 Update 128 unsolicited message bit 8,0 Error
5、0Hello0の不確定の5、1I-H-U1のUp州2、0のPoll2Downは1、0Update128お節介なメッセージビット8、0Errorを述べます。
The changes from RFC-888 are as follows:
RFC-888からの変化は以下の通りです:
1. The status codes have been combined in two classes, one for those
messages involved in starting and stopping the protocol and the
other for those messages involved in maintaining the protocol and
exchanging reachability information. Some messages of either class
may not use all the status codes assigned.
1. 2つのクラス(始まって、プロトコルを維持して、可到達性情報を交換するのにかかわるそれらのメッセージのためにプロトコルともう片方を止めるのにかかわるそれらのメッセージのためのもの)でステータスコードは結合されました。 どちらかのクラスに関するいくつかのメッセージはコードが割り当てたすべての状態を使用しないかもしれません。
2. The status codes for the Request and Confirm indicate whether the
sender can operate in active or passive mode. In RFC-888 this field
must be zero; however, RFC-888 does not specify any mechanism to
decide how the neighbors poll each other.
2. RequestとConfirmのためのステータスコードは、送付者がアクティブであるか受け身のモードで働くことができるかどうかを示します。 RFC-888では、この分野はゼロであるに違いありません。 しかしながら、RFC-888は、隣人がどう互いに投票するかを決めるためにどんなメカニズムも指定しません。
3. The status codes for the Cease, Refuse and Cease-ack have the same
interpretation. This provides a clear and unambiguous indication
when the protocol is terminated due to an unusual situation, for
instance if the NOC dynamically repartitions the ARPANET. The
assigned codes are not consistent with RFC-888, since the codes for
the Refuse and Cease were assigned conflicting values; however, the
differences are minor and should cause no significant problems.
Exterior Gateway Protocol Formal Specification Page 27
D.L. Mills
3. Cease、Refuse、およびCease-ackのためのステータスコードには、同じ解釈があります。 これがNOCであるならダイナミックに例えば、プロトコルが異例の状況のため終えられるときの明確で明白な指示を提供する、配分、アルパネット。 闘争値がRefuseとCeaseのためのコードに割り当てられたので、割り当てられたコードはRFC-888と一致していません。 しかしながら、違いは、小さい方であり. 外のゲートウェイプロトコルFormal Specification27ページ D.L.ミルズをどんな重大な問題にも引き起こすべきではありません。
4. The status codes for the Hello, I-H-U, Poll, Update and Error have
the same interpretation. Codes 0 through 2 are mutually exclusive
and are chosen solely on the basis of the state of the sender. In
the case of the Update (and possibly Error) one of these codes can
be combined with the "unsolicited bit," which corresponds to code
128. In RFC-888 this field is unused for the Poll and Error and may
contain only zero or 128 for the Update, so that the default case is
to assume that reciprocal reachability cannot be determined by these
messages.
4. Hello、I-H-U、Poll、Update、およびErrorのためのステータスコードには、同じ解釈があります。 コード0〜2は、互いに排他的であり、唯一送付者の状態に基づいて選ばれています。 Update(そして、ことによるとError)の場合では、「求められていないビット」にこれらのコードの1つを結合できます。(それは、128をコード化するために対応します)。 RFC-888では、この分野は、PollとErrorにおいて未使用であり、Updateのためにゼロだけか128を含むかもしれません、相互的な可到達性がこれらのメッセージで決定できないと仮定するように不履行格がことである。
5. Some of the reachability codes defined in RFC-888 have been removed
as not applicable.
Exterior Gateway Protocol Formal Specification Page 28
D.L. Mills
5. 適切でないとしてRFC-888で定義される可到達性コードのいくつかを取り除きました。 外のゲートウェイプロトコル形式仕様28ページ D.L.工場
Appendix C. Reachability Analysis
付録C.可到達性分析
The following table shows the state transitions which can occur in
a system of two neighboring EGP gateways. Besides being useful in the
design and verification of the protocol, the table is useful for
implementation and testing.
以下のテーブルは、どれが2がEGPゲートウェイを近所付き合いさせるシステムに起こることができるかを状態遷移に示します。 プロトコルのデザインと検証で役に立つこと以外に、テーブルは実装とテストの役に立ちます。
The system of two neighboring EGP gateways is modelled as a
finite-state automaton constructed as the cartesian product of two state
machines as defined above. Each state of this machine is represented as
[i,j], where i and j are states of the original machine. Each line of
the table shows one state transition of the machine in the form:
有限状態オートマトンが上で定義されるように2状態の直積としてマシンを組み立てたので、2がEGPゲートウェイを近所付き合いさせるシステムはモデル化されます。 このマシンの各状態は[i、j]として表されます。そこでは、iとjがオリジナルのマシンの州です。 テーブルの各線はフォームにおける、マシンの1つの状態遷移を示しています:
[i1,j1] -> [i2,j2] E A
[i1、j1] ->[i2、j2]E A
which specifies the machine in state [i1,j1] presented with event E transitions to state [i2,j2] and generates action A. Multiple actions are separated by the "/" symbol. The special symbol "*" represents the set of lines where all "*"s in the line take on the (same) values 0 - 4 in turn.
「どれが述べるイベントE変遷[i2、j2]が与えられた状態[i1、j1]でマシンを指定して、A.Multiple動作が切り離される動作を発生させるか、」 /、」 シンボル。 「*」という特別なシンボルは線におけるすべての「*」sが順番に(同じ)の値0--4を呈する線のセットを表します。
The table shows only those transitions which can occur as the
result of events arriving at one of the two neighbors. The full table
includes a duplicate set of lines for the other neighbor as well, with
each line derived from a line of the table below using the
transformation:
テーブルは、どれが出来事が2人の隣人のひとりに到着するという結果として起こることができるかをそれらの変遷だけに示します。 完全なテーブルはまた、もう片方の隣人のための線の写しセットを含んでいます、変化を使用する下にテーブルの線から得られた各線で:
[i1,j1] -> [i2,j2] E A => [j1,i1] -> [j2,i2] E A
[i1、j1] >[j1、i1]->[j2、i2]->[i2、j2]E A=E A
State State Event Actions --------------------------------------------------- [*,4] -> [0,4] Cease Cease-ack
州の州のイベント動作--------------------------------------------------- [*、4] ->[0、4]はackをやめてやみます。
[0,1] -> [2,1] Request Confirm/Hello/Up/t1 [0,1] -> [0,1] Request Refuse [0,*] -> [1,*] Start Request/t1
こんにちは、//上/t1[0、1]->[0、1]要求廃物[0、*]->[1、*]を確認する->[2、1]が、要求する[0、1]が要求/t1を始動します。
[1,1] -> [2,1] Request Confirm/Hello/Up/t1 [1,2] -> [2,2] Confirm Hello/Up/t1 [1,3] -> [2,3] Confirm Hello/Up/t1 [1,0] -> [0,0] Refuse Null [1,*] -> [1,*] Start Request/r1 [1,*] -> [0,*] Stop Null [1,*] -> [1,*] t1 Request/t1
要求..上..確認..上..確認..拒否..始め..停止
[2,1] -> [3,1] Up Down/Hello/Poll/t1/t2 [2,1] -> [2,1] Request Confirm/Hello/Up/t1 [2,2] -> [2,2] Hello I-H-U [2,3] -> [2,3] Hello I-H-U [2,2] -> [2,2] I-H-U Process Exterior Gateway Protocol Formal Specification Page 29 D.L. Mills
こんにちは、//上/t1を確認するこんにちは、下に//投票/t1/t2[2、1]->[2、1]への->[3、1]が、要求する[2、1][2、2]、->、こんにちは、こんにちは、I-H-U[2、2]->[2、2]のI-H-Uの加工処理した外のゲートウェイが議定書の中で述べる[2、2]I-H-U[2、3]->[2、3]、D.L.が製粉する形式仕様29ページ
[2,3] -> [2,3] I-H-U Process [2,*] -> [1,*] Start Request/r1 [2,*] -> [4,*] Stop Cease/t1 [2,1] -> [2,1] t1 Hello/t1 [2,2] -> [2,2] t1 Hello/t1 [2,3] -> [2,3] t1 Hello/t1
[2、3]->[2、3]I-H-U Process[2、*]->[1、*]スタートRequest/r1[2、*]->[4、*]停止Cease/t1[2、1]->[2、1]t1 Hello/t1[2、2]->[2、2]t1 Hello/t1[2、3]->[2、3]t1 Hello/t1
[3,1] -> [2,1] Down Null [3,2] -> [2,2] Down Null [3,3] -> [2,3] Down Null [3,1] -> [2,1] Request Confirm/Hello/Up/t1 [3,2] -> [3,2] Hello I-H-U [3,3] -> [3,3] Hello I-H-U [3,2] -> [3,2] I-H-U Process [3,3] -> [3,3] I-H-U Process [3,3] -> [3,3] Poll Update [3,3] -> [3,3] Update Process [3,*] -> [1,*] Start Request/r1 [3,*] -> [4,*] Stop Cease/t1 [3,1] -> [3,1] t1 Hello/t1 [3,2] -> [3,2] t1 Hello/t1 [3,3] -> [3,3] t1 Hello/t1 [3,1] -> [3,1] t2 Poll/t2 [3,2] -> [3,2] t2 Poll/t2 [3,3] -> [3,3] t2 Poll/t2
3 1 ヌル3の下側への->2、1、ヌル3の下側への2->2、2、こんにちは、こんにちは、->2、1が要求するヌル3、1の下側への3->2、3がこんにちは、//上/t1 3を確認して、2->3、2がI-H-U3であり、3->3、3はI-H-U3です、2->3、2I-H-Uの過程3、3->3、3I-H-Uの過程3、3->3、3投票アップデート3; 3 ***->3、3Update Process3、->1、スタートRequest/r1 3、->4、*がCease/t1 3を止めます、1->3、1t1 Hello/t1 3、2->3、2t1 Hello/t1 3、3->3、3t1 Hello/t1 3、1->3、1t2 Poll/t2 3、2->3、2t2 Poll/t2 3、3->3、3t2 Poll/t2
[4,1] -> [4,1] Request Cease [4,*] -> [0,*] Cease Cease-ack [4,0] -> [0,0] Cease-ack Null [4,*] -> [0,*] Stop Null [4,*] -> [4,*] t1 Cease/t1
[4、1]->[4、1]要求Cease[4、*]->[0、*]はack Nullをやめている[4、*]Cease-ack[4、0]->[0、0]->[0、*]停止Null[4、*]->[4、*]t1 Cease/t1をやめます。
In the state-machine model defined in this document all states of
the above machine are reachable; however, some are reachable only in
extreme cases when one neighbor crashes, for example. In the common
case where only one of the neighbors initiates and terminates the
protocol and neither one crashes, for example, not all states are
reachable. Following is a matrix showing the states which can be
reached in this case, where the neighbor that initiates and terminates
the protocol is called the active gateway and the other the passive
gateway.
Exterior Gateway Protocol Formal Specification Page 30
D.L. Mills
本書では定義された州マシンモデルでは、上のマシンのすべての州が届いています。 しかしながら、例えば、1人の隣人がクラッシュするとき、或るものは極端な場合だけで届いています。 例えば、すべての州がどんなよくある例で中、隣人の唯一のものがプロトコルを開始して、終えて、どちらもクラッシュしない届いているというわけではありません。 以下に、この場合達することができる州、プロトコルを開始して、終える隣人がどこにアクティブなゲートウェイと呼ばれるか、そして、およびもう片方に受け身のゲートウェイを示しているマトリクスがあります。 外のゲートウェイプロトコル形式仕様30ページ D.L.工場
Passive Gateway
Active 0 Idle 1 Aqsn 2 Down 3 Up 4 Cease
Gateway +-----------+-----------+-----------+-----------+-----------+
0 Idle |stable | | | |unstable |
1 Aqsn |unstable |unstable |unstable |unstable |unstable |
2 Down | | |stable |unstable | |
3 Up | | |unstable |stable | |
4 Cease |unstable |unstable |unstable |unstable |unstable |
+-----------+-----------+-----------+-----------+-----------+
受け身のゲートウェイアクティブな0使用されていない1Aqsn2下3であるのはゲートウェイ+を4にやめます。-----------+-----------+-----------+-----------+-----------+ 0は怠けます。|うまや| | | |不安定| 1 Aqsn|不安定|不安定|不安定|不安定|不安定| 2下| | |うまや|不安定| | 3 上に| | |不安定|うまや| | 4はやみます。|不安定|不安定|不安定|不安定|不安定| +-----------+-----------+-----------+-----------+-----------+
In the above matrix the blank entries represent unreachable states,
while those marked unstable represent transient states which cannot
persist for long, due to retransmission of Request and Hello messages,
for example.
上のマトリクスで、空白のエントリーは手の届かない州を代表しますが、不安定であるとマークされたものはRequestの「再-トランスミッション」のため長い間持続できない一時的な州と例えばHelloメッセージを表します。
一覧
スポンサーリンク
