MANET Awareness Model
draft-rogge-niewiejska-manet-awareness-model-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Henning Rogge , Julia Niewiejska , Christoph Barz | ||
| Last updated | 2026-07-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 144 errors, 5 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rogge-niewiejska-manet-awareness-model-00
MANET H.R. Rogge
Internet-Draft J.N. Niewiejska
Intended status: Standards Track C.B. Barz
Expires: 21 January 2027 Fraunhofer FKIE
20 July 2026
MANET Awareness Model
draft-rogge-niewiejska-manet-awareness-model-00
Abstract
The MANET Awareness Model is a protocol- and vendor-independent data
model that exports a router's internal knowledge from different
protocols via REST or NETCONF/RESTCONF to services or applications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Rogge, et al. Expires 21 January 2027 [Page 1]
Internet-Draft MANET Awareness Model July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAM Data Model . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. ID values . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1.1. Service-ID . . . . . . . . . . . . . . . . . . . 5
3.1.2. Interface-technology-id . . . . . . . . . . . . . . . 5
3.1.3. Comparator . . . . . . . . . . . . . . . . . . . . . 6
3.1.4. Traffic-attribute-type . . . . . . . . . . . . . . . 6
3.1.5. Traffic-attribute . . . . . . . . . . . . . . . . . . 7
3.1.6. Traffic-classifier . . . . . . . . . . . . . . . . . 7
3.1.7. Traffic-selector-type . . . . . . . . . . . . . . . . 8
3.1.8. Traffic-selector . . . . . . . . . . . . . . . . . . 8
3.1.9. Interface-addresses . . . . . . . . . . . . . . . . . 8
3.1.10. Host-dns . . . . . . . . . . . . . . . . . . . . . . 8
3.1.11. Service-protocol-type . . . . . . . . . . . . . . . . 9
3.2. Dataprovider . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Topologies . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 11
3.4.1.1. Links . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Connectivity . . . . . . . . . . . . . . . . . . . . 12
3.4.3. Destinations . . . . . . . . . . . . . . . . . . . . 12
3.4.4. Attached . . . . . . . . . . . . . . . . . . . . . . 13
3.4.5. Services . . . . . . . . . . . . . . . . . . . . . . 14
3.4.6. Identities . . . . . . . . . . . . . . . . . . . . . 14
3.5. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 15
4. MAM YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7. Normative References . . . . . . . . . . . . . . . . . . . . 33
8. Informative References . . . . . . . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
Mobile ad-hoc networks (MANETs) provide IP connectivity over wireless
links without relying on fixed infrastructure. Particularly in
heterogeneous MANETs, where nodes may use different radio
technologies and link-layer mechanisms, it is important to provide
timely and reliable network state information to the application and
middleware side. Such awareness enables:
Rogge, et al. Expires 21 January 2027 [Page 2]
Internet-Draft MANET Awareness Model July 2026
* *Adaptive traffic shaping* – applications can throttle or
prioritise traffic based on available bandwidth and loss
characteristics and adapt their information exchange requirements
in general.
* *Service migration* – services may be relocated to nodes that
enjoy better connectivity, reducing latency and improving
reliability.
The *MANET Awareness Model (MAM)* defines a lightweight, extensible
data model that exposes local and neighbourhood network state to
consumers. In a typical deployment, the _information provider_ is
the local node (router) that aggregates data from multiple sources,
for example:
+=========================+=================+======================+
| Source | Role | Typical data exposed |
+=========================+=================+======================+
| *Routing protocol* | Topology & | Hop-count, loss-rate |
| (e.g., OLSRv2, AODV) | route metrics | routing metric, … |
+-------------------------+-----------------+----------------------+
| *DLEP* (Dynamic | Radio-link | Data-rate, signal- |
| Link-Exchange Protocol) | characteristics | strength, channel, … |
+-------------------------+-----------------+----------------------+
| *SENSEI* (Smart | End-to-end | Packet loss, RTT/ |
| Estimation of Network | active and | latency, available |
| State) | passive probing | capacity, … |
+-------------------------+-----------------+----------------------+
| *other* | Additional | geo-location, |
| | information | heading, … |
+-------------------------+-----------------+----------------------+
Table 1
MAM specifies a data model (see Section 3) and a corresponding YANG
module (see Section 4). By decoupling the data collection from its
consumption, MAM enables heterogeneous MANETs to make informed,
per-flow decisions while introducing no additional overhead on the
shared wireless medium.
1.1. Requirements Language
In many IETF documents, several words, when they are in all capitals
as shown below, are used to signify the requirements in the
specification. These capitalized words can bring significant clarity
and consistency to documents because their meanings are well defined.
This document defines how those words are interpreted in IETF
documents when the words are in all capitals.
Rogge, et al. Expires 21 January 2027 [Page 3]
Internet-Draft MANET Awareness Model July 2026
* These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.
* The words have the meanings specified herein only when they are in
all capitals.
* When these words are not capitalized, they have their normal
English meanings and are not affected by this document.
Authors who follow these guidelines should incorporate this phrase
near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
2. Objectives
The MANET Awareness Model was created as a single point to access
most of the state of a router (not only the routing protocol!) in a
generic and protocol independent way. It allows a router to
aggregate data from multiple sources and present them in a way that
is understandable for a service or application without knowing the
internal specifics of the router.
The MAM makes most of the topological data of the network accessible
in multiple degrees of details, from interface specific data gathered
by DLEP [RFC8175] or Neighbour Discovery protocols to available end-
to-end routing tables. It can contain a browsable directory of
services available in the network and provide access to geopositions,
both for routers and attached devices.
3. MAM Data Model
This section defines the MANET Awareness Model. Implementations MAY
omit sections of this data model if the underlying routing protocol
or platform does not provide the corresponding information. In
particular, protocols that do not maintain a complete network
topology (e.g., distance-vector protocols) may be unable to populate
fields that require global graph knowledge. Nodes SHOULD include all
information they possess and MUST NOT generate placeholder values for
unavailable data.
Rogge, et al. Expires 21 January 2027 [Page 4]
Internet-Draft MANET Awareness Model July 2026
3.1. Common Elements
This section describes elements that are shared among multiple parts
of the data model.
3.1.1. ID values
All ID values of the MAM can be recognised by the '-id' key suffix.
There are locally generated arbitrary strings by the node that
generated the MAM.
There is no guarantee that different nodes of the network share the
same ID for the same entity, e.g. a route to a special destination.
Matching MAM data entries generated by different network nodes MUST
be done by comparing data values associated to the IDs, e.g. IP
addresses.
3.1.1.1. Service-ID
Service-IDs are special because they can either refer to a list of
predefined constants or be a custom node-specific string as the other
ID values.
DNS
Access to the local DNS service of the node.
MAM REST
Access to the local MANET Awareness Model over HTTP/REST
MAM RESTCONF
Access to the local MANET Awareness Model over RESTCONF
3.1.2. Interface-technology-id
These constants describe the type communication technology that is
used for a specific interface.
radio-hf
Beyond-line-of-sight radio with a centre frequency of 3-30 MHz.
radio-vhf
Long-range radio with a centre frequency of 30-300 MHz.
radio-uhf
Radio with a centre frequency of 300-3000 MHz.
radio-shf
Radio with a centre frequency of 3-30 GHz.
Rogge, et al. Expires 21 January 2027 [Page 5]
Internet-Draft MANET Awareness Model July 2026
cable
Data transmitted over cable, both electrical and optical.
cellular
Data transmitted over cellular towers, e.g. LTE or 5G.
satcom
Data transmitted over or to a satellite in orbit.
wifi
Data transmitted over IEEE 802.11 compatible hardware.
other
Any other communication technology not covered by the above
values.
3.1.3. Comparator
These constants define how the traffic attribute is compared to the
specified constant to check if the condition is true.
less
The attribute must be less than the threshold value.
less-equal
The attribute must be less than or equal to the threshold value.
greater
The attribute must be greater than the threshold value.
greater-equal
The attribute must be greater than or equal to the threshold
value.
3.1.4. Traffic-attribute-type
Network links and paths can be characterised with different
attributes, either gathered from hardware specifications or measured
between nodes of the system. Most of the following constants have
been copied from DLEP [RFC8175].
max-bitrate-rx
Maximum incoming bit rate in bit/s possible over a link or path,
most times defined by hardware limitations.
max-bitrate-tx
Maximum outgoing bit rate in bit/s possible over a link or path,
most times defined by hardware limitations.
Rogge, et al. Expires 21 January 2027 [Page 6]
Internet-Draft MANET Awareness Model July 2026
bitrate-rx
Currently available incoming bit rate in bit/s to a destination.
This may be based purely on currently achievable modulation coding
scheme or shaped by the allocated airtime.
bitrate-tx
Currently available outgoing bit rate in bit/s to a destination.
This may be based purely on currently achievable modulation coding
scheme or shaped by the allocated airtime.
latency
Latency of the transmission over the air until the data will
arrive at the destination in seconds, disregarding delayed
transmission because of media access or queuing.
lossrate
Fraction of the transmission frames being lost as a value between
0 (no loss) and 1 (all frames lost). Frames recovered by radio
mechanisms like retransmissions are not counting as lost.
hopcount
Number of (typically radio-) links being traversed to the
destination counted as a positive integer.
rt-metric
Cost towards the destination as measured by the routing protocol,
expressed as a positive integer. The metric is considered
additive when multiple links are combined.
3.1.5. Traffic-attribute
Traffic attributes are represented as optional named presence
containers on the object they describe. Container names correspond
to the traffic attribute names (e.g. bitrate-tx, latency). Each
container, when present, contains a single leaf named value holding
the measured or configured quantity. An absent container indicates
the metric is unknown or not applicable.
3.1.6. Traffic-classifier
A traffic classifier is a boolean condition comparing a traffic
attribute against a threshold value, e.g. (bitrate-tx > 200000).
Classifiers are represented as optional per-metric presence
containers. Each container, when present, contains a value leaf
holding the threshold and a comparator leaf specifying the comparison
operator. An absent container means the classifier is not active for
that metric.
Rogge, et al. Expires 21 January 2027 [Page 7]
Internet-Draft MANET Awareness Model July 2026
3.1.7. Traffic-selector-type
A traffic selector type defines a field the operating system uses to
detect the QoS class of the traffic.
dscp
The 6-bit DSCP field with values between 0 and 63, of either IPv4
or IPv6 header.
vlan-tos
The 3-bit Priority Code Point (PCP) field in the 802.1Q VLAN
header, values 0 to 7.
vlan-id
QoS class determined by the VLAN ID of the Ethernet VLAN header,
values 0 to 4095.
udp-port
QoS class determined by a specific UDP destination port, both IPv4
and IPv6.
tcp-port
QoS class determined by a specific TCP destination port, both IPv4
and IPv6.
3.1.8. Traffic-selector
Traffic selectors are represented as optional named presence
containers that identify traffic mapped to a topology. Container
names correspond to the selector type names (dscp, vlan-tos, vlan-id,
udp-port, tcp-port). Each container, when present, contains a single
mandatory value leaf holding the matching field value. An absent
container means that selector type is not used for this topology. A
selectors container with no child containers present designates this
topology as the default for all unmatched traffic.
3.1.9. Interface-addresses
A list of at least one IP address combined with an optional MAC
address, all belonging to a single local interface of a network node.
3.1.10. Host-dns
The hostname of a node, optionally including the fully qualified
domain name.
Rogge, et al. Expires 21 January 2027 [Page 8]
Internet-Draft MANET Awareness Model July 2026
3.1.11. Service-protocol-type
The Service protocol type defines what upper-level protocol has to be
used to access a certain service on the port defined in the MAM
description.
TCP
The service uses the TCP protocol with an unspecified service
specific content.
UDP
The service uses the UDP protocol with an unspecified service
specific content.
HTTP
The service uses unencrypted HTTP version 1/2 over a TCP socket.
HTTPS
The service uses encrypted HTTP version 1/2 over a TCP socket.
HTTP3
The service uses encrypted HTTP version 3 over a UDP socket.
OTHER
The service uses a protocol not covered by the above values.
3.2. Dataprovider
Dataprovider is a container that holds information about the router
that generated and provided this data set, including its unique
identifier and relevant timestamps.
node-id
The node-id identifies the router providing this data.
creation-time
The timestamp indicating when the originating router generated
this data set. It reflects the most recent point in time at which
any of the included information was collected, encoded according
to [RFC3339].
request-time
The timestamp indicating when the client requested this data set,
encoded according to [RFC3339].
Rogge, et al. Expires 21 January 2027 [Page 9]
Internet-Draft MANET Awareness Model July 2026
3.3. Topologies
The topologies list maps each topology instance, keyed by topology-
id. Each topology describes how traffic service classes are treated
within the routing domain. Topologies describe the common network-
wide Quality of Service policies that are shared among the nodes.
topology-id
A mandatory unique string identifying a topology instance.
capabilities
A container of optional traffic classifier containers (max-
bitrate-rx, max-bitrate-tx, bitrate-rx, bitrate-tx, latency,
lossrate, hopcount, rt-metric). Each classifier container
contains the corresponding metric leaf together with a comparator
leaf. It defines the minimal interface features required to
participate in this topology. Applications may assume these
capabilities are available.
restrictions
A container of optional traffic classifier containers using the
same names and structure as capabilities. It specifies the
maximum traffic attributes a router or application is permitted to
use within this topology. These might be enforced by firewall or
traffic shaping.
selectors
A container of optional traffic selector presence containers:
dscp, vlan-tos, vlan-id, udp-port, tcp-port. Each selector
container, when present, identifies traffic mapped to this
topology by its value leaf. A selectors container with no
selector containers present designates this topology as the
default for unmatched traffic.
3.4. Nodes
The nodes list represents individual or aggregated entities within
the network, keyed by node-id. Each node entry may describe a single
router or a group of routers represented by aggregated data.
node-id
A mandatory router- or entity-local identifier for a single node
within this data description. There is no guarantee that two
different sources will assign the same node-id to the same router
or entity.
Rogge, et al. Expires 21 January 2027 [Page 10]
Internet-Draft MANET Awareness Model July 2026
members
A list of node-id values. Lists the identifiers of nodes that are
part of this compound or aggregated node. If empty this node
represents a single router.
ip
A list of IP prefixes locally assigned to this node.
dns
Contains the DNS information of the node, including its hostname
and optional fully qualified domain name (FQDN).
3.4.1. Interfaces
A list of network interfaces that are used for communication with
other network nodes.
interface-id
Mandatory identifier of the interface within the context of the
node.
medium
Describes the communication medium attached to the interface.
Contains an interface technology-id and an optional string
description.
interface-endpoint
Specifies the local addresses of the interface, both IPs and
optionally its MAC address. These addresses might not be globally
reachable.
traffic metrics
Optional traffic metric presence containers from the traffic-
attributes grouping: max-bitrate-rx, max-bitrate-tx, bitrate-rx,
bitrate-tx, latency, lossrate, hopcount, rt-metric. These apply
to the interface as a whole and are not neighbour-specific. Each
container, when present, holds a value leaf with the measured
quantity. An absent container indicates the metric is unknown or
not applicable for this interface.
links
A list of links, keyed by remote-id.
3.4.1.1. Links
A direct connection to a neighbouring node over a specific interface
Rogge, et al. Expires 21 January 2027 [Page 11]
Internet-Draft MANET Awareness Model July 2026
remote-id
The mandatory node-id of the remote neighbour.
interface-endpoint
The interface addresses of the remote neighbour, including an
optional MAC address.
traffic metrics
Optional traffic metric presence containers from the traffic-
attributes grouping: max-bitrate-rx, max-bitrate-tx, bitrate-rx,
bitrate-tx, latency, lossrate, hopcount, rt-metric. These
describe attributes specific to the neighbour relationship. Each
container, when present, holds a value leaf with the measured
quantity.
3.4.2. Connectivity
A list of neighbour nodes that are reachable directly (i.e., without
intermediate hops) within the specified topology. This corresponds
to the node-to-node adjacencies in the routing graph. Traffic metric
fields describe link-level characteristics of the direct connection.
remote-id
The mandatory node-id of the neighbour.
topology-id
The mandatory id specifying the topology in which this direct
connectivity exists.
traffic metrics
Optional traffic metric presence containers from the traffic-
attributes grouping: max-bitrate-rx, max-bitrate-tx, bitrate-rx,
bitrate-tx, latency, lossrate, hopcount, rt-metric. These
describe traffic attributes of the direct link to this neighbour.
Each container, when present, holds a value leaf with the measured
quantity.
3.4.3. Destinations
A list of IP prefixes that are reachable via routing from this node
within the specified topology. This list expresses the routing view:
which prefixes can be reached and, optionally, the sequence of nodes
used to reach them. Traffic metric fields associated with a
destination describe end-to-end path characteristics (e.g.
accumulated cost).
ip
The mandatory IP destination prefix.
Rogge, et al. Expires 21 January 2027 [Page 12]
Internet-Draft MANET Awareness Model July 2026
topology-id
The mandatory identifier of the topology over which the
destination is reachable.
traffic metrics
Optional traffic metric presence containers from the traffic-
attributes grouping: max-bitrate-rx, max-bitrate-tx, bitrate-rx,
bitrate-tx, latency, lossrate, hopcount, rt-metric. These
describe end-to-end path characteristics for reaching this
destination. Each container, when present, holds a value leaf
with the measured quantity.
path
A list of intermediate nodes, keyed by hop. Represents the
sequence of nodes used to reach the destination.
hop
The sequence position of the intermediate node in the path,
starting at 1.
remote-id
The mandatory node-id of the intermediate node.
3.4.4. Attached
A list of IP prefixes reachable through this node over a specific
topology. Traffic metric fields describe properties of reaching the
prefix from this node.
ip
The mandatory reachable prefix attached to this node.
topology-id
The mandatory identifier of the topology through which the prefix
is directly reachable.
dns
Describes DNS information associated with this prefix, if
available.
traffic metrics
Optional traffic metric presence containers from the traffic-
attributes grouping: max-bitrate-rx, max-bitrate-tx, bitrate-rx,
bitrate-tx, latency, lossrate, hopcount, rt-metric. These
describe traffic attributes associated with this directly attached
prefix. Each container, when present, holds a value leaf with the
measured quantity.
Rogge, et al. Expires 21 January 2027 [Page 13]
Internet-Draft MANET Awareness Model July 2026
3.4.5. Services
A list of network services hosted on the node or on its attached
networks, keyed by service-id, ip, and port.
service-id
The mandatory identifier of the service. This can either be a
predefined string from the MAM IANA service registry or a custom
string.
ip
The mandatory IP address on which the service is available.
port
The mandatory port number used by the service.
protocol
Transport or application-layer protocol required to access the
service: TCP, UDP, HTTP, HTTPS, HTTP3, or OTHER.
description
Provides an optional textual description of the service.
3.4.6. Identities
A list of geoposition markers generated by the network node, keyed by
identity-id. One entry may represent the position of the node
itself; others may represent attached or tracked entities.
identity-id
Mandatory unique identifier of this identity entry within the
node.
geo-location
Optional container describing the geographic location of this
identity, modelled after the TPV object of gpsd-json. The fields
time, latitude, and longitude are mandatory when the container is
present; all other fields are optional.
geo-location/time
Timestamp of the position fix in UTC, encoded as date-and-time per
RFC 3339.
geo-location/latitude
Latitude in degrees, ranging from -90 (South) to +90 (North).
geo-location/longitude
Longitude in degrees, ranging from -180 (West) to +180 (East).
Rogge, et al. Expires 21 January 2027 [Page 14]
Internet-Draft MANET Awareness Model July 2026
geo-location/altitude
Altitude above the ellipsoid in metres.
geo-location/climb
Vertical speed in metres per second; positive means ascending,
negative descending.
geo-location/track
Course over ground in degrees from true north, ranging from 0 to
360.
geo-location/speed
Speed over ground in metres per second.
self
When true, this identity represents the network node itself.
mapping
An optional list of application-specific key/value pairs, keyed by
namespace and key. Allows applications to correlate this identity
with entries in their own databases.
mapping/namespace
The name or identifier of the application that defined this
mapping.
mapping/key
An application-specific key identifying an aspect of this
identity.
mapping/value
The application-specific value associated with the key for this
identity.
3.5. JSON Encoding
When encoded as JSON [RFC7951], traffic metrics appear as named
containers on their parent object. Each container holds a single
value member. YANG identifier names are used as JSON member names
(e.g. bitrate-tx, not tx_bitrate). An absent container indicates the
metric is not available.
Traffic classifiers follow the same container structure, adding a
comparator member alongside value. Comparator enum values use the
YANG enum names exactly (less, less-equal, greater, greater-equal).
Traffic selectors are also presence containers, each holding a value
member with the matching field value.
Rogge, et al. Expires 21 January 2027 [Page 15]
Internet-Draft MANET Awareness Model July 2026
Example interface entry with a traffic metric:
{
"interface-id": "radio0",
"bitrate-tx": {
"value": 1000000
}
}
Example topology entry with a classifier and a selector:
{
"topology-id": "voice",
"capabilities": {
"bitrate-tx": {
"value": 1000000,
"comparator": "greater"
}
},
"selectors": {
"dscp": {
"value": 46
}
}
}
4. MAM YANG Module
This section defines the MAM YANG module.
<CODE BEGINS> file "ietf-manet-awareness-model.yang"
module ietf-manet-awareness-model {
namespace "urn:de:fraunhofer:fkie:rhn:mam";
prefix mam;
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; }
contact
"Editor: Henning Rogge
<mailto:henning.rogge@fkie.fraunhofer.de>
Editor: Julia Niewiejska
<mailto:julia.niewiejska@fkie.fraunhofer.de>";
description
"This module defines a standardized information access for
middleware and applications to the current state and
Rogge, et al. Expires 21 January 2027 [Page 16]
Internet-Draft MANET Awareness Model July 2026
knowledge of a MANET router";
organization "ietf manet wg";
revision "2026-07-06" {
description
"Flatten traffic attributes, classifiers, and selectors
to concrete fields";
}
grouping comparator {
description
"Comparison operator for use in traffic-classifiers.
Combined with a metric value it forms a boolean
threshold condition, e.g. latency less-equal 0.020.";
leaf comparator {
description "comparator between two numeric values.";
mandatory true;
type enumeration {
enum less;
enum less-equal;
enum greater;
enum greater-equal;
}
}
}
grouping attr-max-bitrate-rx {
description
"Value leaf for the hardware-limited maximum
receive rate.";
leaf value {
description "maximum receive bitrate in bits/s";
mandatory true;
type uint64;
}
}
grouping attr-max-bitrate-tx {
description
"Value leaf for the hardware-limited maximum
transmit rate.";
leaf value {
description "maximum transmit bitrate in bits/s";
mandatory true;
type uint64;
}
}
grouping attr-bitrate-rx {
description
Rogge, et al. Expires 21 January 2027 [Page 17]
Internet-Draft MANET Awareness Model July 2026
"Value leaf for the currently achievable receive rate.";
leaf value {
description "current receive bitrate in bits/s";
mandatory true;
type uint64;
}
}
grouping attr-bitrate-tx {
description
"Value leaf for the currently achievable transmit rate.";
leaf value {
description "current transmit bitrate in bits/s";
mandatory true;
type uint64;
}
}
grouping attr-latency {
description
"Value leaf for the one-way propagation and processing
delay.";
leaf value {
description "latency in seconds";
mandatory true;
type decimal64 {
fraction-digits 9;
range "0 .. max";
}
}
}
grouping attr-lossrate {
description
"Value leaf for the frame loss fraction.";
leaf value {
description "packet loss rate";
mandatory true;
type decimal64 {
fraction-digits 2;
range "0 .. 1";
}
}
}
grouping attr-hopcount {
description
"Value leaf for the hop count.";
leaf value {
description "hop count";
mandatory true;
type uint8;
Rogge, et al. Expires 21 January 2027 [Page 18]
Internet-Draft MANET Awareness Model July 2026
}
}
grouping attr-rt-metric {
description
"Value leaf for the routing protocol cost.";
leaf value {
description "additive routing metric";
mandatory true;
type uint64;
}
}
grouping traffic-attributes {
description
"Optional presence containers reporting measured or
configured properties of a link or path. Each metric
container is independently optional; an absent
container indicates the metric is unavailable or not
applicable.";
container max-bitrate-rx {
presence "max rx bitrate is available";
description
"Hardware-limited maximum receive rate;
does not reflect current load.";
uses attr-max-bitrate-rx;
}
container max-bitrate-tx {
presence "max tx bitrate is available";
description
"Hardware-limited maximum transmit rate;
does not reflect current load.";
uses attr-max-bitrate-tx;
}
container bitrate-rx {
presence "rx bitrate is available";
description
"Currently achievable receive rate.";
uses attr-bitrate-rx;
}
container bitrate-tx {
presence "tx bitrate is available";
description
"Currently achievable transmit rate.";
uses attr-bitrate-tx;
}
container latency {
presence "latency is available";
description
"One-way propagation and processing delay.";
Rogge, et al. Expires 21 January 2027 [Page 19]
Internet-Draft MANET Awareness Model July 2026
uses attr-latency;
}
container lossrate {
presence "lossrate is available";
description
"Frame loss fraction.";
uses attr-lossrate;
}
container hopcount {
presence "hopcount is available";
description
"Number of link-layer hops traversed to reach
this destination.";
uses attr-hopcount;
}
container rt-metric {
presence "router metric is available";
description
"Accumulated routing cost as reported by the
routing protocol.";
uses attr-rt-metric;
}
}
grouping traffic-classifiers {
description
"Optional presence containers expressing threshold
conditions on traffic attributes. Each container
pairs a metric value with a comparison operator.
Multiple present classifiers are all required to
hold simultaneously.";
container max-bitrate-rx {
presence "max rx bitrate is used as classifier";
description
"Threshold condition on the maximum receive
rate.";
uses attr-max-bitrate-rx;
uses comparator;
}
container max-bitrate-tx {
presence "max tx bitrate is used as classifier";
description
"Threshold condition on the maximum transmit
rate.";
uses attr-max-bitrate-tx;
uses comparator;
}
container bitrate-rx {
Rogge, et al. Expires 21 January 2027 [Page 20]
Internet-Draft MANET Awareness Model July 2026
presence "rx bitrate is used as classifier";
description
"Threshold condition on the currently available
receive rate.";
uses attr-bitrate-rx;
uses comparator;
}
container bitrate-tx {
presence "tx bitrate is used as classifier";
description
"Threshold condition on the currently available
transmit rate.";
uses attr-bitrate-tx;
uses comparator;
}
container latency {
presence "latency is used as classifier";
description "Threshold condition on the one-way delay.";
uses attr-latency;
uses comparator;
}
container lossrate {
presence "lossrate is used as classifier";
description
"Threshold condition on the frame loss
fraction.";
uses attr-lossrate;
uses comparator;
}
container hopcount {
presence "hopcount is used as classifier";
description "Threshold condition on the hop count.";
uses attr-hopcount;
uses comparator;
}
container rt-metric {
presence "router metric is used as classifier";
description
"Threshold condition on the accumulated routing
cost.";
uses attr-rt-metric;
uses comparator;
}
}
grouping interface-addresses {
description
"represents the addresses an interface is
Rogge, et al. Expires 21 January 2027 [Page 21]
Internet-Draft MANET Awareness Model July 2026
associated with.";
leaf-list ip {
description "IP addresses set on the interface";
type inet:ip-address;
min-elements 1;
}
leaf mac {
description "Ethernet MAC address of the interface";
type yang:mac-address;
}
}
grouping host-dns {
description
"DNS hostname and optional fully qualified domain
name of a node or attached network prefix.";
container dns {
presence "DNS information is available";
description "DNS naming for this entity.";
leaf hostname {
description
"Unqualified host name, without domain
suffix.";
type string;
mandatory true;
}
leaf fqdn {
description
"Fully qualified domain name, including
hostname and all domain labels.";
type string;
}
}
}
container db {
description
"Top-level read-only operational data exported by
this router, reflecting its current knowledge at
request time.";
config false;
container dataprovider {
description
"Metadata identifying the router that generated
this data set and the timestamps associated
with it.";
leaf node-id {
description "ID of the router providing this data";
Rogge, et al. Expires 21 January 2027 [Page 22]
Internet-Draft MANET Awareness Model July 2026
type leafref {
path "/db/nodes/node-id";
}
}
leaf creation-time {
description
"Timestamp when the data was put together by the
router, the time the most recent data included
in the update was gathered.";
reference
"RFC 3339, Section 5.6: Date and Time on
the Internet: Timestamps";
type yang:date-and-time;
}
leaf request-time {
description
"Timestamp when this data was requested by
the client";
reference
"RFC 3339, Section 5.6: Date and Time on
the Internet: Timestamps";
type yang:date-and-time;
}
}
list topologies {
description
"Each topology represents a way traffic service
classes are handled by the networks
routing protocol.";
key "topology-id";
leaf topology-id {
description "Unique identification of a traffic
topology of the network";
type string;
}
container capabilities {
description
"minimal features interfaces must provide to be
contained in this topology which is also a
minimum capability the application can assume.";
uses traffic-classifiers;
}
container restrictions {
description
"maximum traffic attributes an router/application
is allowed to use on this topology";
uses traffic-classifiers;
Rogge, et al. Expires 21 January 2027 [Page 23]
Internet-Draft MANET Awareness Model July 2026
}
container selectors {
description
"traffic selectors mapped to this topology. an
empty selectors container means this topology is
the 'default' one that gets all traffic not put
into other topologies.";
container dscp {
presence "DSCP is used as selector";
description
"Traffic classified by the 6-bit DSCP
field in the IP header, applicable to
both IPv4 and IPv6.";
leaf value {
description
"DSCP (6 bits) value selecting traffic
for this topology";
mandatory true;
type uint8 {
range "0 .. 63";
}
}
}
container vlan-tos {
presence
"VLAN type of service is used as selector";
description
"Traffic classified by the 3-bit Priority
Code Point (PCP) field in the 802.1Q
VLAN header.";
leaf value {
description
"VLAN TOS value selecting traffic for
this topology";
mandatory true;
type uint8 {
range "0 .. 7";
}
}
}
container vlan-id {
presence "VLAN ID is used as selector";
description
"Traffic classified by VLAN membership;
all frames carrying this VLAN ID are
mapped to the topology.";
leaf value {
Rogge, et al. Expires 21 January 2027 [Page 24]
Internet-Draft MANET Awareness Model July 2026
description
"VLAN ID selecting traffic for this
topology";
mandatory true;
type uint16 {
range "0 .. 4095";
}
}
}
container udp-port {
presence
"UDP destination port is used as selector";
description
"Traffic classified by UDP destination
port, applicable to both IPv4 and
IPv6.";
leaf value {
description
"UDP port selecting traffic for
this topology";
mandatory true;
type uint16;
}
}
container tcp-port {
presence
"TCP destination port is used as selector";
description
"Traffic classified by TCP destination
port, applicable to both IPv4 and
IPv6.";
leaf value {
description
"TCP port selecting traffic for
this topology";
mandatory true;
type uint16;
}
}
}
}
list nodes {
description
"a node represents an entity of the network, either a
single router or a group of routers represented
by aggregated data.";
key "node-id";
uses host-dns;
Rogge, et al. Expires 21 January 2027 [Page 25]
Internet-Draft MANET Awareness Model July 2026
leaf node-id {
description
"node-id is a router/entity-local identification
of a single node in this data description. There
is no guarantee that different nodes queried for
this data will assign the same node-id to the
same router/entity";
type string;
}
leaf-list members {
description
"the list of nodes that are part of this compound
node or group of nodes.";
type leafref {
path "/db/nodes/node-id";
}
}
leaf-list ip {
description
"the list of IP addresses that are locally on
the network node.";
type inet:ip-prefix;
}
list interfaces {
description
"the list of network interfaces locally attached
to this node that are used to communicate to
other network nodes";
key "interface-id";
uses traffic-attributes;
leaf interface-id {
description
"Identification of an interface of a node";
type string;
}
container medium {
presence "details about interface technology";
description
"a description of the communication medium
attached to the network node interface.";
leaf technology-id {
description
"Technology used by an interface.";
mandatory true;
type enumeration {
enum radio-hf;
enum radio-vhf;
Rogge, et al. Expires 21 January 2027 [Page 26]
Internet-Draft MANET Awareness Model July 2026
enum radio-uhf;
enum radio-shf;
enum cable;
enum cellular;
enum satcom;
enum wifi;
enum other;
}
}
leaf description {
description
"Optional free-text label for the
medium, e.g. a radio model name.";
type string;
}
}
container interface-endpoint {
description
"the local addresses of the interface. These
addresses might not be globally reachable";
uses interface-addresses;
}
list links {
description
"a list of known network nodes that can be
reached over this interface";
key "remote-id";
uses traffic-attributes;
leaf remote-id {
description
"The neighbour reachable over this
direct link.";
type leafref {
path "/db/nodes/node-id";
}
}
container interface-endpoint {
description
"the interface addresses of the
remote neighbor";
uses interface-addresses;
}
}
}
list services {
description
"a list of services that are on this network node
Rogge, et al. Expires 21 January 2027 [Page 27]
Internet-Draft MANET Awareness Model July 2026
or on an attached network prefix of the node";
key "service-id ip port";
leaf service-id {
description
"Unique identification of a service as
defined by the services application";
type string;
}
leaf ip {
description
"IP address on which the service
listens.";
type inet:ip-address;
}
leaf port {
description
"Network port on which the service
accepts connections.";
type uint16;
}
leaf protocol {
description
"Transport or application-layer protocol
required to access the service.";
mandatory true;
type enumeration {
enum TCP;
enum UDP;
enum HTTP;
enum HTTPS;
enum HTTP3;
enum OTHER;
}
}
leaf description {
description
"Human-readable description of the
service, its purpose, or usage
hints.";
type string;
}
}
list identities {
description
"a list of geoposition markers generated by the
network node. One of them can be the position of
the network node itself.";
Rogge, et al. Expires 21 January 2027 [Page 28]
Internet-Draft MANET Awareness Model July 2026
key "identity-id";
leaf identity-id {
description
"Identification of an entity that was created
and is handled by the local node. This can be
the node itself, dismounted personal of a
vehicle, remote controlled drones or an
remote entity tracked by the node.";
type string;
}
container geo-location {
description
"geo-location is modelled after the TPV
object of gpsd-json";
leaf time {
description
"Time/date stamp in UTC as defined in
RFC 3339";
reference
"RFC 3339, Section 5.6: Date and Time on
the Internet: Timestamps";
mandatory true;
type yang:date-and-time;
}
leaf altitude {
description
"Altitude, height above ellipsoid,
in meters";
type decimal64 {
fraction-digits 2;
}
}
leaf climb {
description
"Climb (positive) or sink (negative)
rate, meters per second";
type decimal64 {
fraction-digits 2;
}
}
leaf latitude {
description
"Latitude in degrees, positive means
North, negative means South";
mandatory true;
type decimal64 {
Rogge, et al. Expires 21 January 2027 [Page 29]
Internet-Draft MANET Awareness Model July 2026
fraction-digits 9;
range "-90 .. 90";
}
}
leaf longitude {
description
"Longitude in degrees, positive means
East, negative means West";
mandatory true;
type decimal64 {
fraction-digits 9;
range "-180 .. 180";
}
}
leaf track {
description
"Course over ground, degrees from true
north. Values range from 0 to 360,
where 0 and 360 represent the same
bearing (due north).";
type decimal64 {
fraction-digits 2;
range "0 .. 360";
}
}
leaf speed {
description
"Speed over ground, meters per second";
type decimal64 {
fraction-digits 2;
range "0 .. max";
}
}
}
leaf self {
description
"a value of true means that this geoposition
is the one of the network node itself";
type boolean;
}
list mapping {
description
"a list of application specific mappings of
the geoposition to existing data within the
application. With this mapping, applications
can integrate geopositions reported by this
data model back into their own database";
key "namespace key";
Rogge, et al. Expires 21 January 2027 [Page 30]
Internet-Draft MANET Awareness Model July 2026
leaf namespace {
description
"the name or identifier of the
application defining this mapping";
type string;
}
leaf key {
description
"an application specific key describing
an aspect of this geoposition marker";
type string;
}
leaf value {
description
"the application specific value
corresponding to the key for this
geoposition marker";
type string;
mandatory true;
}
}
}
list destinations {
description
"a list of IP prefixes reachable from this
network node over a specific topology";
key "ip topology-id";
uses traffic-attributes;
leaf ip {
description
"Destination prefix reachable via this
routing entry.";
type inet:ip-prefix;
}
leaf topology-id {
description
"Topology over which this destination
is reachable.";
type leafref {
path "/db/topologies/topology-id";
}
}
list path {
description
"a list of intermediate nodes on the way to
the destination. This allows to map a
destination to the hop-by-hop
Rogge, et al. Expires 21 January 2027 [Page 31]
Internet-Draft MANET Awareness Model July 2026
connectivity.";
key "hop";
leaf hop {
description
"Sequence position of this node in
the path, starting at 1; defines
the hop ordering toward the
destination.";
type uint8;
}
leaf remote-id {
description
"Node at this sequence position on
the path to the destination.";
type leafref {
path "/db/nodes/node-id";
}
}
}
}
list connectivity {
description
"a list of topology specific neighbour network
nodes reachable without any intermediate
hop that are part of the same network";
key "remote-id topology-id";
uses traffic-attributes;
leaf remote-id {
description
"The neighbour forming this direct
adjacency.";
type leafref {
path "/db/nodes/node-id";
}
}
leaf topology-id {
description
"Topology within which this direct
adjacency is active.";
type leafref {
path "/db/topologies/topology-id";
}
}
}
list attached {
Rogge, et al. Expires 21 January 2027 [Page 32]
Internet-Draft MANET Awareness Model July 2026
description
"a list of IP prefixes that are reachable
directly through this network node";
key "ip topology-id";
uses host-dns;
uses traffic-attributes;
leaf ip {
description
"IP prefix directly reachable through
this node.";
type inet:ip-prefix;
}
leaf topology-id {
description
"Topology through which this prefix is
directly reachable.";
type leafref {
path "/db/topologies/topology-id";
}
}
}
}
}
}
<CODE ENDS>
5. IANA Considerations
6. Security Considerations
MAM access is primarily meant for the local node or the local network
attached to the node where all possible users are trusted, not to be
used remotely. In this mode the server socket for MAM should be
bound to the loopback address, but SHOULD provide HTTPS access
anyways. If it is meant to be used remotely by other nodes or even
from unknown IPs, access must be limited by standard HTTP mechanisms
like username/password or client certificates and encrypted HTTPS
MUST be used.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Rogge, et al. Expires 21 January 2027 [Page 33]
Internet-Draft MANET Awareness Model July 2026
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
8. Informative References
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
Acknowledgements
The authors thank the participants of NATO IST-194 "Adaptive Networks
at the Tactical Edge" for their valuable feedback. Special thanks go
to Roberto Fronteddu, Florida Institute for Human and Machine
Cognition (IHMC), whose insights were instrumental in extending the
model to support group-level network-state information, particularly
for use in the context of SENSEI.
Authors' Addresses
Henning Rogge
Fraunhofer FKIE
Zanderstraße 5
53177 Bonn-Bad Godesberg
Germany
Email: henning.rogge@fkie.fraunhofer.de
Julia Niewiejska
Fraunhofer FKIE
Zanderstraße 5
53177 Bonn-Bad Godesberg
Germany
Email: julia.niewiejska@fkie.fraunhofer.de
Rogge, et al. Expires 21 January 2027 [Page 34]
Internet-Draft MANET Awareness Model July 2026
Christoph Barz
Fraunhofer FKIE
Zanderstraße 5
53177 Bonn-Bad Godesberg
Germany
Email: christoph.barz@fkie.fraunhofer.de
Rogge, et al. Expires 21 January 2027 [Page 35]