Previous PageNext Page

Chapter 5 - VINES Sequenced Routing Update Protocol (continued)

Sequenced Redirect Packets

Because a client node only stores a neighbor entry for its routing server, the routing information in redirect packets help a client node communicate directly with neighbor routers that are not its routing server.
Because a router only stores neighbor entries for client nodes for which it is a routing server, a router needs a mechanism to create transient neighbor entries for client nodes.

Figure 5-17. Sample Sequenced Redirect Packet

Figure 5-18. Sample Sequenced Redirect Message

Figure 5-19. Sequenced Redirect in a Source Routing Environment

Table 5-6. Redirect Message Fields

Rules for Generating and Processing Sequenced Redirect Packets

The network entry for the destination must exist in the network table.
An existing network entry for the destination must be valid (that is, the network must be reachable and not in suppression).
The router that sent the redirect packet must be the current gateway for reaching the destination.

Redirect Compatibility with Non-Sequenced RTP

Processing Sequenced Redirect Packets that Contain Source Routes

Processing Backup Source Routes

Sequenced Re-initialization Packets

Figure 5-20. Sequenced Re-initialization Packet Header Format

VINES Sequenced RTP Implementation Notes

Neighbor table
Network table
Routing metrics
Routing table timers
Routing table flags
Information exchange algorithms

Sequenced Neighbor Table Implementation

A LAN, which can consist of a single segment or multiple segments linked by bridges. These bridges can either link segments directly, or over some other medium, such as serial lines. For example, all VINES nodes on Token-Ring LANs connected by Token-Ring bridges, are neighbors.

As another example, all VINES nodes on a Token-Ring LAN that consists of local and remote IBM Token-Ring bridges are neighbors.

A point-to-point connection, which includes X.25 virtual circuits, HDLC or block asynchronous lines, ISDN B-Channels, and T1 LAPD connections.
A non-VINES network, such as a NetWare, TCP/IP, or SNA network.

Table 5-7. Neighbor Table Fields

Table 5-8. Neighbor Path Fields

Sequenced Network Table Implementation

On client nodes, there is one entry for the routing server's logical network and one entry for each logical network with which the client node currently communicates.
On routers, there is one entry for each router in the network.

The fields in the entry are described in Table 5-9.

Table 5-9. Network Table Fields


Sequenced RTP Route and Neighbor Path Selection Algorithm

Routing Metrics

Calculating Actual Metrics

The 12 low-order bits indicate metric values based on 200 millisecond ticks.
The four high-order bits provide better granularity based on fractions of 200 millisecond ticks.

Example Calculating the Actual Metric

Using Actual Metrics

x = advertised metric value shifted left by 4 bits
y = advertised metric value shifted right by 12 bits
cost = x | y

Example Using Actual Metrics

The interfaces
The actual metric cost of each interface
The 16-bit value (in both hexadecimal and binary) that the router advertises in routing update packets (netadvcost)

Metric Compatibility with Non-Sequenced RTP

Sequenced Routing Table Flags

A change in the network has occurred.
The router has WAN neighbors that do not support sequenced RTP.
The neighbors are connected to the router by WAN connections, such as serial lines, X.25 virtual circuits, ISDN B-Channels, TCP/IP networks, NetWare networks, SNA networks, or other WAN connections as they become available.

Note: The RTF_SUPPRESS1 flag (0x400) is not used with the sequenced RTP implementation.

The client node is connected to the routing server in a Token-Ring bridge environment by a source route.
The routing server adjusted the metric that the client uses to reach it.

The destination is a router that does not support sequenced RTP, such as an ENS for UNIX 1.0, VINES 4.x, VINES 5.0, or ENS 1.0 server.
All the gateways along the route to the destination support sequenced RTP, such as VINES 5.5 servers.

Sequenced Routing Table Timers

Table 5-10. Routing Table Timers


Example RTS_AGELESS Timer

Example RTS_DEMISE Timer

If the other routers learn that Server A has suddenly become reachable before the timer expires, the other routers allow netidle to reach RTS_AGELESS again in the entry for Server A.
If the other routers receive a subsequent routing update indicating Server A is unreachable before the RTS_DEMISE timer expires, the other routers remove the entry for Server A.
If the other routers do not receive a subsequent routing update indicating Server A is unreachable before RTS_DEMISE expires, the other routers remove the entry for Server A once the timer expires.

How Routing Tables Are Maintained by Sequenced RTP

When no network changes take place
When a router comes on line or goes off line
When a client node comes on line or goes off line
When a client node communicates outside its logical network
When routers initialize WAN connections
When the "Help Thy Neighbor" scenario takes place
When a routing metric changes
When a router reboots

When No Network Changes Take Place

When a Router Comes On Line

1. The new router announces its arrival by broadcasting null routing update packets to neighbors.

2. Neighbor routers add this router to their neighbor table and their network table.

Neighbors use the source address in the VINES IP header and the sequence number and metric fields in the sequenced update header to create the table entries. In the sequenced update header, the metric is derived from the interface where the new router sends the broadcast.

3. The actions that neighbor routers take depend on the number of routers on the data link that connects the existing routers and the new router.

If the new router is only the second router on the data link (that is, there is only one existing router), both the new router and the existing router broadcast full routing updates on that interface.

If the new router is the third (or greater) router on the data link, the existing routers send full topology updates directly to the new router. In this case, the updates are not sent as broadcasts; rather, they are sent directly to the new router. The new router broadcasts its routing update.

4. News of the new router's arrival is propagated through the network. Within 2 seconds, neighbors of the new router broadcast routing updates on all interfaces containing only the news of the router's arrival. These neighbors in turn broadcast updates to their neighbors, and so on.

Neighbors of the new router
Non-neighbors of the new router

1. The neighbor checks the neighbor table for an entry for the new router.

2. Because no entry for the new router exists, the neighbor must create one. The neighbor extracts the following information from the null update packet:

- The LAN address (if applicable) from the data link header

- The source route (if applicable) from the data link header

- The source VINES internet address from the VINES IP header

- The sequence number from the sequenced update header

- The metric from the sequenced update header

3. The neighbor creates an entry for the new router in the neighbor table with the information from step 2. Some of the parameters that the router sets are as follows:

- The time-to-live timer to RTS_RESPONSE in the neighbor path entry for the new router. This gives the new router a chance to send a full routing update. If the new router does not send the update, the neighbor can issue up to three requests for full routing updates to the neighbor.

- Flags in the neighbor path entry to indicate that the new node is a router. If the neighbor is connected by a WAN and does not support sequenced RTP, such as a VINES 4.11 server, the router sets the RTF_PERMANENT flag.

- Metric and cost parameters using the metric from the received null update packet.

- State to INIT.

- Router sequence number to the sequence number received in the null update packet.

- Data link address (such as the LAN address) to the neighbor's data link address.

In addition to setting parameters, the router stores a neighbor path entry for the interface that connects the new router, and stores the packet ID extracted from the sequenced update header.

4. In the network table, routers create an entry for the new router with the received VINES internet address, sequence number and interface metric. Some of the parameters that the router sets are as follows:

- Destination to the source network number in the VINES internet address from the VINES IP header.

- The gateway to the destination to the new router.

- The metric and cost parameters using the metric from the received null update packet.

- Time-to-live timer to RTS_AGE.

- The neighbor sets only the RTF_UP and RTF_GATEWAY flags unless the neighbor, in turn, has WAN neighbors that do not support sequenced RTP, such as VINES 4.11 servers. In this case, the neighbor sets the RTF_UP, RTF_GATEWAY, and RTF_CHANGE flags.

In addition to setting parameters, the router stores the network sequence number that is extracted from the sequenced update header.

5. Within 2 seconds of receiving the null update from the new router, the receiving router broadcasts a routing update containing just news of the change on all of its interfaces. For example, when one new router comes on the network, the routing update contains just one tuple.

6. The neighbor waits for the new router to send it a full topology update. The new router increments its sequence number by 1. Once the update is received, the neighbor changes the state of the new router from INIT to UP and updates the new router's sequence number based on the one that the router advertised.

Example Neighbor of a New Router

Figure 5-21. New Router Announcing Itself to a Neighbor Using Sequenced RTP

1. Each router checks the router sequence number of the neighbor where the router receives news of the network change. When the neighbor sees that the sequence number has increased, the neighbor knows that it can accept the news.

2. The router changes the neighbor's router sequence number in the neighbor entry.

3. In the network table, each router creates an entry for the new router with information in the new router's tuple.

Some of the parameters that each router sets are as follows:

- Destination to the network number in the tuple.

- The network sequence number in the entry to the sequence number in the tuple.

- Timestamps the network change with a value that is one greater than the router's current sequence number.

- A pointer to the neighbor entry for the gateway from which the news was received.

- Metric and cost parameters using the metric from the tuple.

- The time-to-live timer to RTS_AGELESS.

- Only the RTF_UP and RTF_GATEWAY flags unless the router, in turn, has WAN neighbors that do not support sequenced RTP, such as VINES 4.11 servers. In this case, the router sets the RTF_UP, RTF_GATEWAY, and RTF_CHANGE flags.

4. The router increments its current router sequence number by one and broadcasts news of the change.

Example Non-Neighbor of a New Router

Figure 5-22. Router Receiving News of a New Non-Neighbor Using Sequenced RTP

When a Router Goes Off Line

1. Timestamps the network change with a value that is one greater than the current router sequence number.

2. Sets the time-to-live timer to RTS_AGE, turns off the RTF_UP flag and marks as unreachable the network entries for the following nodes:

- The router that left the network

- All destinations for which the router acted as a gateway

If the routers that remain on the network have neighbors that do not support sequenced RTP on WAN interfaces, these routers set the RTF_CHANGE flag in the changed network entries.

3. Increments the current router sequence number by 1 and broadcasts news of the change to all remaining neighbors within two seconds after detecting the change. Each router includes a tuple in the routing update packet for the router that left the network and destinations reached through it. Each tuple contains a metric of 0xFFFF.

4. Deletes the entry for the network associated with the router that has left.

When a Client Node Comes On Line

The routing server's data link address from the data link header
The routing server's source VINES internet address from the VINES IP header
The metric from the assignment response packet header
The sequence number from the assignment response packet header

When a Client Node Goes Off Line

When a Client Node Communicates Outside Its Logical Network

1. The client node finds out the destination VINES internet address of the router through StreetTalk and creates a transient entry in the network table. The client node indicates that the entry needs a better metric by setting the RTF_TRANSIENT flag and the RTF_METRIC flag.

The routing server is used as the temporary router.

A temporary, "best guess" metric is used to reach the destination. See "Client Node Request for Routes" in Chapter 3 for more information on the "best guess" metric.

2. The client node waits 5 seconds before requesting metric information from its routing server:

- In most cases, the redirect packet arrives before the client node is forced to send a routing request packet.

- If the client is forced to send a routing request packet, the routing server responds with a routing response packet containing the correct metric for reaching the destination. If the routing server does not respond initially, the client node continues to send a routing request packet every 5 seconds until a routing response packet containing the correct metric is received.

3. The client node replaces the "best guess" metric with the correct metric for reaching the destination. The client node disables the RTF_METRIC flag for the entry.

When Routers Initialize WAN Connections

A sequenced null update indicating that the router on the other end of the connection supports sequenced RTP
A non-sequenced response or update indicating that the router on the other end of the connection only supports non-sequenced RTP

The two routers create a neighbor path entry for each other. If necessary, they also create the neighbor entry. The state of the neighbor path entry is set to UP.
Routers send sequenced routing request packets to each other, requesting a full routing update as part of the initial routing exchange to synchronize routing tables.
Each router notifies its VINES Security Service to assign the correct level of access (unrestricted, restricted, or secure) on the WAN connection.

When the "Help Thy Neighbor" Scenario Takes Place

Any neighbor that supports sequenced RTP advertises that a network is unreachable, or any WAN neighbor that supports only non-sequenced RTP, such as a VINES 4.11 server, advertises that a network is unreachable. This condition differs from the non-sequenced RTP implementation where only WAN neighbors are helped.
The router can reach the advertised network through another gateway. If the router reaches the advertised network through the neighbor that advertises it as unreachable, the router does not help its neighbor.
The change in the network topology did not alter the router's view of the network that became unreachable to its neighbor.
The router can provide an alternate route to the network that its neighbor can no longer reach.

Marks the network entries that are advertised as unreachable with the RTF_CHANGE flag
Includes these entries in the "changes only" routing update that is sent to the WAN neighbor
Advertises these entries in the next scheduled routing update

Figure 5-23. Help Thy Sequenced RTP Neighbor

When a Routing Metric Changes

Cheaper
Equal
Greater

The current metric indicates that the destination is unreachable (metric of -1).
The network entry is currently suppressed and a new gateway to the destination is advertised.

Sets the RTF_SUPPRESS2 flag to begin the suppression period
Sets the RTF_CHANGE flag if it has WAN neighbors that do not support sequenced RTP
Sets the suppression timer to RTS_SUPPRESS
Timestamps the network entry

Sets the destination to unreachable (-1)
Sets the RTF_CHANGE flag if it has WAN neighbors that do not support sequenced RTP
Timestamps the entry

When a Router Reboots

Requests for full topology information
Updates (full or changes-only) that advertise the router's existence with the correct sequence number (one that matches the router's current value)
Full response to an initial routing request

Previous PageTop Of PageNext Page