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

information is sent out on a WAN. The sequence number
wraps round at 65535.
When a triggered general service acknowledgement is sent
the sequence number is set to the same value as the
triggered general service response packet being
acknowledged.
The sequence number MUST be identical over fragments. If
a fragment is retransmitted the sequence number MUST not
change.
FRAGMENT NUMBER
The fragment number is one for the first fragment of a
triggered general service response update, and is
incremented for each subsequent fragment. A fragment can
contain up to 8 service entries.
When a triggered general service acknowledgement is sent,
the fragment number is set to the same value as the
triggered general service response packet being
acknowledged.
NUMBER OF FRAGMENTS
In a triggered response packet this indicates the number of
packets required to complete the service update.
This field has no relevance for triggered acknowledgement
packets so should be set to zero.
For triggered general service response packets the rest of the
datagram contains a list of services, with information about each.
Each entry in this list contains the service type, service name, full
address (network, node and socket), and the number of hops to the
server.
The maximum datagram size is 534 octets, excluding the IPX header (a
further 30 octets).
7. Timers
A number of timers are supported to handle the triggered update
mechanism:
o Database timers.
o Retransmission timer.
o Reassembly timer.
In this section appropriate timer values for IP RIP are suggested.
For other routing protocols, only the database timer should need to
take different values. The database timer values are chosen to match
equivalent timer operation for using the protocol on a LAN. The
behaviour of a routing entry when a timer is running becomes
indistinguishable from a routing entry learned from a broadcast
update.
Implementations MAY make timer values configurable - and hence
different from the values suggested here - but interoperability
requires that all timers on a sub-network should be the same in all
routers.
7.1 Database Timers
Routes learned by a triggered response command (7) are normally
considered to be permanent - that is they do NOT time out unless
activated by one of the following events:
o If the circuit manager indicates that a next hop router cannot be
contacted, all routes learned from that next hop router should
start timing out as if they had (just) been learned from a
conventional response command (2).
Namely each route exists while the database entry timer is
running and is advertised on other interfaces as if still
present. The route is then advertised as unreachable while a
further hold down timer is allowed to expire, at which point the
entry is deleted.
If the circuit manager indicates that the next hop router can be
contacted while the database entry timer is running, the routes
are reinstated as permanent entries.
If the database entry timer has expired and the circuit manager
indicates that the next hop router is reachable, the routing
application MUST issue a triggered request. The routes will be
reinstated on the basis of any triggered response packet(s)
received.
o If a triggered response packet is received in which a route is
marked unreachable, the hold down timer MUST be started and the
entry is advertised as unreachable on other interfaces. On
expiry of the hold down timer the entry is deleted.
If a triggered response packet is received in which an existing
route is ABSENT, the hold down timer MUST also be started and