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


(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
If a routing update is received from a next hop router on the WAN,
entries in the update are thereafter always considered to be
reachable, unless proven otherwise:
o If in the normal course of routing datagrams, the circuit manager
fails to establish a connection to the next hop router, it
notifies the routing application that the next hop router is not
reachable through an internal circuit down message.
The routing application then goes through a process of timing out
database entries to make them unreachable in the routing sense.
o If the circuit manager is subsequently able to establish a
connec tion to the next hop router, it will notify the routing
applica tion that the next hop router is reachable through an
internal circuit up message.
The routing application will then exchange messages with the next
hop router so as to re-prime their respective routing databases
with up-to-date information.
Handling of circuit up and circuit down messages requires that the
circuit manager takes responsibility for establishing (or
reestablishing) the connection in the event of a next hop router
becoming unreachable. A description of the processes the circuit
manager adopts to perform this task is outside the scope of this
memo.
2.3 WAN Router list
The routing task MAY be provided with a list of routers to send
routing updates to on the WAN. It will comprise of the logical
addresses of next hop routers for which the router has a logical to
physical address mapping. Entries in the list SHOULD be categorized
(on a per-peer basis) as follows:
o Running the standard routing protocol, namely transmitting
updates periodically with the packet formats used in LAN
broadcasts.
This option is supported to allow interoperability with existing
routing implementations, and might also be appropriate if some
of the destinations are using Permanent Virtual Circuits (PVCs)
rather than SVCs.
o Running the triggered update routing protocol proposed in this
memo.
Omitting an address from both of these categories is equivalent to
not running the routing protocols.
If routing packets arrive from a destination not supporting the
appropriate variant they MUST be discarded.
2.4 Triggered Updates and Unreliable Delivery
If triggered update information is sent to next hop routers on the
WAN only once it can fail to arrive for one of the following reasons:
o A free VC resource might not be available, because of a
restricted number of X.25 logical channels or ISDN B-channels.
o The transmit queue might be full - requiring the datagram to be
discarded.
o The VC might be pre-empted (in favour of establishing a VC to

推荐阅读