Protocols

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

protocols used for all communications,
such as the medium-access protocols and the
Internetwork Packet Exchange protocol

administrative protocols,
such as the Routing Information Protocol and the
Service Advertising Protocol

protocols concerned with connection control,
such as the NetWare Core Protocol and Watchdog

protocols that define the coding of service requests,
such as the NetWare Core Protocol

The protocols that make up the SCO IPX/SPX stack may be
installed as a co-resident with other SCO OpenServer networking protocols:

SCO TCP/IP

NetBEUI (provided with SCO Advanced File and Print Server)

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:

802.5 Token-Ring

802.3 Ethernet

Ethernet version 2.0

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:

Bit-level error-checking
checks to make sure that bits within a packet have not been
corrupted.

Packet-level error-checking
checks to make sure
that complete packets are not lost.

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)

Internetwork addressing
as the address of a segment on the network,
identified by the network number assigned during installation.

Intranode addressing
as the address of a process within a node,
identified by a socket number.

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.

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.

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:

workstations to locate the fastest route to a network number.

routers to request routing information from other routers to update
their own internal tables.

routers to respond to route requests from workstations and other
routers.

routers to make sure that
all other routers are aware of the internetwork configuration.

routers to detect a change in the internetwork configuration.

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

RIP packet structure

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:

a workstation request for the name and address of the nearest
server of a certain type

a general request, by a router, for the names and addresses of
either all the servers or all the servers of a certain type
on the internetwork

a response to either a "Get Nearest Server" request
or a general request

periodic broadcasts by servers and routers

changed server information broadcasts

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.