Browse Prior Art Database

Exterior Gateway Protocol (EGP) (RFC0827)

IP.com Disclosure Number: IPCOM000003875D
Original Publication Date: 1982-Oct-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 34 page(s) / 65K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E.C. Rosen: AUTHOR

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 5% of the total text.

RFC 827

EXTERIOR GATEWAY PROTOCOL (EGP)

Eric C. Rosen

Bolt Beranek and Newman Inc.

October 1982

It is proposed to establish a standard for Gateway to Gateway procedures

that allow the Gateways to be mutually suspicious. This document is a

DRAFT for that standard. Your comments are strongly encouraged.

RFC 827 Bolt Beranek and Newman Inc.

Eric C. Rosen

Table of Contents

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

2 NEIGHBOR ACQUISITION.................................. 8

3 NEIGHBOR REACHABILITY PROTOCOL....................... 11

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

5 POLLING FOR NR MESSAGES.............................. 22

6 SENDING NR MESSAGES.................................. 25

7 INDIRECT NEIGHBORS................................... 27

8 HOW TO BE A STUB GATEWAY............................. 28

9 LIMITATIONS.......................................... 32

- i -

RFC 827 Bolt Beranek and Newman Inc.

Eric C. Rosen

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

any proposed change must be made in too many different

places and by too many different people.

- 1 -

RFC 827 Bolt Beranek and Newman Inc.

Eric C. Rosen

...