This document defines the current MTRP control-message payload format and the control-plane message types presently recognized by the implementation.
This document covers:
A control message MUST be carried in an MTRP frame whose IS_CONTROL flag is set.
The payload of a control frame begins with a control-message header.
The current control payload layout is:
Message Header (1 byte)Message Body (variable, opcode-dependent)The current control-message header consists of a single byte:
| Field | Size | Meaning |
|---|---|---|
| Opcode | 1 byte | identifies the control message type |
The current message-header length is 1 byte.
The current opcode set is:
| Value | Name | Current Status |
|---|---|---|
| 0 | NONE | defined |
| 1 | HELLO_NEIGHBORS | implemented |
| 2 | ADDRESS_CLAIM | implemented |
| 3 | ADDRESS_CONFLICT | implemented |
| 4 | ROUTE_ADVERTISEMENT | implemented |
| 5 | ROUTE_REQUEST | defined, not currently implemented |
| 6 | TIME_SYNC | defined, not currently implemented |
The HELLO_NEIGHBORS message is used to advertise local neighbor-facing capability state.
| Field | Size | Meaning |
|---|---|---|
| Security Capabilities | 2 bytes | supported security capability bits |
| Transport Capabilities | 2 bytes | supported transport capability bits |
| Identity | 4 bytes | sender identity value |
Body length is 8 bytes.
Including the 1-byte control-message header, the payload portion used by this message is 9 bytes.
On receipt, the implementation currently uses this message to update neighbor state associated with:
The ADDRESS_CLAIM message is used during dynamic address selection and claim negotiation.
| Field | Size | Meaning |
|---|---|---|
| Candidate Node ID | 2 bytes | node address being claimed |
| Claimant ID | 4 bytes | claimant identity value |
Body length is 6 bytes.
Including the 1-byte control-message header, the payload portion used by this message is 7 bytes.
On receipt, the implementation compares the claimed candidate address and claimant identity against local address-selection state.
The message MAY trigger:
The ADDRESS_CONFLICT message is used to indicate that a proposed address claim conflicts with existing state.
| Field | Size | Meaning |
|---|---|---|
| Candidate Node ID | 2 bytes | disputed node address |
| Target Claimant ID | 4 bytes | claimant identity being challenged |
| Responder ID | 4 bytes | identity of the responding node |
Body length is 10 bytes.
Including the 1-byte control-message header, the payload portion used by this message is 11 bytes.
On receipt, the implementation validates whether the conflict applies to the local pending claim.
A valid conflict MAY cause the node to abandon the current candidate address and re-enter selection behavior.
The ROUTE_ADVERTISEMENT message is used to distribute reachable-destination information between nodes.
| Field | Size | Meaning |
|---|---|---|
| Destination Node ID | 2 bytes | advertised destination |
| Metric | 1 byte | route metric to destination |
| Sequence | 2 bytes | route freshness / version information |
| Flags | 1 byte | route flags |
Body length is 6 bytes.
Including the 1-byte control-message header, the payload portion used by this message is 7 bytes.
On receipt, the implementation evaluates the advertised route and MAY update the forwarding table according to current learned-route policy.
The implementation currently rejects invalid advertised destinations such as:
ROUTE_REQUEST is currently defined in the opcode set but is not presently implemented in the reviewed code path.
This opcode SHOULD be treated as reserved for future use unless and until a payload format and handling rule are formally defined.
TIME_SYNC is currently defined in the opcode set but is not presently implemented in the reviewed code path.
This opcode SHOULD be treated as reserved for future use unless and until a payload format and handling rule are formally defined.
The current implementation defines frame-level flags for:
RELIABLEACKHowever, the control-message opcode set does not currently define a dedicated ACK control-message payload format.
As of the current documented implementation, ACK semantics are not yet defined here as a control-plane message body.
The currently active control-plane message set consists of:
HELLO_NEIGHBORSADDRESS_CLAIMADDRESS_CONFLICTROUTE_ADVERTISEMENTThese messages all use a 1-byte control-message header followed by an opcode-specific body.