|
|
Banyan Virtual Integrated Network Service (VINES) implements a distributed network-operating system based on a proprietary protocol family derived from the Xerox Corporation's Xerox Network Systems (XNS) protocols. VINES uses a client-server architecture in which clients request certain services, such as file and printer access, from servers. This chapter provides a summary of VINES communications protocols. The VINES protocol stack is illustrated in Figure 33-1.
The lower two layers of the VINES stack are implemented with a variety of well-known media-access mechanisms, including High-Level Data Link Control (HDLC), X.25, Ethernet, and Token Ring.
VINES uses the VINES Internetwork Protocol (VIP) to perform Layer 3 activities (including internetwork routing). VINES also supports its own Address- Resolution Protocol (ARP), its own version of the Routing Information Protocol (RIP)---called the Routing Table Protocol (RTP)---, and the Internet Control Protocol (ICP), which provides exception handling and special routing cost information. ARP, ICP, and RTP packets are encapsulated in a VIP header.
VINES network-layer addresses are 48-bit entities subdivided into network (32 bits) and subnetwork (16 bits) portions. The network number is better described as a server number because it is derived directly from the server's key (a hardware module that identifies a unique number and the software options for that server). The subnetwork portion of a VINES address is better described as a host number because it is used to identify hosts on VINES networks. Figure 33-2 illustrates the VINES address format.
The network number identifies a VINES logical network, which is represented as a two-level tree with the root at a service node. Service nodes, which are usually servers, provide address resolution and routing services to clients, which represent the leaves of the tree. The service node assigns VIP addresses to clients.
When a client is powered on, it broadcasts a request for servers, and all servers that hear the request respond. The client chooses the first response and requests a subnetwork (host) address from that server. The server responds with an address consisting of its own network address (derived from its key), concatenated with a subnetwork (host) address of its own choosing. Client subnetwork addresses typically are assigned sequentially, starting with 8001H. Server subnetwork addresses are always 1. Figure 33-3 illustrates the VINES address-selection process.
Dynamic address assignment is not unique in the industry (AppleTalk also uses this process), but it certainly is not as common as static address assignment. Because addresses are chosen exclusively by a particular server (whose address is unique as a result of the hardware key), very little chance exists for duplicating an address. This is fortunate, because duplicate addresses could cause potentially devastating problems for Internet Protocol (IP) and other networks.
In the VINES network scheme, all servers with multiple interfaces are essentially routers. Clients always choose their own server as a first-hop router, even if another server on the same cable provides a better route to the ultimate destination. Clients can learn about other routers by receiving redirect messages from their own server. Because clients rely on their servers for first-hop routing, VINES servers maintain routing tables to help them find remote nodes.
VINES routing tables consist of host/cost pairs, where the host corresponds to a network node that can be reached, and cost corresponds to a delay (expressed in milliseconds), to get to that node. RTP helps VINES servers find neighboring clients, servers, and routers.
Periodically, all clients advertise both their network-layer and their MAC-layer addresses with the equivalent of a hello packet, which indicates that the client is still operating and network-ready. The servers themselves send routing updates to other servers periodically to alert other routers to changes in node addresses and network topology.
When a VINES server receives a packet, it checks to see whether the packet is destined for another server or whether it is a broadcast. If the current server is the destination, the server handles the request appropriately. If another server is the destination, the current server either forwards the packet directly (if the server is a neighbor) or routes it to the next server in line. If the packet is a broadcast, the current server checks to see whether the packet came from the least-cost path. If not, the packet is discarded. If so, the packet is forwarded on all interfaces except the one on which it was received. This approach helps diminish the number of broadcast storms, a common problem in other network environments. Figure 33-4 illustrates the VINES routing algorithm.
Figure 33-5 illustrates the VIP packet format.
RTP distributes network-topology information. Routing-update packets are broadcast periodically by both client and service nodes. These packets inform neighbors of a node's existence and also indicate whether the node is a client or a service node. In each routing-update packet, service nodes include, in each routing update packet, a list of all known networks and the cost factors associated with reaching those networks.
Two routing tables are maintained: a table of all known networks and a table of neighbors. For service nodes, the table of all known networks contains an entry for each known network except the service node's own network. Each entry contains a network number, a routing metric, and a pointer to the entry for the next hop to the network in the table of neighbors. The table of neighbors contains an entry for each neighbor service node and client node. Entries include a network number, a subnetwork number, the media-access protocol (for example, Ethernet) used to reach that node, a local area network (LAN) address (if the medium connecting the neighbor is a LAN), and a neighbor metric.
RTP specifies four packet types: routing update, routing request, routing response, and routing redirect. Routing update is issued periodically to notify neighbors of an entity's existence. Routing requests are exchanged by entities when they must learn the network's topology quickly. Routing responses contain topological information and are used by service nodes to respond to routing-request packets. A routing-redirect packet provides better path information to nodes using inefficient paths.
RTP packets have a 4-byte header that consists of the following 1-byte fields: operation type, which indicates the packet type; node type, which indicates whether the packet came from a service node or a nonservice node; controller type, which indicates whether the controller in the node transmitting the RTP packet has a multibuffer controller; and machine type, which indicates whether the processor in the RTP sender is fast or slow.
Both the controller-type and the machine-type fields are used for pacing.
ARP packets have an 8-byte header that consists of a 2-byte packet type, a 4-byte network number, and a 2-byte subnetwork number. Four packet types exist: a query request, which is a request for an ARP service; a service response, which is a response to a query request; an assignment request, which is sent to an ARP service to request a VINES internetwork address; and an assignment response, which is sent by the ARP service as a response to the assignment request. The network- number and subnet-number fields have meaning only in an assignment- response packet.
ARP clients and services implement the following algorithm when a client starts up. First, the client broadcasts query- request packets. Then, each service that is a neighbor of the client responds with a service- response packet. The client then issues an assignment- request packet to the first service that responded to its query-request packet. The service responds with an assignment-response packet that contains the assigned internetwork address.
Exception notifications are sent when a VIP packet cannot be routed properly, and the error subfield in the VIP header's transport control field is enabled. These packets also contain a field identifying the particular exception by its error code.
ICP entities in service nodes generate metric-notification messages when the metric subfield in the VIP header's transport-control field is enabled, and the destination address in the service node's packet specifies one of the service node's neighbors.
VINES provides three transport-layer services: unreliable-datagram service, reliable-message service, and data-stream service:
As a distributed network, VINES uses the remote procedure call (RPC) model for communication between clients and servers. RPC is the foundation of distributed-service environments. The NetRPC protocol (Layers 5 and 6) provides a high-level programming language that allows access to remote services in a manner transparent to both the user and the application.
At Layer 7, VINES offers file-service and print-service applications, as well as StreetTalk, which provides a globally consistent name service for an entire internetwork.
VINES also provides an integrated applications-development environment under several operating systems, including DOS and UNIX. This development environment allows third parties to develop both clients and services that run in the VINES environment.
Posted: Thu Jun 17 16:36:25 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.