Network Working Group C. Hedrick
Request for Comments: 1058 Rutgers University
June 1988
Routing Information Protocol
Status of this Memo
This RFC describes an existing protocol for exchanging routing
information among gateways and other hosts. It is intended to be
ud as a basis for developing gateway software for u in the
Internet community. Distribution of this memo is unlimited.
Table of Contents
1. Introduction 2
1.1. Limitations of the protocol 4
1.2. Organization of this document 4
2. Distance Vector Algorithms 5
2.1. Dealing with changes in topology 11
2.2. Preventing instability 12
2.2.1. Split horizon 14
2.2.2. Triggered updates 15
3. Specifications for the protocol 16
3.1. Message formats 18
3.2. Addressing considerations 20
3.3. Timers 23
3.4. Input processing 24
3.4.1. Request 25
3.4.2. Respon 26
3.5. Output Processing 28
3.6. Compatibility 31
4. Control functions 31
Overview
This memo is intended to do the following things:
- Document a protocol and algorithms that are currently in
wide u for routing, but which have never been formally
documented.
- Specify some improvements in the algorithms which will
improve stability of the routes in large networks. The
improvements do not introduce any incompatibility with
existing implementations. They are to be incorporated into
Hedrick [Page 1]
RFC 1058 Routing Information Protocol June 1988
all implementations of this protocol.
- Suggest some optional features to allow greater
configurability and control. The features were developed
specifically to solve problems that have shown up in actual
u by the NSFnet community. However, they should have more
general utility.
The Routing Information Protocol (RIP) described here is looly
bad on the program "routed", distri
buted with the 4.3 Berkeley
Software Distribution. However, there are veral other
implementations of what is suppod to be the same protocol.
Unfortunately, the various implementations disagree in various
details. The specifications here reprent a combination of features
taken from various implementations. We believe that a program
designed according to this document will interoperate with routed,
and with all other implementations of RIP of which we are aware.
Note that this description adopts a different view than most existing
implementations about when metrics should be incremented. By making
a corresponding change in the metric ud for a local network, we
have retained compatibility with other existing implementations. See
ction 3.6 for details on this issue.
1. Introduction
This memo describes one protocol in a ries of routing protocols
bad on the Bellman-Ford (or distance vector) algorithm. This
algorithm has been ud for routing computations in computer networks
since the early days of the ARPANET. The particular packet formats
and protocol described here are bad on the program "routed", which
is included with the Berkeley distribution of Unix. It has become a
de facto standard for exchange of routing information among gateways
and hosts. It is implemented for this purpo by most commercial
vendors of IP gateways. Note, however, that many of the vendors
have their own protocols which are ud among their own gateways.
This protocol is most uful as an "interior gateway protocol". In a
nationwide network such as the current Internet, it is very unlikely
that a single routing protocol will ud for the whole network.
Rather, the network will be organized as a collection of "autonomous
systems". An autonomous system will in general be administered by a
single entity, or at least will have some reasonable degree of
technical and administrative control. Each autonomous system will
have its own routing technology. This may well be different for
different autonomous systems. The routing protocol ud within an
autonomous system is referred to as an interior gateway protocol, or
"IGP". A parate protocol is ud to interface among the autonomous
Hedrick [Page 2]
RFC 1058 Routing Information Protocol June 1988
systems. The earliest such protocol, still ud in the Internet, is
"EGP" (exterior gateway protocol). Such protocols are now usually
referred to as inter-AS routing protocols. RIP was designed to work
guanjia with moderate-size networks using reasonably homogeneous technology.
Thus it is suitable as an IGP for many campus and for regional
networks using rial lines who speeds do not vary widely. It is
not intended for u in more complex environments. For more
information on the context int
o which RIP is expected to fit, e
Braden and Postel [3].
RIP is one of a class of algorithms known as "distance vector
algorithms". The earliest description of this class of algorithms
known to the author is in Ford and Fulkerson [6]. Becau of this,
they are sometimes known as Ford-Fulkerson algorithms. The term
Bellman-Ford is also ud. It comes from the fact that the
formulation is bad on Bellman's equation, the basis of "dynamic
programming". (For a standard introduction to this area, e [1].)
The prentation in this document is cloly bad on [2]. This text
contains an introduction to the mathematics of routing algorithms.
It describes and justifies veral variants of the algorithm
prented here, as well as a number of other related algorithms. The
basic algorithms described in this protocol were ud in computer
安全保卫工作方案
routing as early as 1969 in the ARPANET. However, the specific
ancestry of this protocol is within the Xerox network protocols. The
PUP protocols (e [4]) ud the Gateway Information Protocol to
exchange routing information. A somewhat updated version of this
海棠秋
protocol was adopted for the Xerox Network Systems (XNS)
architecture, with the name Routing Information Protocol. (See [7].)
Berkeley's routed is largely the same as the Routing Information
Protocol, with XNS address replaced by a more general address
format capable of handling IP and other types of address, and with
routing updates limited to one every 30 conds. Becau of this
similarity, the term Routing Information Protocol (or just RIP) is
ud to refer to both the XNS protocol and the protocol ud by
routed.
RIP is intended for u within the IP-bad Internet. The Internet
is organized into a number of networks connected by gateways. The
networks may be either point-to-point links or more complex networks
such as Ethernet or the ARPANET. Hosts and gateways are prented
with IP datagrams addresd to some host. Routing is the method by
which the host or gateway decides where to nd the datagram. It may
be able to nd the datagram directly to the destination, if that
destination is on one of the networks that are directly connected to
the host or gateway. However, the interesting ca is when the
destination is not directly reachable. In this ca, the host or
gateway attempts to nd the datagram to a gateway that is nearer the
destination. The goal of a routing protocol is very simple: It is to
Hedrick [Page 3]
RFC 1058 Routing Information Protocol June 1988
supply the information that is needed to do routing.
1.1. Limitations of the protocol
This protocol does not solve every possible routing problem. As
mentioned above, it is primary intended for u as an IGP, in
reasonably homogeneous networks of moderate size
. In addition, the
following specific limitations should be mentioned:
- The protocol is limited to networks who longest path
involves 15 hops. The designers believe that the basic
protocol design is inappropriate for larger networks. Note
that this statement of the limit assumes that a cost of 1
is ud for each network. This is the way RIP is normally
configured. If the system administrator choos to u
larger costs, the upper bound of 15 can easily become a
problem.查阅资料
- The protocol depends upon "counting to infinity" to resolve
certain unusual situations. (This will be explained in the
next ction.) If the system of networks has veral
hundred networks, and a routing loop was formed involving
all of them, the resolution of the loop would require
either much time (if the frequency of routing updates were
limited) or bandwidth (if updates were nt whenever
changes were detected). Such a loop would consume a large
amount of network bandwidth before the loop was corrected.
We believe that in realistic cas, this will not be a
problem except on slow lines. Even then, the problem will
be fairly unusual, since various precautions are taken that
should prevent the problems in most cas.
- This protocol us fixed "metrics" to compare alternative
routes. It is not appropriate for situations where routes
need to be chon bad on real-time parameters such a
measured delay, reliability, or load. The obvious
extensions to allow metrics of this type are likely to
introduce instabilities of a sort that the protocol is not
designed to handle.
1.2. Organization of this document
The main body of this document is organized into two parts, which
occupy the next two ctions:
2 A conceptual development and justification of distance vector
algorithms in general.
Hedrick [Page 4]
RFC 1058 Routing Information Protocol June 1988
3 The actual protocol description.团支部换届
Each of the two ctions can largely stand on its own. Section 2
attempts to give an informal prentation of the mathematical
underpinnings of the algorithm. Note that the prentation follows a
"spiral" method. An initial, fairly simple algorithm is described.
Then refinements are added to it in successive ctions. Section 3
is the actual protocol description. Except where specific references
are made to ction 2, it should be possible to implement RIP
entirely from the specifications given in ction 3.
2. Distance Vector Algorithms
文绉绉 Routing is the task of finding a path from a nder to a desired
destination. In the IP "Catenet model" this reduces primarily to a
matter of finding gateways between
networks. As long as a message
remains on a single network or subnet, any routing problems are
solved by technology that is specific to the network. For example,
the Ethernet and the ARPANET each define a way in which any nder
can talk to any specified destination within that one network. IP
routing comes in primarily when messages must go from a nder on one
such network to a destination on a different one. In that ca, the
message must pass through gateways connecting the networks. If the
networks are not adjacent, the message may pass through veral
intervening networks, and the gateways connecting them. Once the
message gets to a gateway that is on the same network as the
destination, that network's own technology is ud to get to the
destination.
Throughout this ction, the term "network" is ud generically to
cover a single broadcast network (e.g., an Ethernet), a point to
point line, or the ARPANET. The critical point is that a network is
treated as a single entity by IP. Either no routing is necessary (as
with a point to point line), or that routing is done in a manner that
is transparent to IP, allowing IP to treat the entire network as a
single fully-connected system (as with an Ethernet or the ARPANET).
Note that the term "network" is ud in a somewhat different way in
discussions of IP addressing. A single IP network number may be
assigned to a collection of networks, with "subnet" addressing being
ud to describe the individual networks. In effect, we are using
the term "network" here to refer to subnets in cas where subnet
addressing is in u.
A number of different approaches for finding routes between networks
are possible. One uful way of categorizing the approaches is on
the basis of the type of information the gateways need to exchange in
order to be able to find routes. Distance vector algorithms are
bad on the exchange of only a small amount of information. Each
Hedrick [Page 5]
RFC 1058 Routing Information Protocol June 1988
entity (gateway or host) that participates in the routing protocol is
assumed to keep information about all of the destinations within the
system. Generally, information about all entities connected to one
network is summarized by a single entry, which describes the route to
all destinations on that network. This summarization is possible
becau as far as IP is concerned, routing within a network is
invisible. Each entry in this routing databa includes the next
gateway to which datagrams destined for the entity should be nt.
In addition, it includes a "metric" measuring the total distance to
the entity. Distance is a somewhat generalized concept, which may
自信的名言警句
cover the time delay in getting messages to the entity, the dollar
cost of nding messages to it,
etc. Distance vector algorithms get
their name from the fact that it is possible to compute optimal
routes when the only information exchanged is the list of the
distances. Furthermore, information is only exchanged among entities
that are adjacent, that is, entities that share a common network.
Although routing is most commonly bad on information about
networks, it is sometimes necessary to keep track of the routes to
individual hosts. The RIP protocol makes no formal distinction
between networks and hosts. It simply describes exchange of
information about destinations, which may be either networks or
hosts. (Note however, that it is possible for an implementor to
choo not to support host routes. See ction 3.2.) In fact, the
mathematical developments are most conveniently thought of in terms
of routes from one host or gateway to another. When discussing the
algorithm in abstract terms, it is best to think of a routing entry
for a network as an abbreviation for routing entries for all of the
entities connected to that network. This sort of abbreviation makes
n only becau we think of networks as having no internal
structure that is visible at the IP level. Thus, we will generally
assign the same distance to every entity in a given network.
We said above that each entity keeps a routing databa with one
entry for every possible destination in the system. An actual
implementation is likely to need to keep the following information
about each destination:
- address: in IP implementations of the algorithms, this
台式机无法开机 will be the IP address of the host or network.
- gateway: the first gateway along the route to the
destination.
- interface: the physical network which must be ud to reach
the first gateway.
- metric: a number, indicating the distance to the
Hedrick [Page 6]
RFC 1058 Routing Information Protocol June 1988
destination.
- timer: the amount of time since the entry was last updated.
In addition, various flags and other internal information will
probably be included. This databa is initialized with a
description of the entities that are directly connected to the
system. It is updated according to information received in messages
from neighboring gateways.
The most important information exchanged by the hosts and gateways is
that carried in update messages. Each entity that participates in
the routing scheme nds update messages that describe the routing
databa as it currently exists in that entity. It is possible to
maintain optimal routes for the entire system by using only
information obtained from neighboring entities. The algorithm ud
for that will be described in the next ction.
As we mentioned above, the purpo of routing is to find a
