Triggered Extensions to RIP to Support Demand Circuits
Extracted elements (30)
Having only one Update Response packet in flight at a time is the simplest retransmission strategy and is recommended for ease of implementation. Allowing several packets in flight improves throughput for large updates over high-latency WAN links but requires careful handling of out-of-order delivery and database-in-flux retransmissions.
Periodic broadcasting by distance-vector protocols (IP RIP, Netware RIP/SAP) prevents WAN demand circuits from ever closing, since updates arrive every 30 or 60 seconds. Triggered RIP sends routing information on the WAN only when the routing database changes or when the circuit manager signals a reachability change, enabling circuits to remain idle between updates.
Triggered RIP differs from Demand RIP (RFC 1582) by sending only changed routing information rather than full database fragments, allowing immediate application of changes by the receiver. This reduces routing traffic, requires less memory, and removes the 255-fragment upper limit of Demand RIP.
The triggered extensions apply only to WAN interfaces; the protocols run unmodified on LANs and thus interoperate transparently with implementations adhering to the original RIP and SAP specifications.
A limit SHOULD be placed on retransmission attempts; if no response is received after a configurable period (approximately 180 seconds), routes via the next hop are marked unreachable, the hold-down timer is started, and unreachability is advertised on other interfaces.
After sending an Update Flush (Update Response with Flush flag set), the full routing database MUST subsequently be sent. An Update Response with Flush MUST be sent at power-on, in response to an Update Request, and after transitioning from circuit-down to circuit-up.
All alternative routes SHOULD be retained so that no routing information is ever lost or discarded; operating with only a subset of alternative routes adds complexity that is not covered by this specification.
An initial Update Response with the Flush flag set MAY contain no routes and is used at power-on to flush routes learned by the peer from a previous incarnation of the router, preventing stale acknowledgements from causing confusion about which routes are confirmed.
An Update Response MUST be sent in response to an Update Request, and that response MUST have the Flush flag set. Other Update Responses SHOULD NOT be sent until the Flush Update Response has been acknowledged, after which the remainder of the database MUST be sent as Update Responses with Flush NOT set.
An Update Response with the Flush flag set MUST be sent at power-on and SHOULD NOT contain any routes, in order to flush the peer's routing table from a previous incarnation and avoid confusion from stale acknowledgements.
During the over-subscription delay, routing entries MUST NOT start timing out, so that a subsequent circuit-up message can be safely ignored if the delay has not yet expired and no confusion arises from a peer that previously issued a Route Flush.
Routing entries learned from a triggered Update Response on the WAN MUST NOT time out in the normal course of events; they are considered permanent unless a circuit-down event or excessive retransmission failures mark them unreachable.
Split Horizon with Poisoned Reverse MUST be used to determine whether and how a route is advertised on an interface running Triggered RIP. Only the best route (not inferior alternatives) is poisoned.
The Sequence Number MUST be incremented every time a new Update Response packet is sent on the WAN; it is unchanged for retransmissions. The Sequence Number wraps around at 65535. The same Update Response sent to different peers MAY carry different Sequence Numbers.
Three new packet types MUST be supported: Update Request (Command/Operation 9), Update Response (10), and Update Acknowledge (11). All three require the addition of a 4-octet Update Header.
Version MUST be 1 in all Update Headers. Any packet received with a different Version value MUST be silently discarded. Flush values other than 0 or 1 MUST also be silently discarded.
When retransmitting a packet while the routing database is in flux, the packet MUST be re-created from the database to contain only the subset of routes that currently apply; if none still apply, nothing is retransmitted.
When 'several packets in flight' mode is used and the underlying datalink layer bundles multiple Virtual Circuits, it MUST guarantee NOT to reorder datagrams, since out-of-order delivery could corrupt the peer's routing database.
The Over-subscription Timer MAY delay marking routes unreachable upon receiving a circuit-down message, to allow calls to time-division multiplex over limited available channels (e.g., ISDN BRI with fewer B-channels than next-hop routers). A delay as long as the standard 180-second RIP timeout MAY be used.
The Update Acknowledge (Command/Operation 11) is sent in response to every Update Response packet received. If the Update Response has the Flush flag set, the corresponding Acknowledge must also have the Flush flag set, and it echoes the same Sequence Number.
The Update Request (Command 9) requests the peer to send all appropriate entries in its routing database. It is retransmitted every 5 seconds until an Update Response with the Flush flag set is received. It is sent at power-on and whenever the circuit manager signals a transition from circuit-down to circuit-up.
Three timers govern the triggered mechanism: the Database Timer (normally 180 seconds, started when a Flush Update Response is received), the Hold Down Timer (120 seconds, started on route expiry, unreachable notification, or circuit-down), and the Retransmission Timer (5 seconds). An optional Over-subscription Timer MAY also be supported.
The circuit manager SHOULD only allow incoming calls from a well-defined list of known next-hop routers, restricting which physical addresses are permitted to establish a Virtual Circuit to the local router.
The routing task MUST be provided with a list of logical addresses to which triggered updates are to be sent on the WAN; this list MAY be a subset of the next-hop routers maintained by the circuit manager. RIP Version 2 authentication MAY also be applied to Triggered RIP packets.
Routes transition between reachable and unreachable states driven by circuit-manager signals. On circuit-down, database entries are first marked temporary and aged, then marked unreachable for a 120-second hold-down period. On subsequent circuit-up, a full routing exchange is performed to re-prime the routing database.
IP RIP Version 1 triggered packets (Commands 9, 10, 11) insert the 4-octet Update Header after the standard RIP Version 1 command/version header. Update Responses carry up to 25 routing entries of 20 octets each (Address Family, IP address, metric), all big-endian.
IP RIP Version 2 triggered packets insert the 4-octet Update Header after the standard 4-byte RIP header. The Next Hop field MUST be zero because Triggered RIP cannot advertise routes on behalf of other WAN routers. If authentication is used it immediately follows the Update Header.
Netware RIP triggered packets use a 2-octet Operation field followed by the 4-octet Update Header; Update Responses carry up to 50 routing entries of 8 octets each (Network Number 4 octets, Hops 2 octets, Ticks 2 octets), big-endian.
Netware SAP triggered packets use a 2-octet Operation field followed by the 4-octet Update Header; Update Responses carry up to 8 service entries of 64 octets each, containing Service Type (2), Service Name (48), Network Address (4), Node Address (6), Socket Address (2), and Hops to Server (2), all big-endian.
The 4-octet Update Header is prepended to all three triggered packet types. For Update Request: Version (1 octet, must be 1) and 3 zero octets. For Update Response and Update Acknowledge: Version (1 octet), Flush (1 octet), and Sequence Number (2 octets). All fields are big-endian.