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)