📄 rfc1582.txt
字号:
Network Working Group G. Meyer
Request for Comments: 1582 Spider Systems
Category: Standards Track February 1994
Extensions to RIP to Support Demand Circuits
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Running routing protocols on connection oriented Public Data
Networks, for example X.25 packet switched networks or ISDN, can be
expensive if the standard form of periodic broadcasting of routing
information is adhered to. The high cost arises because a connection
has to all practical intents and purposes be kept open to every
destination to which routing information is to be sent, whether or
not it is being used to carry user data.
Routing information may also fail to be propagated if the number of
destinations to which the routing information is to be sent exceeds
the number of channels available to the router on the Wide Area
Network (WAN).
This memo defines a generalized modification which can be applied to
Bellman-Ford (or distance vector) algorithm information broadcasting
protocols, for example IP RIP, Netware RIP or Netware SAP, which
overcomes the limitations of the traditional methods described above.
The routing protocols support a purely triggered update mechanism on
demand circuits on WANs. The protocols run UNMODIFIED on LANs or
fixed point-to-point links.
Routing information is sent on the WAN when the routing database is
modified by new routing information received from another interface.
When this happens a (triggered) update is sent to a list of
destinations on other WAN interfaces. Because routing protocols are
datagram based they are not guaranteed to be received by the peer
router on the WAN. An acknowledgement and retransmission mechanism
is provided to ensure that routing updates are received.
Meyer [Page 1]
RFC 1582 Demand RIP February 1994
The WAN circuit manager advises the routing applications on the
reachability and non-reachability of destinations on the WAN.
Acknowledgements
I would like to thank colleagues at Spider, in particular Richard
Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM), Martha
Steenstrup (BBN), and members of the RIP-2 working group of the IETF
for stimulating discussions and comments which helped to clarify this
memo.
Conventions
The following language conventions are used in the items of
specification in this document:
o MUST -- the item is an absolute requirement of the specification.
MUST is only used where it is actually required for interoperation,
not to try to impose a particular method on implementors
where not required for interoperability.
o SHOULD -- the item should be followed for all but exceptional cir-
cumstances.
o MAY or optional -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
The words "should" and "may" are also used, in lower case, in their
more ordinary senses.
Table of Contents
1. Introduction ........................................... 3
2. Running a routing Protocol on the WAN .................. 4
2.1. Overview ......................................... 4
2.2. Presumption of Reachability ...................... 6
2.3. WAN Router list .................................. 7
2.4. Triggered Updates and Unreliable Delivery ........ 8
2.5. Guaranteeing delivery of Routing Updates ......... 8
2.6. The Routing Database ............................. 9
2.7. New Packet Types ................................. 10
2.8. Fragmentation .................................... 12
2.9. Preventing Queue Overload ........................ 13
3. IP Routing Information Protocol Version 1 .............. 13
4. IP Routing Information Protocol Version 2 .............. 16
5. Netware Routing Information Protocol ................... 17
6. Netware Service Advertising Protocol ................... 20
7. Timers ................................................. 24
Meyer [Page 2]
RFC 1582 Demand RIP February 1994
7.1. Database Timer ................................... 24
7.2. Retransmission Timer ............................. 25
7.3. Reassembly Timer ................................. 26
8. Implementation Considerations ...........................27
9. Security Considerations ................................ 27
10. References ............................................. 28
11. Author's Address ....................................... 29
1. Introduction
Routers are used on connection oriented networks, such as X.25 packet
switched networks and ISDN networks, to allow potential connectivity
to a large number of remote destinations. Circuits on the Wide Area
Network (WAN) are established on demand and are relinquished when the
traffic subsides. Depending on the application, the connection
between any two sites for user data might actually be short and
relatively infrequent.
Practical experience of routing shows that periodic 'broadcasting' of
routing updates on the WAN is unsatisfactory on several counts:
o Running a routing protocol like RIP is expensive if the standard
form of transmitting routing information to every next hop router
every 30 seconds is adhered to. The more routers there are
wishing to exchange information the worse the problem. If there
are N routers on the WAN, N * (N - 1) routing updates are sent over
N * (N - 1)/2 connections every broadcast period.
The expense arises because a circuit has to be kept open to each
destination to which routing information is to be sent. Routing
updates are sufficiently frequent that little benefit is obtainable
on most networks by attempting to set up a call purely for
the duration of the routing update. (There are often minimum call
charges, or there is a charge to set up a call irrespective of
what data is sent.)
The option of reducing the 'broadcast' frequency, while reducing
the cost, would make the system less responsive.
o The number of networks to be connected (N) on the WAN can easily
exceed the number of simultaneous calls (M) which the interface
can support. If this happens the routing 'broadcast' will only
reach M next hop routers, and (N - M) next hop routers will not
receive the routing update.
A basic rate ISDN interface can support 2 simultaneous calls, and
even the number of logical channels most users subscribe to on an
X.25 network is not large. There is no fundamental reason why
Meyer [Page 3]
RFC 1582 Demand RIP February 1994
routing protocols should restrict the user to routing between so
few sites.
o Since there is no broadcast facility on the WAN, 'broadcasting' of
routing information actually consists of sending the updates
separately to all known locations. This means that N routing
updates are queued for transmission on the WAN link (in addition
to any data which might be queued).
Routers take a pragmatic view on queuing datagrams for the WAN.
If the queue length gets too long, so that datagrams at the end of
the queue would take too long be transmitted in a reasonable time
(say 1 to 2 seconds) the router may start discarding them. On an
X.25 network, with slow line speeds (perhaps 9600 baud), it may
not take too many routing updates to fulfill this condition if the
link is also actively being used to carry user data.
This memo addresses all the above problems.
The approach taken is to modify the routing protocols so as to send
information on the WAN only when there has been an update to the
routing database OR a change in the reachability of a next hop router
is indicated by the task which manages connections on the WAN.
Because datagrams are not guaranteed to get through on all WAN media,
an acknowledgement and retransmission system is required to provide
reliability.
This memo describes the modifications required for Bellman-Ford (or
distance vector) algorithm information broadcasting protocols, such
as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN. The protocols
run unmodified on Local Area Networks (LANs) or fixed point-to-point
links, and so interoperate transparently with implementations
adhering to the original specifications.
2. Running Routing Protocols on the WAN
2.1 Overview
Multiprotocol routers are used on connection oriented Wide Area
Networks (WANs), such as X.25 packet switched networks and ISDN
networks, to interconnect LANs. By using the multiplexing properties
of the underlying WAN technology, several LANs can be interconnected
simultaneously through a single physical interface on the router.
A circuit manager provides an interface between the connectionless
network layers (IP, IPX, CLNP etc) and the connection oriented WAN
(X.25 or ISDN). Figure 1 shows a schematic representative stack
Meyer [Page 4]
RFC 1582 Demand RIP February 1994
showing the relationship between routing protocols, the network
layers, the circuit manager and the connection oriented WAN.
-------------- --------- ---------
| RIP | | RIP | | SAP |
-------------- --------- ---------
| | |
-------------- | |
| UDP | | |
-------------- | |
| | |
-------------- ----------------
| IP | | IPX |
-------------- ----------------
| |
-------------------------------------------
| Circuit Manager |
-------------------------------------------
||||||||||
||||||||||
---------------------------
| Connection Oriented |
| WAN stack |
---------------------------
A WAN circuit manager will support a variety of network layer
protocols, on its upper interface. On its lower interface, it
may support one or more subnetworks. A subnetwork may support a
number of Virtual Circuits.
Figure 1. Representative Multiprotocol Router stack
The router has a translation table which relates the network layer
address of the next hop router to the physical address used to
establish a Virtual Circuit (VC) to it. Datagrams may be
encapsulated in a header to distinguish the network layer protocol
[5].
The circuit manager takes datagrams from the connectionless network
layer protocols and (if one is not currently available) opens a VC to
the next hop router. A VC can carry all traffic between two end-
point routers for a given network layer protocol (or with appropriate
encapsulation all network layer protocols). An idle timer is used to
close the VC when the datagrams stop arriving at the circuit manager.
Running routing protocols on the WAN has traditionally consisted of
making small modifications to the methods used on LANs. Where
Meyer [Page 5]
RFC 1582 Demand RIP February 1994
routing information would be broadcast periodically on a LAN
interface, it is converted to a series of periodic updates sent to a
list of addresses on the WAN.
This memo targets two areas:
o Eliminating the overkill inherent in periodic transmission of
routing updates.
o Overcoming the bandwidth limitations on the WAN: the number of
simultaneous VCs to next hop routers and restricted data
throughput which the WAN link can support.
The first of these is overcome by transmitting routing updates
(called routing responses) only when required:
o Firstly, when a specific request for a routing update has been
received.
o Secondly, when the routing database is modified by new
information from another interface.
Update information received in this way is not normally
propagated on other interfaces immediately, but is delayed for a
few seconds to allow information from several updates to be
grouped.
o Thirdly, when the circuit manager indicates that a destination
has changed from an unreachable (circuit down) to a reachable
(circuit up) state.
Because of the inherent unreliability of a datagram based system,
both routing requests and routing responses require acknowledgement,
and retransmission in the event of NOT receiving an acknowledgement.
To overcome the bandwidth limitations the routing application can
perform a form of self-imposed flow control, to spread routing
updates out over a period of time.
2.2 Presumption of Reachability
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -