XNS Protocols

 
XNS includes the following protocols:
   
IDP Internet Datagram Protocol
RIP Routing Information Protocol
PEP Packet Exchange Protocol
SPP Sequenced Packet Protocol

The Xerox Network Systems (XNS) protocols provide routing capability and support for both sequenced and connectionless packet delivery. Novell and 3Com3Plus protocols use the lower layers of XNS for packet delivery.

The XNS protocols is illustrated here in relation to the OSI model:
Click the protocols on the map to see more details.

 

IDP

The Internet Datagram Protocol (IDP) delivers a single frame as an independent entity to an Internet address, irrespective of other packets or addressee responses. XNS generally limits the IDP packets to a maximum size of 576 bytes, excluding the data link header.

The following parameters are available for IDP:

Destination network
Four-byte address of the destination network.

Destination socket
Two-byte socket number of the destination port.

Source network
Four-byte address of the source network.

Source socket
Two-byte socket number of the source port.

Hop count
Indicates the number of routers encountered during transport of the packet. Each router handling a packet increments the hop count by one. When the hop count reaches 16, this protocol discards the packet.

Packet type
Number indicating the higher level protocol in use. XNS defines the following packet types:

0 Unknown.
1 Routing Information Protocol.
2 Echo Protocol.
3 Error Protocol.
4 Packet Exchange Protocol.
5 Sequenced Packet Protocol.

Interested in more details about testing this protocol? click here

 

RIP

XNS uses the Routing Information Protocol (RIP) to maintain a database of network hosts and exchange information about the topology of the network. Each router maintains a list of all networks known to that router along with the routing cost in hops required to reach each network. XNS distributes routing information on the network by routers broadcasting their routing tables every 30 seconds. This protocol sends routing tables as a result of changes in service or topology or in response to a request for routing information.

XNS generally uses the Echo protocol to demonstrate the existence and accessibility of another host on the network, while using the Error protocol to signal routing errors.

Frames

RIP frames may be one of the following commands:

[routing reqst] Request for routing information.
[routing reply] Routing information response.
[echo request] Request to echo the data given.
[echo reply] Echo of the data requested.
[error: unknown error] Error of unknown nature.
[error: corrupt at dest] Data corrupt at destination.
[error: unknown socket] Socket number unknown.
[error: out of resources] Router out of resources.
[error: routing error] Unspecified routing error.
[error: corrupt en route] Data corrupted in transit.
[error: dest unreachable] Destination network unreachable.
[error: TTL expired] Packet discarded after 15 hops.
[error: packet too large] Packet larger than permitted.

Request and Reply Parameters

RIP routing request and routing reply parameters consist of the listing of networks and hop counts. [routing reqst] frames include the network numbers of the networks for which routing information is requested; [routing reply] frames list the networks known to the router. RIP routing parameters are in the following format: NNNNNNNN (CC), where NNNNNNNN is a 4-byte hexadecimal network number and CC is the cost in decimal hops. XNS interprets the network number FFFFFFFF as all networks. A cost of 16 or more hops implies that the network is unreachable.

The parameter for [echo request] and [echo reply] frames is a dump of the echo data.

Error Frames

Each [error:...] frame is followed by up to the first 42 bytes of the frame responsible for the error message. The message [error: packet too large] is followed by the maximum acceptable size parameter (Max=xxx).

Interested in more details about testing this protocol? click here

 

PEP

The Packet Exchange Protocol (PEP) provides a semi-reliable packet delivery service that orients toward single-packet exchanges.

The following parameters are available for PEP:

Packet ID
A unique number used to identify responses as belonging to a particular request. The sending host sets the packet ID field to a fixed value, then looks for PEP responses containing the same packet ID value.

Client type
A registered code used to identify the particular application in use.

Interested in more details about testing this protocol? click here

 

SPP

The Sequenced Packet Protocol (SPP) provides reliable transport delivery with flow control.

The following parameters are available for SPP:

Source connection ID
Reference number used to identify the source end of a transport connection. This protocol establishes Connection IDs at connect time to distinguish between multiple transport connections.

Destination connection ID
Reference number used to identify the target end of a transport connection.

Sequence number
Sequence number of the packet. Each successive packet transmitted and acknowledged on the transport connection must have a sequence number one higher than the previous sequence number.

Acknowledge number
Sequence number of the last packet that the protocol received properly. Each side of the transport connection uses its own sequence of numbers for transmitted packets, resulting in sequence and acknowledge numbers in the same packet generally being out of phase with each other.

Credit
Number of unacknowledged packets that the other side of the transport connection can send.

Transport control flag
When set (value of 1), the packet is used for transport control.

Acknowledge required flag
When set (value of 1), an immediate acknowledgement is requested.

Attention flag
When set (value of 1), the packet is sent regardless of the credit advertised by the destination.

EOM
End of message flag. When set (value of 1), a logical end of message stream is denoted.

Datastream type
Reserved field ignored by the SPP transport layer. SPP provides the datastream type for use by higher level protocols as control information.

Interested in more details about testing this protocol? click here

 

 
Additional Information