Browse Prior Art Database

"STUB" Exterior Gateway Protocol (RFC0888)

IP.com Disclosure Number: IPCOM000003937D
Original Publication Date: 1984-Jan-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 40 page(s) / 37K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

L. Seamonson: AUTHOR [+1]

Related Documents

10.17487/RFC0888: DOI

Abstract

This RFC 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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 8% of the total text.

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

Processing...
Loading...