RFC 2091
Triggered Extensions to RIP to Support Demand Circuits
Triggered Extensions to RIP to Support Demand Circuits 💖
Okay bestie, let's check the title block first 🎀
- Network Working Group
- RFC number: 2091
- Authors: G. Meyer (Shiva) and S. Sherry (Xyplex) 👯
- Category: Standards Track
- Date: January 1997
- Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates
Status of This Memo
This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🗣️ For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract
So here's the tea ☕ This doc defines a modification you can apply to Bellman-Ford (distance vector) algorithm information broadcasting protocols, like IP RIP, Netware RIP, or Netware SAP. The change makes it feasible to run them on connection oriented Public Data Networks 🔥
It also has a bunch of efficiency advantages over the Demand RIP proposal (RFC 1582) 💅
Acknowledgements
Big thank-yous 🫶 to Richard Edmonstone of Shiva, Joahanna Kruger of Xyplex, Steve Waters of DEC, and Guenter Roeck of Conware for the comments and suggestions that made this effort so much better ✨
Conventions
Okay, the language rules 📜 Here's what the words mean in the items of specification:
- MUST -- the item is an absolute requirement of the specification. MUST is only used where it is actually required for interoperation, not to try to impose a particular method on implementors where not required for interoperability.
- SHOULD -- the item should be followed for all but exceptional circumstances.
- MAY or optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor.
The words "should" and "may" are also used, in lower case, in their more ordinary senses 💜
Table of Contents 📚
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 ........................................ 221. Introduction ✨
Routers are used on connection oriented networks, like X.25 packet switched networks and ISDN networks, so they can reach a large number of remote destinations 🌐 Circuits on the Wide Area Network (WAN) get set up on demand and get torn down when the traffic dies down. Depending on the application, the connection between any two sites for user data might be super short and pretty infrequent 🦋
Periodic broadcasting from Bellman-Ford (distance vector) algorithm information broadcasting protocols, meaning IP RIP [1], IP RIP V2 [2], or Netware RIP and SAP [3], usually stops WAN circuits from ever closing 😭 Even on fixed point-to-point links, the overhead of periodic RIP transmission, and even more so SAP broadcasts, can seriously mess with normal data transfer. The reason is just the sheer amount of info hitting the line every 30 or 60 seconds 💀
To fix this, the spec tweaks the distance vector protocols so they only send information over the WAN when there has been an update to the routing database OR a change in the reachability of a next hop router is indicated by the task that manages connections on the WAN 🔥
Datagrams aren't guaranteed to get through on every WAN medium, so an acknowledgement and retransmission system is required to provide reliability 🫶
The protocols run unmodified on Local Area Networks (LANs), so they interoperate transparently with implementations that follow the original specifications 🌸
This proposal differs from Demand RIP [4] conceptually in the following ways:
- If a router has exchanged all routing information with its partner and some routing information subsequently changes, only the changed information is sent to the partner.
- The receiver of routes is able to apply all changes immediately upon receiving information from a partner.
These differences lead to even less routing traffic, and they also need less memory than Demand RIP [4] does. Demand RIP also has an upper limit of 255 fragments in an update, and Triggered RIP lifts that limit because it doesn't use fragmentation at all 👑
2. Overview 🗺️
Multiprotocol routers are used on connection oriented Wide Area Networks (WANs), like X.25 packet switched networks and ISDN networks, to interconnect LANs. By using the multiplexing properties of the underlying WAN technology, several LANs can be interconnected at the same time through a single physical interface on the router 🧚
A circuit manager is the interface between the connectionless network layers (IP and IPX) and the connection oriented WAN (X.25, ISDN, etc.). Figure 1 is a schematic stack showing how routing protocols, network layers, the circuit manager, and the connection oriented WAN all relate 🎀
-------------- --------- ---------
| RIP | | RIP | | SAP |
-------------- --------- ---------
| | |
-------------- | |
| UDP | | |
-------------- | |
| | |
-------------- ----------------
| IP | | IPX |
-------------- ----------------
| |
-------------------------------------------
| Circuit Manager |
-------------------------------------------
||||||||||
||||||||||
---------------------------
| Connection Oriented |
| WAN stack |
--------------------------- Figure 1. Representative Multiprotocol Router stackOn its upper interface, a WAN circuit manager supports a variety of network layer protocols. On its lower interface, it may support one or more subnetworks, and a subnetwork may support a number of Virtual Circuits 💖
The router has a translation table that relates the network layer address of the next hop router to the physical address used to set up a Virtual Circuit (VC) to it 🗂️
The circuit manager takes datagrams from the connectionless network layer protocols and, if one isn't already available, opens a VC to the next hop router. A VC can carry all traffic between two end-point routers for a given network layer protocol (or, with appropriate encapsulation, all network layer protocols). An idle timer (or some other mechanism) closes the VC when datagrams stop arriving at the circuit manager 🕰️
If the circuit manager has data to forward (whether user data OR a routing update) and fails to get a VC, it tells the routing application that the destination is unreachable (circuit down). The circuit manager is then expected to do whatever is necessary to recover the link. Once that works, it tells the routing application (circuit up) 🔁
In Triggered RIP, routing updates only go out on the WAN when they're actually needed:
- When a specific request for a routing update has been received.
- When the routing database is modified by new information from another interface.
- When the circuit manager says a destination has changed from unreachable (circuit down) to reachable (circuit up).
- And also when a unit is first powered on, to make sure at least one update is sent. This can be thought of as a transition from circuit down to circuit up. It MAY contain no routes or services, and it's used to flush routes or services from the peer's database 🧹
In cases 1, 3, and 4 the full contents of the database are sent. In case 2 only the latest changes are sent 📦
Because a datagram based system is inherently unreliable, both routing requests and routing responses require acknowledgement, and retransmission happens in the event of NOT receiving an acknowledgement 🔄
3. The Routing Database 🗄️
Entries in the routing database can be either permanent or temporary. Entries learned from broadcasts on LANs are temporary. They expire if they aren't 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. Certain events can still cause these routes to time out 🌈
3.1 Presumption of Reachability ✨
Okay bestie, so if a routing update comes in from a next hop router on the WAN, every entry in that update is treated as reachable from then on, unless something proves otherwise 🌸
- If the circuit manager is just going about its normal routing-datagram business and can't establish a connection to the next hop router, it tells the routing application that the router isn't reachable by sending an internal circuit down message.
The database entries get marked as temporary and aged normally first. Some implementations may choose to skip this initial aging step. Then the routing application marks the right database entries as unreachable for a hold down period (the normal 120 second RIP hold down timer) ⏳
- If the circuit manager later manages to connect to that next hop router, it sends the routing application an internal circuit up message saying the router is reachable again 🦋
The routing application then swaps messages with the next hop router so both sides can re-prime their routing databases with up-to-date info. Main character reunion energy 🥹
The next hop router can also get marked as unreachable if too many retransmissions of an update go unacknowledged (see section 6.3). Lowkey dramatic, but valid 💀
Handling circuit up and circuit down messages means the circuit manager has to take responsibility for establishing (or re-establishing) the connection whenever a next hop router becomes unreachable. How the circuit manager actually does that is outside the scope of this document, so we're not going there today 🙈
3.2 Alternative Routes 🍓
Here's the vibe: using Triggered RIP to propagate routing information means that NO routing information ever gets LOST or DISCARDED. Not even a little. So all alternative routes SHOULD be retained 🫶
It MAY be possible to operate with a subset of all alternative routes, but that adds complexity to the protocol, which is NOT covered in this document. Not my problem today, bestie 💅
3.3 Split Horizon with Poisoned Reverse 🔥
The rules for Split Horizon with Poisoned Reverse MUST be used to determine whether and/or how a route is advertised on an interface running this protocol. Non-negotiable, periodt 👑
Split Horizon means you leave out routes you learned from a peer when you send updates back to that peer. With Poisoned Reverse, you don't leave them out. Instead you advertise them as unreachable by setting the metric to infinity 🧚
A route only gets poisoned if it's the best route in the database, not an inferior alternative route ✨
Why do we even need Poison Reverse? Because a router might be advertising a route to a network to its partner, and then later learn a better route to that same network from that partner. Without Poison Reverse, the partner won't know it should discard the inferior route it learned from the first router. Chaotic, but makes sense 😭
3.4 Managing Routing Updates 💜
The routing database SHOULD be considered a sequence of elements, ordered by the time each one was last updated. If the best route changes (so a new route gets added or a route's metric changes), that route gets reordered and given a new highest sequence number 🌈
Sending updates to a peer means running through the database from the oldest entry to the newest. Once an entry has been sent and acknowledged, it's generally never resent. As new routing information arrives, only the new information gets sent. Efficiency queen behaviour 👑
3.5 Retransmissions 🎀
Retransmitting updates is simplest if you never have more than one un-acknowledged update outstanding, which is called "one packet in flight". You keep a copy of the update packet and retransmit it until it's acknowledged. Then you send the next update packets in turn until the full database (to date) has been sent and acknowledged 🦋
It gets more complicated if you send several packets in quick succession without waiting for an acknowledgement between packets, which is called "several packets in flight" 😵💫
- If packets arrive out of order, they could corrupt the peer's database. If the underlying datalink layer bundles several VCs, it MUST guarantee to NOT reorder datagrams. Bestie, this one is serious 🚨
- If the elements making up a packet that needs retransmitting change because of an alteration in the database, stale incorrect information could get sent. Newer information could also overtake older information. Plot twist nobody wants 🙃
To guard against this, when "retransmitting" a packet while the database is in flux, the packet MUST be re-created from the database so it only contains the subset of routes that currently apply. And if none of the routes still apply, nothing gets "retransmitted" at all 🫠
For simplicity of implementation, we'd advise having only one packet in flight. However, if the round trip for a response and acknowledgement is quite long, this could significantly delay large updates. If you want to understand the extra complexity of managing several packets in flight, see Appendix A 🌸
4. New Packet Types ✨
To support triggered updates, three new packet types MUST be supported. For IP RIP Version 1 [1] and IP RIP Version 2 [2], these are identified by the Command Field values shown below 💖
- 9 - Update Request
- 10 - Update Response
- 11 - Update Acknowledge
For Netware RIP and SAP [3], the equivalent Field that tells the packet types apart is called Operation, and these take the same values 🧚
These Command and Operation types require the addition of a 4 octet Update header. All three packet types contain a Version, which MUST be 1. Update Response and Update Acknowledge also have a Sequence Number and a Flush Flag 🎀
4.1 Update Request 🍓
The Update Request has the Command/Operation value 9 🔥
It's a request asking the peer system to send ALL appropriate elements in its routing database. It gets retransmitted at periodic intervals (every 5 seconds) until an Update Response message comes back with the Flush flag set ⏰
An Update Request gets transmitted in these situations:
- Firstly, when the router is powered on.
- Secondly, when the circuit manager indicates a destination has been in an unreachable (circuit down) state and changes to a reachable (circuit up) state.
An Update Request may also be sent at other times, to compensate for discarding non-optimal routing information, or if an Update Response continues to be unacknowledged (see section 6.3) 🥲
4.2 Update Response 💅
The Update Response has the Command/Operation value 10 💜
It's a message containing zero or more routes in an update. It gets retransmitted at periodic intervals until an Update Acknowledge is received 🦋
An Update Response message MUST be sent:
- In response to an Update Request. The Update Response MUST have the Flush flag set. Other Update Responses should NOT be sent until an Update Acknowledge has been received acknowledging the Flush flag.
The remainder of the database MUST then be sent as a series of Update Responses with the Flush flag NOT set 📦
- An Update Response with the Flush flag set MUST also be sent at power on, to flush the peer's routing table learned from a previous incarnation. This Update Response SHOULD NOT contain any routes. That way there's no chance an acknowledgement for a response sent BEFORE the unit restarted gets mixed up about which routes are being acknowledged 🙈
Update Response messages keep getting sent any time there's fresh routing information to propagate 🌈
Each new Update Response gets its own Sequence Number. The Sequence Number only has "meaning" to the sender of the Update Response. The same Update Response sent to different peers MAY have a different Sequence Number 🧚
An Update Response packet with the Flush flag set MUST be sent to a peer:
- At power on.
- In response to an Update Request packet.
- After transitioning from a circuit down to a circuit up state.
After sending an Update Flush, the full database MUST be sent subsequently 🫶
4.3 Update Acknowledge 🌸
The Update Acknowledge has the Command/Operation value 11 ✨
It's a message sent in response to every Update Response packet received. If the Update Response packet has the flush flag set, then so should the Update Acknowledge packet 👑
5. Packet Formats 💖
5.1 Update Header 🎀
To support the mechanism outlined in this proposal, the packet format for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3] gets modified to include an additional small header when using Commands Update Request (9), Update Response (10) and Update 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) |
+-------------------------------+-------------------------------+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 one
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 a different Version MUST be silently discarded 🚫
The Sequence Number MUST be incremented every time a new Update Response packet is sent on the WAN. The Sequence Number is unchanged for retransmissions. The Sequence Number wraps round at 65535 🔢
Flush is set to 1 in an Update Response if the peer is required to start timing out its entries. Otherwise it's set to zero. Any other values MUST be silently discarded 🧹
The peer returns an Update Acknowledge containing the same Sequence Number and Flush 🫶
5.2 IP Routing Information Protocol Version 1 🌈
IP RIP [1] is a UDP-based protocol which generally sends and receives datagrams on UDP port number 520 🦋
To support the mechanism outlined in this proposal, the packet format for RIP Version 1 [1] is modified when using Commands Update Request (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 which lets RIP updates include subnetting information 🧠
To support the mechanism outlined in this proposal, the packet format for RIP Version 2 [2] is modified when using Commands Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 4 ✨
5.4 Netware Routing Information Protocol 🧚
Netware [3] supports a mechanism that lets routers on an internetwork exchange routing information using the Routing Information Protocol (RIP), which runs over the Internetwork Packet Exchange (IPX) protocol using socket number 453h 🌸
To support the mechanism outlined in this proposal, the packet format for Novell RIP [3] is modified when using Operations Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 5 🫠
5.5 Netware Service Advertising Protocol ✨
okay so Netware [3] has this whole vibe where servers on an internetwork can advertise their services by name and type 💅 That's the Service Advertising Protocol (SAP), and it runs over the Internetwork Packet Exchange (IPX) protocol using socket number 452h 🎀 SAP works on similar principles to RIP, so it's giving déjà vu 🫶 Routers act as SAP agents. They collect service info from different networks and relay it to whoever's interested 🦋
To support the mechanism outlined in this proposal, the packet format for Novell SAP [3] gets modified when using Operations Update Request (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) |
+-------------------------------+-------------------------------+
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 mark representing one bit, is shown above. All fields are coded in network byte order (big-endian) 💕
The four octets of the Update header are included in Update Request (Command 9), Update Response (10) and Update Acknowledge (11) packets. They are not present in packet types in the original RIP Version 1 specification 🧚
Figure 3. IP RIP Version 1 packet format
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 each tick mark representing one bit, is shown above. All fields are coded in network byte order (big-endian) 🌈
The four octets of the Update header are included in Update Request (Command 9), Update Response (10) and Update Acknowledge (11) Packets. They are not present in packet types in the original RIP Version 2 specification 💜
Next Hop MUST be zero, since Triggered RIP can NOT advertise routes on behalf of other WAN routers. This one is non-negotiable, bestie 🙅♀️
If authentication is used, it immediately follows the Update header 🔐
Figure 4. IP RIP Version 2 packet format
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 mark representing one bit, is shown above. All fields are coded in network byte order (big-endian) 🍓
The four octets of the Update header are included in Update Request (Operation 9), Update Response (10) and Update Acknowledge (11) packets. They are not present in packet types in the original Novell RIP specification ✨
Figure 5. Netware RIP packet format
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 mark representing one bit, is shown above. All fields are coded in network byte order (big-endian) 🧚♀️
The four octets of the Update header are included in Update Request (Operation 9), Update Response (10) and Update Acknowledge (11) packets. They are not present in packet types in the original Novell SAP specification 💅
Figure 6. Netware SAP packet format
6. Timers ⏰
Three timers are supported to handle the triggered update mechanism:
- Database timer.
- Hold down timer.
- Retransmission timer.
An optional over-subscription timer MAY also be supported 🫧
6.1 Database Timer
Routes learned by an Update Response are normally considered to be permanent 🌸
When an Update Response with the Flush flag set is received, 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 (usually 180 seconds) 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 🦋
6.2 Hold down Timer
A hold down timer of 120 seconds is started on a route:
- When the database timer for the route expires.
- When a formerly reachable route changes to unreachable in an incoming response.
- When a circuit down is received from the circuit manager.
While the hold down timer is running, routes are advertised as unreachable on other interfaces 🙈
When the hold down timer expires, the route MAY be deleted from the database PROVIDING its unreachability has been successfully propagated to all WAN destinations, or the remaining WAN destinations are in a circuit down state. If a route can not be deleted when the hold-down timer expires, it MAY subsequently be deleted when each and every peer is either up-to-date or is in a circuit down state 👑
If the hold down timer is already running, it is NOT reset by any events which would start the hold down timer 💀
6.3 Retransmission Timer ⏰
okay so the routing task runs its own retransmission timer, and it's giving reliability 🔁
- an Update Request packet keeps getting retransmitted on a regular schedule until an Update Flush packet shows up. an Update Flush packet is just an Update Response packet with the Flush field set, and it need not contain any routes 🧹
- an Update Response packet keeps getting retransmitted on a regular schedule until an Update Acknowledge packet arrives with the same Sequence Number 🫶
with call setup on the WAN taking about a second, 5 seconds is the right value for the retransmission timer ✨
to guard against failures in the circuit manager, a limit SHOULD be placed on the number of retransmissions 🛡️ if no response comes back after a configurable amount of time (say 180 seconds), the routes via that next hop router get marked as unreachable, the hold down timer starts, and the entry is advertised as unreachable on other interfaces 💀
after that, the next hop router can be polled with Update Requests, but at a lower frequency. a sensible poll interval is minutes rather than seconds 🐢 you could also start an Update Request through administrative action instead. when a response finally comes back, the routers should do a complete exchange of routing information 💖
6.4 Over-subscription Timer 🎀
over-subscription is when there are more next hop routers to send updates to on the WAN than there are channels 📞 for example, 3 next hop routers hooked up to an ISDN Basic Rate Interface (BRI), which can only handle 2 calls at once 😭
to avoid route oscillation, routes may NOT be marked unreachable right away when the circuit manager sends a circuit down message 🙅♀️ a timeout MAY be used to delay marking them unreachable long enough for the calls to "time division multiplex" over the channels that are available 🧚 a timeout as long as the regular 180 second RIP route timeout MAY be a good fit. generally, the more over-subscription there is, the longer the timeout should be 📈
implementations that want to support over-subscription can put the delay in the circuit manager or in the routing application, whichever they like 🌸
if the delay lives in the routing application, the routing entries MUST NOT start timing out during the delay. that way, a circuit up message can be ignored if the timeout from the circuit down message hasn't expired yet. this avoids confusion if the peer previously sent a Route Flush command and was partway through an update 🙈
7. Security Considerations 🔐
the circuit manager is required to be given a list of physical addresses so it can set up a call to the next hop router 📋 the circuit manager SHOULD only accept incoming calls from that same well defined list of routers 🚫📞
elsewhere in the system, there will be a set of logical address and physical address tuples so the network protocols can run over the correct circuit 🗺️ this could be a lookup table, or in some cases there might be an algorithmic conversion between the two addresses 🧮
the routing (or service advertising) task MUST be given a list of logical addresses that triggered updates get sent to on the WAN 💌 that list MAY be a subset of the next hop routers the circuit manager keeps track of 👑
RIP Version 2 also lets you add further authentication to Triggered RIP packets 🔑 very important stuff, bestie 💅
Appendix A - Implementation Suggestion 🧠
this section is a suggestion for how the database could be structured to handle Triggered RIP 🗂️
every entry in the database gets a unique route number 🔢 every time the best route to a network changes, a global route number goes up, and the changed route gets the new number. this route number is completely internal to the router, and it has no connection to the Sequence Number sent in Update Responses to the peer 🫣
the route number needs to be big enough that it doesn't wrap around, or the routes can get renumbered before that becomes a problem 🔄 renumbering needs the database to be stable, meaning no Update Responses are queued up waiting for Acknowledgement ⏳
it's probably easier to manage the routes if they're chained together, with a pointer to a later entry (and possibly a pointer to an earlier one too), which reflects the route number and age 🔗
to do a complete update, you run through the routes from oldest to newest and send them out in Update Responses 📤 any later changes to the database get treated as sending only the changed entries, from the previous latest to the new latest ✨
when several packets are in flight, you have to be careful with retransmissions 👀 an Update Response 'retransmission' MAY be different from the original. when sending a sequence of Update Responses, each Response packet contains a number of routes, and those routes are represented by a series of routes with consecutive route numbers 🧩 here's an example with three Update Responses, Sequence Numbers 10, 11 and 12, each containing 10 routes:
Sequence Number Routes represented by Route Numbers
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, 130now say these Update Responses are NOT acknowledged, and in the meantime the routing database changes. the routes represented by route numbers 104, 112 - 116 and 127 have changed and been given new route numbers 131 - 137. the retransmission will look like this:
Sequence Number Routes represented by Route Numbers
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⚠️ VERY IMPORTANT: a retransmission must contain only the SUB-SET of route numbers that currently apply. if there are NO suitable routes to send, it is not necessary to send an empty retransmission. 🙅♀️
another 'retransmission' strategy is to always use different sequence numbers when resending updates 🔀 say you transmit packets with sequence numbers 10 through 20, and responses come back for every packet except those with sequence numbers 14 and 17. in that case, only the data in packets 10 through 13 can be considered acknowledged. the data from packet 14 onwards MUST be re-sent, with new sequence numbers starting at 21 🦋
References 📚
[1] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers 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.
Authors' Address 🖊️
Gerry Meyer Shiva Stanwell Street Edinburgh EH6 5NG Scotland, UK
Phone: (UK) 131 554 9424 Fax: (UK) 131 467 7749 Email: gerry@europe.shiva.com
Steve Sherry Xyplex 295 Foster St. Littleton, MA 01460
Phone: (US) 508 952 4745 Fax: (US) 508 952 4887 Email: shs@xyplex.com 💜
📦 where this page comes from
- ietf: rfc2091 1997-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms