Chapter 3 - VINES Network Layer Protocols
VINES network layer protocols are primarily responsible for routing VINES transport layer reliable messages and unreliable datagrams to destination nodes.
In the VINES architecture, the network layer provides only datagram-based services. It does not support virtual connections in any form, but attempts to deliver any transport layer datagram or message.
The network layer presents received datagrams or messages to the transport layer in the correct size, and free of any bit errors. It does not guarantee the reception of transport layer datagrams or messages in the sequence in which they were transmitted.
Messages and datagrams are contained within network layer units of data called packets. Packets originate from and are destined for network layer protocol entities, which implement specific network layer protocols.
The network layer can replicate packets. Packets cannot exceed 1500 bytes, including the 18-byte VINES IP header.
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 shows a sample packet.
The VINES architecture currently defines four network layer protocols:
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.
Each of the network layer protocols has an entity within each node in the network.
RTP and VINES ARP support internal network layer functions. No interface exists between the transport layer and either of these protocol entities.
ICP, RTP, and VINES ARP entities exist in a sublayer above VINES IP. All ICP, RTP, and VINES ARP packets are encapsulated by a VINES IP header. ICP, RTP, and VINES ARP packets do not contain any data that originates from higher layers. Figure 3-2 shows the relationship between the VINES IP header and the other network layer headers.
The VINES architecture provides interfaces to other network layer protocols such as DARPA IP, IPX, and AppleTalk DDP. See Chapter 9 for more information.
VINES Network Layer Addressing
The VINES architecture defines a two-level network layer addressing scheme. Each node has a 48-bit network layer address called the VINES internet address, which is globally unique when it is assigned. No two nodes anywhere in the network can have the same VINES internet address simultaneously.
The VINES internet address is independent of any data link layer address assigned to a node on a physical medium. A data link layer address is used by data link layer protocol entities to identify nodes on a data link. The format of data link addresses varies depending on the specific data link protocol.
The 48-bit internet address consists of two fields:
![]()
A network ID in the high-order 32 bits ![]()
The subnetwork ID in the low-order 16 bits
The network ID identifies a VINES logical network, which is a grouping of nodes. A VINES logical network is represented as a two-level hierarchy, with the top of the hierarchy at a router, which is a server or third-party router. The router provides address resolution and routing services to client nodes, which are usually DOS, Windows, or OS/2 workstations. The client nodes to which the router assigns addresses make up the bottom tier of the hierarchy. The router assigns VINES internet addresses to client nodes.
For addressing purposes, the logical network does not map directly to the physical media topology. Nodes that are members of a single network can reside on different physical media, while nodes from different logical networks can exist on the same medium.
Unique 48-bit internet addresses are formed as follows:
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.
Routers assign subnetwork IDs from 32768 (0x8000) through 65534 (0xFFFE). Banyan routers begin assigning subnetwork IDs at 32769 (0x8001). Subnetwork IDs from 2 (0x0002) through 32767 (0x7FFF) are reserved for future use. The subnetwork ID 65535 (0xFFFF) is reserved to indicate a broadcast within the specified network. Usually, broadcasts are initiated by higher-level protocol entities (for example, transport layer entities) or applications. The network ID 0xFFFFFFFF is reserved to indicate a broadcast to all networks.
To guarantee address uniqueness, Banyan has divided the network ID space into disjoint ranges. This allows Banyan to assign different network ID ranges to different manufacturers with confidence that duplicate network IDs will never appear.
Current Network ID Format
Currently, the 32-bit network ID consists of three fields.
Bits 0 and 1 This field is reserved for future use. It must be 0 (zero).
Bits 2 through 10 This field contains the 9-bit manufacturer code that identifies the router vendor. Banyan is the only company authorized to assign this code.
Bits 11 through 3 This field contains the 21-bit serial number that uniquely identifies each unit from the manufacturer.
This format allows 512 possible manufacturer codes (0 to 511). Each manufacturer code has over two million serial numbers available (0 to 2,097,151). The two high-order bits allow for expansion of either the manufacturer code field or manufacturer serial number field in the future.
Old Network ID Format
An earlier format for network IDs allocated five bits for the manufacturer code and 27 bits for the manufacturer serial number. No bits were reserved for expansion.
Bits 0 through 4 This field contains the 5-bit manufacturer code that identifies the router vendor.
Bits 5 through 31 This field contains the 27-bit serial number that uniquely identifies each unit from the manufacturer.
Manufacturer codes were assigned to the following companies under the old format:
![]()
Banyan ![]()
Banyan Specials ![]()
Convergent Technology (acquired by UNISYS) ![]()
Wang Laboratories
Compatibility of Network ID Formats
The current format fully supports the old format without restricting the serial number ranges already assigned.
Because the highest manufacturer code assigned under the old format was 00011 for Wang Laboratories, the high-order two bits of the network ID were always 0 (zero). Therefore, it is safe to define the high-order two bits as a reserved field for possible expansion in the future.
The current manufacturer code format overlaps the first six bits of the old manufacturer serial number format. To protect the serial number ranges already assigned, a manufacturer code in the old format maps into a range of manufacturer codes in the new format.
Example Compatibility Between Current and Old Formats
Convergent Technology was assigned the manufacturer code 00001 under the old format. The first 11 bits of a Convergent Technology serial number are 00001XXXXXX, where X represents either 1 or 0 (zero).
Under the current format, the Convergent Technology network ID maps to 00 in the reserved field, and 001XXXXXX in the manufacturer code field. The remaining 21 bits for the serial number are unaffected.
Notice that the bit patterns are identical in the two formats:
Old 00001 XXXXXXXXXXXXXXXXXXXXXXXXXXX
Current 00 001XXXXXX XXXXXXXXXXXXXXXXXXXXX
Banyan is the only company authorized to assign manufacturer codes. Table 3-1 lists the manufacturer codes assigned and network ID ranges.
VINES Internet Address Example
Figure 3-3 shows two logical networks that span three physical networks (two Ethernet LANs and a Token-Ring LAN).
VINES IP moves packets from the VINES IP entity in the source node to the VINES IP entity in the destination node. This node is specified by the destination VINES internet address in the VINES IP header.
VINES IP prefixes an 18-byte header to each packet. Each VINES IP packet contains a single datagram destined for a transport layer protocol entity or another network layer protocol entity. Figure 3-4 shows the format of the VINES IP header.
The fields in the VINES IP header are as follows.
Checksum Field The checksum field is used by VINES IP to detect bit-error corruption of the packet. Except for network broadcasts, VINES IP uses the checksum field only when the packet has traveled over an end-to-end path that includes a physical medium unable to provide a guaranteed error-detection service. Otherwise, the checksum field is null (0xFFFF). When the field is null, no checksum is required.
All network broadcasts are checksummed, regardless of the physical media over which they travel.
The checksum field is valid when its value is either null or the calculated checksum. For information on how VINES IP entities handle checksums, see "VINES IP Implementation Notes" later in this section.
Packet Length Field The packet length field contains the length value of the packet in network byte order. After processing the checksum field, VINES IP checks this field to determine whether the packet is valid.
Transport Control Field The transport control field consists of several subfields, as shown in Figure 3-5.
Note: Bit 7 in Figure 3-5 is used for encapsulation. See Table 3-2.
Table 3-2 shows the values for the transport control subfields.
How VINES IP uses bits 4 through 6 depends on whether the packet is a broadcast packet. A broadcast packet is a VINES IP packet that is part of a network layer broadcast (that is, the destination VINES internet address is 0xFFFFFFFF).
For broadcast packets, VINES IP uses bits 4 through 6 for the class subfield.
For other packets, VINES IP uses bits 4, 5, and 6 for the error, metric, and redirect subfields.
The rest of this section describes these subfields.
Class Subfield - VINES IP uses the class subfield to filter broadcasts on transmission. VINES IP uses the class subfield with the hop count to qualify the range that a broadcast packet can travel. This reduces the number of extraneous broadcast packets that a node receives.
Table 3-3 shows class subfield values.
Error Subfield - The error subfield indicates that the packet's originator wants to receive exception notification. If a VINES IP entity can't route a packet for any reason, and the error subfield is set to 1, the entity requests ICP to send an exception notification packet to the transport layer protocol entity from which the packet originated. This packet tells the entity that the packet cannot be routed.
Packets in IPC reliable messages or SPP data streams always have the error subfield set to 1. The IPC entity or the SPP entity sets the error subfield. See "VINES ICP" later in this chapter for more information.
Metric Subfield - Transport layer protocol entities on routers set the metric subfield to 1 when they need to learn the routing cost of moving packets between another router and one of its neighbor client nodes. The routing cost is referred to as a metric. When the ICP entity on the router neighboring the destination client node sees the metric subfield set in a VINES IP packet, the entity transmits a metric notification packet to the transport layer protocol entity on the source router. The metric notification packet informs the transport layer protocol entity of a routing-cost factor for the final hop to the destination node. See "Routing Metrics" and "VINES ICP" later in this chapter for more information.
Transport layer protocol entities on client nodes set the metric subfield to 1 only when client nodes communicate directly, such as when a VINES user uses the CHAT utility to communicate with another user.
Redirect Subfield - When the redirect subfield is set to 1, the last router that forwarded the packet is capable of sending and accepting redirect packets. The meaning of this field is the reverse for packets encapsulated in UDP; that is, when the redirect subfield is cleared (set to 0), the system is capable of sending and accepting redirect packets. See Chapter 4 and Chapter 5 for more information on redirect packets.
Hop Count Subfield - The hop count subfield can contain any value from 0x0 to 0xF. The source node initializes the hop count subfield to the maximum number of hops or routers that can handle the packet. As each router handles the packet, the node decrements the hop count field by one. If a router receives a packet that is not destined for itself and the hop count field is 0 (zero), the node discards the packet. This procedure prevents packets from being improperly routed due to rapid topological change.
Encapsulation Subfield - Set to 1 by clients using IP encapsulation (not UDP encapsulation) and by servers using UDP encapsulation. Servers forwarding a packet from an IP client clear this field (set it to 0).
Packet Type Field - The packet type field indicates the network
or transport layer protocol
entity destination for the metric or exception notification packet.
The field contains one of the values shown in Table 3-4.
Currently, the protocols listed in Table 3-4 are the only protocol entities that interface directly to VINES IP.
Source and Destination Address Fields The rest of the VINES IP header fields in Figure 3-4 contain the VINES internet addresses of the source of the packet and the destination of the packet. The source address follows the destination address in the order of transmission.
VINES IP is responsible for properly routing packets from a VINES IP entity on one node to a similar protocol entity on another node. A VINES IP entity does not guarantee to preserve the sequential delivery of packets to a destination.
Routing Algorithm
On routers, VINES IP follows a basic algorithm when it processes a received packet:
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.
When a router transmits a non-broadcast packet, it sets the hop count to 15. As each router forwards the packet along the route to the destination, the hop count is decremented by one. If two end points in the network are separated by more than 15 routers, the end points cannot communicate with each other.
If VINES IP needs to forward a packet on the same interface on which it receives the packet, VINES IP solicits the services of VINES RTP, which transmits a redirect packet to the node identified by the source data link address (for example, an Ethernet address) in the original VINES IP packet.
The flowchart in Figure 3-6 illustrates the VINES IP routing algorithm.
The algorithm described in Figure 3-6 is simplified for client nodes, which do not route packets between different media. Client nodes reject packets for these reasons:
![]()
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
VINES IP on a router is responsible for selecting routes when it forwards packets originating from other routers or client nodes. When packets originate from a router or a client node, IPC and SPP on that router or client node selects routes. See "Selecting Neighbor Paths and Routes" in Chapter 4 for more information.
Invoking ICP
VINES IP can invoke the assistance of the Internet Control Protocol (ICP) for one of two reasons:
![]()
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
VINES IP returns exception indications if a packet meets all of the following conditions:
![]()
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.
VINES IP returns routing cost indications if the packet meets all of the following conditions:
![]()
The packet is not a broadcast packet. ![]()
The metric subfield option is set to 1. ![]()
The final destination node is a neighbor.
See "VINES ICP" later in this chapter for more information.
Calculating Checksums
VINES IP calculates the checksum as follows:
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 IP reserves a one's complement minus 0 (0xFFFF) checksum value to indicate the presence of a null checksum. Usually, VINES IP does not calculate checksums until VINES IP attempts to route a packet through a data link layer service that does not guarantee data integrity. Before VINES IP passes the packet to the service, VINES IP calculates the checksum and sets it in the VINES IP header if the checksum field was null previously.
RTP distributes topological information to support VINES IP. VINES supports two RTP implementations:
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.
The two implementations are different in the way they guarantee the integrity of routing table information. The sequenced RTP implementation provides a more controlled and reliable means of maintaining routing tables than the non-sequenced RTP implementation.
This section introduces RTP and focuses on basic RTP terms and concepts. Because of the complexity of RTP and because there are two RTP implementations, two chapters are reserved for this protocol. See Chapter 4 and Chapter 5 for detailed information on RTP.
The sequenced RTP implementation makes use of sequence numbers, which allow routers to determine whether the routing table information they receive from neighbor routers is up to date. In their routing tables, neighbor routers associate sequence numbers with each other. Each time one neighbor router sends new topology information to another, the sending router increments its sequence number by one and includes the updated sequence number in the RTP header of the RTP packet. When it receives the packet, the receiving router updates its routing table with the new sequence number.
The non-sequenced implementation does not use sequence numbers to guarantee the integrity of routing table information. Instead, the non-sequenced implementation relies more heavily on suppression of routing table updates and other techniques to accomplish this goal.
This section describes concepts and terms that are common to both non-sequenced and sequenced RTP.
Nodes
RTP defines two types of network nodes: client nodes and routers.
Client Nodes - Do not support a route-through service for packets addressed to other nodes. Client nodes run VINES protocols and include DOS, Windows, or OS/2 workstations, and others as they become available. Client nodes do not include Macintosh workstations, which use AppleTalk protocols to communicate with servers.
Routers - Support a route-through service for packets addressed to other nodes. Routers include servers and third-party routers.
Routing Tables
The main purpose of RTP is to build and maintain routing tables in the network. These tables maintain information on routes to destinations in the network. VINES IP uses this information when selecting the appropriate route for forwarding a packet to a destination.
Routers and client nodes maintain two routing tables: a network table and a neighbor table.
Network Table - For routers, the network table contains an entry, called a network entry, for each known logical network except the router's own network.
Client nodes keep track of only their own logical networks and routes to other networks with which they are currently communicating on an as-needed basis, thereby reducing the amount of memory that the table requires. When a client node needs to communicate outside of its logical network, it asks its routing server for the correct route to the destination. The routing server then responds with the correct route. The client node stores the correct route until it no longer needs to communicate with the route's destination.
See "VINES ARP" later in this chapter for more information on routing servers.
The contents of the network table depends on the RTP implementation. See Chapter 4 and Chapter 5 for more information on the contents of the network table.
Neighbor Table - On routers, the neighbor table contains an entry, called a neighbor entry, for each neighbor router and client node. Each neighbor entry points to a list of neighbor path entries, one for each direct connection to the neighbor. This allows a router to have multiple connections to a neighbor, such as two routers connected by both an Ethernet LAN and a Token-Ring LAN.
On client nodes, the contents of the neighbor table depends on the RTP implementation. See Chapter 4 and Chapter 5 for more information on the contents of the neighbor table.
RTP Packets
RTP uses VINES IP to move RTP packets throughout the network. These packets perform the operations required to build and maintain routing tables in the network. An RTP packet is a VINES IP packet with an RTP header following the VINES IP header. In some cases, RTP information, such as routing table entries called tuples, follows the RTP header. Figure 3-7 shows a generic RTP packet.
Note: The FRP header appears in the packet only if applicable. See Chapter 2 for more information on FRP.
There are several kinds of RTP packets. Each type of RTP packet is designed to perform a specific RTP operation. For example, a routing request packet allows client nodes and routers to request routing table information from other routers.
The types and purposes of RTP packets vary, depending on whether the RTP implementation is non-sequenced or sequenced. See Chapter 4 and Chapter 5 for more information on RTP packets.
A routing metric is an estimated, round-trip delay time associated with the route that maximum-sized VINES IP packets will take to a destination. The routing metric value is specified in 200-millisecond intervals called ticks.
Routing metrics are used by VINES IP to select the least-cost route to a destination. VINES IP selects the route with the lowest routing metric.
A routing metric value of 0xFFFF indicates that the specified destination network is unreachable. Networks become unreachable because of any number of problems, ranging from serial line breaks to a server failure.
The exact metric value for a routing table entry depends on the number of hops to a destination and the type of intermediate interfaces. Each intermediate interface has a metric assigned to it. The total metric for the route is the sum of metrics of the intermediate interfaces. See Table 4-8 for information on interface metrics.
Example Routing Metric
The metric for the route between JPTOK001 (in Tokyo) and USCHI002 (in Chicago) in Figure 3-8 is 92. The routing software on JPTOK001 adds the metric for the 9600 bps HDLC leased line (90) to the metric for the 16-Mbps Token-Ring link (2).
Dynamic Routing Table Maintenance
VINES networks are dynamic. Routers inform each other of changes in the network, such as a new server coming on line or a route becoming unavailable. Client nodes request routing table information from routing servers. RTP is designed to dynamically maintain routing tables.
Four examples of dynamic routing table maintenance are as follows:
![]()
Propagation of network changes ![]()
Client node requests for routes ![]()
Routing redirects
Propagation of Network Topology Changes
RTP propagates news of the following topology changes through the network:
![]()
A router comes on line or goes off line ![]()
A router comes on line, goes off line, or has its metric modified
When news of network topology changes need to be broadcast throughout the entire network, the routers that initially detect the change broadcast news of the change to their neighbors. Only routers propagate topology changes.
When neighbor routers receive news of network changes, they propagate the news to their neighbors on all of their interfaces (including the interface that they received the news on). This process continues, from router to router, until the news reaches all the routers in the network.
Example Propagation of Network Topology Changes
Assume that a new server comes on the network and announces its arrival to neighbor routers. Once a neighbor router includes the appropriate entries for the new server in its routing tables, it broadcasts an entry for the new server to its neighbors. This broadcast occurs on all interfaces. Other routers in the network propagate the news of the new server's arrival throughout the network in the same manner.
Figure 3-9 shows how news of a new server's (JPTOK002) arrival is propagated through the network. News of other network changes, such as servers going off the network or route changes, is propagated in the same way. Servers propagate news of network changes on all of their network interfaces, including the interface on which they receive the news.
Remember, routers broadcast news of network changes on all of their interfaces, including the interface on which they received news of the change. For example, USCHI001 will broadcast news of the change to JPTOK001 over the HDLC leased line, even though it received the news from JPTOK001 on that link.
Routers do not perform a network-wide broadcast when network changes occur. Instead, the news of network changes are propagated across the network as a series of controlled, zero-hop data link broadcasts, from router to router.
Client Node Request for Routes
Since client nodes do not keep complete network tables, the client node must be able to quickly learn how to reach new networks with which it wants to communicate. In the client node, RTP performs this general algorithm:
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.
The exact algorithm depends on the RTP implementation. See Chapter 4 and Chapter 5 for more information.
Before the correct metric is received, the "best guess" metric is calculated each time a packet is transmitted, as follows:
metric for reaching routing server + 15
The metric for reaching the routing server and the 15 value are in 200 millisecond ticks.
Figure 3-10 shows how a client node requests a route from its routing server in order to communicate with a server on another LAN.
As illustrated in Figure 3-10, no routing redirect is necessary because the routing server provides the best route to the destination. See "Routing Redirects," which follows, for more information on redirects.
Because client nodes and routers may not always choose the best route to a destination, RTP provides a redirect mechanism to inform a node that it did not make the appropriate routing decision.
Some examples of situations in which redirects correct errant routing decisions follow:
![]()
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 shows a variation of Figure 3-10, in which a client node incorrectly uses its routing server as the temporary gateway to a destination when a better route exists. The routing server sends a redirect to the client node informing it of the better route.
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 assigns unique VINES internet addresses to nodes without internet addresses. VINES ARP employs the services of VINES IP to move packets between nodes.
This protocol defines two types of protocol entities: an address resolution service and an address resolution client.
In most cases, an address resolution service is implemented within a router that has these characteristics:
![]()
VINES IP route-through capabilities ![]()
A static, unique 32-bit network ID
An address resolution client is implemented in a node that is not pre-assigned a unique VINES internet address. Address resolution clients are usually implemented in client nodes that support VINES protocols, such as DOS or OS/2 workstations, and others as they become available. Address resolution clients are not implemented in Macintosh workstations, which use AppleTalk protocols to communicate with routers.
When a client node loads VINES software, the address resolution client issues broadcasts to find a router, called a routing server. The routing server is the router that provides the address resolution service to the client by assigning the VINES internet address.
Two implementations of VINES ARP are currently supported:
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.
In order to interoperate, nodes that support sequenced ARP also support non-sequenced ARP. For example, a client node that runs VINES 5.5 can use a VINES 5.0 server as its routing server if no VINES 5.5 servers are available, and a server that runs VINES 5.5 can provide an address resolution service to a VINES 5.0 client node.
VINES Non-Sequenced ARP Protocol Specification
Non-sequenced ARP is the older of the two VINES ARP implementations. It is currently supported under VINES 4.xx, VINES 5.0, VINES 5.5, and ENS for UNIX 1.0. Over time, this implementation will be phased out in favor of the sequenced ARP implementation.
Non-sequenced ARP packets are prefixed with an 8-byte header that follows the VINES IP header. Figure 3-12 shows the header.
The fields in the VINES non-sequenced ARP header are as follows.
Packet Type Field The packet type field indicates the type of VINES ARP packet. Table 3-5 shows the values that the VINES ARP packet type field contains.
Because the first byte of the packet type field is all 0s (zeroes), address resolution clients and services that support sequenced ARP use the byte as the version number to identify non-sequenced ARP packets. Thus, when an address resolution client or service receives a packet with a first byte of 0 (zero), it knows that the sender supports non-sequenced ARP only.
VINES Internet Address Field The VINES internet address field in the VINES ARP header contains a significant value for assignment response packets only. For all other packet types, the VINES internet address field is reserved. The field begins with the 4-byte network ID, and ends with the 2-byte subnetwork ID. The network ID matches the routing server's network ID, and the routing server assigns a subnetwork ID that is unique within the routing server's logical network.
VINES Sequenced ARP Protocol Specification
Sequenced ARP is the newer of the two VINES ARP implementations. It is supported under VINES 5.5, and will be supported under all future VINES revisions. Eventually, it will also be supported under ENS for UNIX and ENS.
Sequenced ARP packets are prefixed with a 14-byte header that follows the VINES IP header. Figure 3-13 shows the header.
The fields in the VINES sequenced ARP header are as follows.
Version Number Field The version number field indicates that the packet is a sequenced VINES ARP packet. The field is used by address resolution clients and address resolution services that support sequenced ARP to distinguish between sequenced ARP packets and non-sequenced ARP packets. This field contains 1 in sequenced ARP packets.
Packet Type Field The packet type field indicates the type of VINES ARP packet. The values are the same as those described in Table 3-5.
VINES Internet Address Field The VINES internet address field in the sequenced ARP header is identical to the same field in the non-sequenced ARP header. This field is found in assignment response packets only. See the section "Non-Sequenced ARP Protocol Specification" earlier for more information.
Sequence Number Field The sequence number field contains the routing server's sequence number. This field is found in assignment response packets only. The client uses this number to validate further routing updates from the routing server. See Chapter 5 for more information on sequence numbers.
Metric Field The metric field contains the metric of the data link on which the client and the routing server communicate. This field is found in assignment response packets only. For example, if the client and the routing server communicate over an Ethernet LAN, the metric would be 2. If the client and the routing server communicate over a 9600 bps serial line, the metric would be 90. See "VINES RTP" earlier in this chapter for an explanation of metrics.
VINES ARP Implementation Notes
The algorithms that are used to implement both non-sequenced ARP and sequenced ARP are very similar. Address resolution clients and services implement the following algorithm when a client initializes:
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 illustrates this algorithm.
In Figure 3-14, Server A becomes the client's routing server because it responded faster to the client's query request than Server B. Many factors determine which server responds first, including the speed of the server's processor, the position of the server in a Token-Ring topology, the server's current processing load, and so on.
The client sends the query request in a VINES IP broadcast packet with the hop count field set to 0 (zero). For the assignment request packet, the client sets the destination address field in the VINES IP header to the value of the source address field of the VINES IP header in the service response packet. For both the query request and the assignment request packets, the client sets the source node address in the VINES IP header to 0 (zero).
Because the client has no assigned VINES internet address until it receives the assignment response packet, the potential routing server sends service response and assignment response packets with the destination VINES internet address field of the VINES IP header set to 0 (zero).
The potential routing server uses the client node's data link address, such as an Ethernet address, to address the client node until it has a VINES internet address. The routing server obtains the data link address by copying it from the data link header of the query request packet. The routing server sends service response and assignment response packets to the specific data link address of the client.
VINES ARP Client States
At any given time, a client node can be in one of the VINES ARP client states in Table 3-6.
VINES ARP Service States
At any given time, the router can be in one of the VINES ARP service states in Table 3-7.
VINES ARP Timers
When the client node sends a query request or an assignment request, the node maintains a two-second timer. The timer terminates when the client node receives the expected response. If the timer expires before the client node receives the expected response, the client node performs one of these actions:
![]()
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.
The node also maintains a two-second timer when it sends an assignment request. The timer terminates when the client node receives the expected response. If the timer expires before the client node receives the expected response, the client node re-enters initialization state, broadcasts a query request, and resets the timer.
Metric for Reaching the Routing Server
The metric field in sequenced assignment response packets is needed for the client node to learn the correct metric between itself and the routing server. The client node cannot always correctly assume that the metric of the data link to which the client node is connected is the correct metric for reaching the routing server.
For example, if the client and the routing server are connected through one or more IBM Token-Ring bridges, the client node cannot assume that the correct metric for reaching the routing server is the metric for the Token-Ring LAN to which it is connected. The metric for the source route between the client node and the routing server must be used. Figure 3-15 shows a situation in which a client node cannot assume that the metric for the 4-Mbps LAN to which it is connected is the correct metric for reaching its routing server.
VINES ARP is designed so that its non-sequenced and sequenced implementations can interoperate. The interoperability burden lies with the address resolution clients and services that support both implementations. It is their responsibility to work with clients and services that support the non-sequenced implementation only.
Address resolution clients and services that support both implementations use the first byte of VINES ARP packets to determine whether the packet is non-sequenced or sequenced. If the first byte is 0 (zero), the packet is non-sequenced. If the first byte is 1, the packet is sequenced.
The examples in this section illustrate how non-sequenced ARP and sequenced ARP interoperate. A mixed VINES 5.0 (non-sequenced ARP) and VINES 5.5 (sequenced ARP) network is used in all of the illustrations.
Example VINES 5.5 Client Node and a Mix of VINES 5.0 and VINES 5.5 Servers
Figure 3-16 shows a LAN with a VINES 5.5 client node and a mix of VINES 5.0 servers and VINES 5.5 servers. The client node broadcasts sequenced query request packets, which VINES 5.0 servers ignore because they do not recognize the sequenced ARP packet format. Server B drops the query request, and Server A becomes the client node's routing server.
Example VINES 5.0 Client Node and a Mix of VINES 5.0 Servers and VINES 5.5 Servers
Figure 3-17 shows a LAN with a VINES 5.0 client node and a mix of VINES 5.0 servers and VINES 5.5 servers. Server A becomes the VINES 5.0 client node's routing server, even though it runs VINES 5.5. This happens because Server A supports both non-sequenced and sequenced ARP, and responded to the client node's query request faster than Server B.
Example VINES 5.5 Client Node and VINES 5.0 Servers Only
Figure 3-18 shows a LAN with a VINES 5.5 client node and VINES 5.0 servers. The VINES 5.5 client node first attempts a sequenced query request. When it receives no response after two seconds, it attempts a non-sequenced query request, which is answered with a non-sequenced service response.
Example VINES 5.0 Client Node and VINES 5.5 Servers
Figure 3-19 shows a LAN with a VINES 5.0 client node and VINES 5.5 servers. When Server A and Server B recognize 0 (zero) in the first byte of the client node's query request, each knows that the requesting client node supports non-sequenced ARP. Because Server A and Server B support both non-sequenced and sequenced ARP, they can handle query requests from a VINES 5.0 client node without any problems.
ICP currently returns the following information to transport layer protocol entities:
![]()
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.
A transport layer protocol entity invokes both functions through options specified in the transport control field of the VINES IP header.
In addition, ICP implements an equivalent of the Internet Control Message Protocol (ICMP) echo and request functions. The ICP echo request and reply format is described in this section. This echo request and reply is only implemented on the router side.
ICP packets are prefixed with a 4-byte header that follows the VINES IP header. Figure 3-20 shows the ICP header.
The fields in the ICP header are as follows.
Packet Type Field Table 3-8 shows the values that the packet type field contains.
Exception, Metric, Request/Reply Field The second field in the ICP header contains one of the following elements:
![]()
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 lists the communication error codes that can appear in the field.
For exception notification packets, ICP attaches the ICP header to a copy of part of the original VINES IP packet that caused the exception notification to be generated. That part of the original VINES IP packet can be up to 40 bytes. The bytes include the VINES IP header but do not include any data link layer protocol headers attached to the original packet.
A routing metric follows the ICP header in metric notification packets.
For echo request or reply packets, the second field in the ICP header contains a value of 0x0 for requests and 0x1 for replies. No data follows the header.
VINES ICP Implementation Notes
This section provides implementation notes on exception notification and metric notification.
Exception Notification
A VINES IP entity causes the ICP entity to generate an exception notification packet under one or more of the following conditions:
![]()
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.
A router cannot properly route a VINES IP packet when it contains an unknown destination address. A client node cannot properly receive a VINES IP packet when it contains a destination address that does not match the client node's VINES internet address. This tends to happen when the client node quickly reboots, obtains a new VINES internet address, and receives packets containing the old address on an SPP virtual connection.
Packets in IPC reliable messages and in SPP data streams always have the error subfield enabled.
See "VINES IP" earlier in this chapter for more information on the error subfield.
An exception notification packet indicates the exception condition in the exception field of the ICP header. The exception field always contains a standard network communications error code. Table 3-9 describes these codes.
Metric Notification
An ICP entity in a router generates a metric notification packet only when both of the following conditions are met:
![]()
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.
The metric notification packet contains the value of the neighbor metric in the metric field of the ICP header. Because routers only store the correct routing metric to other routers in their routing tables, their SPP and IPC protocol entities need help to calculate the correct metric to destination client nodes that are not directly connected. The router that acts as the last hop to the destination client node supplies the correct metric in the metric field to the router that needs that information.
Before obtaining the correct metric, the router that requires metric notification uses a "best guess" temporary metric based on the metric for the route to the client node's logical network. See "Client Node Request for Routes" earlier in this chapter for information on how the "best guess" metric is calculated. See "VINES RTP" earlier in this chapter for more information on metrics.
Figure 3-21 illustrates metric notification.
In Figure 3-21, a DOS workstation establishes an SPP connection with a server, Server B, that is not on the same LAN. When Server B initially transmits packets to the workstation on the SPP connection, it sets the metric subfield in the Transport Control field of the VINES IP header. When Server A routes the packets and sees that the metric subfield is set, it sends a metric notification packet to Server B, informing it of the correct metric to the workstation.
Before it receives metric notification, Server B uses a temporary, "best guess" metric to reach the workstation.
Interfaces to Other Network Layer Protocols
VINES IP currently has interfaces to the following industry-standard 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
Chapter 9 describes the interfaces to these protocols.
On routers, VINES network layer protocols are run in the UNIX kernel on VINES and ENS servers, and run as a streams driver on ENS for UNIX servers.
On client nodes, VINES network layer protocols are resident in the VINES communications driver TSR on DOS workstations, and run as part of an OS/2 driver on OS/2 workstations.