分享
 
 
 

RFC823 - DARPA Internet gateway

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Request for Comments: 823

Obsoletes IEN-30 and IEN-109

THE DARPA INTERNET GATEWAY

RFC823

Robert Hinden

Alan Sheltzer

Bolt Beranek and Newman Inc.

10 Moulton St.

Cambridge, Massachusetts 02238

September 1982

Prepared for

Defense Advanced Research Projects Agency

Information Processing Techniques Office

1400 Wilson Boulevard

Arlington, Virginia 22209

This RFCis a status report on the Internet Gateway developed by BBN. It

describes the Internet Gateway as of September 1982. This memo presents

detailed descriptions of message formats and gateway procedures, however

this is not an implementation specification, and sUCh details are

subject to change.

DARPA Internet Gateway September 1982

RFC823

Table of Contents

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

2 BACKGROUND............................................ 2

3 FORWARDING INTERNET DATAGRAMS......................... 5

3.1 Input............................................... 5

3.2 IP Header Checks.................................... 6

3.3 Routing............................................. 7

3.4 Redirects........................................... 9

3.5 Fragmentation....................................... 9

3.6 Header Rebuild..................................... 10

3.7 Output............................................. 10

4 PROTOCOLS SUPPORTED BY THE GATEWAY................... 12

4.1 Cross-Net Debugging Protocol....................... 12

4.2 Host Monitoring Protocol........................... 12

4.3 ICMP............................................... 14

4.4 Gateway-to-Gateway Protocol........................ 14

4.4.1 Determining Connectivity to Networks............. 14

4.4.2 Determining Connectivity to Neighbors............ 16

4.4.3 Exchanging Routing Information................... 17

4.4.4 Computing Routes................................. 19

4.4.5 Non-Routing Gateways............................. 22

4.4.6 Adding New Neighbors and Networks................ 23

4.5 Exterior Gateway Protocol.......................... 24

5 GATEWAY SOFTWARE..................................... 26

5.1 Software Structure................................. 26

5.1.1 Device Drivers................................... 27

5.1.2 Network Software................................. 27

5.1.3 Shared Gateway Software.......................... 29

5.2 Gateway Processes.................................. 29

5.2.1 Network Processes................................ 29

5.2.2 GGP Process...................................... 30

5.2.3 HMP Process...................................... 31

APPENDIX A. GGP Message Formats.......................... 32

APPENDIX B. Information Maintained by Gateways........... 39

APPENDIX C. GGP Events and Responses..................... 41

REFERENCES............................................... 43

-i-

DARPA Internet Gateway September 1982

RFC823

1 INTRODUCTION

This document eXPlains the design of the Internet gateway

used in the Defense Advanced Research Project Agency (DARPA)

Internet program. The gateway design was originally documented

in IEN-30, "Gateway Routing: An Implementation Specification"

[2], and was later updated in IEN-109, "How to Build a Gateway"

[3]. This document reflects changes made both in the internet

protocols and in the gateway design since these documents were

released. It supersedes both IEN-30 and IEN-109.

The Internet gateway described in this document is based on

the work of many people; in particular, special credit is given

to V. Strazisar, M. Brescia, E. Rosen, and J. Haverty.

The gateway's primary purpose is to route internet datagrams

to their destination networks. These datagrams are generated and

processed as described in RFC791, "Internet Protocol - DARPA

Internet Program Protocol Specification" [1]. This document

describes how the gateway forwards datagrams, the routing

algorithm and protocol used to route them, and the software

structure of the current gateway. The current gateway

implementation is written in macro-11 assembly language and runs

in the DEC PDP-11 or LSI-11 16-bit processor.

-1-

DARPA Internet Gateway September 1982

RFC823

2 BACKGROUND

The gateway system has undergone a series of changes since

its inception, and it is continuing to evolve as research

proceeds in the Internet community. This document describes the

implementation as of mid-1982.

Early versions of gateway software were implemented using

the BCPL language and the ELF operating system. This

implementation evolved into one which used the MOS operating

system for increased performance. In late 1981, we began an

effort to produce a totally new gateway implementation. The

primary motivation for this was the need for a system oriented

towards the requirements of an operational communications

facility, rather than the research testbed environment which was

associated with the BCPL implementation. In addition, it was

generally recognized that the complexity and buffering

requirements of future gateway configurations were beyond the

capabilities of the PDP-11/LSI-11 and BCPL architecture. The new

gateway implementation therefore had a second goal of producing a

highly space-efficient implementation in order to provide space

for buffers and for the extra mechanisms, such as monitoring,

which are needed for an operational environment.

-2-

DARPA Internet Gateway September 1982

RFC823

This document describes the implementation of this new

gateway which incorporates several mechanisms for operations

activities, is coded in assembly language for maximum space-

efficiency, but otherwise is fundamentally the same architecture

as the older, research-oriented, implementations.

One of the results of recent research is the thesis that

gateways should be viewed as elements of a gateway system, where

the gateways act as a loosely-coupled packet-switching

communications system. For reasons of maintainability and

operability, it is easiest to build such a system in an

homogeneous fashion where all gateways are under a single

authority and control, as is the practice in other network

implementations.

In order to create a system architecture that permitted

multiple sets of gateways with each set under single control but

acting together to implement a composite single Internet System,

new protocols needed to be developed. These protocols, such as

the "Exterior Gateway Protocol," will be introduced in the later

releases of the gateway implementation.

We also anticipate further changes to the gateway

architecture and implementation to introduce support for new

-3-

DARPA Internet Gateway September 1982

RFC823

capabilities, such as large numbers of networks, Access control,

and other requirements which have been proposed by the Internet

research community. This document represents a snapshot of the

current implementation, rather than a specification.

-4-

DARPA Internet Gateway September 1982

RFC823

3 FORWARDING INTERNET DATAGRAMS

This section describes how the gateway forwards datagrams

between networks. A host computer that wants an IP datagram to

reach a host on another network must send the datagram to a

gateway to be forwarded. Before it is sent into the network, the

host attaches to the datagram a local network header containing

the address of the gateway.

3.1 Input

When a gateway receives a message, the gateway checks the

message's local network header for possible errors and performs

any actions required by the host-to-network protocol. This

processing involves functions such as verifying the local network

header checksum or generating a local network acknowledgment

message. If the header indicates that the message contains an

Internet datagram, the datagram is passed to the Internet header

check routine. All other messages received that do not pass

these tests are discarded.

-5-

DARPA Internet Gateway September 1982

RFC823

3.2 IP Header Checks

The Internet header check routine performs a number of

validity tests on the IP header. Datagrams that fail these tests

are discarded causing an HMP trap to be sent to the Internet

Network Operations Center (INOC) [7]. The following checks are

currently performed:

o Proper IP Version Number

o Valid IP Header Length ( >= 20 bytes)

o Valid IP Message Length

o Valid IP Header Checksum

o Non-Zero Time to Live field

After a datagram passes these checks, its Internet destination

address is examined to determine if the datagram is addressed to

the gateway. Each of the gateway's internet addresses (one for

each network interface) is checked against the destination

address in the datagram. If a match is not found, the datagram

is passed to the forwarding routine.

If the datagram is addressed to the gateway itself, the IP

options in the IP header are processed. Currently, the gateway

supports the following IP options:

-6-

DARPA Internet Gateway September 1982

RFC823

o NOP

o End of Option List

o Loose Source and Record Route

o Strict Source and Record Route

The datagram is next processed according to the protocol in the

IP header. If the protocol is not supported by the gateway, it

replies with an ICMP error message and discards the datagram.

The gateway does not support IP reassembly, so fragmented

datagrams which are addressed to the gateway are discarded.

3.3 Routing

The gateway must make a routing decision for all datagrams

that are to be to forwarded. The routing algorithm provides two

pieces of information for the gateway: 1) the network interface

that should be used to send this datagram and 2) the destination

address that should be put in the local network header of the

datagram.

The gateway maintains a dynamic Routing Table which contains

an entry for each reachable network. The entry consists of a

network number and the address of the neighbor gateway on the

shortest route to the network, or else an indication that the

-7-

DARPA Internet Gateway September 1982

RFC823

gateway is directly connected to the network. A neighbor gateway

is one which shares a common network with this gateway. The

distance metric that is used to determine which neighbor is

closest is defined as the "number of hops," where a gateway is

considered to be zero hops from its directly connected networks,

one hop from a network that is reachable via one other gateway,

etc. The Gateway-to-Gateway Protocol (GGP) is used to update the

Routing Table (see Section 4.4 describing the Gateway-to-Gateway

Protocol).

The gateway tries to match the destination network address

in the IP header of the datagram to be forwarded, with a network

in its Routing Table. If no match is found, the gateway drops

the datagram and sends an ICMP Destination Unreachable message to

the IP source. If the gateway does find an entry for the network

in its table, it will use the network address of the neighbor

gateway entry as the local network destination address of the

datagram. However, if the final destination network is one that

the gateway is directly connected to, the destination address in

the local network header is created from the destination address

in the IP header of the datagram.

-8-

DARPA Internet Gateway September 1982

RFC823

3.4 Redirects

If the routing procedure decides that an IP datagram is to

be sent back out the same network interface that it was read in,

then this gateway is not on the shortest path to the IP final

destination. Nevertheless, the datagram will still be forwarded

to the next address chosen by the routing procedure. If the

datagram is not using the IP Source Route Option, and the IP

source network of the datagram is the same as the network of the

next gateway chosen by the routing procedure, an ICMP Redirect

message will be sent to the IP source host indicating that

another gateway should be used to send traffic to the final IP

destination.

3.5 Fragmentation

The datagram is passed to the fragmentation routine after

the routing decision has been made. If the next network through

which the datagram must pass has a maximum message size that is

smaller than the size of the datagram, the datagram must be

fragmented. Fragmentation is performed according to the

algorithm described in the Internet Protocol Specification [1].

Certain IP options must be copied into the IP header of all

-9-

DARPA Internet Gateway September 1982

RFC823

fragments, and others appear only in the first fragment according

to the IP specification. If a datagram must be fragmented, but

the Don't fragment bit is set, the datagram is discarded and an

ICMP error message is sent to the IP source of the datagram.

3.6 Header Rebuild

The datagram (or the fragments of the original datagram if

fragmentation was needed) is next passed to a routine that

rebuilds the Internet header. The Time to Live field is

decremented by one and the IP checksum is recomputed.

The local network header is now built. Using the

information oBTained from its routing procedure, the gateway

chooses the network interface it considers proper to send the

datagram and to build the destination address in the local

network header.

3.7 Output

The datagram is now enqueued on an output queue for delivery

towards its destination. A limit is enforced on the size of the

output queue for each network interface so that a slow network

-10-

DARPA Internet Gateway September 1982

RFC823

does not unfairly use up all of the gateway's buffers. If a

datagram cannot be enqueued due to the limit on the output queue

length, it is dropped and an HMP trap is sent to the INOC. These

traps, and others of a similar nature, are used by operational

personnel to monitor the operations of the gateways.

-11-

DARPA Internet Gateway September 1982

RFC823

4 PROTOCOLS SUPPORTED BY THE GATEWAY

A number of protocols are supported by the gateway to

provide dynamic routing, monitoring, debugging, and error

reporting. These protocols are described below.

4.1 Cross-Net Debugging Protocol

The Cross-Net Debugging Protocol (XNET) [8] is used to load

the gateway and to examine and deposit data. The gateway

supports the following XNET op-codes:

o NOP

o Debug

o End Debug

o Deposit

o Examine

o Create Process

4.2 Host Monitoring Protocol

The Host Monitoring Protocol (HMP) [6] is used to collect

measurements and status information from the gateways.

Exceptional conditions in the gateways are reported in HMP traps.

The status of a gateway's interfaces, neighbors, and the networks

which it can reach are reported in the HMP status message.

-12-

DARPA Internet Gateway September 1982

RFC823

Two types of gateway statistics, the Host Traffic Matrix and

the gateway throughput, are currently defined by the HMP. The

Host Traffic Matrix records the number of datagrams that pass

through the gateway with a given IP source, destination, and

protocol number. The gateway throughput message collects a

number of important counters that are kept by the gateway. The

current gateway reports the following values:

o Datagrams dropped because destination net unreachable

o Datagrams dropped because destination host unreachable

o Per Interface:

Datagrams received with IP errors

Datagrams received for this gateway

Datagrams received to be forwarded

Datagrams looped

Bytes received

Datagrams sent, originating at this gateway

Datagrams sent to destination hosts

Datagrams dropped due to flow control limitations

Datagrams dropped due to full queue

Bytes sent

o Per Neighbor:

Routing updates sent to

Routing updates received from

Datagrams sent, originating here

Datagrams forwarded to

Datagrams dropped due to flow control limitations

Datagrams dropped due to full queue

Bytes sent

-13-

DARPA Internet Gateway September 1982

RFC823

4.3 ICMP

The gateway will generate the following ICMP messages under

appropriate circumstances as defined by the ICMP specification

[4]:

o Echo Reply

o Destination Unreachable

o Source Quench

o Redirect

o Time Exceeded

o Parameter Problem

o Information Reply

4.4 Gateway-to-Gateway Protocol

The gateway uses the Gateway-to-Gateway Protocol (GGP) to

determine connectivity to networks and neighbor gateways; it is

also used in the implementation of a dynamic, shortest-path

routing algorithm. The current GGP message formats (for release

1003 of the gateway software) are presented in Appendix A.

4.4.1 Determining Connectivity to Networks

When a gateway starts running it assumes that all its

neighbor gateways are "down," that it is disconnected from

-14-

DARPA Internet Gateway September 1982

RFC823

networks to which it is attached, and that the distance reported

in routing updates from each neighbor to each network is

"infinity."

The gateway first determines the state of its connectivity

to networks to which it is physically attached. The gateway's

connection to a network is declared up if it can send and receive

internet datagrams on its interface to that network. Note that

the method that the gateway uses to determine its connectivity to

a network is network-dependent. In some networks, the host-to-

network protocol determines whether or not datagrams can be sent

and received on the host interface. In these networks, the

gateway simply checks-status information provided by the protocol

in order to determine if it can communicate with the network. In

other networks, where the host-to-network protocols are less

sophisticated, it may be necessary for the gateway to send

datagrams to itself to determine if it can communicate with the

network. In these networks, the gateways periodically poll the

network using GGP network interface status messages [Appendix A]

to determine if the network interface is operational.

The gateway has two rules relevant to computing distances to

networks: 1) if the gateway can send and receive traffic on its

-15-

DARPA Internet Gateway September 1982

RFC823

network interface, its distance to the network is zero; 2) if it

cannot send and receive traffic on the interface, its distance to

the network is "infinity." Note that if a gateway's network

interface is not working, it may still be able to send traffic to

the network on an alternate route via one of its neighbor

gateways.

4.4.2 Determining Connectivity to Neighbors

The gateway determines connectivity to neighbors using a "K

out of N" algorithm. Every 15 seconds, the gateway sends GGP

Echo messages [Appendix A] to each of its neighbors. The

neighbors respond by sending GGP echo replies. If there is no

reply to K out of N (current values are K=3 and N=4) echo

messages sent to a neighbor, the neighbor is declared down. If a

neighbor is down and J out of M (current values are J=2 and M=4)

echo replies are received, the neighbor is declared to be up.

The values of J,K,M,N and the time interval are operational

parameters which can be adjusted as required.

-16-

DARPA Internet Gateway September 1982

RFC823

4.4.3 Exchanging Routing Information

The gateway sends routing information in GGP Routing Update

messages. The gateway receives and transmits routing information

reliably using sequence-numbered messages and a retransmission

and acknowledgment scheme as explained below. For each neighbor,

the gateway remembers the Receive Sequence Number, R, that it

received in the most recent routing update from that neighbor.

This value is initialized with the sequence number in the first

Routing Update received from a neighbor after that neighbor's

status is set to "up." On receipt of a routing update from a

neighbor, the gateway subtracts the Receive Sequence Number, R,

from the sequence number in the routing update, S. If this value

(S-R) is greater than or equal to zero, then the gateway accepts

the routing update, sends an acknowledgment (see Appendix A) to

the neighbor containing the sequence number S, and replaces the

Receive Sequence Number, R, with S. If this value (S-R) is less

than zero, the gateway rejects the routing update and sends a

negative acknowledgment [Appendix A] to the neighbor with

sequence number R.

The gateway has a Send Sequence Number, N, for sending

routing updates to all of its neighbors. This sequence number

-17-

DARPA Internet Gateway September 1982

RFC823

can be initialized to any value. The Send Sequence Number is

incremented each time a new routing update is created. On

receiving an acknowledgment for a routing update, the gateway

subtracts the sequence number acknowledged, A, from the Send

Sequence Number, N. If the value (N-A) is non-zero, then an old

routing update is being acknowledged. The gateway continues to

retransmit the most recent routing update to the neighbor that

sent the acknowledgment. If (N-A) is zero, the routing update

has been acknowledged. Note that only the most recent routing

update must be acknowledged; if a second routing update is

generated before the first routing update is acknowledged, only

the second routing update must be acknowledged.

If a negative acknowledgment is received, the gateway

subtracts the sequence number negatively acknowledged, A, from

its Send Sequence Number, N. If this value (N-A) is less than

zero, then the gateway replaces its Send Sequence Number, N, with

the sequence number negatively acknowledged plus one, A+1, and

retransmits the routing update to all of its neighbors. If (N-A)

is greater than or equal to zero, then the gateway continues to

retransmit the routing update using sequence number N. In order

to maintain the correct sequence numbers at all gateways, routing

updates must be retransmitted to all neighbors if the Send

-18-

DARPA Internet Gateway September 1982

RFC823

Sequence Number changes, even if the routing information does not

change.

The gateway retransmits routing updates periodically until

they are acknowledged and whenever its Send Sequence Number

changes. The gateway sends routing updates only to neighbors

that are in the "up" state.

4.4.4 Computing Routes

A routing update contains a list of networks that are

reachable through this gateway, and the distance in "number of

hops" to each network mentioned. The routing update only

contains information about a network if the gateway believes that

it is as close or closer to that network then the neighbor which

is to receive the routing update. The network address may be an

internet class A, B, or C address.

The information inside a routing update is processed as

follows. The gateway contains an N x K distance matrix, where N

is the number of networks and K is the number of neighbor

gateways. An entry in this matrix, represented as dm(I,J), is

the distance to network I from neighbor J as reported in the most

-19-

DARPA Internet Gateway September 1982

RFC823

recent routing update from neighbor J. The gateway also contains

a vector indicating the connectivity between itself and its

neighbor gateways. The values in this vector are computed as

discussed above (see Section 4.4.2, Determining Connectivity to

Neighbors). The value of the Jth entry of this vector, which is

the connectivity between the gateway and the Jth neighbor, is

represented as d(J).

The gateway copies the routing update received from the Jth

neighbor into the appropriate row of the distance matrix, then

updates its routes as follows. The gateway calculates a minimum

distance vector which contains the minimum distance to each

network from the gateway. The Ith entry of this vector,

represented as MinD(I) is:

MinD(I) = minimum over all neighbors of d(J) + dm(I,J)

where d(J) is the distance between the gateway and the Jth

neighbor, and dm(I,J) is the distance from the Jth neighbor to

the Ith network. If the Ith network is attached to the gateway

and the gateway can send and receive traffic on its network

interface (see Section 4.4.2), then the gateway sets the Ith

entry of the minimum distance vector to zero.

-20-

DARPA Internet Gateway September 1982

RFC823

Using the minimum distance vector, the gateway computes a

list of neighbor gateways through which to send traffic to each

network. The entry for a given network contains one of the

neighbors that is the minimum distance away from that network.

After updating its routes to the networks, the gateway

computes the new routing updates to be sent to its neighbors.

The gateway reports a network to a neighbor only if it is as

close to or closer to that network than its neighbor. For each

network I, the routing update contains the address of the network

and the minimum distance to that network which is MinD(I).

Finally, the gateway must determine whether it should send

routing updates to its neighbors. The gateway sends new updates

to its neighbors if every one of the following three conditions

occurs: 1) one of the gateway's interfaces changes state, 2)

one of the gateway's neighbor gateways changes state, and 3) the

gateway receives a routing update from a neighbor that is

different from the update that it had previously received from

that neighbor. The gateway sends routing updates only to

neighbors that are currently in the "up" state.

The gateway requests a routing update from neighbors that

are in the "up" state, but from which it has yet received a

-21-

DARPA Internet Gateway September 1982

RFC823

routing update. Routing updates are requested by setting the

appropriate bit in the routing update being sent [Appendix A].

Similarly, if a gateway receives from a neighbor a routing update

in which the bit requesting a routing update is set, the gateway

sends the neighbor the most recent routing update.

4.4.5 Non-Routing Gateways

A Non-routing Gateway is a gateway that forwards internet

traffic, but does not implement the GGP routing algorithm.

Networks that are behind a Non-routing Gateway are known a-priori

to Routing Gateways. There can be one or more of these networks

which are considered to be directly connected to the Non-routing

Gateway. A Routing Gateway will forward a datagram to a Non-

routing Gateway if it is addressed to a network behind the Non-

routing Gateway. Routing Gateways currently do not send

Redirects for Non-routing Gateways. A Routing Gateway will

always use another Routing Gateway as a path instead of a Non-

routing Gateways if both exist and are the same number of hops

away from the destination network. The Non-routing Gateways path

will be used only when the Routing Gateway path is down; when the

Routing Gateway path comes back up, it will be used again.

-22-

DARPA Internet Gateway September 1982

RFC823

4.4.6 Adding New Neighbors and Networks

Gateways dynamically add routing information about new

neighbors and new networks to their tables. The gateway

maintains a list of neighbor gateway addresses. When a routing

update is received, the gateway searches this list of addresses

for the Internet source address of the routing update message.

If the Internet source address of the routing update is not

contained in the list of neighbor addresses, the gateway adds

this address to the list of neighbor addresses and sets the

neighbor's connectivity status to "down." Routing updates are

not accepted from neighbors until the GGP polling mechanism has

determined that the neighbor is up.

This strategy of adding new neighbors requires that one

gateway in each pair of neighbor gateways must have the

neighbor's address configured in its tables. The newest gateway

can be given a complete list of neighbors, thus avoiding the need

to re-configure older gateways when new gateways are installed.

Gateways obtain routing information about new networks in

several steps. The gateway has a list of all the networks for

which it currently maintains routing information. When a routing

update is received, if the routing update contains information

-23-

DARPA Internet Gateway September 1982

RFC823

about a new network, the gateway adds this network to the list of

networks for which it maintains routing information. Next, the

gateway adds the new network to its distance matrix. The

distance matrix comprises the is the matrix of distances (number

of hops) to networks as reported in routing updates from the

neighbor gateways. The gateway sets the distance to all new

networks to "infinity," and then computes new routes and new

routing updates as outlined above.

4.5 Exterior Gateway Protocol

The Exterior Gateway Protocol (EGP) is used to permit other

gateways and gateway systems to pass routing information to the

DARPA Internet gateways. The use of the EGP permits the user to

perceive all of the networks and gateways as part of one total

Internet system, even though the "exterior" gateways are disjoint

and may use a routing algorithm that is different and not

compatible with that used in the "interior" gateways. The

important elements of the EGP are:

o Neighbor Acquisition

The procedure by which a gateway requests that it become a

neighbor of another gateway. This is used when a gateway

wants to become a neighbor of another in order to pass

-24-

DARPA Internet Gateway September 1982

RFC823

routing information. This includes the capability to accept

or refuse the request.

o Neighbor Up/Down

The procedure by which a gateway decides if another gateway

is up or down.

o Network Reachability Information

The facility used to pass routing and neighbor information

between gateways.

o Gateway Going Down

The ability of a gateway to inform other gateways that it is

going down and no longer has any routes to any other

networks. This permits a gateway to go down in an orderly

way without disrupting the rest of the Internet system.

A complete description of the EGP can be found in IEN-209, the

"Exterior Gateway Protocol" [10].

-25-

DARPA Internet Gateway September 1982

RFC823

5 GATEWAY SOFTWARE

The DARPA Internet Gateway runs under the MOS operating

system [9] which provides facilities for:

o Multiple processes

o Interprocess communication

o Buffer management

o Asynchronous input/output

o Shareable real-time clock

There is a MOS process for each network that the gateway is

directly connected to. A data structure called a NETBLOCK

contains variables of interest for each network and pointers to

local network routines. Network processes run common gateway

code while network-specific functions are dispatched to the

routines pointed to in the NETBLOCK. There are also processes

for gateway functions which require their own timing, such as GGP

and HMP.

5.1 Software Structure

The gateway software can be divided conceptually into three

parts: MOS Device Drivers, Network software, and Shared Gateway

software.

-26-

DARPA Internet Gateway September 1982

RFC823

5.1.1 Device Drivers

The gateway has a set of routines to handle sending and

receiving data for each type of hardware interface. There are

routines for initialization, initiation, and interruption for

both the transmit and receive sides of a device. The gateway

supports the following types of devices:

a) ACC LSI-11 1822

b) DEC IMP11a 1822

c) ACC LHDH 1822

d) ACC VDH11E

e) ACC VDH11C

f) Proteon Ring Network

g) RSRE HDLC

h) Interlan Ethernet

i) BBN Fibernet

j) ACC XQ/CP X.25 **

k) ACC XQ/CP HDH **

5.1.2 Network Software

For each connected network, the gateway has a set of eight

routines which handle local network functions. The network

routines and their functions are described briefly below.

_______________

** Planned, not yet supported.

-27-

DARPA Internet Gateway September 1982

RFC823

Up.net Perform local network initialization such as

flapping the 1822 ready line.

Sg.net Handle specific local network timing functions

such as timing out 1822 Destination Deads.

Rc.net A message has been received from the network

interface. Check for any input errors.

Wc.net A message has been transmitted to the network

interface. Check for any output errors.

Rs.net Set up a buffer (or buffers) to receive messages

on the network interface.

Ws.net Transmit a message to the network interface.

Hc.net Check the local network header of the received

message. Perform any local network protocol

tasks.

Hb.net Rebuild the local network header.

There are network routines for the following types of

networks:

o Arpanet (a,b,c,k)

o Satnet (d,e,k)

o Proteon Ring Network (f)

o Packet Radio Network (a,b,c)

o Rsre HDLC Null Network (g)

o Ethernet (h)

o Fibernet (i)

o Telenet X.25 (j) **

Note: The letters in parentheses refer to the device drivers used

_______________

** Planned, not yet supported.

-28-

DARPA Internet Gateway September 1982

RFC823

for each type of network as described in the previous section.

5.1.3 Shared Gateway Software

The internet processing of a datagram is performed by a body

of code which is shared by the network processes. This code

includes routines to check the IP header, perform IP

fragmentation, calculate the IP checksum, forward a datagram, and

implement the routing, monitoring, and error reporting protocols.

5.2 Gateway Processes

5.2.1 Network Processes

When the gateway starts up, each network process calls its

local network initialization routine and read start routine. The

read start routine sets up two maximum network size buffers for

receiving datagrams. The network process then waits for an input

complete signal from the network device driver.

When a message has been received, the MOS Operating System

signals the appropriate network process with an input complete

signal. The network process wakes up and executes the net read

-29-

DARPA Internet Gateway September 1982

RFC823

complete routine. After the message has been processed, the

network process waits for more input.

The net read complete routine is the major message

processing loop in the gateway. The following actions are

performed when a message has been received:

o Call Local Network Read Complete Routine

o Start more reads

o Check local Network Header

o Check Internet header

o Check if datagram is for the gateway

o Forward the datagram if necessary

o Send ICMP error message if necessary.

5.2.2 GGP Process

The GGP process periodically sends GGP echos to each of the

gateway's neighbors to determine neighbor connectivity, and sends

interface status messages addressed to itself to determine

network connectivity. The GGP process also sends out routing

updates when necessary. The details of the algorithms currently

implemented by the GGP process are given in Section 4.4,

Gateway-to-Gateway Protocol, and in Appendix C.

-30-

DARPA Internet Gateway September 1982

RFC823

5.2.3 HMP Process

The HMP process handles timer-based gateway statistics

collection and the periodic transmission of traps.

-31-

DARPA Internet Gateway September 1982

RFC823

APPENDIX A. GGP Message Formats

Note that the GGP protocol is currently undergoing extensive

changes to introduce the Exterior Gateway Protocol facility; this

is the vehicle needed to permit gateways in other systems to

exchange routing information with the gateways described in this

document.

Each GGP message consists of an Internet header followed by

one of the messages explained below. The values (in decimal) in

the Internet header used in a GGP message are as follows.

Version 4.

IHL Internet header length in 32-bit Words.

Type of Service 0.

Total Length Length of Internet header and data in

octets.

ID, Flags,

Fragment Offset 0.

Time to Live Time to live in seconds. This field is

decremented at least once by each

machine that processes the datagram.

Protocol Gateway Protocol = 3.

Header Checksum The 16 bit one's complement of the one's

complement sum of all 16-bit words in

the header. For computing the checksum,

the checksum field should be zero.

-32-

DARPA Internet Gateway September 1982

RFC823

Source Address The address of the gateway's interface

from which the message is sent.

Destination Address The address of the gateway to which the

message is sent.

-33-

DARPA Internet Gateway September 1982

RFC823

ROUTING UPDATE

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

!Gateway Type ! unused (0) ! ; 2 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Sequence Number ! ; 2 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! need-update ! n-distances ! ; 2 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! distance 1 ! n1-dist ! ; 2 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net11 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; bytes

! net12 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; bytes

.

.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! net1n1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; n1 nets at

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; dist 1

. ...

. ; ndist groups

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; of nets

! distance n ! nn-dist ! ; 2 bytes

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! netn1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; bytes

! netn2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; bytes

.

.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! netnnn !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; nn nets at

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; dist n

Gateway Type 12 (decimal)

Sequence Number The 16-bit sequence number used to

identify routing updates.

need-update An 8-bit field. This byte is set to 1

-34-

DARPA Internet Gateway September 1982

RFC823

if the source gateway requests a routing

update from the destination gateway, and

set to 0 if not.

n-distances An 8-bit field. The number of

distance-groups reported in this update.

Each distance-group consists of a

distance value and a number of nets,

followed by the actual net numbers which

are reachable at that distance. Not all

distances need be reported.

distance 1 hop count (or other distance measure)

which applies to this distance-group.

n1-dist number of nets which are reported in

this distance-group.

net11 1, 2, or 3 bytes for the first net at

distance "distance 1".

net12 second net

...

net1n1 etc.

-35-

DARPA Internet Gateway September 1982

RFC823

ACKNOWLEDGMENT or NEGATIVE ACKNOWLEDGMENT

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gateway Type Unused Sequence number

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gateway Type Acknowledgments are type 2. Negative

acknowledgments are type 10.

Sequence Number The 16-bit sequence number that the

gateway is acknowledging or negatively

acknowledging.

-36-

DARPA Internet Gateway September 1982

RFC823

GGP ECHO and ECHO REPLY

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gateway Type Unused

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gateway Type 8 for echo message; 0 for echo reply.

Source Address In an echo message, this is the address

of the gateway on the same network as

the neighbor to which it is sending the

echo message. In an echo reply message,

the source and destination addresses are

simply reversed, and the remainder is

returned unchanged.

-37-

DARPA Internet Gateway September 1982

RFC823

NETWORK INTERFACE STATUS

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

! Gateway Type ! unused !

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gateway Type 9

Source Address

Destination Address The address of the gateway's network

interface. The gateway can send Net

Interface Status messages to itself to

determine if it is able to send and

receive traffic on its network

interface.

-38-

DARPA Internet Gateway September 1982

RFC823

APPENDIX B. Information Maintained by Gateways

In order to implement the shortest-path routing algorithm,

gateways must maintain information about their connectivity to

networks and other gateways. This section explains the

information maintained by each gateway; this information can be

organized into the following tables and variables.

o Number of Networks

The number of networks for which the gateway maintains

routing information and to which it can forward traffic.

o Number of Neighbors

The number of neighbor gateways with which the gateway

exchanges routing information.

o Gateway Addresses

The addresses of the gateway's network interfaces.

o Neighbor Gateway Addresses

The address of each neighbor gateway's network interface

that is on the same network as this gateway.

o Neighbor Connectivity Vector

A vector of the connectivity between this gateway and each

of its neighbors.

o Distance Matrix

A matrix of the routing updates received from the neighbor

gateways.

-39-

DARPA Internet Gateway September 1982

RFC823

o Minimum Distance Vector

A vector containing the minimum distance to each network.

o Routing Updates from Non-Routing Gateways

The routing updates that would have been received from each

non-routing neighbor gateway which does not participate in

this routing strategy.

o Routing Table

A table containing, for each network, a list of the neighbor

gateways on a minimum-distance route to the network.

o Send Sequence Number

The sequence number that will be used to send the next

routing update.

o Receive Sequence Numbers

The sequence numbers that the gateway received in the last

routing update from each of its neighbors.

o Received Acknowledgment Vector

A vector indicating whether or not each neighbor has

acknowledged the sequence number in the most recent routing

update sent.

-40-

DARPA Internet Gateway September 1982

RFC823

APPENDIX C. GGP Events and Responses

The following list shows the GGP events that occur at a

gateway and the gateway's responses. The variables and tables

referred to are listed above.

o Connectivity to an attached network changes.

a. Update the Minimum Distance Vector.

b. Recompute the Routing Updates.

c. Recompute the Routing Table.

d. If any routing update has changed, send the new routing

updates to the neighbors.

o Connectivity to a neighbor gateway changes.

a. Update the Neighbor Connectivity Vector.

b. Recompute the Minimum Distance Vector.

c. Recompute the Routing Updates.

d. Recompute the Routing Table.

e. If any routing update has changed, send the new routing

updates to the neighbors.

o A Routing Update message is received.

a. Compare the Internet source address of the Routing Update

message to the Neighbor Addresses. If the address is not

on the list, add it to the list of Neighbor Addresses,

increment the Number of Neighbors, and set the Receive

Sequence Number for this neighbor to the sequence number

in the Routing Update message.

b. Compare the Receive Sequence Number for this neighbor to

the sequence number in the Routing Update message to

determine whether or not to accept this message. If the

message is rejected, send a Negative Acknowledgment

message. If the message is accepted, send an

Acknowledgment message and proceed with the following

steps.

-41-

DARPA Internet Gateway September 1982

RFC823

c. Compare the networks reported in the Routing Update

message to the Number of Networks. If new networks are

reported, enter them in the network vectors, increase the

number of networks, and expand the Distance Matrix to

account for the new networks.

d. Copy the routing update received into the appropriate row

of the Distance Matrix.

e. Recompute the Minimum Distance Vector.

f. Recompute the Routing Updates.

g. Recompute the Routing Table.

h. If any routing update has changed, send the new routing

updates to the neighbors.

o An Acknowledgment message is received.

Compare the sequence number in the message to the Send

Sequence Number. If the Send Sequence Number is

acknowledged, update the entry in the Received

Acknowledgment Vector for the neighbor that sent the

acknowledgment.

o A Negative Acknowledgment message is received.

Compare the sequence number in the message to the Send

Sequence Number. If necessary, replace the Send Sequence

Number, and retransmit the routing updates.

-42-

DARPA Internet Gateway September 1982

RFC823

REFERENCES

[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet

Program Protocol Specification," RFC791, USC/Information

Sciences Institute, September 1981.

[2] Strazisar, V., "Gateway Routing: An Implementation

Specification," IEN-30, Bolt Beranek and Newman Inc., August

1979.

[3] Strazisar, V., "How to Build a Gateway," IEN-109, Bolt

Beranek and Newman Inc., August 1979.

[4] Postel, J., "Internet Control Message Protocol - DARPA

Internet Program Protocol Specification," RFC792,

USC/Information Sciences Institute, September 1981.

[5] Postel, J., "Assigned Numbers," RFC790, USC/Information

Sciences Institute, September 1981.

[6] Littauer, B., Huang, A., Hinden, R., "A Host Monitoring

Protocol," IEN-197, Bolt Beranek and Newman Inc., September

1981.

[7] Santos, P., Chalstrom, H., Linn, J., Herman, J.,

"Architecture of a Network Monitoring, Control and

Management System," Proc. of the 5th Int. Conference on

Computer Communication, October 1980.

[8] Haverty, J., "XNET Formats for Internet Protocol Version 4,"

IEN-158, Bolt Beranek and Newman Inc., October 1980.

[9] Mathis, J., Klemba, K., Poggio, "TIU Notebook- Volume 2,

Software Documentation," SRI, May 1979.

[10] Rosen, E., "Exterior Gateway Protocol," IEN-209, Bolt

Beranek and Newman Inc., August 1982.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有