DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Administering SCO IPX/SPX

Protocols

NetWare client-server communications are governed by a series of protocols. These protocols can be divided by functionality:

The protocols that make up the SCO IPX/SPX stack may be installed as a co-resident with other SCO OpenServer networking protocols: Please refer to ``Protocol stacks'' for more information on LAN card and protocol stack coexistence.

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
NCP is supported by SCO IPX/SPX but is only used by SCO Gateway for NetWare.
The information presented in the following sections is technical in nature and is most valuable to those individuals designing, implementing, or administering NetWare networks. It is also useful to individuals and organizations developing applications specifically for NetWare. The sections provide:

These sections explain the packet structures defined by each protocol, and the algorithms followed by workstations, routers, and file servers when transmitting or receiving packets.

For detailed information on Novell networks, see the Novell documentation.


NOTE: Some of the information in the following sections does not apply directly to SCO IPX/SPX. It does, however, describe the environment in which IPX/SPX operates. You should be familiar with this environment to make effective use of IPX/SPX.

How protocols work

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:


Application layer
The content of the application layer is up to the individual user.

Presentation layer
Performs functions that are requested sufficiently often to warrant finding a general solution for them.

Session layer
The user's interface into the network.

Transport layer
Accepts data from the session layer, splits it into smaller units if necessary, passes these to the network layer, and ensures that the pieces all arrive correctly at the other end.

Network layer
Controls the operation of the subnet.

Data link layer
Takes a raw transmission facility and transforms it into a line that appears free of transmission errors to the network layer.

Physical layer
Concerned with transmitting raw bits over a communication channel.

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:


Medium-access protocols
Defines the addressing that distinguishes each node an a NetWare network.

Internetwork Packet Exchange (IPX)
Defines the addressing schemes used on a NetWare network.

Sequenced Packet Exchange (SPX)
Provides security and reliability to the IPX protocol.

Routing Information Protocol (RIP)
Facilitates the exchange of routing information on a NetWare network.

Service Advertising Protocol (SAP)
Allows service-providing nodes to advertise their services and addresses.

NetWare Core Protocol (NCP)
Defines the connection control and service request encoding that make possible the interaction between clients and servers.

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 protocols

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.

Error-checking

Two types of error-checking can be performed:

Medium-access protocols provide bit-level error-checking in the form of a cyclic redundancy check (CRC). This CRC, which is appended to every packet that is transmitted, assures that virtually all of the packets successfully received will be free of corruption. In view of this level of integrity, NetWare does not provide any additional bit-level error-checking within any of its upper-level protocols. Bit-level error-checking and node-addressing are provided by the majority of medium-access protocol implementations.

Internetwork Packet Exchange (IPX)

The Internetwork Packet Exchange (IPX) protocol was adopted by Novell from the Xerox Network System (XNS) Internet Datagram Protocol. IPX defines:

It relies on the network hardware for the definition of node addressing.

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.

Internetwork addressing

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

Intranode addressing

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

IPX packet structure

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

Sequenced Packet Exchange (SPX)

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.

SPX packet structure

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:


Connection control
Indicates whether the packet is a system or application packet.

Data stream type
Specifies the type of data found in the packet.

Source connection ID
Identification number assigned to the local transport endpoint.

Destination connection ID
Identification number assigned to the remote transport endpoint.

Sequence number
Number of packets exchanged in one direction on the connection.

Acknowledgement number
Sequence number of the next packet SPX expects to receive.

Allocation number
Used to implement flow control between communicating applications. SPX only sends packets until the local sequence number equals the allocation number on the remote machine.

Routing Information Protocol (RIP)

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.

RIP broadcasts

The broadcast of RIP packets allows:

For more information on routers and the functions they perform, see the Novell NetWare documentation.

RIP packet structure

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:


Operation
indicates whether the packet is a request or a response. A 1 in this field indicates a request; a 2 indicates a response.

Network Number
Identifies the network segment the packet will be sent to.

Number of Hops
Indicates the number of routers the packet must pass through to reach a network number.

Number of Ticks
Indicates how much time is required for the packet to reach the specified network segment. The number in this field is always at least one. (A ``tick'' is approximately 1/18 of a second; there are 18.21 ticks in a second.)

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.

Service Advertising Protocol (SAP)

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.

SAP broadcasts

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.

SAP packet structure

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:


Operation
Specifies the operation that the packet is performing.

Service type
Specifies the type of service offered by the server.

Server name
Specifies the name of the broadcasting server.

Network address
Specifies the network number of the broadcasting server.

Node address
Specifies the node number of the broadcasting server.

Socket address
Specifies the socket number of the service provider.

Hops to server
Specifies the number of hops to the broadcasting server.

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.


Next topic: Packet delivery
Previous topic: How IPX/SPX works

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003