Previous PageNext Page

Chapter 3 - VINES Network Layer Protocols

Introduction

Note: VINES IP allows packets of up to 1500 bytes. However, at this time, the largest number of bytes found in a VINES IP packet is 1484 bytes on Ethernet, Token-Ring, and ProNET-10 LANs, T1 server-to-server connections, and ISDN server-to-server connections.

Figure 3-1. Sample VINES Packet

VINES IP - Responsible for moving packets through the network.

VINES RTP - Distributes topological information to support the routing services that VINES IP provides.

VINES ARP - Assigns VINES internet addresses to nodes that do not already have addresses.

VINES ICP - Provides diagnostics and support functions to certain transport layer protocol entities, such as providing notification on some network errors and topological conditions.

Figure 3-2. Relationship Between VINES IP and Other Network Layer Headers

VINES Network Layer Addressing

A network ID in the high-order 32 bits
The subnetwork ID in the low-order 16 bits

Network IDs

1. Each router has a unique 32-bit network ID. The network ID is the serial number of the router. Each router uses a value of 1 for the subnetwork ID.

2. A router distributes unique VINES internet addresses to neighbor client nodes. To form addresses, the router concatenates its network ID to a subnetwork ID value that is not being used in the router's network. The subnetwork ID uniquely identifies the client node within the router's network.

Subnetwork IDs

Network ID Formats

Current Network ID Format

Old Network ID Format

Banyan
Banyan Specials
Convergent Technology (acquired by UNISYS)
Wang Laboratories

Compatibility of Network ID Formats

Example Compatibility Between Current and Old Formats

Old         00001 XXXXXXXXXXXXXXXXXXXXXXXXXXX

Current   00 001XXXXXX XXXXXXXXXXXXXXXXXXXXX

Manufacturer Code Assignments

Table 3-1. Manufacturer Codes and Network ID Ranges (Current Format)

VINES Internet Address Example

Figure 3-3. VINES Internet Address Example

VINES IP

VINES IP Specification

Figure 3-4. VINES Internet Protocol Header

Note: Bit 7 in Figure 3-5 is used for encapsulation. See Table 3-2.

Figure 3-5. Transport Control Field

Table 3-2. Transport Control Subfields

Table 3-3. Class Subfield Values

Table 3-4. Packet Type Field Values

VINES IP Implementation Notes

Routing Algorithm

1. VINES IP checks the VINES IP header for validity. The size of the packet must be greater than or equal to the value contained in the packet length field of the VINES IP header. Otherwise, the packet is discarded.

2. VINES IP checks the destination address field. The way in which VINES IP handles the packet depends on whether it is a broadcast packet, a packet specifically destined for the local node, or a packet specifically destined for some other node. If the address equals the local VINES internet address, the packet is specifically destined for the local node. VINES IP passes the packet to the protocol indicated by the value of the packet type field, as long as the checksum is valid.

If the address equals the broadcast address, the packet is a broadcast packet. The packet is accepted under these conditions:

- The checksum is valid.

- The VINES IP entity on the local node receives the packet on the same route that the entity would choose to reach the source node.

- The interface has not been assigned a secure or restricted level of access. Only VINES ARP and RTP broadcast packets are accepted on these interfaces. See Managing VINES Security or Managing ENS Security for more information on levels of access.

3. Once accepted, VINES IP passes a copy of the broadcast packet to the protocol entity specified by the packet type field.

4. VINES IP checks the hop count field. If the hop count is not equal to 0 (zero), the count is decremented. VINES IP rebroadcasts the packet on all local media except the one on which the packet was received.

5. If the address is not equal to the local VINES internet address or to the broadcast address, the packet is specifically destined for another node. If the hop count is nonzero, VINES IP decrements the hop count and performs a routing-table lookup to select the next intermediate hop. VINES IP then forwards the packet to the next hop.

If the hop count is 0 (zero), VINES IP discards the packet.

Figure 3-6. VINES IP Routing Algorithm for Routers

If the destination address does not equal their own local VINES internet address or broadcast address
If the checksum or packet length is invalid

Selecting Routes

Invoking ICP

To return exception indications to a node that is the source of an undeliverable packet
To return an indication of the neighbor metric that VINES IP on the local node uses for the last hop to a client node

The packet is not a broadcast packet.
The destination VINES internet address does not match the VINES internet address of the receiver.
The error option subfield within the transport control field is set to 1.

The packet is not a broadcast packet.
The metric subfield option is set to 1.
The final destination node is a neighbor.

Calculating Checksums

1. VINES IP initializes the accumulated checksum value to 0 (zero).

2. VINES IP views the packet as a sequence of 16-bit values, starting with byte 0 (zero) of the VINES IP header as the most significant byte of the first 16-bit value. The checksum ends at the last byte of the packet.

If the packet has an odd number of bytes, VINES IP forms the last 16-bit value using the last byte of the packet as the high-order eight bits. VINES IP sets the low-order eight bits to 0 (zero).

3. VINES IP assumes that the 16-bit checksum field is set to 0 (zero) when added to the accumulated checksum. VINES IP also assumes that the 4-bit hop count subfield of the transport control field is set to 0 (zero) for checksum purposes. VINES IP makes the hop count assumption to save the cost of recalculating the checksum when a broadcast packet must be forwarded across multiple hops.

4. VINES IP adds each 16-bit value to the accumulated checksum value using one's complement arithmetic.

5. If the final checksum value equals a one's complement minus 0 (0xFFFF), VINES IP sets the final value to plus 0 (0x0000).

6. VINES IP sets the checksum field to the final accumulated checksum value.

VINES RTP

Sequenced RTP - Sequenced RTP was introduced with VINES 5.5, and will eventually become the single RTP standard on all VINES, ENS for UNIX, and ENS platforms. Sequenced RTP provides sequenced routing updates.

Non-sequenced RTP - Non-sequenced RTP is the earlier of the two RTP implementations.

Sequenced RTP

Non-Sequenced RTP

Basic RTP Concepts and Terms

Nodes

Routing Tables

RTP Packets

Figure 3-7. RTP Packet

Note: The FRP header appears in the packet only if applicable. See Chapter 2 for more information on FRP.

Routing Metrics

Example Routing Metric

Figure 3-8. Sample Routing Metric

Dynamic Routing Table Maintenance

Propagation of network changes
Client node requests for routes
Routing redirects

Propagation of Network Topology Changes

A router comes on line or goes off line
A router comes on line, goes off line, or has its metric modified

Example Propagation of Network Topology Changes

Figure 3-9. Propagating News of Network Changes

 

Client Node Request for Routes

1. The client node locates the destination VINES internet address of the server through StreetTalk.

2. The client node creates a temporary entry in the network table.

The routing server is used as the temporary router.

A temporary, "best guess" metric is used to reach the destination. The client node can transmit IPC or SPP packets once the temporary metric is created.

3. After 200 milliseconds, a client node that supports non-sequenced RTP requests the appropriate metric from the routing server. 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.

Client nodes that support sequenced RTP wait 400 milliseconds before asking the routing server for the appropriate metric. 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.

4. The routing server replies with the appropriate metric. The workstation replaces the "best guess" metric with the correct metric for reaching the destination.

5. If there is a better route for reaching the destination, the routing server will send a redirect packet to the client node, telling the client node about the better route.

metric for reaching routing server + 15

Figure 3-10. Client Node Requesting a Route from Its Routing Server

Routing Redirects

A client node uses its routing server as the temporary gateway to a destination and a better route exists. The routing server sends a redirect to the client node informing it of the better route.
A client node uses a router as the gateway to reach a particular destination. Suddenly, a gateway that provides a better route to the destination becomes available. When the original gateway learns of the better route, it sends a redirect to the client node informing it of the better route.

Figure 3-11. Routing Server Redirecting a Client Node

Note: For VINES 5.5 and greater, the request for the correct metric is not sent if the redirect packet is received within 400 milliseconds after the transient entry is created.

VINES ARP

VINES IP route-through capabilities
A static, unique 32-bit network ID

Sequenced ARP - Sequenced ARP is designed to work with sequenced RTP. When the routing server assigns the VINES internet address to the client, it also includes its sequence number and a routing metric for reaching it. See Chapter 5 for a description of sequence numbers. See Chapter 4 for a description of routing metrics.

Non-Sequenced ARP - Non-sequenced ARP is designed to work with non-sequenced RTP, and is simpler than sequenced ARP. When the routing server assigns the client the VINES internet address, the routing server only assigns the address, and passes no other information.

VINES Non-Sequenced ARP Protocol Specification

Figure 3-12. VINES Non-Sequenced ARP Header

Table 3-5. VINES ARP Packet Type Field Values

VINES Sequenced ARP Protocol Specification

Figure 3-13. VINES Sequenced ARP Header

VINES ARP Implementation Notes

1. The client broadcasts query request packets.

2. Each service that is a neighbor of the client responds with a service response packet. The first one to respond becomes the routing server if the address assignment process completes.

3. The client sends an assignment request packet to the routing server.

4. In response to the assignment request packet, the server sends an assignment response packet to the client, which contains the assigned VINES internet address. The server forms the address by concatenating a subnetwork ID not currently in use in the server's logical network to the network ID.

The server becomes the client's routing server when the client receives the assignment response packet.

In addition, address resolution services that support sequenced ARP pass a sequence number and routing metric to clients that support sequenced ARP.

Figure 3-14. VINES ARP Address Assignment Algorithm

VINES ARP Client States

Table 3-6. VINES ARP Client States

VINES ARP Service States

Table 3-7. VINES ARP Service States

VINES ARP Timers

Enters old query state and sends a non-sequenced query request, if a sequenced query request was transmitted and no response was received.

For example, suppose that a VINES 5.5 client resides on a LAN that has only VINES 5.0 servers. When the client broadcasts a query request, the client will not receive a service response, since VINES 5.0 servers do not implement sequenced ARP. After two seconds, the client assumes that no sequenced address resolution services are on the LAN, enters old query state, resets the two-second timer, and broadcasts a non-sequenced query request.

Re-enters initialization state, broadcasts a query request, and resets the timer, if a non-sequenced query request was transmitted and no response was received.

Metric for Reaching the Routing Server

Figure 3-15. Client Node and Routing Server Separated by Token-Ring Bridges

VINES ARP Interoperability

Example VINES 5.5 Client Node and a Mix of VINES 5.0 and VINES 5.5 Servers

Figure 3-16. VINES 5.5 Client Node and a Mix of VINES 5.0 and VINES 5.5 Servers

Example VINES 5.0 Client Node and a Mix of VINES 5.0 Servers and VINES 5.5 Servers

Figure 3-17. VINES 5.0 Client Node and a Mix of VINES 5.0 and VINES 5.5 Servers

Example VINES 5.5 Client Node and VINES 5.0 Servers Only

Figure 3-18. VINES 5.5 Client Node and VINES 5.0 Servers

Example VINES 5.0 Client Node and VINES 5.5 Servers

Figure 3-19. VINES 5.0 Client Node and VINES 5.5 Servers

VINES ICP

Indications of network layer exceptions that occur during the routing of a transport layer message. ICP packets that contain these indications are called exception notification packets.
Metric information about the final transmission medium used to reach a client node. ICP packets that contain metric information are called metric notification packets.

VINES ICP Specification

Figure 3-20. VINES ICP Header

Table 3-8 ICP Packet Type Field Values

A communication error code that indicates an error
A routing metric for the final transmission medium that is used to reach a client node
An echo request or reply

Table 3-9. Communication Error Codes

VINES ICP Implementation Notes

Exception Notification

The entity cannot properly route a VINES IP packet.
The entity cannot properly receive a VINES IP packet.
The packet has the error subfield enabled in the VINES IP header's transport control field.

Note: The error subfield is not checked if the packet is received on an interface that is assigned secure access. See Managing VINES Security for more information on secure access.

Metric Notification

The entity routes a packet that has the metric subfield enabled in the transport control field of the VINES IP header.
The destination address in the VINES IP header specifies a node that is a neighbor of the router.

Figure 3-21. Metric Notification

Interfaces to Other Network Layer Protocols

The DARPA IP, which is part of the TCP/IP suite of protocols
AppleTalk Datagram Delivery Protocol (DDP)
Internetwork Packet Exchange (IPX) protocol
SNA Advanced Program-to-Program Communication (APPC) protocol

Platform Implementation Notes

Previous PageTop Of PageNext Page