| 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?
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?
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?
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?
|