rfc888.txt

RFC 相关的技术文档

     RFC 888                                              JANUARY 1984



     there  is  a  significant  amount  of protocol run between direct

     neighbors (see below), if some gateway no longer needs  to  be  a

     direct  neighbor  of  some other, it is "polite" to indicate this

     fact with a Neighbor Cease Message.  The Neighbor  Cease  Message

     should  be  retransmitted  (up  to some number of times) until an

     acknowledgment for it is received.


          Once  a  Neighbor  Cease  message  has  been  received,  the

     Neighbor   Reachability  Protocol  (below)  should  cease  to  be

     executed.


          A stub should have tables configured in with  the  addresses

     of  a  small  number  of  the  core gateways (no more than two or

     three) with which it has  a  common  network.   It  will  be  the

     responsibility  of the stub to initiate neighbor acquisition with

     these gateways.  If the direct neighbors of  a  stub  should  all

     fail,  it  will  be  the responsibility of the stub to acquire at

     least one new direct neighbor.  It can do so by choosing  one  of

     the  core  gateways which it has had as an indirect neighbor (see

     below), and executing the neighbor acquisition protocol with  it.

     (It  is  possible  that  no  more than one core gateway will ever

     agree to become a direct neighbor with any given stub gateway  at

     any one time.)




                                   - 9 -







     RFC 888                                              JANUARY 1984



     4  NEIGHBOR REACHABILITY PROTOCOL


          It is important for a gateway to keep real-time  information

     as  to the reachability of its neighbors.  If a gateway concludes

     that a particular neighbor cannot be  reached,  it  should  cease

     forwarding  traffic to that gateway.  To make that determination,

     a NEIGHBOR REACHABILITY protocol is  needed.   The  EGP  protocol

     provides two messages types for this purpose -- a "Hello" message

     and an "I Heard You" message.


          When a "Hello" message is received from a  direct  neighbor,

     an "I Heard You" must be returned to that neighbor "immediately".

     The delay between receiving a "Hello" and returning an  "I  Heard

     You" should never be more than a few seconds.


          Core  gateways  will  use  the   following   algorithm   for

     determining reachablility of an exterior neighbor:


          A reachable  neighbor  shall  be  declared  unreachable  if,

     during  the  time  in  which  the  core  gateway  sent its last n

     "Hello"s, it received fewer than k "I Heard You"s in return.   An

     unreachable  neighbor  shall be declared reachable if, during the

     time in which the core gateway  sent  its  last  m  "Hello"s,  it

     received at least j "I Heard You"s in return.




                                  - 10 -







     RFC 888                                              JANUARY 1984



          Stub  gateways  may  also  send  "Hello"s  to  their  direct

     neighbors  and  receive  "I Heard You"s in return.  The algorithm

     for determining reachability may  be  similar  to  the  algorithm

     described  above.  However, it is not necessary for stubs to send

     "Hello"s.  The "Hello" and "I Heard You" messages have  a  status

     field  which  the  sending  gateway  uses  to indicate whether it

     thinks  the  receiving  gateway  is  reachable  or   not.    This

     information  can  be  useful  for  diagnostic  purposes.  It also

     allows a stub gateway  to  make  its  reachability  determination

     parasitic  on  its  core neighbor: only the core gateway actually

     needs to send "Hello" messages, and the stub can declare it up or

     down based on the status field in the "Hello".  That is, the stub

     gateway (which sends only  "I  Heard  You"s)  declares  the  core

     gateway  (which  sends  only  "Hello"s)  to be reachable when the

     "Hello"s from the core indicate that it has declared the stub  to

     be reachable.


          The frequency with which the  "Hello"s  are  sent,  and  the

     values of the parameters k, n, j, and m cannot be specified here.

     For best results, this will depend on the characteristics of  the

     neighbor  and  of the network which the neighbors have in common.

     THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE DETERMINED

     JOINTLY  BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO NEIGHBORING



                                  - 11 -







     RFC 888                                              JANUARY 1984



     GATEWAYS;  choosing  algorithms  and  parameters  in   isolation,

     without  considering  the characteristics of the neighbor and the

     connecting network, would not be expected to  result  in  optimum

     reachability determinations.


          However, the Neighbor Acquisition Request and Reply messages

     provide  neighbors with a way to inform each other of the minimum

     frequency at which they  are  willing  to  answer  Hellos.   When

     gateway  G sends a Neighbor Acquisition Request to gateway G', it

     states that it does not  wish  to  answer  Hellos  from  G'  more

     frequently  than  once  every  X  seconds.   G'  in  its Neighbor

     Acquisition Reply states that it does not wish to  answer  Hellos

     from  G  more  frequently  than  once  every  Y seconds.  The two

     frequencies do not have to be the same, but  each  neighbor  must

     conform  to  the  interval requested by the other.  A gateway may

     send Hellos less frequently than requested, but not more.


          A  direct  neighbor  gateway   should   also   be   declared

     unreachable  if  the  network  connecting it supplies lower level

     protocol information from which this can be deduced.   Thus,  for

     example,  if  a gateway receives an 1822 Destination Dead message

     from the ARPANET which indicates that a direct neighbor is  dead,

     it should declare that neighbor unreachable.  The neighbor should




                                  - 12 -







     RFC 888                                              JANUARY 1984



     not be declared reachable again until  the  requisite  number  of

     Hello/I-Heard-You packets have been exchanged.


          A direct neighbor which  has  become  unreachable  does  not

     thereby  cease  to  be  a  direct  neighbor.  The neighbor can be

     declared reachable again without  any  need  to  go  through  the

     neighbor  acquisition  protocol  again.  However, if the neighbor

     remains unreachable for an extremely long period of time, such as

     an  hour,  the  gateway  should  cease to treat it as a neighbor,

     i.e., should cease sending Hello messages to  it.   The  neighbor

     acquisition  protocol  would  then  need to be repeated before it

     could become a direct neighbor again.


          "Hello" messages from sources other  than  direct  neighbors

     should  simply  be ignored.  However, logging the presence of any

     such messages might provide useful diagnostic information.


          A gateway which is going down, or  whose  interface  to  the

     network which connects it to a particular neighbor is going down,

     should send a Neighbor Cease  message  to  all  direct  neighbors

     which  will  no  longer  be  able to reach it.  The Cease message

     should use the info field to specify the reason as "going  down".

     It  should  retransmit  that message (up to some number of times)

     until it receives a Neighbor Cease Acknowledgment.  This provides



                                  - 13 -







     RFC 888                                              JANUARY 1984



     the  neighbors  with an advance warning of an outage, and enables

     them to prepare for it in a way which will minimize disruption to

     existing traffic.










































                                  - 14 -







     RFC 888                                              JANUARY 1984



     5  NETWORK REACHABILITY (NR) MESSAGE


          Terminology: Let gateway G have an interface to  network  N.

     We  say  that G is AN APPROPRIATE FIRST HOP to network M relative

     to network N (where M and N are distinct networks) if and only if

     the following condition holds:


          Traffic which is destined for network M, and  which  arrives

          at gateway G over its network N interface, will be forwarded

          to M by G over a path  which  does  not  include  any  other

          gateway with an interface to network N.


          In short, G is  an  appropriate  first  hop  for  network  M

     relative  to network N just in case there is no better gateway on

     network N through which to route traffic which  is  destined  for

     network  M.   For  optimal routing, traffic in network N which is

     destined for network M ought always to be forwarded to a  gateway

     which is an appropriate first hop.


          In  order  for  exterior  neighbors  G  and  G'  (which  are

     neighbors  over network N) to be able to use each other as packet

     switches for forwarding traffic to remote networks, each needs to

     know  the  list of networks for which the other is an appropriate

     first hop.  The Exterior  Gateway  Protocol  defines  a  message,




                                  - 15 -







     RFC 888                                              JANUARY 1984



     called  the  Network  Reachability  Message  (or NR message), for

     transferring this information.


          Let G be a gateway on network N.  Then the NR message  which

     G sends about network N must contain the following information:


          A list of all the networks for which  G  is  an  appropriate

          first hop relative to network N.


     If G' can obtain this information from exterior neighbor G,  then

     it  knows  that no traffic destined for networks which are NOT in

     that list should be forwarded to G.  (It cannot simply  conclude,

     however,  that all traffic for any networks in that list ought to

     be forwarded via G, since G' may also have other neighbors  which

     are also appropriate first hops to network N.  For example, G and

     G'' might each be neighbors of G',  but  might  be  "equidistant"

     from  some  network  M.   Then each could be an appropriate first

     hop.)


          For each network in the list, the NR message also  specifies

     the "distance" (according to some metric whose definition is left

     to the designers of the autonomous system of which gateway G is a

     member)  from  G  to  that  network.   Core  gateways will report

     distances less than 128 for networks that can be reached  without




                                  - 16 -







     RFC 888                                              JANUARY 1984



     leaving  the  core  system,  and  greater  than  or  equal to 128

     otherwise.  A stub gateway should report distances less than  128

     for all networks listed in its NR messages.


          The maximum value of distance (255.) shall be taken to  mean

     that  the network is UNREACHABLE.  ALL OTHER VALUES WILL BE TAKEN

     TO MEAN THAT THE NETWORK IS REACHABLE.


          If an NR message from some gateway G fails to  mention  some

     network  N which was mentioned in the previous NR message from G,

     it is possible that N has become unreachable from G.  If  several

     successive  NR  messages  from  G omit mention of N, it should be

     taken to mean that  N  is  no  longer  reachable  from  G.   This

     procedure  is  necessary  to  ensure  that  networks which can no

     longer be  reached,  but  which  are  never  explicitly  declared

     unreachable, are timed out and removed from the list of reachable

     networks.


          It will often be the case that where a core gateway G and  a

     stub  gateway  G'  are  direct neighbors on network N, G knows of

     many more gateway neighbors on network N,  and  knows  for  which

     networks  those  gateway neighbors are the appropriate first hop.

     Since the stub G' may not know about all these  other  neighbors,

     it  is  convenient  and often more efficient for it to be able to



                                  - 17 -







     RFC 888                                              JANUARY 1984



     obtain this information from G.  Therefore, the  EGP  NR  message

     also  contains  fields  which allow the core gateway G to specify

     the following information:


          a) A list of all neighbors (both interior and exterior) of G

             (on  network  N)  which  G  has reliably determined to be

             reachable.  G may also include indirect neighbors in this

             list (see below.)


          b) For each of those neighbors, the  list  of  networks  for

             which that neighbor is an appropriate first hop (relative

             to network N).


          c) For each such <neighbor, network>  pair,  the  "distance"

             from that neighbor to that network.


          Thus the NR message provides a means of allowing  a  gateway

     to  "discover" new neighbors by seeing whether a neighbor that it

     already knows  of  has  any  additional  neighbors  on  the  same

     network.  This information also makes possible the implementation

     of the INDIRECT NEIGHBOR strategy defined below.


          A  more  precise  description  of  the  NR  message  is  the

     following.





                                  - 18 -