RIP Specifications

  1. Format of RIP Datagram (And RIP commands)
  2. Addressing considerations
  3. Timers
  4. Input processing
  5. Output processing


Format of RIP Datagram:

The format of the RIP header is shown here:

 EACH WORD (LINE) IS 32 BITS
 THE FIELDS SIZE (e.g, (1) ) ARE IN OCTETS

The portion of the datagram from address family field through metric may appear up to 25 times. IP address is the usual 4-octet Internet address, in network order. The special address 0.0.0.0 is used to describe a default route. The address family identifier for IP is 2. The metric field must contain a value between 1 and 15 inclusive, specifying the current metric for the destination, or the value 16, which indicates that the destination is not reachable. The maximum datagram size is 512 octets. (IP or UDP headers not counted) Every datagram contains a command, a version number, and possible arguments.
Here is a summary of the commands implemented in version 1 of RIP:

  1. request A request for the responding system to send all or part of its routing table.
  2. response A message containing all or part of the sender's routing table. This message may be sent in response to a request or poll, or it may be an update message generated by the sender.
  3. traceon Obsolete. Messages containing this command are to be ignored.
  4. traceoff Obsolete. Messages containing this command are to be ignored.
  5. reserved This value is used by Sun Microsystems for its own purposes. If new commands are added in any succeeding version, they should begin with 6. Messages containing this command may safely be ignored by implementations that do not choose to respond to it.

Addressing considerations

The RIP packet formats do not distinguish among various types of address. Fields that are labeled "address" can contain any of the following: When routing a datagram , its destination address must first be checked against the list of host addresses. Then it must be checked to see whether it matches any known subnet or network number. Finally, if none of these match, the default route is used.

"Border" gateway s send only a single entry for the network as a whole to host s in other networks. This means that a border gateway will send different information to different neighbors. For neighbors connected to the subnetted network, it generates a list of all subnets to which it is directly connected, using the subnet number. For neighbors connected to other networks, it makes a single entry for the network as a whole, showing the metric associated with that network. (This metric would normally be the smallest metric for the subnets to which the gateway is attached.)

Timers

Every 30 seconds, the output process is instructed to generate a complete response to every neighboring gateway .

There are two timers associated with each route, a "timeout" and a "garbage-collection time". Upon expiration of the timeout, the route is no longer valid. However, it is retained in the table for a short time, so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the tables.

The timeout is initialized when a route is established, and any time an update message is received for the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered to have expired, and the deletion process which we are about to describe is started for it.

Deletions can occur for one of two reasons: (1) the timeout expires, or (2) the metric is set to 16 because of an update received from the current gateway . (See response command for a discussion processing updates from other gateway s.) In either case, the following events happen:

- The garbage-collection timer is set for 120 seconds.

- The metric for the route is set to 16 (infinity). This causes the route to be removed from service.

- A flag is set noting that this entry has been changed, and the output process is signalled to trigger a response.

Until the garbage-collection timer expires, the route is included in all updates sent by this host , with a metric of 16 (infinity). When the garbage-collection timer expires, the route is deleted from the tables.

Should a new route to this network be established while the garbage- collection timer is running, the new route will replace the one that is about to be deleted. In this case the garbage-collection timer must be cleared.

Input processing

Before processing the recived datagram s, certain general format checks must be made. These depend upon the version number field in the datagram , as follows: After checking the version number and doing any other preliminary checks, processing will depend upon the value in the command field.
 
 

Output processing

Let describe the processing used to create response messages that contain all or part of the routing table. This processing may be triggered in any of the following ways:
- by input processing when a request is seen. In this case, the resulting message is sent to only one destination.
- by the regular routing update. Every 30 seconds, a response containing the whole routing table is sent to every neighboring gateway .
- by triggered updates. Whenever the metric for a route is changed, an update is triggered. (The update may be delayed.)

Triggered updates require special handling for two reasons. First, experience shows that triggered updates can cause excessive loads on networks with limited capacity or with many gateway s on them. Thus the protocol requires that implementors include provisions to limit the frequency of triggered updates. After a triggered update is sent, a timer should be set for a random time between 1 and 5 seconds. If other changes that would trigger updates occur before the timer expires, a single update is triggered when the timer expires, and the timer is then set to another random value between 1 and 5 seconds. Triggered updates may be suppressed if a regular update is due by the time the triggered update would be sent.

Second, triggered updates do not need to include the entire routing table. In principle, only those routes that have changed need to be included. Thus messages generated as part of a triggered update must include at least those routes that have their route change flag set. They may include additional routes, or all routes, at the discretion of the implementor; however, when full routing updates require multiple packet s, sending all routes is strongly discouraged. When a triggered update is processed, messages should be generated for every directly-connected network. Split horizon processing is done when generating triggered updates as well as normal updates.

If, after split horizon processing, a changed route will appear identical on a network as it did previously, the route need not be sent; if, as a result, no routes need be sent, the update may be omitted on that network. (If a route had only a metric change, or uses a new gateway that is on the same network as the old gateway , the route will be sent to the network of the old gateway with a metric of infinity both before and after the change.) Once all of the triggered updates have been generated, the route change flags should be cleared.

If input processing is allowed while output is being generated, appropriate interlocking must be done. The route change flags should not be changed as a result of processing input while a triggered update message is being generated.

The only difference between a triggered update and other update messages is the possible omission of routes that have not changed. The rest of the mechanisms about to be described must all apply to triggered updates.

Here is how a response datagram is generated for a particular directly-connected network:

The IP source address must be the sending host 's address on that network. This is important because the source address is put into routing tables in other host s. If an incorrect source address is used, other host s may be unable to route datagram s. Sometimes gateway s are set up with multiple IP addresses on a single physical interface. Normally, this means that several logical IP networks are being carried over one physical medium. In such cases, a separate update message must be sent for each address, with that address as the IP source address.

Set the version number to the current version of RIP.
Set the command to response. Set the bytes labeled "must be zero" to zero. Now start filling in entries. To fill in the entries, go down all the routes in the internal routing table. Recall that the maximum datagram size is 512 bytes. When there is no more space in the datagram , send the current message and start a new one. If a triggered update is being generated, only entries whose route change flags are set need be included.

Routes to subnets will be meaningless outside the network, and must be omitted if the destination is not on the same subnetted network. they should be replaced with a single route to the network of which the subnets are a part. Similarly, routes to host s must be eliminated if they are subsumed by a network route.

If the route passes these tests, then the destination and metric are put into the entry in the output datagram . Routes must be included in the datagram even if their metrics are infinite. If the gateway for the route is on the network for which the datagram is being prepared, the metric in the entry is set to 16, or the entire entry is omitted. Omitting the entry is simple split horizon. Including an entry with metric 16 is split horizon with poisoned reverse.