rfc888.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,359 行 · 第 1/4 页

                                  RFC 888


                     "STUB" EXTERIOR GATEWAY PROTOCOL


                            Linda J. Seamonson

                               Eric C. Rosen


                            BBN Communications


                               January 1984










This note describes the Exterior Gateway Protocol used to connect Stub
Gateways to an Autonomous System of core Gateways.  This document specifies
the working protocol, and defines an ARPA official protocol.  All
implementers of Gateways should carefully review this document.
















     RFC 888                                              JANUARY 1984



                             Table of Contents





     1   INTRODUCTION.......................................... 1

     2   DEFINITIONS AND OVERVIEW.............................. 4

     3   NEIGHBOR ACQUISITION.................................. 7

     4   NEIGHBOR REACHABILITY PROTOCOL....................... 10

     5   NETWORK REACHABILITY (NR) MESSAGE.................... 15

     6   POLLING FOR NR MESSAGES.............................. 22

     7   SENDING NR MESSAGES.................................. 24

     8   INDIRECT NEIGHBORS................................... 26

     9   LIMITATIONS.......................................... 27

     A   APPENDIX A - EGP MESSAGE FORMATS..................... 28
     A.1   NEIGHBOR ACQUISITION MESSAGE....................... 28
     A.2   NEIGHBOR HELLO/I HEARD YOU MESSAGE................. 30
     A.3   NR POLL MESSAGE.................................... 32
     A.4   NETWORK REACHABILITY MESSAGE....................... 34
     A.5   EGP ERROR MESSAGE.................................. 37

















                                   - i -








     RFC 888                                              JANUARY 1984



     1  INTRODUCTION


          The DARPA Catenet is expected to be a continuously expanding

     system,  with  more  and  more  hosts  on  more and more networks

     participating in it.  Of course, this will require more and  more

     gateways.   In  the  past,  such  expansion  has taken place in a

     relatively unstructured manner.  New gateways,  often  containing

     radically different software than the existing gateways, would be

     added and would immediately begin  participating  in  the  common

     routing algorithm via the GGP protocol.  However, as the internet

     grows larger and larger, this simple method of expansion  becomes

     less and less feasible.  There are a number of reasons for this:



          - the overhead of the routing algorithm becomes  excessively

            large;


          - the  proliferation   of   radically   different   gateways

            participating  in  a single common routing algorithm makes

            maintenance and fault isolation nearly  impossible,  since

            it  becomes  impossible to regard       the internet as an

            integrated communications system;


          - the  gateway  software  and  algorithms,  especially   the

            routing  algorithm, become too rigid and inflexible, since



                                   - 1 -







     RFC 888                                              JANUARY 1984



            any proposed change  must be made in  too  many  different

            places   and   by   too   many   different        people.




          In the future, the internet is expected to evolve into a set

     of  separate  sections or  "autonomous  systems",  each  of which

     consists of a set of one or more relatively homogeneous gateways.

     The  protocols,  and  in  particular  the routing algorithm which

     these gateways use among themselves, will be  a  private  matter,

     and  need never be implemented in gateways outside the particular

     sections or system.


          In the simplest case, an autonomous system might consist  of

     just a single gateway connecting, for example, a local network to

     the ARPANET.  Such a gateway might be called  a  "stub  gateway",

     since  its  only purpose is to interface the local network to the

     rest of the internet, and it is  not  intended  to  be  used  for

     handling  any traffic which neither originated in nor is destined

     for that particular local network.  In the near-term  future,  we

     will  begin  to  think  of  the  internet  as a set of autonomous

     systems, one of which consists of the DARPA gateways  on  ARPANET

     and  SATNET,  and  the others of which are stub gateways to local

     networks.   The former system, which we  shall  call  the  "core"




                                   - 2 -







     RFC 888                                              JANUARY 1984



     system,  will be used as a transport or "long-haul" system by the

     latter systems.


          Ultimately, the internet may consist of a number of co-equal

     autonomous  systems,  any  of  which  may  be used as a transport

     medium for traffic originating in any system and destined for any

     system.  This more general case is still the subject of research.

     This paper describes only how stub gateways connect to  the  core

     system using the Exterior Gateway Protocol (EGP).































                                   - 3 -







     RFC 888                                              JANUARY 1984



     2  DEFINITIONS AND OVERVIEW


          For the purposes of this paper, a "stub gateway" is  defined

     as follows:


          - it is not a core gateway

          - it shares a network with at least one core gateway (has an

            interface on the same network as some core gateway)

          - it has interfaces to one or more networks  which  have  no

            core gateways

          - all other nets which are reachable from  the  core  system

            via  the stub have no other path to the core system except

            via the stub



          The stub gateway is expected to fully execute  the  Internet

     Control Message Protocol (ICMP), as well as the EGP protocol.  In

     particular, it must respond to ICMP echo requests, and must  send

     ICMP  destination  dead  messages  as  appropriate.   It  is also

     required to send ICMP Redirect messages as appropriate.



          Autonomous systems will be  assigned  16-bit  identification

     numbers  (in  much  the same ways as network and protocol numbers

     are now assigned), and every EGP message header contains a  field




                                   - 4 -







     RFC 888                                              JANUARY 1984



     for  this  number.   Zero  will not be assigned to any autonomous

     system; the use  of  zero  as  an  autonomous  system  number  is

     reserved for future use.


          We call two gateways "neighbors" if there is  a  network  to

     which  each  has  an interface.  If two neighbors are part of the

     same autonomous system, we  call  them  INTERIOR  NEIGHBORS;  for

     example,  any  two core gateways on the same network are interior

     neighbors of each other.  If two neighbors are not  part  of  the

     same  autonomous  system,  we  call  them EXTERIOR NEIGHBORS; for

     example, a stub gateway and any core gateway that share a network

     are exterior neighbors of each other.  In order for one system to

     use another as a transport medium, gateways  which  are  exterior

     neighbors  of  each other must be able to find out which networks

     can be reached through the other.  The Exterior Gateway  Protocol

     enables this information to be passed between exterior neighbors.

     Since it is a polling protocol, it also enables each  gateway  to

     control   the  rate  at  which  it  sends  and  receives  network

     reachability information, allowing each system to control its own

     overhead.   It  also  enables  each system to have an independent

     routing algorithm whose operation cannot be disrupted by failures

     of other systems.





                                   - 5 -







     RFC 888                                              JANUARY 1984



          The Exterior Gateway Protocol has three parts: (a)  Neighbor

     Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c)

     Network  Reachability  determination.   Note  that  all  messages

     defined  by EGP are intended to travel only a single "hop".  That

     is, they originate at one gateway and are sent to  a  neighboring

     gateway   without  the  mediation  of  any  intervening  gateway.

     Therefore, the time-to-live field should be set to a  very  small

     value.   Gateways  which  encounter EGP messages in their message

     streams which are not addressed to them may discard them.


          Each EGP message contains a sequence  number.   The  gateway

     should maintain one sequence number per neighbor.

























                                   - 6 -







     RFC 888                                              JANUARY 1984



     3  NEIGHBOR ACQUISITION


          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   two-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

     or a Neighbor Acquisition Refusal 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



                                   - 7 -







     RFC 888                                              JANUARY 1984



     Neighbor Acquisition Reply message.


          The gateway  that  sent  the  Request  should  consider  the

     Neighbor Acquisition complete when it has received the neighbor's

     Reply.  The gateway that  sent  the  Reply  should  consider  the

     acquisition complete when it has sent the Reply.


          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  Request  from  a  gateway  which  is

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


          A Neighbor Acquisition Request or Reply from  gateway  G  to

     gateway  G'  carries the minimum interval in seconds with which G

     is willing to answer Neighbor Reachability Hello Messages from G'

     and the minimum interval in seconds with which G is willing to be

     polled for NR messages (see below).


          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

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



                                   - 8 -