RFC1582 - Extensions to RIP to Support Demand Circuits( 二 )


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

推荐阅读