As per Relevance of the word acknowledge, we have this rfc below:
Network Working Group G.
Request for Comments: 2091
Category: Standards Track S.
January 1997
Triggered Extensions to RIP to Support Demand
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document defines a modification which can be applied
Bellman-Ford (distance vector) algorithm information
protocols - for example IP RIP, Netware RIP or Netware SAP -
makes it feasible to run them on connection oriented Public
Networks
This proposal has a number of efficiency advantages over the
RIP proposal (RFC 1582).
The authors wish to thank Richard Edmonstone of Shiva,
Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of
for many comments and suggestions which improved this effort
The following language conventions are used in the items
specification in this document
o MUST -- the item is an absolute requirement of the specification
MUST is only used where it is actually required
interoperation, not to try to impose a particular method
implementors where not required for interoperability
o SHOULD -- the item should be followed for all but
circumstances
Meyer & Sherry Standards Track [Page 1]
RFC 2091 Trigger RIP January 1997
o MAY or optional -- the item is truly optional and may be
or ignored according to the needs of the implementor
The words "should" and "may" are also used, in lower case,
their more ordinary senses
Table of
1. Introduction ........................................... 2
2. Overview ............................................... 3
3. The Routing Database ................................... 5
3.1. Presumption of Reachability ...................... 6
3.2. Alternative Routes ............................... 6
3.3. Split Horizon with Poisoned Reverse .............. 7
3.4. Managing Updates ................................. 7
3.5. Retransmissions .................................. 7
4. New Packet Types ....................................... 8
4.1. Update Request (9) ............................... 9
4.2. Update Response (10) ............................. 9
4.3. Update Acknowledge (11) .......................... 10
5. Packet Formats ......................................... 10
5.1. Update Header .................................... 10
5.2. IP Routing Information Protocol Version 1 ........ 11
5.3. IP Routing Information Protocol Version 2 ........ 11
5.4. Netware Routing Information Protocol ............. 12
5.5. Netware Service Advertising Protocol ............. 12
6. Timers ................................................. 17
6.1. Database Timer ................................... 17
6.2. Hold Down Timer .................................. 17
6.3. Retransmission Timer ............................. 18
6.4. Over-subscription Timer .......................... 18
7. Security Considerations ................................ 19
Appendix A - Implementation Suggestion .................... 20
References ................................................ 21
Authors' Addresses ........................................ 22
1.
Routers are used on connection oriented networks, such as X.25
switched networks and ISDN networks, to allow potential
to a large number of remote destinations. Circuits on the Wide
Network (WAN) are established on demand and are relinquished when
traffic subsides. Depending on the application, the
between any two sites for user data might actually be short
relatively infrequent
Meyer & Sherry Standards Track [Page 2]
RFC 2091 Trigger RIP January 1997
Periodic broadcasting by Bellman-Ford (distance vector)
information broadcasting protocols IP RIP [1], IP RIP V2 [2]
Netware RIP and SAP [3] generally prevents WAN circuits from
closed. Even on fixed point-to-point links the overhead of
transmission of RIP - and even more so SAP broadcasts - can
interrupt normal data transfer simply through the quantity
information which hits the line every 30 or 60 seconds
To overcome these limitations, this specification modifies
distance vector protocols so as to send information on the WAN
when there has been an update to the routing database OR a change
the reachability of a next hop router is indicated by the task
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
reliability
The protocols run unmodified on Local Area Networks (LANs) and
interoperate transparently with implementations adhering to
original specifications
This proposal differs from Demand RIP [4] conceptually as follows
o If a router has exchanged all routing information with its
and some routing information subsequently changes only the
information is sent to the partner
o The receiver of routes is able to apply all changes
upon receiving information from a partner
These differences lead to further reduced routing traffic and
require less memory than Demand RIP [4]. Demand RIP also has
upper limit of 255 fragments in an update which is lifted
Triggered RIP (which does not use fragmentation).
2.
Multiprotocol routers are used on connection oriented Wide
Networks (WANs), such as X.25 packet switched networks and
networks, to interconnect LANs. By using the multiplexing
of the underlying WAN technology, several LANs can be
simultaneously through a single physical interface on the router
Meyer & Sherry Standards Track [Page 3]
RFC 2091 Trigger RIP January 1997
A circuit manager provides an interface between the
network layers, IP and IPX, and the connection oriented WAN, X.25,
ISDN etc. Figure 1 shows a schematic representative stack
the relationship between routing protocols, the network layers,
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
layer protocols, on its upper interface. On its lower interface
it may support one or more subnetworks. A subnetwork may
a number of Virtual Circuits
Figure 1. Representative Multiprotocol Router
The router has a translation table which relates the network
address of the next hop router to the physical address used
establish a Virtual Circuit (VC) to it
The circuit manager takes datagrams from the connectionless
layer protocols and (if one is not currently available) opens a VC
the next hop router. A VC can carry all traffic between two end
point routers for a given network layer protocol (or with
encapsulation all network layer protocols). An idle timer (or
other mechanism) is used to close the VC when the datagrams
arriving at the circuit manager
Meyer & Sherry Standards Track [Page 4]
RFC 2091 Trigger RIP January 1997
If the circuit manager has data to forward (whether user data OR
routing update) and fails to obtain a VC it informs the
application that the destination is unreachable (circuit down).
circuit manager is then expected to perform whatever is necessary
recover the link. Once successful, it informs the
application (circuit up).
In Triggered RIP, routing updates are only transmitted on the
when required
1 When a specific request for a routing update has been received
2 When the routing database is modified by new information
another interface
3 When the circuit manager indicates that a destination has
from an unreachable (circuit down) to a reachable (circuit up
state
4 And also when a unit is first powered on to ensure that at
one update is sent. This can be thought of as a transition
circuit down to circuit up. It MAY contain no routes or services
and is used to flush routes or services from the peer's database
In cases 1,3 and 4 the full contents of the database is sent.
case 2 only the latest changes are sent
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
3. The Routing
Entries in the routing database can either be permanent or temporary
Entries learned from broadcasts on LANs are temporary. They
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.
events can cause these routes to time out
Meyer & Sherry Standards Track [Page 5]
RFC 2091 Trigger RIP January 1997
3.1 Presumption of
If a routing update is received from a next hop router on the WAN
entries in the update are thereafter always considered to
reachable, unless proven otherwise
o If in the normal course of routing datagrams, the circuit
fails to establish a connection to the next hop router,
notifies the routing application that the next hop router is
reachable through an internal circuit down message
The database entries are first marked as temporary and
normally; Some implementations may choose to omit this
aging step. The routing application then marks the
database entries as unreachable for a hold down period (the
120 second RIP hold down timer).
o If the circuit manager is subsequently able to establish
connection to the next hop router, it will notify the
application that the next hop router is reachable through
internal circuit up message
The routing application will then exchange messages with the
hop router so as to re-prime their respective routing
with up-to-date information
The next hop router may also be marked as unreachable if an
number of retransmissions of an update go unacknowledged (see
6.3).
Handling of circuit up and circuit down messages requires that
circuit manager takes responsibility for establishing (or re
establishing) the connection in the event of a next hop
becoming unreachable. A description of the processes the
manager adopts to perform this task is outside the scope of
document
3.2 Alternative
A requirement of using Triggered RIP for propagating
information is that NO routing information ever gets LOST
DISCARDED. This means that all alternative routes SHOULD
retained
It MAY be possible to operate with a sub-set of all
routes, but this adds complexity to the protocol - which is
covered in this document
Meyer & Sherry Standards Track [Page 6]
RFC 2091 Trigger RIP January 1997
3.3 Split Horizon with Poisoned
The rules for Split Horizon with Poisoned Reverse MUST be used
determine whether and/or how a route is advertised on an
running this protocol
Split Horizon consists of omitting routes learned from a peer
sending updates back to that peer. With Poisoned Reverse instead
omitting those routes, they are advertised as unreachable (
the metric to infinity).
A route is only poisoned if it is the best route (rather than
inferior alternative route) in the database
Poison Reverse is necessary because a router may be advertising
route to a network to its partner and then later learn a better
for the same network from the partner. Without Poison Reverse
partner will not know to discard the inferior route learned from
first router
3.4 Managing Routing
The routing database SHOULD be considered to be a sequence
elements ordered by the time it was last updated. If there is
change in the best route (i.e. a new route is added or a route'
metric has changed), the route is reordered and given a new
sequence number
Sending updates to a peer consists of running through the
from the oldest entry to the newest entry. Once an entry has
sent and acknowledged it is generally never resent. As new
information arrives, only the new information is sent
3.5
Handling retransmission of updates is simplest if updates
restricted to never having more than one un-acknowledged
outstanding - "one packet in flight". A copy of the update
can be kept and retransmitted until acknowledged - and
subsequent update packets are sent in turn until the full
(to date) has been sent and acknowledged
Meyer & Sherry Standards Track [Page 7]
RFC 2091 Trigger RIP January 1997
Things become more complicated if several packets are sent in
succession without waiting for an acknowledgements between packets -
"several packets in flight":
o If packets arrive out of order they could corrupt the peer'
database. If the underlying datalink layer bundles several VCs
it MUST guarantee to NOT reorder datagrams
o If the elements making up a packet requiring retransmission
because of an alteration in the database, stale
information could be sent (again new information could
old information).
To guard against this when 'retransmitting' a packet when
database is in flux the packet MUST be re-created from the
to contain only the subset of routes which currently apply. And
none of the routes still apply, nothing will be 'retransmitted'.
For simplicity of implementation we would advise having only
packet in flight. However if the 'round trip' for a response
acknowledgement is quite long this could significantly delay
updates. See Appendix A for an understanding of the
complexity of managing several packets in flight
4. New Packet
To support triggered updates, three new packet types MUST
supported. For IP RIP Version 1 [1] and IP RIP Version 2 [2]
are identified by the Command Field values shown
o 9 - Update
o 10 - Update
o 11 - Update
For Netware RIP and SAP [3] the equivalent Field to
between packet types is called Operation and these take the
values
These Command and Operation types require the addition of a 4
Update header. All three packet types contain a Version, which
be 1. Update Response and Update Acknowledge also have a
Number and a Flush Flag
Meyer & Sherry Standards Track [Page 8]
RFC 2091 Trigger RIP January 1997
4.1 Update
The Update Request has the Command/Operation value 9.
It is a request to the peer system to send ALL appropriate
in its routing database. It is retransmitted at periodic
(every 5 seconds) until an Update Response message is received
the Flush flag set
An Update Request is transmitted in the following circumstances
o Firstly when the router is powered on
o Secondly when the circuit manager indicates a destination has
in an unreachable (circuit down) state and changes to a
(circuit up) state
An Update Request may also be sent at other times to compensate
discarding non-optimal routing information or if an Update
continues to be unacknowledged (see section 6.3).
4.2 Update
The Update Response has the Command/Operation value 10.
It is a message containing zero or more routes in an update. It
retransmitted at periodic intervals until an Update Acknowledge
received
An Update Response message MUST be sent
o In response to an Update Request. The Update Response MUST
the Flush flag set. Other Update Responses should NOT be
until an Update Acknowledge has been received acknowledging
Flush flag
The remainder of the database MUST then be sent as a series
Update Responses with the Flush flag NOT set
o An Update Response with the Flush flag set MUST also be sent
power on to flush the peer's routing table learned from a
incarnation. This Update Response SHOULD NOT contain any routes
This avoids any possibility of an acknowledgement being
to a response sent BEFORE the unit was restarted causing
about which routes are being acknowledged
Update Response messages continue to be sent any time there is
routing information to be propagated
Meyer & Sherry Standards Track [Page 9]
RFC 2091 Trigger RIP January 1997
Each new Update Response is given a different Sequence Number.
Sequence Number only has 'meaning' to the sender of the
Response. The same Update Response sent to different peers MAY
a different Sequence Number
An Update Response packet with the Flush flag set MUST be sent to
peer
o At power on
o In response to an Update Request packet
o After transitioning from a circuit down to a circuit up state
After sending an Update Flush, the full database MUST be
subsequently
4.3 Update
The Update Acknowledge has the Command/Operation value 11.
It is a message sent in response to every Update Response
received. If the Update Response packet has the flush flag set
so should the Update Acknowledge packet
5. Packet
5.1 Update
To support the mechanism outlined in this proposal the packet
for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3]
are modified to include an additional small header when
Commands Update Request (9), Update Response (10) and
Acknowledge (11). Commands are called Operations in Netware
Update Request (9):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (1) | must be zero (3) |
+-------------------------------+-------------------------------+
Meyer & Sherry Standards Track [Page 10]
RFC 2091 Trigger RIP January 1997
Update Response (10) and Update Acknowledge (11):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (1) | Flush (1) | Sequence Number (2) |
+-------------------------------+-------------------------------+
Four octet Update headers, with each tick mark representing
bit. All fields are coded in network byte order (big-endian).
Figure 2. Update Headers
Version MUST be 1 in all headers. Any packets received for
different Version MUST be silently discarded
The Sequence Number MUST be incremented every time a new
Response packet is sent on the WAN. The Sequence Number is
for retransmissions. The Sequence Number wraps round at 65535.
Flush is set to 1 in an Update Response if the peer is required
start timing out its entries - otherwise it is set to zero.
other values MUST be silently discarded
The peer returns an Update Acknowledge containing the same
Number and Flush
5.2 IP Routing Information Protocol Version 1
IP RIP [1] is a UDP-based protocol which generally sends and
datagrams on UDP port number 520.
To support the mechanism outlined in this proposal the packet
for RIP Version 1 [1] is modified when using Commands Update
(9), Update Response (10) and Update Acknowledge (11). See Figure 3.
5.3 IP Routing Information Protocol Version 2
IP RIP Version 2 [2] is an enhancement to IP RIP Version 1
allows RIP updates to include subnetting information
To support the mechanism outlined in this proposal the packet
for RIP Version 2 [2] is modified when using Commands Update
(9), Update Response (10) and Update Acknowledge (11). See Figure 4.
Meyer & Sherry Standards Track [Page 11]
RFC 2091 Trigger RIP January 1997
5.4 Netware Routing Information
Netware [3] supports a mechanism that allows routers on
internetwork to exchange routing information using the
Information Protocol (RIP) which runs over the Internetwork
Exchange (IPX) protocol using socket number 453h
To support the mechanism outlined in this proposal the packet
for Novell RIP [3] is modified when using Operations Update
(9), Update Response (10) and Update Acknowledge (11). See Figure 5.
5.5 Netware Service Advertising
Netware [3] also supports a mechanism that allows servers on
internetwork to advertise their services by name and type using
Service Advertising Protocol (SAP) which runs over the
Packet Exchange (IPX) protocol using socket number 452h.
operates on similar principals to running RIP. Routers act as
agents, collecting service information from different networks
relay it to interested parties
To support the mechanism outlined in this proposal the packet
for Novell SAP [3] is modified when using Operations Update
(9), Update Response (10) and Update Acknowledge (11). See Figure 6.
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | RIP Version (1)| must be zero (2) |
+---------------+---------------+-------------------------------+
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (4) |
+-------------------------------+-------------------------------+
Meyer & Sherry Standards Track [Page 12]
RFC 2091 Trigger RIP January 1997
Update Response then has up to 25 routing entries (each 20 octets):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
.
.
The format of an IP RIP datagram in octets, with each tick
representing one bit. All fields are coded in network byte
(big-endian).
The four octets of the Update header are included in Update
(Command 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the original
Version 1 specification
Figure 3. IP RIP Version 1 packet
Meyer & Sherry Standards Track [Page 13]
RFC 2091 Trigger RIP January 1997
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) |RIP Version (1)| must be zero (2) |
+---------------+---------------+-------------------------------+
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (4) |
+-------------------------------+-------------------------------+
Update Response then has up to 25 routing entries (each 20 octets):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) - must be zero |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
.
.
The format of an IP RIP Version 2 datagram in octets, with
tick mark representing one bit. All fields are coded in
byte order (big-endian).
The four octets of the Update header are included in Update
(Command 9), Update Response (10) and Update Acknowledge (11)
Packets. They are not present in packet types in the original
Version 2 specification
Next Hop MUST be zero, since Triggered RIP can NOT advertise
on behalf of other WAN routers
If authentication is used it immediately follows the Update header
Figure 4. IP RIP Version 2 packet
Meyer & Sherry Standards Track [Page 14]
RFC 2091 Trigger RIP January 1997
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation (2) |
+---------------+---------------+
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (4) |
+-------------------------------+-------------------------------+
Update Response then has up to 50 routing entries (each 8 octets):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Number (4) |
+---------------------------------------------------------------+
| Number of Hops (2) | Number of Ticks (2) |
+---------------------------------------------------------------+
.
.
The format of a Netware RIP datagram in octets, with each tick
representing one bit. All fields are coded in network byte
(big-endian).
The four octets of the Update header are included in Update
(Operation 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the
Novell RIP specification
Figure 5. Netware RIP packet
Meyer & Sherry Standards Track [Page 15]
RFC 2091 Trigger RIP January 1997
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation (2) |
+---------------+---------------+
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (4) |
+-------------------------------+-------------------------------+
Update Response then has up to 8 service entries (each 64 octets):
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type (2) | |
+-------------------------------+ |
| Service Name (48) |
| . |
.
. +-------------------------------+
| . | Network Address (4) |
+-------------------------------+-------------------------------+
| Network Address (cont) | |
+-------------------------------+ |
| Node Address (6) |
+-------------------------------+-------------------------------+
| Socket Address (2) | Hops to Server (2) |
+-------------------------------+-------------------------------+
.
.
The format of a Netware SAP datagram in octets, with each tick
representing one bit. All fields are coded in network byte
(big-endian).
The four octets of the Update header are included in Update
(Operation 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the
Novell SAP specification
Figure 6. Netware SAP packet
Meyer & Sherry Standards Track [Page 16]
RFC 2091 Trigger RIP January 1997
6.
Three timers are supported to handle the triggered update mechanism
o Database timer
o Hold down timer
o Retransmission timer
An optional over-subscription timer MAY also be supported
6.1 Database
Routes learned by an Update Response are normally considered to
permanent
When an Update Response with the Flush flag set is received,
routes learned from that next hop router should start timing out
if they had (just) been learned from a conventional Response (
2).
Namely each route exists while the database entry timer (usually 180
seconds) is running and is advertised on other interfaces as if
present. The route is then advertised as unreachable while a
hold down timer is allowed to expire
6.2 Hold down
A hold down timer of 120 seconds is started on a route
o When the database timer for the route expires
o When a formerly reachable route changes to unreachable in
incoming response
o When a circuit down is received from the circuit manager
While the hold down timer is running routes are advertised
unreachable on other interfaces
When the hold down timer expires the route MAY be deleted from
database PROVIDING its unreachability has been
propagated to all WAN destinations, or the remaining WAN
are in a circuit down state. If a route can not be deleted when
hold-down timer expires, it MAY subsequently be deleted when each
every peer is either up-to-date or is in a circuit down state
Meyer & Sherry Standards Track [Page 17]
RFC 2091 Trigger RIP January 1997
If the hold down timer is already running it is NOT reset by
events which would start the hold down timer
6.3 Retransmission
The routing task runs a retransmission timer
o An Update Request packet is retransmitted periodically until
Update Flush packet is received. An Update Flush packet is
Update Response packet with the Flush field set. It need
contain routes
o An Update Response packet is retransmitted periodically until
Update Acknowledge packet is received containing the same
Number
With call set up time on the WAN being of the order of a second,
value of 5 seconds for the retransmission timer is appropriate
To prevent against failures in the circuit manager a limit SHOULD
placed on the number of retransmissions. If no response has
received after a configurable length of time (say 180 seconds)
via the next hop router are marked as unreachable, the hold
timer is started and the entry is advertised as unreachable on
interfaces
The next hop router may then be polled with Update Requests at
reduced frequency. A suitable poll interval would be of the order
minutes rather than seconds. Alternatively an Update Request
be initiated by administrative action. When a response is
the routers should perform a complete exchange of
information
6.4 Over-subscription
Over-subscription is where there are more next hop routers to
updates to on the WAN than there are channels. For example 3
hop routers accessed by an ISDN Basic Rate Interface (BRI) which
only support 2 calls simultaneously
To avoid route oscillation routes may NOT be marked
immediately on receiving a circuit down message from the
manager. A timeout MAY be used to delay marking the
unreachable for sufficiently long to allow the calls to '
division multiplex' over the available channels. A timeout as
as the regular 180 second RIP route timeout MAY be suitable.
general the greater the over-subscription, the longer the time
should be
Meyer & Sherry Standards Track [Page 18]
RFC 2091 Trigger RIP January 1997
Implementations wishing to support over-subscription may
the delay within the circuit manager or within the
application
If the delay is implemented within the routing application
routing entries MUST NOT start timing out during the delay.
allows the circuit up message to be ignored if the timeout
receiving the circuit down has still to expire. This avoids
confusion if the peer had previously issued a Route Flush command
was part way through an update
7. Security
The circuit manager is required to be provided with a list
physical addresses to enable it to establish a call to the next
router. The circuit manager SHOULD only allow incoming calls to
accepted from the same well defined list of routers
Elsewhere in the system there will be a set of logical address
physical address tuples to enable the network protocols to run
the correct circuit. This may be a lookup table, or in
instances there may be an algorithmic conversion between the
addresses
The routing (or service advertising) task MUST be provided with
list of logical addresses to which triggered updates are to be
on the WAN. The list MAY be a subset of the list of next hop
maintained by the circuit manager
RIP Version 2 also allows further authentication of Triggered
packets
Meyer & Sherry Standards Track [Page 19]
RFC 2091 Trigger RIP January 1997
Appendix A - Implementation
This section suggests how the database might be structured to
Triggered RIP
Each entry in the database is given a unique route number.
time a best route to a network changes, a global route number
incremented and the changed route is given the new route number
Note that this route number is completely internal to the router
has no bearing on the Sequence Number sent in Update Responses
to the peer
The route number size should be large enough so as not to wrap
- or the routes can be renumbered before it becomes a problem. Re
numbering requires that the database environment is stable (No
Responses are queued awaiting Acknowledgement
Is is probably easier to manage the routes if they are also
together using a pointer to a later (and possibly also a pointer
an earlier) entry which reflect the route number/age
Performing a complete update then consists of running though
routes from the oldest to the latest and sending them out in
Responses. Subsequent changes to the database are treated as
out only the changed entries (from the previous latest to the
latest).
When allowing for several packets in flight care must be taken
retransmissions. An Update Response 'retransmission' MAY
different from the original. When transmitting a sequence of
Responses each Response packet contains a number of routes which is
represented by a series of routes with consecutive route numbers
Consider sending three Update Responses with Sequence numbers 10,11
and 12 each containing 10 routes
Sequence Number Routes represented by Route
10 101, 102, 103, 104, 105, 106, 107, 108, 109, 110
11 111, 112, 113, 114, 115, 116, 117, 118, 119, 120
12 121, 122, 123, 124, 125, 126, 127, 128, 129, 130
Meyer & Sherry Standards Track [Page 20]
RFC 2091 Trigger RIP January 1997
If these Update Responses are NOT acknowledged, but in the
the routing database has changed and the routes represented by
numbers 104, 112 - 116 and 127 have changed and been assigned
route numbers 131 - 137, the retransmission will look like
Sequence Number Routes represented by Route
10 101, 102, 103, 105, 106, 107, 108, 109, 110
11 111, 117, 118, 119, 120
12 121, 122, 123, 124, 125, 126, 128, 129, 130
13 131, 132, 133, 134, 135, 136, 137
To perform a retransmission it is VERY IMPORTANT that
retransmission contains only the SUB-SET of route numbers
currently apply. If there are NO suitable routes to send, it is
necessary to send an empty retransmission
An alternative 'retransmission' strategy is to always use
sequence numbers when resending updates. Consider
packets with sequence numbers 10 through 20 - and responses
received from all packets except those with sequence numbers 14
17. In this case only the data in packets 10 through 13 can
considered to be acknowledged. The data from packet 14 onwards
be re-sent and given new sequence numbers starting at 21.
[1] Hedrick. C., "Routing Information Protocol", RFC 1058,
University, June 1988.
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, November 1994.
[3] Novell Incorporated., "IPX Router Specification", Version 1.20,
October 1993.
[4] Meyer. G., "Extensions to RIP to Support Demand Circuits",
Spider Systems, February 1994.
Meyer & Sherry Standards Track [Page 21]
RFC 2091 Trigger RIP January 1997
Authors' Address
Gerry
Stanwell
Edinburgh EH6 5
Scotland,
Phone: (UK) 131 554 9424
Fax: (UK) 131 467 7749
Email: gerry@europe.shiva.
Steve
295 Foster St
Littleton, MA 01460
Phone: (US) 508 952 4745
Fax: (US) 508 952 4887
Email: shs@xyplex.
Meyer & Sherry Standards Track [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
