This is an old revision of the document!
Table of Contents
2. Frame Format
2.1 Purpose
This document defines the high-level structure of an MTRP frame.
2.2 Frame Model
An MTRP frame consists of:
- a protocol header
- a payload
- implementation-local metadata used during processing
Only the serialized protocol header and payload are transmitted on the wire as part of the MTRP frame representation.
2.3 Header Layout
The MTRP header carries the core routing-visible fields used for forwarding and protocol handling.
A conceptual full header layout is shown below.
| Field | Size | Purpose |
|---|---|---|
| Version | 1 byte | Protocol version |
| Flags | 1 byte | Control and behavior flags |
| Network ID | 2 bytes | Logical network identifier |
| Origin Node ID | 2 bytes | Original sender node |
| Destination Node ID | 2 bytes | Intended destination node |
| Previous Hop Node ID | 2 bytes | Last forwarding node |
| Message ID | 2 bytes | Per-origin message identifier |
| TTL | 1 byte | Remaining hop count |
The exact serialized layout MUST match the implementation used by the current firmware.
2.4 Header Semantics
2.4.1 Version
The version field identifies the protocol/header format in use.
2.4.2 Flags
The flags field carries protocol behavior bits such as:
- control/data distinction
- relay requirement
- compact-header signaling
- future reliability signaling
2.4.3 Network ID
The network ID distinguishes one logical MTRP network from another.
2.4.4 Origin Node ID
The origin node ID identifies the original sender of the frame.
2.4.5 Destination Node ID
The destination node ID identifies the intended recipient of the frame.
2.4.6 Previous Hop Node ID
The previous hop node ID identifies the node that most recently forwarded or transmitted the frame.
2.4.7 Message ID
The message ID is used for duplicate suppression and message tracking.
2.4.8 TTL
The TTL field limits how many forwarding hops a frame may traverse.
2.4 Payload Responsibilities
The payload carries protocol-specific or application-specific content.
Examples include:
- control messages
- route advertisements
- application data
2.5 Local Metadata
Local metadata is used by the router during internal processing and route resolution.
Local metadata is not equivalent to the serialized wire header.
Examples of local metadata include:
- ingress path identifier
- ingress path metric
- resolved egress path identifier
- resolved next-hop identifier
- local delivery behavior flags
2.6 Compact Operation
On constrained transports, MTRP MAY use a compact on-wire representation.
Compact operation SHOULD preserve core routing semantics while reducing header cost on limited transports.
Compact operation does not remove the requirement for the receiver to correctly determine how the frame is to be interpreted.
2.7 Broadcast and Unicast Semantics
A frame MAY be addressed as either:
- unicast, for a specific destination node
- broadcast, for network-wide or local-scope distribution
Broadcast handling and unicast handling MAY differ in forwarding and reliability behavior.
2.8 Current Limitations
The present documentation does not fully specify:
- fragmentation format
- reliable-delivery extensions
- end-to-end acknowledgment fields
- group-address wire format