|
|
NetWare client-server communications are governed by a series of protocols. These protocols can be divided by functionality:
The following table describes which protocols are used and supported by SCO IPX/SPX:
Protocols supported by SCO IPX/SPX
| Protocol | Supported | API provided |
|---|---|---|
| Internetwork Packet Exchange (IPX) | yes | yes |
| Sequenced Packet Exchange (SPX) | yes | yes |
| Service Advertising Protocol (SAP) | yes | yes |
| Routing Information Protocol (RIP) | yes | no |
| NetWare Core Protocol (NCP) | yes | no |
| Novell Virtual Terminal (NVT) | yes | yes |
For detailed information on Novell networks, see the Novell documentation.
Most computer networks require that information transferred between two nodes be divided into blocks, called packets. These packets make the information more manageable for sending and receiving nodes, as well as any intermediate nodes (bridges or routers). In addition to the information, or data, that is being transferred, each packet contains control information used for error-checking, addressing, and other purposes.
The protocols used on the network define the content of this control information. In most cases, multiple protocols exist within a packet; each protocol defines a different portion of the control information for the packet, and the control information for each protocol serves a different purpose.
When multiple protocols are used, the control information for the highest level protocol is placed around the data first, then the control information for each subsequent protocol in the protocol stack is added to the beginning and/or end of the packet. This process is called ``enveloping'' and is illustrated in ``Example of multiple protocols in a packet''.
Example of multiple protocols in a packet
| Header Control Information for Protocol #3 |
| Header Control Information for Protocol #2 |
| Header Control Information for Protocol #l |
| Data |
| Trailer Control Information for Protocol #l |
| Trailer Control Information for Protocol #2 |
| Trailer Control Information for Protocol #3 |
The enveloping pattern illustrated in the previous table is common in the computer communications industry. However, the tasks assigned to each protocol in the packet differ for different vendors' implementations. In an effort to standardize the definition of protocols -- and therefore make the networking implementations of different vendors interoperable -- several standards organizations have been formed by governments and corporations. One of these, the International Standards Organization (ISO), has developed a model, called the Open Systems Interconnection (OSI) model, that specifies how protocols should be defined in the future.
The OSI model separates the functions required for effective computer communications (such as error-checking and addressing) into the following seven categories, or layers, presented below from the highest to the lowest:
Having been defined prior to the finalization of the OSI model, the protocols used by NetWare do not all correspond exactly to the OSI model's definitions. NetWare uses a variety of protocols. Some of these protocols were developed specifically for NetWare; some are used throughout the networking industry. The protocols required for communications between NetWare workstations and file servers are:
These protocols are described in greater detail in the following sections.
``Mapping of NetWare protocols to OSI model'' provides a relative mapping of the NetWare protocols -- also called the NetWare protocol stack -- to the OSI model; in actuality, a direct correlation to the layer boundaries of the two architectures does not exist. The NetWare protocols follow the enveloping pattern previously shown in ``Example of multiple protocols in a packet''. More specifically, the upper level protocols (NCP, SAP, and RIP) are enveloped by IPX, and IPX is subsequently enveloped by a medium-access protocol header and trailer.
Mapping of NetWare protocols to OSI model
Medium-access protocol implementations define the addressing that distinguishes each node on a NetWare network. This addressing is implemented within the hardware of each network interface controller (NIC).
A number of medium-access protocols are defined, many of which are used with NetWare. The focus within this document is on the implementations of medium-access protocols, the most common of which are:
The 802.x protocols are defined by the Institute of Electrical and Electronic Engineers (IEEE). Ethernet version 2.0 was co-developed by XEROX and Digital Equipment Corporation. These medium-access protocol implementations are primarily concerned with the transport of packets from one node to another on a single network segment.
To move a packet to the proper node on a network, a medium-access control (MAC) header is placed at the beginning of every packet. This header contains address fields for both the source and destination nodes to indicate where the packet originated and where it is going. Each NIC checks the destination address in the MAC header of each packet sent on the network segment to which it is attached. If the destination address matches the NIC's own address, or if the packet is a broadcast packet intended for all nodes, the NIC will copy the packet.
Two types of error-checking can be performed:
The Internetwork Packet Exchange (IPX) protocol was adopted by Novell from the Xerox Network System (XNS) Internet Datagram Protocol. IPX defines:
IPX is a datagram-based, connectionless protocol. Datagram-based, connectionless protocols do not require an acknowledgment for each packet sent. Packet acknowledgment, or connection control, must be provided by protocols above IPX.
The basis of IPX addressing is the network number assigned during the installation and configuration process. Each network segment on a NetWare internetwork must be assigned a unique network number (sometimes called the external network number). Each server (SCO OpenServer or NetWare) must also be assigned a unique internal network number. These network numbers are used by routers to forward packets to their final destination segment.
``Network numbering'' illustrates how internal and external network numbers are used.
Network numbering
The basis of IPX intranode addressing is socket numbers. Since several processes normally operate within a node, socket numbers provide a means by which each process can distinguish itself to IPX. When a process needs to communicate on the network, it requests that a socket number be assigned to it. Any packets IPX receives that are addressed to that socket are passed on to the corresponding process. Hence, socket numbers provide a quick method of routing packets within a node.
Novell has reserved several socket numbers for specific purposes. These are shown in ``Socket numbers used in the NetWare environment''. Because socket numbers are internal to each node, several workstations can use the same socket number at one time without any fear of confusion.
Socket numbers used in the NetWare environment
| Socket number | Description |
|---|---|
| 451h | NetWare Core Protocol |
| 452h | Service Advertising Protocol |
| 453h | Routing Information Protocol |
| 455h | NetBIOS |
| 456h | Diagnostics |
| 4000h-6000h | Ephemeral sockets; used for interaction with file servers and other network communications |
The network, node, and socket addresses for both the destination and the source are held within the packet's IPX header. The IPX header is placed after the MAC header and before the packet data. (Packet data usually contains the header of a higher-level protocol.) ``IPX packet structure'' illustrates the structure of an IPX packet on an 802.3 network.
IPX packet structure
The Sequenced Packet Exchange (SPX) protocol works with the Internetwork Packet Exchange protocol (IPX) to provide reliable delivery. SPX guarantees that packets are received intact, in the order they were sent, and eliminates duplicate packets.
IPX receives packets from the network and passes on those for SPX to handle.
SPX requests verification from the destination module for each packet sent. By checking a verification value against a value calculated before transmission, SPX ensures that the packet arrives intact. In the case of a missing packet, the transmitting SPX module retransmits, and continues to do so up to a program-specified number of retries.
SPX does not provide group broadcast support; packets can only be sent to a single session partner. SPX can detect if its partner has disappeared.
SPX uses IPX and a medium-access protocol for its transport.
The SPX packet structure is shown in ``SPX packet structure''. This structure is enveloped within the data area of IPX.
SPX packet structure
An SPX packet contains the following fields:
The Routing Information Protocol (RIP) facilitates the exchange of routing information on a NetWare internetwork. Like IPX, the RIP protocol was derived from XNS. However, an extra field, ``Number of ticks'', was added to the packet structure to improve the decision criteria for selecting the fastest route to a destination. This change prohibits the straight integration of NetWare's RIP with strictly conforming XNS implementations.
The broadcast of RIP packets allows:
For more information on routers and the functions they perform,
see the Novell NetWare documentation.
The RIP packet structure is shown in ``RIP packet structure''. This structure is enveloped within the data area of IPX.
RIP packet structure
The packet contains the following fields:
The ``Operation'' field can be followed by one or more sets of information, each consisting of a network number and the number of hops and ticks to that network number. A RIP packet can contain a maximum of 50 sets of network number information.
The original XNS definition of the RIP did not include the ``Number of Ticks'' field. The ``Number of ticks'' field was added by the developers of NetWare so that the NetWare shell could estimate how long it should wait for a response from a file server. Also, if multiple routes exist to a network number, a router uses the route with the smallest number of ticks when forwarding packets to that network number.
If a RIP packet is a request for information, only the ``Network Number'' field applies; the ``Number of hops'' and ``Number of ticks'' fields are essentially nulled out. A response packet can be either a reply to a request from a router or workstation or a periodic broadcast by a router.
The Service Advertising Protocol (SAP) allows service-providing nodes -- such as file servers, print servers, gateway servers, and application servers -- to advertise their services and addresses. SAP makes the process of adding and removing services on an internetwork dynamic. As servers are booted up, they advertise their services using SAP; when they are brought down, they use SAP to indicate that their services will no longer be available.
Through SAP, clients on the network can determine what services are available on the network and obtain the internetwork address of the nodes (servers) where they can access those services. This is an important function, because a workstation cannot initiate a session with a service provider without first having that server's address.
A gateway server, for instance,
will broadcast a SAP packet every 60 seconds
(the period defined for all servers advertising with SAP)
onto the network segment to which it is connected.
The SAP agent in each router on that segment copies the
information contained in the SAP packet into an internal table
called the server information table.
Because the SAP agent in
each router keeps up-to-date information on available servers, a
client wanting to locate the gateway server can access a nearby
router for the correct IPX address.
Like RIP, SAP uses IPX and a medium-access protocol for its transport. ``SAP Packet Structure'' illustrates the structure of a SAP packet.
SAP Packet Structure
A SAP packet contains the following fields:
The ``Operation'' field can specify the following operations:
There can be one or more sets of fields
following the ``Operation'' field.
If the
packet contains information about more than one server, it will
contain more than one set of fields (n sets of fields).
Each SAP
packet can contain information about up to seven servers.