RFC 1582
Extensions to RIP to Support Demand Circuits
Extensions to RIP to Support Demand Circuits 🎀
okay bestie, let's get into it ✨ this is RFC 1582, written by G. Meyer from Spider Systems in February 1994 🌸. It's in the Standards Track category, so it's an actual spec for the whole Internet community. The title block doesn't list anything it obsoletes or updates, so there's nothing to report there 💅.
Status of This Memo 📜
this is an Internet standards track protocol doc for the Internet community, and it's open for discussion and suggestions 🫶. check out "Internet Official Protocol Standards" (STD 1) for the current standardization state and status of this protocol 🦋. distribution of this memo is unlimited, so share away 💖.
Abstract 🌈
okay so running routing protocols on connection oriented Public Data Networks (like X.25 packet switched networks or ISDN) can get really expensive if you stick to the standard periodic broadcasting of routing info 😭. the cost is high because a connection basically has to stay open to every destination that gets routing info, even when nothing is using it to carry user data 💀.
routing info can also fail to get propagated if the number of destinations it needs to reach is bigger than the number of channels the router has on the Wide Area Network (WAN) 🙈.
this memo defines a generalized modification for Bellman-Ford (or distance vector) algorithm broadcasting protocols. examples include IP RIP, Netware RIP, and Netware SAP. it fixes the problems with the old methods I just mentioned, and it's giving main character energy 👑✨.
the routing protocols support a purely triggered update mechanism on demand circuits on WANs. the protocols run UNMODIFIED on LANs or fixed point-to-point links 🍓.
routing info goes out on the WAN when the routing database gets modified by new info from another interface. when that happens, a (triggered) update gets sent to a list of destinations on other WAN interfaces 🧚. datagram-based protocols aren't guaranteed to reach the peer router on the WAN, so there's an acknowledgement and retransmission mechanism to make sure routing updates actually get received 🔥.
the WAN circuit manager tells the routing apps which destinations on the WAN are reachable and which aren't 💜.
Acknowledgements 🫶
I'd like to thank my colleagues at Spider, especially Richard Edmonstone, Tom Daniel and Alam Turland, plus Yakov Rekhter (IBM), Martha Steenstrup (BBN), and the members of the RIP-2 working group of the IETF. their discussions and comments helped clarify this memo, and they're literally iconic 🌟.
Conventions 💅
the following language conventions are used in the items of specification in this document:
- 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 ........................................... 3
2. Running a routing Protocol on the WAN .................. 4
2.1. Overview ......................................... 4
2.2. Presumption of Reachability ...................... 6
2.3. WAN Router list .................................. 7
2.4. Triggered Updates and Unreliable Delivery ........ 8
2.5. Guaranteeing delivery of Routing Updates ......... 8
2.6. The Routing Database ............................. 9
2.7. New Packet Types ................................. 10
2.8. Fragmentation .................................... 12
2.9. Preventing Queue Overload ........................ 13
3. IP Routing Information Protocol Version 1 .............. 13
4. IP Routing Information Protocol Version 2 .............. 16
5. Netware Routing Information Protocol ................... 17
6. Netware Service Advertising Protocol ................... 20
7. Timers ................................................. 24
7.1. Database Timer ................................... 24
7.2. Retransmission Timer ............................. 25
7.3. Reassembly Timer ................................. 26
8. Implementation Considerations ...........................27
9. Security Considerations ................................ 27
10. References ............................................. 28
11. Author's Address ....................................... 291. Introduction 🦋
okay so routers get used on connection oriented networks, like X.25 packet switched networks and ISDN, so one router can have potential connectivity to a bunch of remote destinations 🌸. WAN circuits get set up on demand and let go once the traffic dies down. depending on the app, the connection between any two sites for user data might be super short and pretty rare ✨.
practical experience shows that periodic 'broadcasting' of routing updates on the WAN is unsatisfying in a few ways 😭:
- running a routing protocol like RIP is expensive if you stick to the standard approach of sending routing info to every next hop router every 30 seconds. the more routers that want to swap info, the worse it gets 💀. if there are N routers on the WAN,
N * (N - 1)routing updates get sent overN * (N - 1)/2connections every broadcast period 🔥.
the cost comes from the fact that a circuit has to stay open to each destination that gets routing info. routing updates are frequent enough that setting up a call just for the length of one update doesn't help much on most networks 🙅♀️. (there are often minimum call charges, or a charge to set up a call no matter what data gets sent.)
lowering the 'broadcast' frequency would cut the cost, but the system would be less responsive 🫠.
- the number of networks to connect (N) on the WAN can easily be bigger than the number of simultaneous calls (M) the interface can handle 😬. if that happens, the routing 'broadcast' only reaches M next hop routers, and the other (N - M) next hop routers don't get the update 💔.
a basic rate ISDN interface supports 2 simultaneous calls, and even the number of logical channels most people subscribe to on an X.25 network isn't large 🙈. there's no fundamental reason routing protocols should limit you to routing between so few sites 👑.
- there's no broadcast facility on the WAN, so 'broadcasting' routing info actually means sending the updates separately to every known location. that means N routing updates get queued for transmission on the WAN link, on top of any data that's already queued 📦.
routers take a pragmatic view on queuing datagrams for the WAN. if the queue gets too long, so the datagrams at the end would take too long to transmit in a reasonable time (say 1 to 2 seconds), the router may start discarding them 😱. on an X.25 network with slow line speeds (maybe 9600 baud), it doesn't take many routing updates to hit that point if the link is also busy carrying user data 🥲.
this memo addresses all the above problems 💖.
the approach is to modify the routing protocols so they send info on the WAN only when there's been an update to the routing database OR when the task that manages WAN connections indicates a change in the reachability of a next hop router ✨.
because datagrams aren't guaranteed to get through on all WAN media, an acknowledgement and retransmission system is required to provide reliability 🫶.
this memo describes the modifications needed for Bellman-Ford (or distance vector) algorithm information broadcasting protocols, like IP RIP [1,2] or Netware RIP and SAP [3] on the WAN 🧚. the protocols run unmodified on Local Area Networks (LANs) or fixed point-to-point links, so they interoperate transparently with implementations that follow the original specs 🌈.
2. Running Routing Protocols on the WAN 🚀
2.1 Overview ✨
okay so multiprotocol routers live on connection oriented WANs like X.25 packet switched networks and ISDN, and their whole job is connecting LANs together 🌐. the bestie part is that they use the multiplexing properties of the WAN tech, so several LANs can be interconnected at the same time through one physical interface on the router. iconic efficiency 💅
a circuit manager is the middleman 🎀 it sits between the connectionless network layers (IP, IPX, CLNP etc) and the connection oriented WAN (X.25 or ISDN). here's a rep stack so you can see how routing protocols, network layers, the circuit manager and the WAN all fit together 🦋
-------------- --------- ---------
| RIP | | RIP | | SAP |
-------------- --------- ---------
| | |
-------------- | |
| UDP | | |
-------------- | |
| | |
-------------- ----------------
| IP | | IPX |
-------------- ----------------
| |
-------------------------------------------
| Circuit Manager |
-------------------------------------------
||||||||||
||||||||||
---------------------------
| Connection Oriented |
| WAN stack |
---------------------------the circuit manager is lowkey doing a lot 😭 on its upper interface it supports a variety of network layer protocols, and on its lower interface it may support one or more subnetworks. a subnetwork may support a number of Virtual Circuits, so there's a whole layered vibe going on 🧚
Figure 1. Representative Multiprotocol Router stack 🌸
the router keeps a translation table that connects the network layer address of the next hop router to the physical address it uses to set up a Virtual Circuit (VC) to that router 💜 datagrams may get encapsulated in a header so the network layer protocol can be told apart [5] 🫶
the circuit manager grabs datagrams from the connectionless network layer protocols, and if there isn't already a VC to the next hop router, it opens one 🔥 a VC can carry all the traffic between two end-point routers for one network layer protocol, or with the right encapsulation, for all of them ✨ an idle timer closes the VC once datagrams stop arriving at the circuit manager, so nothing is left hanging around 🌈
running routing protocols on the WAN has traditionally meant making small tweaks to the methods used on LANs 🍓 where routing info would be broadcast periodically on a LAN interface, it's turned into a series of periodic updates sent to a list of addresses on the WAN.
this memo targets two areas:
- eliminating the overkill that comes with sending routing updates periodically 💀
- overcoming the bandwidth limitations on the WAN, which means the number of simultaneous VCs to next hop routers and the restricted data throughput the WAN link can handle 🙈
the first one gets fixed by only sending routing updates (called routing responses) when they're actually needed ✨
- firstly, when a specific request for a routing update comes in.
- secondly, when the routing database gets changed by new info from another interface.
this kind of update info isn't usually passed on to other interfaces right away. it waits a few seconds so info from several updates can get grouped together 🎀
- thirdly, when the circuit manager says a destination has moved from unreachable (circuit down) to reachable (circuit up) 👑
because a datagram based system is inherently unreliable 😭, both routing requests and routing responses need acknowledgement, and they get retransmitted if an acknowledgement is NOT received 💅
to deal with bandwidth limits, the routing application can do a form of self-imposed flow control 🦋 it spreads routing updates out over a period of time so it's not flooding the link all at once.
2.2 Presumption of Reachability 🔮
if a routing update comes in from a next hop router on the WAN, the entries in that update are from then on always considered reachable, unless someone proves otherwise 💖
- if, in the normal course of routing datagrams, the circuit manager fails to connect to the next hop router, it tells the routing application that the router isn't reachable through an internal circuit down message 💀
the routing application then starts timing out database entries so they become unreachable in the routing sense 🥲
- if the circuit manager is later able to connect to the next hop router, it tells the routing application the router is reachable again, through an internal circuit up message 🌸
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 ✨
handling circuit up and circuit down messages means the circuit manager is responsible for setting up (or setting up again) the connection if a next hop router becomes unreachable 🫶 how the circuit manager actually does that is outside the scope of this memo, so that's a different story 📖
2.3 WAN Router list 📋
the routing task MAY be given a list of routers to send routing updates to on the WAN 🧚 the list is made up of the logical addresses of next hop routers that the router has a logical to physical address mapping for. entries in the list SHOULD be sorted (on a per-peer basis) into these categories:
- running the standard routing protocol, which means sending updates periodically with the packet formats used in LAN broadcasts 💜
this option is there so it can play nicely with existing routing implementations, and it might also make sense if some of the destinations are using Permanent Virtual Circuits (PVCs) instead of SVCs 🎀
- running the triggered update routing protocol proposed in this memo ⭐
leaving an address out of both of these categories is the same as not running the routing protocols at all 🙈
if routing packets come in from a destination that doesn't support the right variant, they MUST be discarded 🚫 no exceptions, periodt 💅
2.4 Triggered Updates and Unreliable Delivery 💥
if triggered update info only gets sent to next hop routers on the WAN once, it can fail to arrive for one of these reasons 😭
- a free VC resource might not be available, because there's a restricted number of X.25 logical channels or ISDN B-channels 🍓
- the transmit queue might be full, which means the datagram has to be discarded 💀
- the VC might be pre-empted (in favour of setting up a VC to another next hop router) while the datagram is sitting in a queue. that flushes the queue and the datagram gets discarded 🌈
- when the method of transport isn't guaranteed, like with PPP where there's no acknowledgement and no retransmission of HDLC frames, a corrupted frame means the datagram is lost 🥀
2.5 Guaranteeing delivery of Routing Updates 🛡️
to guarantee that routing updates get delivered on the WAN, an acknowledgement and retransmission scheme MUST be used ✨ the flow goes like this:
- send a routing update to a next hop router on the WAN 🚀
- the other router responds with an acknowledgement packet, and the original router receives that acknowledgement 🫶
- otherwise, the original router keeps retransmitting the update until an acknowledgement comes back 🔁
retransmission timer values are covered in section 7 ⏰
if the routing database changes before an acknowledgement arrives, a new routing update with an updated sequence number gets sent out. if an acknowledgement for the old routing update shows up, it gets ignored 🙈
- a router only updates its routing database once it has a complete update, which may come in several fragments 🧩 each fragment is acknowledged on its own.
this mechanism covers the cases where the datagram gets lost because of a frame error or gets discarded because the queue was overfull 🌸 the routing update and the acknowledgement will eventually both get through, so we're not giving up on them 💖
if the circuit manager can't establish a connection, there's a mechanism that lets the circuit manager tell the routing task about the failure 📣 the routing task can then hold off on retransmissions until a circuit is available, which is very considerate of it honestly 🥹
2.6 The Routing Database 🗄️
if you're using triggered updates to spread routing info, there's one big rule 🚨 NO routing information ever gets LOST or DISCARDED 😭
the routing database MUST adopt one of these strategies:
- it must keep ALL the alternative routing information it learns from any routing updates from the LAN and the WAN. that way, if the best route disappears, an alternative route (if there is one) can replace it as the new best route 👑
- if the memory that takes up is a problem, the routing application must keep SOME alternative routing information instead, say a best route and two alternatives 🧠
if the router ever has to throw away routing info about a route, it should note that it did 📝 if the routes it kept disappear because they've become unreachable, the router MUST send a request on all interfaces to try and get the discarded alternatives back 🔍
it is recommended that the request goes out BEFORE all routes to a destination have been lost ⏳
entries in the routing database can be permanent or temporary 🌈 entries learned from broadcasts on LANs are temporary. they'll expire if they aren't refreshed by more broadcasts 🍂
entries learned from a triggered response on the WAN are 'permanent' 💎 they MUST not time out in the normal course of events. the state of these entries MUST be changed to 'temporary' by these events:
- the arrival of a routing update that has the entry set to unreachable 💀
the normal hold down timer MUST be started, and after that the entry disappears from the routing database 🫠
- the arrival of a routing update where the entry is absent 👻
if the hold down timer isn't already running, the entry MUST be set to unreachable and the hold down timer started 🕰️
- a message from the circuit manager saying it failed to make a connection in normal running 📩
the routing table MUST be scanned for all routes via that next hop router, and aging of those entries MUST commence 🧹 if the aging timer expires, the entry MUST be set to unreachable and the hold down timer started. if the hold down timer expires, the entry disappears from the routing database 👋
- if the interface goes down, the circuit manager should indicate that all circuits on that interface have gone down 🔌
database timer values are covered in section 7 ⏰💜
2.7 New Packet Types ✨
okay bestie, to make triggered updates work, three new packet types MUST be supported 💅:
TRIGGERED REQUEST 🎀
this one basically asks the responding system to send over all the appropriate elements in its routing database 📬
a triggered request keeps getting resent at periodic intervals until a triggered response comes back 🔁
so when do you actually send these? here's the tea ☕
- Firstly, when the router is powered on ⚡
- Secondly, when the circuit manager says a destination has been in an unreachable (
circuit down) state for an extended period and it flips to a reachable (circuit up) state 🔌 - Thirdly, if all the routing update fragments fail to show up within a set period 😬
- It may also send triggered requests at other times to make up for tossing out non-optimal routing information 🗑️
TRIGGERED RESPONSE 💜
this one's a message with all the appropriate elements of the routing database packed inside 📦. An appropriate element is an entry NOT learned from the interface the routing information is going out on. This is called "split horizon" 🙅♀️
stability gets a glow-up with "poisoned reverse" 🧪. On routes learned from a destination, you also include some of those routes in the updates sent back to that destination, but you mark them as unreachable. A route only gets poisoned if it's the best route (rather than an inferior alternative route) in the database.
a triggered response can be sent back as a reply to a triggered request, or it can be an update that goes out because the routing database changed 🔄
this one's non-negotiable 🚨: a triggered response MUST be sent in response to a triggered request, even if there are no routes to propagate. That's the case for a host that only has a WAN interface but still wants to run the triggered update protocol 🖥️
a triggered response keeps getting resent at periodic intervals until a triggered acknowledgement arrives 🔁
TRIGGERED ACKNOWLEDGEMENT 🦋
it's the reply sent for every triggered response packet that comes in 🤝
now the packet fields. Triggered response and triggered acknowledgement packets MUST contain additional fields for a sequence number, fragment number and number of fragments 🧩
if a triggered request or response isn't acknowledged after 10 retransmissions, the routes to that destination should get marked as unreachable for the duration of a hold down timer, and only then get deleted 🕰️
then the destination gets polled at a lower frequency using triggered request packets 🐢. When a triggered response comes back, the router should prime the next hop router by sending its routing database through triggered response packets 💌
strictly speaking, polling should happen indefinitely to keep the database intact 🧠. However, the administrator MAY wish the router to stop polling after a few attempts, believing the silence is a mis-configuration of the next hop router 🤷♀️. In that case, the destination should be marked as NOT supporting the mechanism, and no more routing messages should be sent to it 🚫
before marking the destination as not supporting the mechanism, at least 5 triggered request polls (without acknowledgement) should be sent 📣
plot twist 🎭: if a destination that was marked as not supporting the mechanism later sends a valid 'triggered' message, it should be marked as supporting the mechanism once more (so the next hop router's configuration changes can be allowed for). It should then be sent a triggered request and a triggered response to obtain and propagate up-to-date routing information 🌈
2.8 Fragmentation 🧩
if a routing update is big enough, the information MUST be fragmented across several triggered response packets 📚:
- each fragment MUST be individually acknowledged with a triggered acknowledgement packet 🫶
the sender of the routing update MUST keep retransmitting fragments that haven't been acknowledged, periodically (or until the destination gets marked as not supporting the mechanism) 🔁
- a router that receives fragments MUST re-assemble them before updating its routing database 🪡
- if not all fragments arrive within four times the retransmit period, they MUST be discarded 🗑️
then a triggered request packet MUST be sent to the originator of the routing update 📨
when the originator gets that triggered request packet, it MUST retransmit all fragments 💥
- if a fragment with an updated sequence number shows up, all fragments with the earlier sequence number MUST be discarded 👋
an updated sequence number is defined as any sequence number that is different. There's no concept of the sequence number's value telling you how old it is 🕰️
fragmentation timer values get their own moment in section 7 ⏰
2.9 Preventing Queue Overload 🚦
to stop too many routing messages piling up in the queue at a WAN interface 🚧, the routing task MAY run a scheme where "broadcasting" a triggered request or triggered response to a WAN interface gets staggered. Basically, all routing requests or routing responses are not sent to all next hop routers on the interface in one big batch:
- the routing task should limit how many triggered request messages are still waiting on a triggered response 🙅
- the routing task should limit how many triggered response messages are still waiting on a triggered acknowledgement ⏳
as outstanding messages get properly acknowledged, more messages can go out to other next hop routers 💨, until every next hop router has been sent the message and has acknowledged it ✅
the max number of outstanding messages sent without acknowledgement depends on the link speed and on how many other routing protocols are running the triggered update mechanism 🏎️
messages should always be acknowledged immediately (even if it pushes past the limit), since a connection is almost certainly available 💖. That has the potential benefit of letting the VC close sooner (on its idle timer) ⏲️
sending all the triggered request fragments to a destination at once is also beneficial ✨
3. IP Routing Information Protocol Version 1 🎀
okay bestie, this section is meant to be read alongside reference [1] 📚✨
IP RIP is a UDP-based protocol, and it generally sends and receives datagrams on UDP port number 520 🦋
to make the mechanism in this proposal work, the packet format for RIP version 1 [1] gets a glow-up, as you can see in Figure 2 💅
Every Routing Information Protocol datagram contains the following 👑
COMMAND 💌 Commands supported in RIP Version 1 are: request (1), response (2), traceon (3), traceoff (4), SUN reserved (5). The fields sequence number, fragment number and number of fragments MUST NOT be included in packets with these command values 🚫
The following new commands (with values in brackets) are required:
TRIGGERED REQUEST (6) 🔁
A request for the responding system to send all of its routing database.
Only the first 4 octets of the packet format shown in figure 2 are sent, since all routing information is implied by this request type.
TRIGGERED RESPONSE (7) 📬
A message containing all of the sender's routing database, excluding those entries learned from the interface to which the routing information is being sent.
This message may be sent in response to a triggered request, or it may be an update message resulting from a change in the routing database.
A triggered response message MUST be sent in response to a triggered request message even if there are no routes to propagate. This would be the case for a host which had a WAN interface only, but which wished to run the triggered update protocol 🌸
Here's Figure 2, the IP RIP packet format, in all its glory ✨
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) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
The following new fields are inserted for some commands
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
Followed by 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 is shown in octets, with each tick mark representing one bit. All fields are in network order 🧚
The four octets: sequence number (2), fragment number (1) and number of fragments (1) are not present in the original RIP specification. They are only present if command takes the values 7 or 8 🙈
Figure 2. IP Routing Information Protocol packet format 🎀
TRIGGERED ACKNOWLEDGEMENT (8) 🫶
A message sent in response to every triggered response packet received.
Only the first 8 octets of the packet format shown in figure 2 are sent.
VERSION 🌈 In this instance, Version 1.
SEQUENCE NUMBER 🔢
This is a new field inserted if command takes the values 7 or 8.
The sequence number MUST be incremented every time updated information is sent out on a WAN. The sequence number wraps round at 65535 🔄
When a triggered acknowledgement is sent, the sequence number is set to the same value as the triggered 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 routing update, and is incremented for each subsequent fragment. A fragment can contain up to 25 routing entries.
When a triggered acknowledgement is sent, the fragment number is set to the same value as the triggered response packet being acknowledged.
NUMBER OF FRAGMENTS 🧮
In a triggered response packet, this indicates the number of packets required to complete the routing update.
This field has no relevance for triggered acknowledgement packets, so it should be set to zero.
For triggered response packets, the rest of the datagram contains a list of destinations, with information about each. Each entry in this list contains the address family identifier (2 for IP), a destination network or host, and the metric for it. The packet format is intended to allow RIP to carry routing information for several different protocols, identifiable by the family identifier 🌟
The IP address is the usual Internet address, stored as 4 octets in network order. The metric field contains a value between 1 and 15 inclusive, specifying the current metric for the destination, or the value 16 (representing 'infinity'), which indicates that the destination is not reachable. Each route sent by a router supersedes any previous route to the same destination from the same router 💜
The maximum datagram size is 508 octets, excluding UDP and IP headers 📏
4. IP Routing Information Protocol Version 2 🦋
An enhancement to IP RIP to include subnetting has recently become available [2]. This section only describes differences from that RFC 💖
The triggered update mechanism can be supported by including the triggered request (6), triggered response (7) and triggered acknowledgement (8) commands described in the previous section 🔁
The sequence number, fragment number and number of fragments fields are included in triggered response and triggered acknowledgement commands 🧠
The triggered request packet should also contain the 4 extra octets corresponding to the sequence number, fragment number and number of fragments fields, but set to zero 0️⃣
Because additional security information is included in RIP Version 2 packets, this MUST be appended to the triggered request and triggered acknowledgement packets, as well as being present in the triggered response packet 🔐
⚠️ bestie, that last one is a MUST, so don't skip the security info on any of those three packet types 💀
The version number becomes 2. Other aspects of packet layout follow reference [2] 🎀
5. Netware Routing Information Protocol 💅
okay bestie, this section is a sidekick to references [3], so you have to read them together 📚 It only describes the differences from the spec, so it won't repeat everything for you 🫶
Netware [3] is the trade name of Novell Research's protocols for computer communication, which are derived and extended from Xerox Network System's (XNS) protocols [4]. the family tree is giving XNS 🌳✨
Netware supports a mechanism that lets routers on an internetwork swap routing information using the Routing Information Protocol (RIP). That RIP runs over the Internetwork Packet Exchange (IPX) protocol using socket number 453h 🦋
Netware RIP and IP RIP are cousins 👯♀️ They both come from XNS RIP, but there's some divergence, mostly at the packet format level, to reflect their differing addressing schemes 💜
The triggered update mechanism can be applied to Netware RIP. To support the mechanism outlined in this proposal, the packet format for Netware RIP is modified as shown in Figure 3 ✨
Every datagram contains the following:
RIP OPERATION 🎀
Operations supported in standard Netware RIP are: request (1) and response (2).
The fields sequence number, fragment number and number of fragments MUST NOT be included in packets with these operation values. 🙈
The following new operations are required (with values chosen to be the same as for IP RIP commands):
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+The following new fields are inserted for some operations 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+Followed by 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. All fields are in network order.
The four octets: sequence number (2), fragment number (1) and number of fragments (1) are not present in the original RIP specification. They are only present if operation takes the values 7 or 8.
Figure 3. Netware Routing Information Protocol packet format 📸
TRIGGERED REQUEST (6) 🙋♀️
A request for the responding system to send all of its routing database.
Only the first 2 octets of the packet format shown in figure 3 are sent, since all routing information is implied by this request type.
TRIGGERED RESPONSE (7) 📬
A message containing all of the sender's routing database, excluding those entries learned from the interface to which the routing information is being sent.
This message may be sent in response to a triggered request, or it may be an update message resulting from a change in the routing database.
A triggered response message MUST be sent in response to a triggered request message even if there are no routes to propagate. This would be the case for a host which had a WAN interface only, but which wished to run the triggered update protocol. no routes? still gotta reply, bestie 🥺
TRIGGERED ACKNOWLEDGEMENT (8) 🫡
A message sent in response to every triggered response packet received.
Only the first 6 octets of the packet format shown in figure 3 are sent.
SEQUENCE NUMBER 🔢
This is a new field inserted if operation takes the values 7 or 8.
The sequence number MUST be incremented every time updated information is sent out on a WAN. The sequence number wraps round at 65535 🔄
When a triggered acknowledgement is sent, the sequence number is set to the same value as the triggered response packet being acknowledged.
The sequence number MUST be identical over fragments. If a fragment is retransmitted, the sequence number MUST not change. this one is non-negotiable, no cap 🔥
FRAGMENT NUMBER 🧩
The fragment number is one for the first fragment of a routing update, and is incremented for each subsequent fragment. A fragment can contain up to 50 routing entries.
When a triggered acknowledgement is sent, the fragment number is set to the same value as the triggered response packet being acknowledged.
NUMBER OF FRAGMENTS 🍰
In a triggered response packet, this indicates the number of packets required to complete the routing update.
This field has no relevance for triggered acknowledgement packets, so it should be set to zero.
For triggered response packets, the rest of the datagram contains a list of networks, with information about each. Each entry in this list contains a destination network, and the number of hops and number of ticks for each. ✨
The maximum datagram size is 406 octets, excluding the IPX header (a further 30 octets). that's the whole vibe, periodt 🌈👑
6. Netware Service Advertising Protocol 🎀
okay bestie, read this one alongside [3] 📚 because this section ONLY covers what's different from the spec, not the whole thing 💅
Netware [3] also has a mechanism where servers on an internetwork can advertise their services by name and type. It's called 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 🌸. Routers act as SAP agents: they collect service information from different networks and relay it to interested parties 🫶.
To support the triggered update mechanism outlined in this proposal, the packet format for Netware SAP gets a glow-up 💖 and is modified as shown in Figure 4.
Every Service Advertising Protocol datagram contains the following:
SAP OPERATION 🦋
Operations supported in standard Netware SAP are: general service query (1), general service response (2), nearest service query (3) and nearest service response (4) 🍓
The fields sequence number, fragment number and number of fragments MUST NOT be included in packets with these operation values.
The following new operations are required:
TRIGGERED GENERAL SERVICE QUERY (6)
A request for the responding system to send the identities of all servers of all types 👑
Only the first 2 octets of the packet format shown in figure 4 are sent, since all service types are implied by this request type 🧚
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+The following new fields are inserted for some operations 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+Followed by up to 8 service entries (each 66 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 (4) |
+---------------------------------------------------------------+
| Service Name (48) |
+ +
.
| . |
+---------------------------------------------------------------+
| Network Address (4) |
+---------------------------------------------------------------+
| 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. All fields are in network order 🔥
The four octets: sequence number (2), fragment number (1) and number of fragments (1) are not present in the original SAP specification. They are only present if operation takes the values 7 or 8 🙈
Figure 4. Netware Service Advertising Protocol packet format
TRIGGERED GENERAL SERVICE RESPONSE (7)
A message containing all of the sender's services table, excluding those entries learned from the interface to which the service advertising information is being sent out 🎀
This message may be sent in response to a triggered general service query, or it may be an update message resulting from a change in the service advertising database ✨
A triggered general service response message MUST be sent in response to a triggered general request message even if there are no services to advertise. This would be the case for a router with a LAN network which had work stations but no servers on it 💀
TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)
A message sent in response to every triggered general service response packet received 🫶
Only the first 6 octets of the packet format shown in figure 4 are sent 🦋
SEQUENCE NUMBER 🔢
This is a new field inserted if operation takes the values 7 or 8 💖
The sequence number MUST be incremented every time updated 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 it 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:
- Database timers.
- Retransmission timer.
- 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 means they do NOT time out unless one of the following events kicks them off 💥
- 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 🧚
- 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 the entry is advertised as unreachable on other interfaces. On expiry of the hold down timer, the entry is deleted 👑
For IP RIP, the hold down timer should always run for 120 seconds, to be consistent with RIP usage on broadcast networks. The database entry timer should by default run for 180 seconds. The network can be made more responsive by reducing the database entry timer value. However, making this timer too short can lead to network instabilities 😭. The duration of the database entry timer allows a period of grace in which contention for network resources can be resolved by the circuit manager 🍓
7.2 Retransmission Timer
The routing task runs a retransmission timer:
- When a triggered request is sent, it will be retransmitted periodically while a triggered response packet is not received.
- When a triggered response is sent, a note of the sequence number and fragment number(s) of the routing update is kept.
Fragments will be retransmitted at periodic intervals while a triggered acknowledgement packet is not received for the appropriate fragment 🔁
With call set up time on the WAN being of the order of a second, a value of 5 seconds for the retransmission timer is appropriate ⭐
If no response is received after 10 retransmissions, routes via the next hop router are marked as 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 🙈
The next hop router is then polled using a triggered request packet at 60 second intervals. If a response is received, the routers should exchange routing information using triggered response packets 🦋
It may not be desirable to poll indefinitely, since a lack of response (when a circuit is up) is most likely caused by incorrect configuration of the next hop router. An administrator definable number of polls (5 or greater) should be provided 🧩
If the circuit manager indicates that the next hop router is unreachable, the retransmission is suppressed until the circuit manager indicates that the next hop router is reachable once more. Counting of the number of retransmissions continues from where it left off prior to the circuit down indication 💜
7.3. Reassembly Timer ✨
okay bestie, so when a router gets a triggered response update, it MUST acknowledge each fragment 🫶 If the update got chopped up over more than one packet, the receiving router MUST store the fragments until ALL fragments are received 📦 no half-finished updates allowed, periodt 💅
The moment the first fragment shows up, a timer should be started ⏰ If all the fragments don't make it in before that period is up, they get tossed 🗑️ and a triggered request goes back to the originator (with retransmissions if needed). Then the originator MUST resend ALL triggered response fragments 🔁 which is giving second chances, no cap ✨
The reassembly timer should be set to four times the retransmission timer 🧮 So if the suggested retransmission timer is 5 seconds, the suggested reassembly timer SHOULD be 20 seconds ⏳ the math checks out, bestie 🎀
Implementations MAY let you configure the reassembly timer and the retransmission timer, as long as you keep that 1:4 ratio 🎛️ but heads up: interoperability will be compromised on WANs where all the participating routers DO NOT use the same values for these timers 😬 that's a whole vibe problem 💀
Last thing! Fragments MUST also be discarded if a new fragment with a different sequence number shows up 🚫 and in that case a triggered request MUST not be sent 🙅♀️
8. Implementation Considerations 🛠️
So in the implementation this memo describes, the circuit manager and the routing applications are assumed to be super close, like they're basically the same 'program' 👯♀️ That's not necessarily true for every product that's a router though 🙃
Like, there are UNIX host implementations where the routing application is separate from the kernel, and that's usually where the circuit manager gets installed 🐧 In those setups you can stop (or crash) the routing applications without touching anything going on in the kernel 💥
Other implementations might put the circuit manager on its own separate card, which can give it a whole life of its own 🃏
Now, when the applications and the circuit manager have independent lives, a keep-alive mechanism MUST be provided between them 💓 That way, if the application or network layer dies and gets restarted, they can resynchronize their state tables 🔄
Ideally, when an application dies, the circuit manager should close all existing VCs for that application, make no further outgoing calls, and reject incoming calls until the application is running again 📵
If the circuit manager is using some form of encapsulation, several applications might be sharing the same VC 🧦 In that case the circuit manager may wish to filter out datagrams for the appropriate network layer, but only if just one of the applications is affected. But honestly? That's not an ideal solution 😅
Conversely, if the application thinks the circuit manager has died, it should mark all routes via the circuit manager as unreachable and advertise them on other interfaces for the duration of the hold down timer before deleting them 🗺️
9. Security Considerations 🔐
Okay, security time, bestie 🚨 Security is provided by a number of aspects:
- The circuit manager is required to be provided with a list of physical addresses so it can set up a call to the next hop router on an X.25 SVC or ISDN B-channel 📞
The circuit manager SHOULD only allow incoming calls to be accepted from the 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 run over the correct circuit 🗝️ This may be a lookup table, or in some instances there may be an algorithmic conversion between the two addresses 🧮
- The routing (or service advertising) task MUST be provided with a list of logical addresses to which triggered updates are to be sent on the WAN. The list MAY be a subset of the list of next hop routers maintained by the circuit manager. 🎯
There MAY also be a separate list of next hop routers to which traditional broadcasts of routing (or service advertising) updates should be sent. Next hop routers omitted from either list are assumed to be not participating in routing (or service advertising) updates. 👀
The list (or lists) doubles as a list of routers from which routing updates are allowed to be received from the WAN. Any routing information received from a router not in the appropriate list MUST be discarded. 🛑
10. References 📚
Here are the receipts, bestie 🧾
[1] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1388, Xylogics, January 1993.
[3] Novell Incorporated., "IPX Router Specification", Version 1.10, October 1992.
[4] Xerox Corporation., "Internet Transport Protocols", Xerox System Integration Standard XSIS 028112, December 1981.
[5] Malis. A., Robinson. D., and R. Ullmann, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN Communications, Computervision Systems Integration, Process Software Corporation, August 1992.
11. Author's Address 💌
Meet the author, Gerry, the brain behind all of this 🧠🌸
Gerry Meyer
Spider Systems
Stanwell Street
Edinburgh EH6 5NG
Scotland, UK
Phone: (UK) 31 554 9424
Fax: (UK) 31 554 0649
EMail: gerry@spider.co.uk📦 where this page comes from
- ietf: rfc1582 1994-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms