Previous PageNext Page

Chapter 5 - VINES Sequenced Routing Update Protocol

Introduction

Implementation Overview

Router implementation
Client node implementation
Non-sequenced RTP compatibility
Verifying routing information

Router Implementation

When network topology changes occur
When routers or client nodes specifically request routing table information

When requested
When they are new routers that have just come on the network
When they detect the presence of a new router

Client Node Implementation

Non-Sequenced RTP Compatibility

Verifying Routing Information

The validity of a router's overall routing information
The currentness of specific network information that any router advertises to its neighbor routers

Validating a Router's Overall Information

Figure 5-1. Comparing Router Sequence Numbers

The sequence number comparison
The current state of the neighbor from which the sequenced update packet is received
The contents of the sequenced update packet

Note: Routers always check their neighbors' router sequence number before accepting sequenced updates or responses. However, if the sequenced update or response consists of multiple fragments, the router does not process the routing update or response until it is fully reassembled. See "Fragmentation and Reassembly" later in this chapter for an explanation of how RTP handles fragmentation.

Neighbor States

Table 5-1. Neighbor States

Rules for Validating Router Sequence Numbers

Table 5-2. Rules for Validating Router Sequence Numbers

Table Notes

The sequence number in the packet is greater than the sequence number in the neighbor table by one
The neighbor state is UP
The received packet contains a null update

The sequence number in the packet is greater than the sequence number in the neighbor table by more than one.
The sequenced update does not contain full topology information.

Processing Accepted Routing Updates or Responses

Resets the time-to-live timer (nbidle) in the entry.
Recalculates the routing metric (nbmetric) in the entry.
Recopies the neighbor's link address (nbdladdr) from the frame header.

When a router can use multiple Token-Ring interfaces and multiple source routes to reach the neighbor, the action that the router takes depends on whether the neighbor supports sequenced RTP.

If the neighbor supports sequenced RTP, the router saves only the link address associated with the source route of the first update or response received based on the packet ID. See "Sequenced Update Packet Header Format" later in this chapter for more information on the packet ID.

If the neighbor does not support sequenced RTP, the router saves the link address associated with the source route with the lowest metric.

Note: Received router sequence numbers that are either lower than the stored router sequence number or are greater by more than one are never accepted.

The neighbor's state is not UP.
The routing update does not contain resynchronization information.

Resets the time-to-live timer (nbidle) in the entry.
Recalculates the routing metric (nbmetric) in the entry.
Recopies the neighbor's link address (nbdladdr) from the frame header.
Recopies the neighbor's link address (nbdladdr) from the frame header. When a router can use multiple Token-Ring interfaces and multiple source routes to reach the neighbor, the router copies only the link address associated with the best source route to reach the neighbor. The best source route is the one with the lowest routing metric.

If applicable, recopies the source route to reach the neighbor into the neighbor path entry.
If the neighbor provides the best route to the destination network, the router updates the network sequence number, gateway pointer, and metric field in the entry for the destination network. If the neighbor supports non-sequenced RTP, the router updates the time-to-live timer.

Updating the Router Sequence Number

The router has detected changes in the network. These entries will be contained in a routing update broadcast.
The router broadcasts a routing update.

Validating Specific Network Information

A network sequence number
A timestamp sequence number

Network Sequence Number

If the network is associated with a neighbor router, the network sequence number is extracted from the sequenced update header of the update packet received from the neighbor. See "Sequenced Update Packets" later in this chapter for a description of this header.

Thus, a router increments the network sequence number for a neighbor network only when the router associated with that network increments its router sequence number.

If the network is associated with a non-neighbor router, the network sequence number is extracted from a tuple for the network in the update packet. See the section "Sequenced Update Packets" later in this chapter for a description of this packet.

A router increments the network sequence number for a non-neighbor network only when the router associated with that network is involved in a network change, such as a change in the metric for reaching the router's network.

Example Network Sequence Number

Timestamp Sequence Number

A new network comes on line.
The metric for reaching a network increases.
A network becomes unreachable.
"Good news" concerning the network, such as a decreased metric, no longer needs to be suppressed and can be advertised.

Example Timestamp Sequence Number

Validating Network Sequence Numbers

Neighbor Network

Example Using the Router Sequence Number to Validate a Network Entry

Figure 5-2. Sequence Numbers on Neighbor Routers

The metric (netmetric and nbmetric) for the route between Server A and Server B is 4.
Server A's current router sequence number (nbseqno) is 3 and Server B's current router sequence number is 4.
The network sequence number in the network entry for Server A is 3, which matches Server A's current router sequence number.
Server B timestamped the network entry for Server A with a timestamp sequence number of 2. This means that Server B increased its router sequence number from 1 to 2 when it learned of Server A's existence.

Figure 5-3. Updating Neighbor Network Entries

A new neighbor path entry is created for the Ethernet LAN.
The metric (netmetric) in the network table for the route between Server A and Server B changed from 4 to 2 because the higher throughput capacity of the 10 Mbps Ethernet LAN.
Server A's current router sequence number (nbseqno) changed from 3 to 4, and Server B's current router sequence number changed from 4 to 5. This happens because both servers detect the network change.
The network sequence number in the network entry for Server A (netownseqno) changed from 3 to 4, matching Server A's current router sequence number.
Server B timestamped the network entry for Server A with a timestamp sequence number of 5.

Non-Neighbor Network

Example Using the Network Sequence Number to Validate a Network Entry

Figure 5-4. Sequence Numbers on Neighbor and Non-Neighbor Routers

The metric (netmetric) for the route between Server A and
Server C is 6, which is the sum of the 4-Mbps Token-Ring metric (4) and the 10 Mbps Ethernet metric (2). The metric for the route between Server B and Server C is 2.
Server A's current router sequence number (nbseqno) is 3, Server B's current router sequence number is 4, and Server C's current router sequence number is 5.
The network sequence number in the network entry for Server A is 3. This means that Server A's current router sequence number was 3 when Server C learned of Server A.
The network sequence number in the network entry for Server B is 4, which matches Server B's current router sequence number.
Server C timestamped the network entry for Server A with a timestamp sequence number of 5. This means that Server C increased its router sequence number from 4 to 5 when it learned of Server A's existence.
Server C timestamped the network entry for Server B with a timestamp sequence number of 5. This means that Server C increased its router sequence number from 4 to 5 when news of network changes was received from Server B.

Figure 5-5. Updating Non-Neighbor Network Entries

Validates Server B's knowledge of the network with the router sequence number in the RTP header
Validates Server A's network entry with the network sequence number in the data portion of the sequenced RTP packet

The metric (netmetric) for the route between Server A and Server C changed from 6 to 4 because the higher throughput capacity of the 10 Mbps Token-Ring.
Server A's current router sequence number (nbseqno) changed from 3 to 4; Server B's current router sequence number changed from 4 to 5; and Server C's current router sequence number changed from 5 to 6.
The network sequence number in the network entry for Server A (netownseqno) changed from 3 to 4. The network sequence number was 3 because Server A's network number was 3 when Server C last received news of a change to Server A.
Server B advertised a network sequence number for Server A that was greater than the number that Server C stored for Server A. Server C accepted Server B's advertisement as a better metric to reach Server A.
Server C timestamped the network entry for Server A with a timestamp sequence number of 6.
Server C updated Server B's network sequence number, but did not modify the timestamp sequence number for Server B's network entry. Server C did not modify the timestamp because the news of the change did not involve Server B's logical network.

Timestamping Network Entries

1. The requesting router looks at the current router sequence number for the neighbor router in its neighbor table, and furnishes that number in the request.

2. The neighbor router uses the furnished sequence number as a reference point. The neighbor router responds with just the network entries that have timestamp sequence numbers greater than the furnished sequence number. In the sequenced packet header, the neighbor router includes its current router sequence number.

RTP takes into account detection of a wrap around condition. See "Detecting a Wrap Around Condition" later in this chapter for more information.

Example Timestamp Sequence Numbers

1. Compares its current router sequence number (5) to the timestamp sequence numbers in all of its network entries.

2. Determines that two entries have timestamp sequence numbers (6) greater than its current router sequence number.

3. Includes information from the two entries in its next routing update.

4. Increments its current router sequence number to 6, including incremented sequence number in the sequenced update header.

5. Broadcasts the packet.

Detecting a Wrap Around Condition

1. When the router receives a router sequence number from a neighbor, the router checks to see if the received number is 1 greater than the sequence number stored for the neighbor in the router's neighbor table.

2. If the received router sequence number is not 1 greater than the sequence number stored for the neighbor, the router subtracts the stored sequence number from the received sequence number. The router stores the number resulting from this calculation in a signed long variable.

3. The action that the router takes depends on the number resulting from the calculation.

If the number is greater than 0 (zero), the router missed some routing updates from the neighbor.

If the number equals 0 (zero), the received sequence number equals the sequence number stored for the neighbor.

If the number is less than 0 (zero), the received sequence number is outdated.

Reconnecting to the Network

current sequence number + max changes
---------------------------------------------------------------
stored sequence number

max. changes = cache period (in seconds) / 2 second intervals
= 1800/2
= 900

Note: This description of stored sequence numbers may not be correct on platforms that do not support native VINES, such as third-party routers. To accommodate these platforms, sequenced RTP implements sequenced re-initialization packets, which are described in "Sequenced Re-initialization Packets" later in this chapter.

Sample Use of Sequence Numbers

Figure 5-6. Network with Three Routers

Figure 5-7. Server D Comes on the Network

Figure 5-8. Server B Learns of Server D and Builds Server D's Network Table

Server B has incremented its router sequence number to 3 and timestamped the entry for Server D with 3.
Server D stores 3 as the network sequence number for Server D.

Figure 5-9. Server B Updates Server A and Server C

Figure 5-10. All Neighbors Update Each Other

Server A and Server C timestamp the network entry for Server D with the incremented sequence numbers and increment their router sequence numbers by 1.
Server B increments the network sequence numbers for all of the other servers (including Server D) because it received routing update broadcasts from the three other servers containing incremented sequence numbers.
Server A and Server C store a sequence number of 0 (zero) for Server D since 0 (zero) is the sequence number they received from Server B when they learned of Server D.
Server D updates its own router sequence number after broadcasting an update.

Figure 5-11. Routing Update Process Has Completed

VINES Sequenced RTP Specification

Sequenced RTP Packet Format

Sequenced update packet broadcast to LAN neighbors
Sequenced re-initialization packet broadcast to LAN neighbors

Figure 5-12. Sequenced RTP Packet Format

Sequenced requests
Sequenced updates
Sequenced redirects
Sequenced re-initialization

Table 5-3. Sequenced Operation Type Field Values

Table 5-4. Sequenced Node Type Field Values

Example Version Mismatch

Routers that do not support sequenced RTP
Client nodes that do not support sequenced RTP

Example Neighbor Routers that Do Not Support Sequenced RTP

The neighbor can only be reached across a non-VINES network, such as a TCP/IP network or NetWare network.
The connection to the neighbor router was automatically configured.

Discards the packet
Informs the TCP/IP or IPX/SPX protocol of the invalid connection

Example Avoiding Automatic Connections

Sequenced Request Packets

The destination VINES internet address set to the VINES broadcast address
The destination data link layer address set to the address of the destination node

When they communicate with routers and other client nodes outside of their routing server's logical network. The request packet requests the routing server to send a sequenced update packet, which contains routing metric information used by the client node to communicate with the destination.
When they communicate with their routing server through a Token-Ring bridge. The request packet requests the routing server for the appropriate routing metric to reach it.

Note: Routers that support sequenced RTP respond to client node routing requests differently than routers that support non-sequenced RTP. For example, while 5.0 servers reply with a routing response packet, 5.5 servers reply with a routing update packet. The RTP header indicates that the routing update packet is of the response type.

When they establish a WAN connection
When they detect the loss of a routing update
During the initial routing update exchange with a new neighbor that supports sequenced RTP
When they cannot reassemble a multipacket update or response

Sequenced Request Packet Header Format

Figure 5-13. Sequenced Request Packet Header Format

0x1 Value - Requests routing information for a specified list of networks. Client nodes must request this information from their routing servers to communicate with logical networks outside their own. The response provides the real metric for reaching these networks, replacing the educated guess metric that the client node uses initially. The client node includes a desired list of the network IDs in the data portion of the request packet.

0x2 Value - Requests routing information on changes in the network topology that have occurred since a specific point in time. A router usually requests this type of information when it detects a loss of a routing update from a neighbor router. The router sends the request directly to the neighbor router. The router provides the sequence number from the last valid update or response received from the neighbor as the reference point. The router includes the sequence number in the data portion of the packet.

0x4 Value - Requests full topology information (that is, information about all known networks) from another router. A router can request this information for synchronization purposes or during the establishment of a WAN connection. The data portion of the request packet is empty.

0x8 Value - Requests a simple response from a routing server. A simple response consists of a routing update packet with just packet headers and no routing information in the data portion of the packet.

Sequenced Request Packet Data

Requests for information on specific networks
Requests for routing information on changes in the network topology that have occurred since a specific point in time

Sequenced Update Packets

Propagate news of network changes
Inform neighbors of each other's continued presence
Respond to routing request packets

Propagate News of Network Changes

Inform Neighbors of Continued Presence

Respond to Routing Request Packets

Sequenced Update Packet Header Format

Figure 5-14. Sequenced Update Packet Header

Table 5-5. Information Type Field Values

The network has come on line.
The network is no longer reachable.
The network can be reached through a better route.
The network is no longer suppressed. See Chapter 4 for a description of suppression.
The router forced routing information to a neighbor. When a neighbor loses its direct path to a corresponding network and has a backup route through a router, this action tells the neighbor that the router can act as a gateway to the destination. See "When the "Help Thy Neighbor" Scenario Takes Place" later in this chapter for more information.

Example Control Flags Field

Example Packet ID Field

Example Data Offset Field

To synchronize the metrics assigned to any WAN point-to-point connection when different line speeds are configured on each end. Examples of these connections include HDLC, block asynchronous, X.25 serial line, and TCP/IP server-to-server connections. Client nodes or routers use the slowest speed (that is, the highest metric value).
To deliver metric information on source routes to client nodes. Because client nodes do not store metric information for source routes across specific Token-Ring bridges, client nodes must request this information from their routing server. When the routing server receives the routing request from the client node, it calculates the metric for the source route in the received routing request packet's Token-Ring header. The routing server then returns this metric in the metric field of the routing response.

Example Synchronizing Routing Metrics

Tuples

Figure 5-15. Sequenced Update Packet with One Tuple

Fragmentation and Reassembly

VINES IP packet length - (VINES IP header size + RTP header size + updt header size)
--------------------------------------------------------------------------------------------------------------------------------
                                                         update data size (in bytes)

number of tuples = update data size in bytes / tuple size in bytes

Example Fragmentation and Reassembly of a Multipacket Update

Figure 5-16. Fragmentation and Re-assembly of a Multipacket Update

Previous PageTop Of PageNext Page