ZXDSTD2: ZXDNET CONTROL MESSAGE PROTOCOL
DOWNLOAD
ZXDNET CONTROL MESSAGE PROTOCOL
PROTOCOL SPECIFICATION
ZXDSTD: 2
author: tntxxd@ztx6d
last-update: 2025/01/31
1. INTRODUCTION
The Zxdnet Protocol (ZP) is used for host-to-host datagram service in a system
of interconnected networks called the Catenet. The network connecting devices
are called Gateways. Occasionally a gateway or destination host will communicate
with a source host, for example, to report an error in datagram processing or to
ensure if the device is alive. For such purposes this protocol, the Zxdnet
Control Message Protocol (ZCMP), is used. ZCMP, uses the basic support of ZP as
if it were a higher level protocol, however, ZCMP is actually an integral part
of ZP, and must be implemented by every ZP module.
ZCMP messages are sent in several situations: for example, when a datagram
cannot reach its destination and when the gateway does not have the buffering
capacity to forward a datagram.
The Zxdnet Protocol is not designed to be absolutely reliable. The purpose of
these control messages is to provide feedback about problems in the
communication environment, not to make ZP reliable. There are still no
guarantees that a datagram will be delivered or a control message will be
returned. Some datagrams may still be undelivered without any report of their
loss. The higher level protocols that use ZP must implement their own
reliability procedures if reliable communication is required.
The ZCMP messages typically report errors in the processing of datagrams. To
avoid the infinite regress of messages about messages etc., no ZCMP messages are
sent about ZCMP messages.
2. FORMAT
ZCMP messages are sent using the basic ZP header. The Zxdnet Protocol Number
is 1. The first octet of the data portion of the datagram is a ZCMP type field;
the value of this field determines the format of the remaining data.
2.1. Error Report Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zxdnet Header + Maximum 12 bytes of Original Data Datagram |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ZP Fields:
Destination Address
The source network and address from the original datagram's data.
ZCMP Fields:
Type = 1.
Code
0 = net unreachable.
1 = host unreachable.
2 = protocol unreachable.
3 = port unreachable.
4 = out of MTU.
5 = time to live exceeded in transit.
6 = data missing.
7 = data corruption.
Checksum
The checksum is the 16-bit ones's complement of the one's complement
sum of the ZCMP message starting with the ZCMP Type. For computing the checksum,
the checksum field should be zero. If the computed checksum is zero, it is
transmitted as all ones. If the checksum field in the received datagram is zero,
the receiver must skip the verification process.
2.2. Echo or Echo Reply Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (0-24) bytes...
+-+-+-+-+-
ZP Fields:
Addresses
The address of the source in an echo message will be the destination
of the echo reply message. To form an echo reply message, the source and
destination addresses are simply reversed, the code changed to 1, and the
checksum recomputed.
ZCMP Fields:
Type = 2.
Code
0 = echo.
1 = echo reply.
Checksum
The checksum is the 16-bit ones's complement of the one's complement
sum of the ZCMP message starting with the ZCMP Type. For computing the checksum,
the checksum field should be zero. If the computed checksum is zero, it is
transmitted as all ones. If the checksum field in the received datagram is zero,
the receiver must skip the verification process.
Description
The data received in the echo message must be returned in the echo
reply message.