rfc827.txt

RFC 相关的技术文档

          Before it is possible to obtain routing information from  an

     exterior  gateway,  it  is necessary to acquire that gateway as a

     direct neighbor.  (The distinction between  direct  and  indirect

     neighbors  will  be  made  in a later section.)  In order for two

     gateways to become direct neighbors, they must be  neighbors,  in

     the  sense  defined  above,  and  they  must execute the NEIGHBOR

     ACQUISITION  PROTOCOL,  which  is  simply  a  standard  three-way

     handshake.


          A gateway that wishes to initiate neighbor acquisition  with

     another  sends  it  a Neighbor Acquisition Request.  This message

     should be repeatedly transmitted (at a reasonable  rate,  perhaps

     once  every  30 seconds or so) until a Neighbor Acquisition Reply

     is received.  The Request will contain an  identification  number

     which  is  copied into the reply so that request and reply can be

     matched up.


          A gateway receiving  a  Neighbor  Acquisition  Request  must

     determine  whether  it  wishes to become a direct neighbor of the

     source of the Request.  If not, it may, at  its  option,  respond

     with   a   Neighbor   Acquisition   Refusal  message,  optionally

     specifying the reason for refusal.  Otherwise, it should  send  a

     Neighbor Acquisition Reply message.  It must also send a Neighbor




                                   - 8 -

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



     Acquisition Request message, unless it has done so already.


          Two gateways become direct neighbors when each  has  sent  a

     Neighbor  Acquisition  Message to, and received the corresponding

     Neighbor Acquisition Reply from, the other.


          Unmatched Replies or Refusals should be  discarded  after  a

     reasonable  period  of time.  However, information about any such

     unmatched messages may be useful for diagnostic purposes.


          A Neighbor Acquisition  Message  from  a  gateway  which  is

     already a direct neighbor should be responded to with a Reply and

     a Neighbor Acquisition Message.


          If  a  Neighbor  Acquisition  Reply  is  received   from   a

     prospective neighbor, but a period of time passes during which no

     Neighbor Acquisition Message is received  from  that  prospective

     neighbor,  the  neighbor  acquisition  protocol  shall  be deemed

     incomplete.  A Neighbor Cease message (see below) should then  be

     sent.   If  one  gateway  still desires to acquire the other as a

     neighbor, the protocol must be repeated from the beginning.


          If  a  gateway  wishes  to  cease  being  a  neighbor  of  a

     particular  exterior  gateway, it sends a Neighbor Cease message.

     A gateway  receiving  a  Neighbor  Cease  message  should  always

     respond with a Neighbor Cease Acknowledgment.  It should cease to




                                   - 9 -

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



     treat the sender of the message as a neighbor in any way.   Since

     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.


          NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY

     INITIALLY  DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER.

     While this is hardly a trivial problem, it is  not  part  of  the

     External Gateway Protocol.





















                                  - 10 -

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



     3  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.


          At  the  current  time,   the   reachability   determination

     algorithm  is  left to the designers of a particular gateway.  We

     have in mind algorithms like the following:


          A reachable  neighbor  shall  be  declared  unreachable  if,

     during the time in which we sent our last n "Hello"s, we received

     fewer than k "I Heard You"s in return.  An  unreachable  neighbor

     shall  be declared reachable if, during the time in which we sent

     our last m "Hello"s, we received at least j  "I  Heard  You"s  in

     return.





                                  - 11 -

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



          However, 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  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.


          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 one gateway to

     make its reachability determination parasitic on the other:  only

     one  gateway  actually  needs  to  send "Hello" messages, and the

     other can declare it up or down based on the status field in  the

     "Hello".   That  is,  the  "passive" gateway (which sends only "I

     Heard  You"s)  declares  the  "active"  one  (which  sends   only

     "Hello"s)  to  be reachable when the "Hello"s from the active one

     indicate that it has declared the passive one  to  be  reachable.

     Of  course,  this can only work if there is prior agreement as to

     which neighbor is to be the active one.  (Ways of coming to  this




                                  - 12 -

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



     "prior agreement" are not part of the Exterior Gateway Protocol.)


          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

     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" and "I Heard You" messages from gateway G to gateway

     G'  also  carry  the identification number of the NR poll message

     (see below) which G has most recently received from G'.






                                  - 13 -

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



          "Hello" and "I Heard You" messages from gateway G to gateway

     G'  also  carry  the  minimum interval in minutes with which G is

     willing to be polled by G' for NR messages (see below).


          "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 Gateway Going Down message to all direct  neighbors

     which  will  no longer be able to reach it.  It should retransmit

     that message (up to some number of times)  until  it  receives  a

     Gateway  Going  Down Acknowledgment.  This provides 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 827                              Bolt Beranek and Newman Inc.
                                                         Eric C. Rosen



     4  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,

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

     transferring this information.



                                  - 15 -

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



          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 contains a

     byte  which  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.

     This information might (or might not) be useful in  the  interior

     routing algorithm of gateway G', or for diagnostic purposes.


          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.



                                  - 16 -

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



          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 shall be assumed that N is still reachable from  G.   HOWEVER,

     IF  N IS NOT MENTIONED IN TWO SUCCESSIVE NR MESSAGES FROM G, THAT

     SHALL BE TAKEN TO MEAN THAT N IS  NO  LONGER  REACHABLE  FROM  G.