rfc-1582

Extensions to RIP to Support Demand Circuits

G. Meyer
date1994-02 streamLegacy statusPROPOSED STANDARD pages29 canonicalhttps://www.rfc-editor.org/rfc/rfc1582 doi10.17487/RFC1582
This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

Extracted elements (26)

design-rationale §2.2

Entries learned from triggered responses on the WAN are treated as 'permanent' (non-expiring) rather than temporary, because there are no periodic refreshes to keep them alive. They only become temporary upon explicit unreachability signals (circuit down, absent route, or explicit metric-16 update).

routing

design-rationale §1

Periodic broadcasting of routing updates on demand circuits (X.25, ISDN) is expensive because circuits must be kept open to every destination for the duration of routing traffic, even when no user data is flowing. On a network of N routers, N*(N-1) updates are sent over N*(N-1)/2 connections every broadcast period.

routing

design-rationale §2.7

Stability is improved by adding 'poisoned reverse' on routes learned from a destination: routes learned from a peer are included in updates sent back to that peer but marked unreachable. Only best routes (not inferior alternatives) are poisoned.

routing

design-rationale §2.1

The triggered update approach sends routing information on the WAN only when the routing database is modified by new information from another interface, or when the circuit manager indicates a change in reachability. This eliminates periodic broadcasts while preserving correctness.

routing

design-rationale §2.9

To prevent queue overload on WAN interfaces, the routing task MAY stagger triggered requests and responses rather than sending to all next-hop routers simultaneously, limiting the number of outstanding unacknowledged messages as a function of link speed and number of concurrent routing protocols.

routing

interoperability-note §2.3

The triggered update mechanism runs unmodified on LANs and fixed point-to-point links; the WAN router list can designate some peers as running the standard periodic protocol to allow interoperability with existing implementations, including those using Permanent Virtual Circuits (PVCs).

routing

normative-requirement §2.7 MUST

A triggered response message MUST be sent in response to a triggered request even if there are no routes to propagate, to confirm receipt and prevent indefinite retransmission by the requester.

routing

normative-requirement §7.2 MUST

After 10 unacknowledged retransmissions, routes via the next hop MUST be marked unreachable and the hold-down timer started. The peer is then polled at 60-second intervals with triggered requests; after an administrator-configurable minimum of 5 failed polls the destination MAY be marked as not supporting the mechanism.

routing

normative-requirement §4 MUST

Because RIP Version 2 includes security authentication information in packets, this security data MUST be appended to triggered request and triggered acknowledgement packets, as well as being present in triggered response packets.

routing, security

normative-requirement §7.1 MUST

For IP RIP, the hold-down timer MUST run for 120 seconds (consistent with LAN RIP) and the database entry timer defaults to 180 seconds. If the database entry timer expires while a circuit is down, the routing application MUST issue a triggered request when the circuit comes back up.

routing

normative-requirement §2.8 MUST

If a fragment with an updated (different) sequence number is received, ALL fragments with the earlier sequence number MUST be discarded. There is no concept of sequence number age; any difference denotes a new update.

routing

normative-requirement §2.8 MUST

If a routing update is sufficiently large it MUST be fragmented over several triggered response packets. Each fragment MUST be individually acknowledged. If all fragments are not received within four times the retransmit period they MUST be discarded and a triggered request sent to the originator.

routing

normative-requirement §8 MUST

In implementations where the routing application and circuit manager have independent lifecycles, a keep-alive mechanism MUST be provided between them so that if either dies and restarts, they can resynchronize their state tables.

routing

normative-requirement §2.3 MUST

Routing packets arriving from a WAN destination not listed in the appropriate router category (standard or triggered) MUST be discarded.

routing, security

normative-requirement §7.3 SHOULD

The reassembly timer SHOULD be set to four times the retransmission timer value (suggested: 20 seconds with a 5-second retransmission timer). Implementations MAY make both configurable in the 1:4 ratio, but interoperability requires all routers on a subnetwork use the same values.

routing

normative-requirement §2.6 MUST

The routing database MUST adopt a strategy ensuring no routing information is ever lost: it must keep all or some alternative routing information, and if discarded routes' remaining entries disappear, the router MUST issue a request on all interfaces to recover discarded alternatives.

routing

normative-requirement §3 MUST

The sequence number MUST be incremented every time updated routing information is sent on a WAN, and MUST remain identical across all fragments of the same update. If a fragment is retransmitted, its sequence number MUST NOT change.

routing

normative-requirement §2.7 MUST

Three new packet types MUST be supported: TRIGGERED REQUEST (asks peer for full routing database), TRIGGERED RESPONSE (full database excluding split-horizon entries), and TRIGGERED ACKNOWLEDGEMENT (per-fragment ACK for every triggered response received).

routing

normative-requirement §2.5 MUST

To guarantee delivery of routing updates on the WAN, an acknowledgement and retransmission scheme MUST be used: the sender retransmits the update until a triggered acknowledgement is received, and if the routing database changes before an ACK arrives, a new update with an updated sequence number is sent.

routing

protocol-element §3

IP RIP gains three new command values: TRIGGERED REQUEST (6), TRIGGERED RESPONSE (7), and TRIGGERED ACKNOWLEDGEMENT (8). The triggered request sends only the first 4 octets; the triggered acknowledgement sends the first 8 octets (header plus sequence/fragment fields). The sequence number wraps at 65535.

routing, ip

security-consideration §9 SHOULD

The circuit manager SHOULD only accept incoming calls from a well-defined list of known next-hop routers (identified by physical address). This prevents unauthorized routers from injecting routing information via spurious circuit establishment.

security, routing

security-consideration §9 MUST

The routing task MUST be provided with an explicit list of logical addresses to which triggered updates are sent on the WAN. Any routing information received from a router not in the appropriate list MUST be discarded, preventing route injection from unlisted peers.

security, routing

state-machine §2.6

Routing database entries transition between 'permanent' and 'temporary' states. Entries learned from WAN triggered responses are permanent until: (a) an explicit unreachable update arrives, starting the hold-down timer; (b) the entry is absent from a triggered response, also starting hold-down; (c) the circuit manager signals circuit-down, triggering aging. After hold-down expiry, entries are deleted.

routing

wire-format §3

IP RIP triggered commands (7 = TRIGGERED RESPONSE, 8 = TRIGGERED ACKNOWLEDGEMENT) insert four additional octets after the standard 4-octet header: sequence number (2 octets), fragment number (1 octet), number of fragments (1 octet). These fields are absent for standard commands (1–5). Up to 25 routing entries of 20 octets each follow in triggered response packets.

routing, ip, udp

wire-format §5

Netware RIP triggered commands insert four octets after the 2-octet operation field: sequence number (2 octets), fragment number (1 octet), number of fragments (1 octet). Up to 50 routing entries of 8 octets each (network number 4 octets, hops 2 octets, ticks 2 octets) follow in triggered response packets. Maximum datagram is 406 octets excluding the 30-octet IPX header.

routing

wire-format §6

Netware SAP triggered commands use the same 4-octet extension (sequence number 2, fragment 1, fragment-count 1). Up to 8 service entries of 66 octets each follow: service type (4), service name (48), network address (4), node address (6), socket address (2), hops to server (2). Maximum datagram is 534 octets excluding the 30-octet IPX header.

routing