"STUB" Exterior Gateway Protocol
RFC 888

Document Type RFC - Unknown (January 1984; No errata)
Updated by RFC 904
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 888 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text