rfc888.txt

RFC 相关的技术文档

     RFC 888                                              JANUARY 1984



          The data portion of the  message  will  consist  largely  of

     blocks  of data.  Each block will be headed by a gateway address,

     which will be the address  either  of  the  gateway  sending  the

     message  or  of  one  of  that gateway's neighbors.  Each gateway

     address will be followed by a list of the networks for which that

     gateway  is  an  appropriate first hop.  All networks at the same

     distance from the gateway will be grouped together in this  list,

     preceded  by  the  distance  itself and the number of networks at

     that distance.  The whole list is preceded  by  a  count  of  the

     distance-groups in the list.


          Preceding the list of data blocks is:

          a) The count (one byte) of the number of interior  neighbors

             of  G  for  which  this message contains data blocks.  By

             convention, this count will include the data block for  G

             itself, which should be the first one to appear.


          b) The count (one byte) of the number of exterior  neighbors

                of  G  for  which  this  message contains data blocks.




          c) The address of the network which this message  is  about.

             If  G  and  G' are neighbors on network N, then in the NR

             message going from G  to  G',  this  is  the  address  of



                                  - 19 -







     RFC 888                                              JANUARY 1984



             network   N.   For  convenience,  four  bytes  have  been

             allocated for this address -- the trailing one,  two,  or

             three bytes should be zero.


          Then follow the data blocks themselves, first the block  for

     G itself, then the blocks for all the interior neighbors of G (if

     any), then the blocks for  the  exterior  neighbors.   Since  all

     gateways  mentioned  are  on  the same network, whose address has

     already been given, the gateway  addresses  are  given  with  the

     network  address part (one, two, or three bytes) omitted, to save

     space.


          In the list of networks, each network address is either one,

     two,  or three bytes, depending on whether it is a class A, class

     B, or class C network.  No trailing bytes are used.


          The NR message  sent  by  a  stub  should  be  the  simplest

     allowable.   That  is,  it  should have only a single data block,

     headed by its own address (on the network it has in  common  with

     the neighboring core gateway), listing just the networks to which

     it is an appropriate first hop.  These will be just the  networks

     that can be reached no other way, in general.







                                  - 20 -







     RFC 888                                              JANUARY 1984



          The core gateways will send complete NR messages, containing

     information  about all other gateways on the common network, both

     core gateways (which shall be listed as interior  neighbors)  and

     other  gateways (which shall be listed as exterior neighbors, and

     may include the stub itself).  This information will  enable  the

     stub  to  become  an  indirect  neighbor (see below) of all these

     other gateways.  That is, the stub shall forward traffic directly

     to  these  other  gateways  as  appropriate, but shall not become

     direct neighbors with them.


          The  stub  should  NEVER  forward  to   any   (directly   or

     indirectly)  neighboring  core gateway any traffic for which that

     gateway is not an appropriate first hop, as indicated  in  an  NR

     message.   Of  course, this does not apply to datagrams which are

     using the source route option; any such datagrams  should  always

     be  forwarded as indicated in the source route option field, even

     if that  requires  forwarding  to  a  gateway  which  is  not  an

     appropriate first hop.













                                  - 21 -







     RFC 888                                              JANUARY 1984



     6  POLLING FOR NR MESSAGES


          No gateway is required to send  NR  messages  to  any  other

     gateway,  except  as  a  response  to  an  NR  Poll from a direct

     neighbor.  However, a gateway is required to  respond  to  an  NR

     Poll  from  a  direct neighbor within several seconds (subject to

     the qualification two paragraphs  hence),  even  if  the  gateway

     believes that neighbor to be down.


          The EGP NR Poll message is defined  for  this  purpose.   No

     gateway  may  poll another for an NR message more often than once

     per minute.  A gateway receiving more than one  poll  per  minute

     may  simply  ignore  the  excess  polls,  or  may return an error

     message.


          The minimum interval which gateway  G  will  accept  as  the

     polling  interval  from gateway G' and the minimum interval which

     G' will accept as the polling interval from G  are  specified  at

     the  time  that  G  and  G'  become  direct  neighbors.  Both the

     Neighbor Acquisition Request and the Neighbor  Acquisition  Reply

     allow  the  sender  to  specify,  in seconds, its desired minimum

     polling interval.  If G specifies to G' that its minimum  polling

     interval  is  X,  G'  should not poll G more frequently than once

     every X seconds.  G will not guarantee to  answer  more  frequent



                                  - 22 -







     RFC 888                                              JANUARY 1984



     polls.


          Polls must only  be  sent  to  direct  neighbors  which  are

     declared reachable by the neighbor reachability protocol.


          An NR Poll message contains a sequence number chosen by  the

     polling  gateway.   The polled gateway will return this number in

     the NR message it sends in response to the poll,  to  enable  the

     polling gateway to match up received NR messages with polls.


          In general, a poll should be retransmitted  some  number  of

     times  (with a reasonable interval between retransmissions) until

     an NR message is received.  IF NO NR MESSAGE  IS  RECEIVED  AFTER

     THE MAXIMUM NUMBER OF RETRANSMISSIONS, THE POLLING GATEWAY SHOULD

     ASSUME THAT THE POLLED GATEWAY IS NOT AN  APPROPRIATE  FIRST  HOP

     FOR  ANY  NETWORK  WHATSOEVER.   The  optimum  parameters for the

     polling/retransmission  algorithm  will  be  dependent   on   the

     characteristics   of   the  two  neighbors  and  of  the  network

     connecting them.


          Received NR messages whose  identification  numbers  do  not

     match  the  identification  number of the most recently sent poll

     shall be ignored.  There is no provision for multiple outstanding

     polls to the same neighbor.




                                  - 23 -







     RFC 888                                              JANUARY 1984



     7  SENDING NR MESSAGES


          In general, NR messages are to be sent only in response to a

     poll.   However,  between  two  successive polls from an exterior

     neighbor, a gateway may send one  and  only  one  unsolicited  NR

     message  to  that  neighbor.   This  gives  it limited ability to

     quickly announce  network  reachability  changes  that  may  have

     occurred in the interval since the last poll.  Excess unsolicited

     NR messages may be ignored, or an error message may be returned.


          An NR message should be sent within  several  seconds  after

     receipt  of  a poll.  Failure to respond in a timely manner to an

     NR poll may result in the polling  gateway's  deciding  that  the

     polled gateway is not an appropriate first hop to any network.


          NR messages sent in response to  polls  carry  the  sequence

     number  of  the  poll  message in their "sequence number" fields.

     Unsolicited NR messages carry the identification  number  of  the

     last  poll  received,  and have the "unsolicited" bit set.  (Note

     that this allows for only a single  unsolicited  NR  message  per

     polling period.)


          Polls from  non-neighbors,  from  neighbors  which  are  not

     declared  reachable, or with bad IP source network fields, should




                                  - 24 -







     RFC 888                                              JANUARY 1984



     be responded to with an EGP error message  with  the  appropriate

     "reason"  field.   If  G  sends  an  NR poll to G' with IP source

     network N, and G' is not a neighbor of  G  on  its  interface  to

     network  N  (or G' does not have an interface to network N), then

     the source network field is considered "bad".


          A gateway is normally not required to send more than one  NR

     message  within the minimum interval specified at the time of the

     neighbor acquisition.  An exception to  this  must  be  made  for

     duplicate polls (successive polls with the same sequence number),

     which occur when an NR message is lost  in  transit.   A  gateway

     should  send an NR message containing its most recent information

     in response to a duplicate poll.























                                  - 25 -







     RFC 888                                              JANUARY 1984



     8  INDIRECT NEIGHBORS


          Becoming a "direct neighbor" of an exterior gateway requires

     three  steps:  (a)  neighbor  acquisition, (b) running a neighbor

     reachability protocol, and (c) polling the neighbor  periodically

     for NR messages.  Suppose, however, that gateway G receives an NR

     message from G', in which G'  indicates  the  presence  of  other

     neighbors  G1, ..., Gn, each of which is an appropriate first hop

     for some set of networks to which G' itself is not an appropriate

     first hop.  Then G should be allowed to forward traffic for those

     networks directly to the appropriate one of G1, ..., Gn,  without

     having to send it to G' first.  In this case, G may be considered

     an INDIRECT NEIGHBOR of G1, ..., Gn, since it is  a  neighbor  of

     these  other  gateways for the purpose of forwarding traffic, but

     does not perform neighbor acquisition, neighbor reachability,  or

     exchange   of  NR  messages  with  them.   Neighbor  and  network

     reachability information is obtained indirectly via G', hence the

     designation  "indirect  neighbor".   We say that G is an indirect

     neighbor of G1, ..., Gn VIA G'.


          If G is an indirect neighbor of  G'  via  G'',  and  then  G

     receives  an  NR  message  from  G'' which does not mention G', G

     should treat G' as having become unreachable.




                                  - 26 -







     RFC 888                                              JANUARY 1984



     9  LIMITATIONS


          It must be clearly  understood  that  the  Exterior  Gateway

     Protocol   does  not  in  itself  constitute  a  network  routing

     algorithm.  In addition, it does not provide all the  information

     needed  to  implement  a  general area routing algorithm.  If the

     topology does not obey the  rules  given  for  stubs  above,  the

     Exterior  Gateway  Protocol  does  not provide enough topological

     information to prevent loops.


          If any gateway sends an NR message with  false  information,

     claiming  to be an appropriate first hop to a network which it in

     fact cannot even reach, traffic  destined  to  that  network  may

     never be delivered.  Implementers must bear this in mind.






















                                  - 27 -







     RFC 888                                              JANUARY 1984



     A  APPENDIX A - EGP MESSAGE FORMATS

          The Exterior Gateway Protocol runs under Internet Protocol as
     protocol number 8 (decimal).




     A.1  NEIGHBOR ACQUISITION MESSAGE

      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      !    Info       !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !        Checksum               !       Autonomous System #     !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !        Sequence #             !       NR Hello interval       !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !        NR poll interval       !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Description:

          The Neighbor Acquisition messages are used by interior and
          exterior gateways to become neighbors of each other.

     EGP Version #

         2

     Type

         3

     Code

          Code = 0      Neighbor Acquisition Request
          Code = 1      Neighbor Acquisition Reply
          Code = 2      Neighbor Acquisition Refusal (see Info field)
          Code = 3      Neighbor Cease Message (see Info field)
          Code = 4      Neighbor Cease Acknowledgment

     Checksum



                                  - 28 -