📄 rfc1582.txt
字号:
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
Meyer [Page 6]
RFC 1582 Demand RIP February 1994
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.
Meyer [Page 7]
RFC 1582 Demand RIP February 1994
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
another next hop router) while the datagram is in a queue,
resulting in the queue being flushed and the datagram
discarded.
o In cases where the method of transport is not guaranteed, for
example with PPP where there is no acknowledgement and
retransmission of HDLC frames, a corrupted frame will result in
the loss of the datagram.
2.5 Guaranteeing delivery of Routing Updates
To guarantee delivery of routing updates on the WAN an
acknowledgement and retransmission scheme MUST be used:
o Send a routing update to a next hop router on the WAN.
o The other router responds with an acknowledgement packet.
The original router receives the acknowledgement.
o Otherwise the original router retransmits the update until an
acknowledgement is received.
Retransmission timer values are covered in section 7.
In cases where the routing database is modified before an
acknowledgement is received a new routing update with an
updated sequence number is sent out. If an acknowledgement for
the old routing update is received it is ignored.
o A router only updates its routing database when it receives a
complete update, which may consist of several fragments. Each
fragment is individually acknowledged.
The above mechanism caters for cases where the datagram is lost
because of a frame error or is discarded because of an over-full
Meyer [Page 8]
RFC 1582 Demand RIP February 1994
queue. The routing update and acknowledgement will eventually both
get through.
In cases where the circuit manager cannot establish a connection, a
mechanism is provided to allow the circuit manager to inform the
routing task of the failure to make a connection so that it can
suppress retransmissions until a circuit becomes available.
2.6 The Routing Database
A requirement of using triggered updates for propagating routing
information is that NO routing information ever gets LOST or
DISCARDED.
The routing database MUST adopt one of the following strategies:
o It must keep ALL alternative routing information it learns from
any routing updates from the LAN and the WAN, so that if the
best route disappears an alternative route (if available) can
replace it as the new best route.
o If the amount of memory this consumes is problematic the routing
application must keep SOME alternative routing information - say
a best route and two alternatives.
If the router ever has to discard routing information about a
route it should note the fact. If the routes that have been
kept disappear because they have become unreachable, the router
MUST issue a request on all interfaces to try and obtain
discarded alternatives.
It is recommended that the request is issued BEFORE all routes
to a destination have been lost.
Entries in the routing database can either be permanent or temporary.
Entries learned from broadcasts on LANs are temporary. They will
expire if not periodically refreshed by further broadcasts.
Entries learned from a triggered response on the WAN are 'permanent'.
They MUST not time out in the normal course of events. The entries
state MUST be changed to 'temporary' by the following events:
o The arrival of a routing update containing the entry set to
unreachable.
The normal hold down timer MUST be started, after which the
entry disappears from the routing database.
Meyer [Page 9]
RFC 1582 Demand RIP February 1994
o The arrival of a routing update with the entry absent.
If the hold down timer is not already running, the entry MUST be
set to unreachable and the hold down timer started.
o A message sent from the circuit manager, to indicate that it
failed to make a connection in normal running.
The routing table MUST be scanned for all routes via that next
hop router. Aging of these routing entries MUST commence. If
the aging timer expires the entry MUST be set to unreachable and
the hold down timer started. If the hold down timer expires the
entry disappears from the routing database.
o If the interface goes down, the circuit manager should indicate
that all circuits on that interface have gone down.
Database timer values are covered in section 7.
2.7 New Packet Types
To support triggered updates, three new packet types MUST be
supported:
TRIGGERED REQUEST
A request to the responding system to send all
appropriate elements in its routing database.
A triggered request is retransmitted at periodic
intervals until a triggered response is received.
Routing requests are transmitted in the following
circumstances:
o Firstly when the router is powered on.
o Secondly when the circuit manager indicates a
destination has been in an unreachable (circuit down)
state for an extended period and changes to a
reachable (circuit up) state.
o Thirdly in the event of all routing update fragments
failing to arrive within a set period.
o It may also send triggered requests at other times to
compensate for discarding non-optimal routing
information.
Meyer [Page 10]
RFC 1582 Demand RIP February 1994
TRIGGERED RESPONSE
A message containing all appropriate elements of the
routing database. An appropriate element is an entry
NOT learned from the interface to which the routing
information is being sent out. This is known as "split
horizon".
Stability is improved by adding "poisoned reverse" on
routes learned from a destination. This consists of also
including some routes learned from a destination in
routing updates sent back to that destination, but
setting the routes as unreachable. A route is only
poisoned if it is the best route (rather than an inferior
alternative route) in the database.
A triggered response message may be sent in response to a
triggered request, or it may be an update message issued
because of a change in the routing database.
A triggered response message MUST be sent in response to
a triggered request message even if there are no routes
to propagate. This would be the case for a host which
had a WAN interface only, but which wished to run the
triggered update protocol.
A triggered response is retransmitted at periodic
intervals until a triggered acknowledgement is received.
TRIGGERED ACKNOWLEDGEMENT
A message sent in response to every triggered response
packet received.
Triggered response and triggered acknowledgement packets MUST contain
additional fields for a sequence number, fragment number and number
of fragments.
If a triggered request or response is not acknowledged after 10
retransmissions, routes to the destination should be marked as
unreachable for the duration of a hold down timer before being
deleted.
The destination should then be polled at a lower frequency using
triggered request packets. When a triggered response is received,
the router should prime the next hop router my sending its routing
database through triggered response packets.
Meyer [Page 11]
RFC 1582 Demand RIP February 1994
Strictly speaking polling should occur indefinitely to guarantee
database integrity. However the administrator MAY wish the router to
cease polling after a few attempts believing that the lack of
response is due to a mis-configuration of the next hop router. The
destination should be marked as NOT supporting the mechanism and no
further routing messages should be sent to that destination.
Before marking the destination as not supporting the mechanism, at
least 5 triggered request polls (without acknowledgement) should be
sent.
If a destination marked as not supporting the mechanism, subsequently
sends a valid 'triggered' message, the destination should be marked
as supporting the mechanism once more (to allow for the next hop
router's configuration being changed). It should be sent a triggered
request and a triggered response to obtain and propagate up-to-date
routing information.
2.8 Fragmentation
If a routing update is sufficiently large, the information MUST be
fragmented over several triggered response packets:
o Each fragment MUST be individually acknowledged with a triggered
acknowledgement packet.
The sender of the routing update MUST periodically retransmit
fragments which have not been acknowledged (or until the
destination is marked as not supporting the mechanism).
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -