ZXDSTD1: ZXDNET PROTOCOL
DOWNLOAD
ZXDNET PROTOCOL
PROTOCOL SPECIFICATION
ZXDSTD: 1
author: tntxxd@ztx6d
last-update: 2025/01/31
1. INTRODUCTION
1.1. Motivation
The Zxdnet Protocol is designed for interconnected systems within embedded
device communication networks. It facilitates the transmission of data blocks
(referred to as datagrams) between source and destination hosts, which are
identified by fixed-length addresses. As the protocol does not support datagram
fragmentation, upper-layer protocols must implement fragmentation and reassembly
mechanisms for oversized packets.
1.2. Scope
The Zxdnet Protocol is intentionally scoped to perform core functions
required for delivering discrete data units (referred to as Zxdnet datagrams)
from a source to a destination across interconnected network systems. It does
not implement end-to-end reliability, flow control, sequencing, or other
services typical of host-to-host protocols. Instead, the protocol leverages
capabilities of the underlying networks to enable differentiated service types
and quality levels.
1.3. Interfaces
This protocol is called on by host-to-host protocols in a Zxdnet
environment. This protocol calls on local network protocols to carry the Zxdnet
datagram to the next gateway or destination host.
For example, a SUDP module would call on the Zxdnet module to take a SUDP
segment (including the SUDP header and user data) as the data portion of a
Zxdnet datagram. The SUDP module would provide the addresses and other
parameters in the Zxdnet header to the Zxdnet module as arguments of the call.
The Zxdnet module would then create a Zxdnet datagram and call on the local
network interface to transmit the Zxdnet datagram.
1.4. Operation
The Zxdnet Protocol implements one basic functions: addressing.
The Zxdnet modules use the addresses carried in the Zxdnet header to
transmit Zxdnet datagrams toward their destinations. The selection of a path for
transmission is called routing.
The model of operation is that a Zxdnet module resides in each host engaged
in Zxdnet communication and in each gateway that interconnects networks. These
modules share common rules for interpreting address fields. In addition, these
modules (especially in gateways) have procedures for making routing decisions
and other functions.
The Zxdnet Protocol treats each Zxdnet datagram as an independent entity
unrelated to any other Zxdnet datagram. There are no connections or logical
circuits (virtual or otherwise).
The Zxdnet Protocol employs three key mechanisms to deliver its services:
Service Type (ST), Time to Live (TTL), and Header Checksum.
The Service Type (ST) field specifies the desired quality of service for a
datagram. It represents an abstract set of parameters that define service
options available across Zxdnet-compatible networks. Gateway nodes utilize this
indication to dynamically select transmission parameters (e.g., latency,
priority), determine the next-hop network path, or choose an optimal downstream
gateway during datagram routing.
The Time to Live (TTL) field defines the maximum hop count allowed for a
datagram. The sender initializes this value, and each routing node decrements it
by one upon processing. If the TTL reaches zero before the datagram arrives at
its destination, the datagram is immediately discarded. This mechanism prevents
infinite routing loops and enforces delivery scope constraints.
The Header Checksum verifies the integrity of the datagram header during
processing. If a checksum mismatch is detected (indicating header corruption),
the receiving entity must discard the datagram immediately. Notably, this
mechanism does not validate payload data and errors in the data field may
persist undetected.
The Zxdnet Protocol does not provide a reliable communication facility.
There are no acknowledgments either end-to-end or hop-by-hop. There is no error
control for data, only a header checksum. There are no retransmissions or flow
control.
Error conditions (e.g., TTL expiration, checksum failure) may be reported
via the Zxdnet Control Message Protocol (ZCMP), which operates within the Zxdnet
Protocol module.
2. OVERVIEW
2.1. Relation to Other Protocols
The following diagram illustrates the place of the Zxdnet Protocol in the
protocol hierarchy:
+------+ +-----+ +-----+ +-----+
|Telnet| | HTTP| |SDHCP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | SUDP| ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Zxdnet Protocol & ZCMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
Protocol Relationships
Zxdnet Protocol interfaces on one side to the higher level host-to-host
protocols and on the other side to the local network protocol.
2.2. Model of Operation
The model of operation for transmitting a datagram from one application
program to another is illustrated by the following scenario:
We suppose that this transmission will involve one intermediate gateway.
The sending application program prepares its data and calls on its local
Zxdnet module to send that data as a datagram and passes the destination address
and other parameters as arguments of the call.
The Zxdnet module prepares a datagram header and attaches the datato it. The
Zxdnet module determines a local network address for this Zxdnet address, in
this case it is the address of a gateway.
It sends this datagram and the local network address to the local network
interface.
The local network interface creates a local network header, and attaches the
datagram to it, then sends the result via the local network.
The datagram arrives at a gateway host wrapped in the local network header,
the local network interface strips off this header, and turns the datagram over
to the Zxdnet module. The Zxdnet module determines from the Zxdnet address that
the datagram is to be forwarded to another host in a second network. The Zxdnet
module determines a local net address for the destination host. It calls on the
local network interface for that network to send the datagram.
This local network interface creates a local network header and attaches the
datagram sending the result to the destination host.
At this destination host the datagram is stripped of the local net header by
the local network interface and handed to the Zxdnet module.
The Zxdnet module determines that the datagram is for an application program
in this host. It passes the data to the application program in response to a
system call, passing the source address and other parameters as results of the
call.
Application Application
Program Program
\ /
Zxdnet Module Zxdnet Module Zxdnet Module
\ / \ /
LNI-1 LNI-1 LNI-2 LNI-2
\ / \ /
Local Network 1 Local Network 2
Transmission Path
2.3. Function Description
The Zxdnet Protocol is designed to empower users in building self-contained,
fully controlled private networks, eliminating the traditional distinction
between "public" and "private" addressing. All unicast
addresses are inherently local network addresses, with no dependency on external
authorities or global routing infrastructures.
Network Autonomy Principles
Decentralized Addressing:
No centralized registration or allocation body exists. Users
autonomously assign addresses within their networks.
All unicast addresses (e.g., 192.0.2.0/24) are valid within the local
network scope.
Interconnection by Choice:
Networks may remain isolated or interconnect via gateways explicitly
configured by the user.
No implicit global routing; cross-network communication requires manual
gateway policy definitions.
Address Architecture
Zxdnet employs a 32-bit address space with CIDR, categorized as follows:
Unspecified/Local Broadcast Address (0.0.0.0/32):
Bit Pattern: 00000000 00000000 00000000 00000000.
As Source: Uninitialized device (e.g., 0.0.0.0 during bootstrap).
As Destination: Link-local broadcast (non-routable beyond subnet).
Loopback Address (0.0.0.128/25):
Bit Pattern: 00000000 00000000 00000000 1XXXXXXX.
Confined to internal host communication.
NAT Expansion Address (0.0.0.64/26):
Bit Pattern: 00000000 00000000 00000000 01XXXXXX.
Confined to local address scaling.
Multicast Address (224.0.0.0/5):
Bit Pattern: 11111XXX XXXXXXXX XXXXXXXX XXXXXXXX.
Destination-only: Valid within user-defined multicast domains.
Reserved Addresses (0.0.0.1-0.0.0.63):
Bit Pattern: 00000000 00000000 00000000 00XXXXXX (XXXXXX!=000000).
Constraint: These addresses MUST NOT be assigned to any device or used
in datagram headers.
Unicast Address (All non-reserved patterns):
Scope: Assigned to devices, globally routable.
Key Design Distinctions from Traditional IP
Network Broadcast Simplification:
No per-subnet broadcast address (e.g., 192.168.1.255 in IP).
Universal local broadcast via 0.0.0.0 only.
CIDR Efficiency:
The first address in a CIDR block (e.g., 172.16.0.0/16) is a valid host
address.
100% of addresses in a CIDR range are assignable to interfaces.
Operational Constraints
NAT Localization: NAT Expansion Addresses (0.0.0.64/26) MUST NOT appear in
inter-network communications.
Broadcast Containment: 0.0.0.0 MUST be discarded by any gateway receiving
it.
2.4. Gateways
Gateways implement Zxdnet Protocol to forward datagrams between networks.
In a gateway the higher level protocols need not be implemented.
+-------------------------------+
| Zxdnet Protocol |
+-------------------------------+
| |
+---------------+ +---------------+
| Local Net | | Local Net |
+---------------+ +---------------+
Gateway Protocols
3. SPECIFICATION
3.1. Zxdnet Header Format
A summary of the contents of the Zxdnet header follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|ServiceType| Extra Flag | Time to Live | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zxdnet Datagram Header
Note that each tick mark represents one bit position.
Service Type: 6 bits
The Service Type provides an indication of the abstract parameters of the
quality of service desired. These parameters are to be used to guide the
selection of the actual service parameters when transmitting a datagram through
a particular network. Several networks offer service precedence, which somehow
treats high precedence traffic as more important than other traffic (generally
by accepting only traffic above a certain precedence at time of high load). The
major choice is a three way tradeoff between low-delay,high-reliability, and
high-throughput.
Bit 0: Explicit Congestion Notification (ECN): When the link is
congested, the gateway sets this bit to 1.
Bit 1: No Errors (NE): If this bit is set to 1, error conditions are not
reported via ZCMP, even if an error occurs.
Bit 2: 0 = Normal Delay, 1 = Low Delay.
Bit 3: 0 = Normal Throughput, 1 = High Throughput.
Bit 4: 0 = Normal Reliability, 1 = High Reliability.
Bit 5: User defined.
0 1 2 3 4 5
+---+---+---+---+---+---+
|ECN|N E| D | T | R | U |
+---+---+---+---+---+---+
Extra Flag: 8 bits
The Extra Flag is defined and used by the user.
Time to Live: 8 bits
This field defines the maximum hop count allowed for a datagram. The
sender initializes this value, and each routing node decrements it by one upon
processing. If the TTL reaches zero before the datagram arrives at its
destination, the datagram is immediately discarded. This mechanism prevents
infinite routing loops and enforces delivery scope constraints.
Protocol: 8 bits
This field indicates the next level protocol used in the data portion of
the Zxdnet datagram.
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets, including
Zxdnet header and data. This field allows the length of a datagram to be up to
65535 octets. Such long datagrams are impractical for most hosts and networks.
All hosts must be prepared to accept datagrams of up to 48 octets. It is
recommended that hosts only send datagrams larger than 48 octets if they have
assurance that the destination is prepared to accept the larger datagrams.
The number 48 is selected to allow a reasonable sized data block to be
transmitted in addition to the required header information. For example, this
size allows a data block of 32 octets plus 16 header octets to fit in a
datagram. The Zxdnet header is 16 octets.
Header Checksum: 16 bits
A checksum computed over the header fields only. As certain header fields
(e.g., Time to Live) may change during transit, this checksum MUST be validated
and recalculated at every node that processes the header.
Checksum Algorithm:
The checksum field is the 16-bit one's complement of the one's
complement sum of all 16-bit words in the header. During computation, the
checksum field itself is treated as zero. If the computed checksum is zero, it
is transmitted as all ones.
Zero Checksum Handling:
If the checksum field in the received datagram is zero, the receiver
must skip the verification process.
Source Address: 32 bits
The source address. See section 2.3.
Destination Address: 32 bits
The destination address. See section 2.3.
4. EXAMPLE
Zxdnet Datagram Structure (Hex View):
0000: 00 00 40 01
0004: 00 14 00 00
0008: 0a 01 00 01
000C: 0a 01 00 02
0010: 48 65 6c 6c
Field Breakdown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|ServiceType| Extra Flag | Time to Live | Protocol |
|0|0|0 0 0 0 0 0|0 0 0 0 0 0 0 0| 0x40 | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | Header Checksum |
| 0x0014 | 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
| 0x0a010001 (10.1.0.1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| 0x0a010002 (10.1.0.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Data (4 bytes) |
| 0x48 0x65 0x6c 0x6c ("Hell") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Parameters:
ServiceType: 0x00 (Default: Normal delay/throughput/reliability and NE
disabled)
TTL: 0x40 (maximum 64 hops)
Protocol: 0x01
Total Length: 0x0014 (16 header + 4 data = 20 bytes)
Checksum: 0x0000 (Sender skipped validation)
User Data: ASCII "Hell" (0x48 65 6c 6c)