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. 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 Editor: Julia Niewiejska "; 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"; } } } } } } 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, . 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 8. Informative References [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . 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]