rfc904.txt

RFC 的详细文档！

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.

4.1.3.  Hello Polling Mode

     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.

     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


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:

                Status  Sender capabilities
                --------------------------------
                0       either active or passive
                1       active only
                2       passive only

     The receiver inspects this field and sets the value of M according
to its own capabilities as follows:

                Status  Receiver capabilites
                field   0       1       2
                -------------------------------
                0       *       active  passive 
                1       passive active  passive
                2       active  active  **

     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.

4.1.4.  Timers

     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.

     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.

     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


                Idle    Aqsn    Down    Up      Cease
        Timer   0       1       2       3       4
        ---------------------------------------------
        t1              P3      T1              P3
        t2                              T2      
        t3              P5      P5              P5

4.2.  Starting and Stopping the Protocol

     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.

     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.

     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.

     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.

     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.

4.3.  Determining Neighbor Reachability

     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


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.

     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.

     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.

     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.

     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.

     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.

     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


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.


     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.

4.4.  Determining Network Reachability

     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.

     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.

     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.


Exterior Gateway Protocol Formal Specification                   Page 16
D.L. Mills


     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.

     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.

     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.

4.5.  Error Messages

     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.