DTN Management Architecture

1.1. Purpose

This document describes how challenged network properties affect the operation of devices in those networks. This description is presented as a logical architecture formed from a union of best practices for operating devices deployed in challenged environments.¶

The provided logical architecture documents one approach for management in support of device self-operation. Self-operation is the practice of operating a device without human interactivity, without system-in-the-loop synchronous function, and without a synchronous underlying transport layer. This means that devices determine their own schedules for data reporting, their own operational configuration, and perform their own error discovery and mitigation.¶

1.2. Scope

This document includes that information necessary to document existing practices for operating devices in a challenged network in the context of a logical architecture. A logical architecture describes the concepts and principles that support the logical operation of a system. This includes identifying components of the system (such as in a reference model), the behaviors they enable, and use cases describing how those behaviors result in the desired operation of the system.¶

Logical architectures are not functional architectures. Therefore, any functional design for achieving desired behaviors is out of scope for this document. What is presented here is a set of architectural principles. It is not implied to be complete or to define interfaces between components.¶

The selection of any particular transport or network layer is outside of the scope of this document. The DTNMA does not require the use of any specific protocol such as IP, BP, TCP, or UDP. In particular, the DTNMA design does not assume the use of either IPv4 or IPv6.¶

Network features such as naming, addressing, routing, and communications security are out of scope of the DTNMA. It is presumed that any operational network communicating DTNMA messages would implement these services for any payloads carried by that network.¶

The interactions between and amongst the DTNMA and other management approaches are outside of the scope of this document.¶

1.3. Organization

The remainder of this document is organized into the following nine sections, described as follows.¶

Terminology:

This section identifies terms fundamental to understanding DTNMA concepts. Whenever possible, these terms align in both word selection and meaning with their use in other management protocols.¶

Challenged Network Overview:

This section describes important aspects of challenged networks and necessary approaches for their management.¶

Desirable Design Properties:

This section defines those properties of the DTNMA needed to operate within the constraints of a challenged network. These properties are similar to the specification of system-level requirements of a DTN management solution.¶

Current Remote Management Approaches:

This section provides a brief overview of existing remote management approaches. Where possible, the DTNMA adopts concepts from these approaches. The limitations of current approaches from the perspective of the DTNMA desirable properties are identified and discussed.¶

Motivation for New Features:

This section provides an overall motivation for this work, to include explaining why a management architecture for challenged networks is useful and necessary.¶

Reference Model:

This section defines a reference model that can be used to reason about the DTNMA independent of an implementation or implementation architecture. This model identifies the logical components of the system and the high-level relationships and behaviors amongst those components.¶

Desired Services:

This section identifies and defines the DTNMA services provided to network and mission operators.¶

Logical Autonomy Model:

This section provides an exemplar data model that can be used to reason about DTNMA control and data flows. This model is based on the DTNMA reference model.¶

Use Cases:

This section presents multiple use cases accommodated by the DTNMA architecture. Each use case is presented as a set of control and data flows referencing the DTNMA reference model and logical autonomy model.¶

3.1. Challenged Network Constraints

Constrained networks are defined as networks where "some of the characteristics pretty much taken for granted with link layers in common use in the Internet at the time of writing are not attainable." [RFC7228]. This broad definition captures a variety of potential issues relating to physical, technical, and regulatory constraints on message transmission. Constrained networks typically include nodes that regularly reboot or are otherwise turned off for long periods of time, transmit at low or asynchronous bitrates, and/or have very limited computational resources.¶

Separately, a challenged network is defined as one that "has serious trouble maintaining what an application would today expect of the end-to-end IP model" [RFC7228]. Links in such networks may be impacted by attenuation, propagation delays, mobility, occultation, and other limitations imposed by energy and mass considerations. Therefore, systems relying on such links cannot guarantee timely end-to-end data exchange.¶

By these definitions, a "challenged" network is a special type of "constrained" network, where constraints prevent timely end-to-end data exchange. As such, "all challenged networks are constrained networks ... but not all constrained networks are challenged networks ... Delay-Tolerant Networking (DTN) has been designed to cope with challenged networks" [RFC7228].¶

Solutions that work in constrained networks might not be solutions that work in challenged networks. In particular, challenged networks exhibit the following properties that impact the way in which the function of network management is considered.¶

• Timely end-to-end data exchange cannot be guaranteed to exist at any given time between any two nodes.¶
• Latencies on the order of seconds, hours, or days must be tolerated.¶
• Individual links may be uni-directional.¶
• Bi-directional links may have asymmetric data rates.¶
• The existence of external infrastructure, services, systems, or processes such as a Domain Name Service (DNS) or a Certificate Authority (CA) cannot be guaranteed.¶

3.2. Topology and Service Implications

The set of constraints that might be present in a challenged network impact both the topology of the network and the services active within that network.¶

Operational networks handle cases where nodes join and leave the network over time. These topology changes may or may not be planned, they may or may not represent errors, and they may or may not impact network services. Challenged networks differ from other networks not in the present of topological change, but in the likelihood that impacts to topology result in impacts to network services.¶

The difference between topology impacts and service impacts can be expressed in terms of connectivity. Topological connectivity usually refers to the existence of a path between an application message source and destination. Service connectivity, alternatively, refers to the existence of a path between a node and one or more services needed to process (often just-in-time) application messaging. Examples of service connectivity include access to infrastructure services such as a Domain Name System (DNS) or a Certificate Authority (CA).¶

In networks that might be partitioned most of the time, it is less likely that a node would concurrently access both an application endpoint and one or more network service endpoints. For this reason, network services in a challenged network should be designed to allow for asynchronous operation. Accommodating this use case often involves the use of local caching, pre-placing information, and not hard-coding message information at a source that might change when a message reaches its destination.¶

        _
       /
      /  +------------+              +-----------+    Local    +---------+
TIER /   | DM (Remote |              | DA (Local |  Operation  | Managed |
 2   \   |  Operator) |              | Operator) | <---------> |   Apps  |
MGMT  \  +------------+              +-----------+             +---------+
       \_       ^                          ^
                | configs                  | configs
        _       |                          |
       /        V                          V
      /  +------------+    Remote    +------------+
TIER /   | Management |  Management  | Management |
 1   \   |   Server   | <----------> |   Client   |
MGMT  \  +------------+              +------------+
       \_

3.3. Management Special Cases

The following special cases illustrate some of the operational situations that can be encountered in the management of devices in a challenged network.¶

One-Way Management:

A managed device can only be accessed via a uni-directional link, or a via a link whose duration is shorter than a single round-trip propagation time.¶

Summary Data:

A managing device can only receive summary data of a managed device's state because a link or path is constrained by capacity or reliability.¶

Bulk Historical Reporting:

A managing device receives a large volume of historical report data for a managed device. This can occur when a managed device rejoins a network or has access to a high capacity link (or path) to the managed device.¶

Multiple Managers

A managed device tracks multiple managers in the network and communicates with them as a function of time, local state, or network topology. This includes challenged networks that interconnect two or more unchallenged networks such that managed and managing devices exist in different networks.¶

These special cases highlight the need for managed devices to operate without presupposing a dedicated connection to a single managing device. To support this, managing devices deliver instruction sets that govern the local, autonomous behavior of managed devices. These behaviors include (but are not limited to) collecting performance data, state, and error conditions, and applying pre-determined responses to pre-determined events. Managing devices in a challenged network might never expect a reply to a command, and communications from managed devices may be delivered much later than the events being reported.¶

4.1. Dynamic Architectures

The DTNMA should be agnostic of the underlying physical topology, transport protocols, security solutions, and supporting infrastructure of a given network. Due to the likelihood of operating in a frequently partitioned environment, the topology of a network may change over time. Attempts to stabilize an architecture around individual nodes can result in a brittle management framework and the creation of congestion points during periods of connectivity.¶

The DTNMA should not prescribe any association between a DM and a DA other than those defined in this document. There should be no logical limitation to the number of DMs that can control a DA, the number of DMs that a DA should report to, or any requirement that a DM and DA relationship implies a pair.¶

4.2. Hierarchically Modeled Information

The DTNMA should use data models to define the syntactic and semantic contracts for data exchange between a DA and a DM. A given model should have the ability to "inherit" the contents of other models to form hierarchical data relationships.¶

Many network management solutions use data models to specify the semantic and syntactic representation of data exchanged between managed and managing devices. The DTNMA is not different in this regard - information exchanged between DAs and DMs should conform to one or more pre-defined, normative data models.¶

A common best practice when defining a data model is to make it cohesive. A cohesive model is one that includes information related to a single purpose such as managing a single application or protocol. When applying this practice, it is not uncommon to develop a large number of small data models that, together, describe the information needed to manage a device.¶

Another best practice for data model development is the use of inclusion mechanisms to allow one data model to include information from another data model. This ability to include a data model avoids repeating information in different data models. When one data model includes information from another data model, there is an implied model hierarchy.¶

Data models in the DTNMA should allow for the construction of both cohesive models and hierarchically related models. These data models should be used to define all sources of information that can be retrieved, configured, or executed in the DTNMA. This includes supporting DA autonomy functions such as parameterization, filtering, and event driven behaviors. These models will be used to both implement interoperable autonomy engines on DAs and define interoperable report parsing mechanisms on DMs.¶

4.3. Adaptive Push of Information

DAs in the DTNMA architecture should determine when to push information to DMs as a function of their local state.¶

Pull management mechanisms require a managing device to send a query to a managed device and then wait for a response to that specific query. This practice implies some serialization mechanism (such as a control session) between entities. However, challenged networks cannot guarantee timely round-trip data exchange. For this reason, pull mechanisms should be avoided in the DTNMA.¶

Push mechanisms, in this context, refer to the ability of DAs to leverage local autonomy to determine when and what information should be sent to which DMs. The push is considered adaptive because a DA determines what information to push (and when) as an adaptation to changes to the DA's internal state. Once pushed, information might still be queued pending connectivity of the DA to the network.¶

4.4. Efficient Data Encoding

Messages exchanged between a DA and a DM in the DTNMA should be defined in a way that allows for efficient on-the-wire encoding. DTNMA design decisions that result in smaller message sizes should be preferred over those that result in larger message sizes.¶

There is a relationship between message encoding and message processing time at a node. Messages with little or no encodings may simplify node processing whereas more compact encodings may require additional activities to generate/parse encoded messages. Generally, compressing a message takes processing time at the sender and decompressing a message takes processing time at a receiver. Therefore, there is a design tradeoff between minimizing message sizes and minimizing node processing.¶

However, there is a significant advantage to smaller message sizes in a challenged network. Smaller messages require smaller periods of viable transmission for communication, they incur less re-transmission cost, and they consume less resources when persistently stored en-route in the network.¶

4.5. Universal, Unique Data Identification

Data elements within the DTNMA should be uniquely identifiable so that they can be individually manipulated. Further, these identifiers should be universal - the identifier for a data element should be the same regardless of role, implementation, or network instance.¶

Identification schemes that are relative to a specific DA or specific system configuration might change over time. In particular, nodes in a challenged network may change their status or configuration during periods of partition from other parts of the network. Resynchronizing relative state or configuration should be avoided whenever possible.¶

4.6. Runtime Data Definitions

The DTNMA allows for the addition of new data elements to a data model as part of the runtime operation of the management system. These definitions may represent custom data definitions that are applicable only for a particular device or network. Custom definitions should also be able to be removed from the system during runtime.¶

The goal of this approach is to dynamically add or remove data elements to the local runtime schemas as needed - such as the definition of new counters, new reports, or new rules.¶

The custom definition of new data from existing data (such as through data fusion, averaging, sampling, or other mechanisms) provides the ability to communicate desired information in as compact a form as possible.¶

Custom data elements should be calculated and used both as parameters for DA autonomy and for more efficient reporting to DMs. Defining new data elements allows for DAs to perform local data fusion and defining new reporting templates allows for DMs to specify desired formats and generally save on link capacity, storage, and processing time.¶

4.7. Autonomous Operation

The management of applications by a DA should be achievable using only knowledge local to the DA because DAs might need to operate during times when they are disconnected from a DM.¶

DA autonomy may be used for simple automation of predefined tasks or to support semi-autonomous behavior in determining when to run tasks and how to configure or parameterize tasks when they are run.¶

Important features provided by the DA are listed below. These features work together to accomplish tasks. As such, there is commonality amongst their definitions and nature of their benefits.¶

Stand-alone Operation:

Pre-configuration allows DAs to operate without regular contact with other nodes in the network. Updates for configurations remain difficult in a challenged network, but this approach removes the requirement that a DM be in-the-loop during regular operations. Sending stimuli-and-responses to a DA during periods of connectivity allows DAs to self-manage during periods of disconnectivity.¶

Deterministic Behavior:

Operational systems might need to act in a deterministic way even in the absence of an operator in-the-loop. Deterministic behavior allows an out-of-contact DM to predict the state of a DA and to determine how a DA got into a particular state.¶

Engine-Based Behavior:

Operational systems might not be able to deploy "mobile code" [RFC4949] solutions due to network bandwidth, memory or processor loading, or security concerns. Engine-based approaches provide configurable behavior without incurring these concerns.¶

Authorization, and Accounting:

The DTNMA does not require a specific underlying transport protocol, network infrastructure, or network services. Therefore, mechanisms for authorization and accounting need to be present in a standard way at DAs and DMs to provide these functions if the underlying network does not. This is particularly true in cases where multiple DMs may be active concurrently in the network.¶

To understand the contributions of these features to a common behavior, consider the example of a managed device coming online with a set of pre-installed configuration. In this case, the device's stand-alone operation comes from the pre-configuration of its local autonomy engine. This engine-based behavior allows the system to behave in a deterministic way and any new configurations will need to be authorized before being adopted.¶

Features such as deterministic processing and engine-based behavior do not preclude the use of other Artificial Intelligence (AI) and Machine Learning (ML) approaches on a managed device.¶

5.1. SNMP and SMI Models

An early and widely used example of a remote management protocol is the Simple Network Management Protocol (SNMP) currently at Version 3 [RFC3410]. The SNMP utilizes a request/response model to get and set data values within an arbitrarily deep object hierarchy. Objects are used to identify data such as host identifiers, link utilization metrics, error rates, and counters between application software on managing and managed devices [RFC3411]. Additionally, SNMP supports a model for unidirectional push messages, called event notifications, based on agent-defined triggering events.¶

SNMP relies on logical sessions with predictable round-trip latency to support its "pull" mechanism but a single activity is likely to require many round-trip exchanges. Complex management can be achieved, but only through careful orchestration of real-time, end-to-end, managing-device-generated query-and-response logic.¶

There is existing work that uses the SNMP data model to support some low-fidelity Agent-side processing, to include the Distributed Management Expression MIB [RFC2982] and Definitions of Managed Objects for the Delegation of Management Scripts [RFC3165]. However, Agent autonomy is not an SNMP mechanism, so support for a local agent response to an initiating event is limited. In a challenged network where the delay between a managing device receiving an alert and sending a response can be significant, SNMP is insufficient for autonomous event handling.¶

5.2. XML-Infoset-Based Protocols and YANG Models

Several network management protocols, including NETCONF [RFC6241], RESTCONF [RFC8040], and CORECONF [I-D.ietf-core-comi], share the same XML information set [xml-infoset] for its hierarchical managed information and [XPath] expressions to identify nodes of that information model. Since they share the same information model and the same data manipulation operations, together they will be referred to as "*CONF" protocols. Each protocol, however, provides a different encoding of that information set and its related operation-specific data.¶

The YANG modeling language of [RFC7950] is used to define the data model for these management protocols. Currently, YANG represents the IETF standard for defining managed information models.¶

5.3. gRPC Network Management Interface (gNMI)

Another emerging but not-IETF-affiliated management protocol is the gRPC Network Management Interface (gNMI) [gNMI] which is based on gRPC messaging and uses Protobuf data modeling.¶

The same limitations of RESTCONF listed above apply to gNMI because of its reliance on synchronous HTTP exchanges and TLS security for normal operations, as well as the likely deep nesting of data schemas. There is a capability for gNMI to transport JSON-encoded YANG-modeled data, but this composing is not fully standardized and relies on specific tool integrations to operate.¶

5.4. Intelligent Platform Management Interface (IPMI)

A lower-level remote management protocol, intended to be used to manage hardware devices and network appliances below the operating system (OS), is the Intelligent Platform Management Interface (IPMI) standardized in [IPMI]. The IPMI is focused on health monitoring, event logging, firmware management, and serial-over-LAN (SOL) remote console access in a "pre-OS or OS-absent" host environment. The IPMI operates over a companion Remote Management Control Protocol (RMCP) for messaging, which itself can use UDP for transport.¶

Because the IPMI and RCMP are tailored to low-level and well-connected devices within a datacenter, with typical workflows requiring many messaging round trips or low-latency interactive sessions, they are not suitable for operation over a challenged network.¶

5.5. Autonomic Networking

The future of network operations requires more autonomous behavior including self-configuration, self-management, self-healing, and self-optimization. One approach to support this is termed Autonomic Networking [RFC7575].¶

There is a large and growing set of work within the IETF focused on developing an Autonomic Networking Integrated Model and Approach (ANIMA). The ANIMA work has developed a comprehensive reference model for distributing autonomic functions across multiple nodes in an autonomic networking infrastructure [RFC8993].¶

This work, focused on learning the behavior of distributed systems to predict future events, is an emerging network management capability. This includes the development of signalling protocols such as GRASP [RFC8990] and the autonomic control plane (ACP) [RFC8368].¶

Both autonomic and challenged networks require similar degrees of autonomy. However, challenged networks cannot provide the complex coordination between nodes and distributed supporting infrastructure necessary for the frequent data exchanges for negotiation, learning, and bootstrapping associated with the above capabilities.¶

There is some emerging work in ANIMA as to how disconnected devices might join and leave the autonomic control plane over time. However, this work is solving an important, but different, problem than that encountered by challenged networks.¶

5.6. Deep Space Autonomy

Outside of the terrestrial networking community, there are existing and established remote management systems used for deep space mission operations. Examples of two of these are for the New Horizons mission to Pluto [NEW-HORIZONS] and the DART mission to the asteroid Dimorphos [DART].¶

The DTNMA has some heritage in the concepts of deep space autonomy, but each of those mission instantiations use mission-specific data encoding, messaging, and transport as well as mission-specific (or heavily mission-tailored) modeling concepts and languages. Part of the goal of the DTNMA is to take the proven concepts from these missions and standardize the messaging syntax as well as a modular data modeling method.¶

7.1. Important Concepts

This section describes a network management concept for challenged networks (generally) and those conforming to the DTN architecture (in particular). The goal of this section is to describe how DTNMA services provide DTNMA desirable properties.¶

Similar to other network management architectures, the DTNMA draws a logical distinction between a managed device and a managing device. Managed devices use a DA to manage resident applications. Managing devices use a DM to both monitor and control DAs.¶

The DTNMA differs from some other management architectures in three significant ways, all related to the need for a device to self-manage when disconnected from a managing device.¶

Pre-shared Definitions:

Managing and managed devices should operate using pre-shared data definitions and models. This implies that static definitions should be standardized whenever possible and that managing and managed devices may need to negotiate definitions during periods of connectivity.¶

Agent Self-Management:

A managed device may find itself disconnected from its managing device. In many challenged networking scenarios, a managed device may spend the majority of its time without a regular connection to a managing device. In these cases, DAs manage themselves by applying pre-shared policies received from managing devices.¶

Command-Based Interface:

Managing devices communicate with managed devices through a command-based interface. Instead of exchanging variables, objects, or documents, a managing device issues commands to be run by a managed device. These commands may create or update variables, change data stores, or impact the managed device in ways similar to other network management approaches. The use of commands is, in part, driven by the need for DAs to receive updates from both remote management devices and local autonomy. The use of controls for the implementation of commands is discussed in more detail in Section 9.5.¶

7.2. Model Overview

A DTNMA reference model is provided in Figure 2 below. In this reference model, applications and services on a managing device communicate with a DM which uses pre-shared definitions to create a set of policy directives that can be sent to a managed device's DA via a command-based interface. The DA provides local monitoring and control (commanding) of the applications and services resident on the managed device. The DA also performs local data fusion as necessary to synthesize data products (such as reports) that can be sent back to the DM when appropriate.¶

DTNMA Reference Model¶

       Managed Device                            Managing Device
+----------------------------+           +-----------------------------+
| +------------------------+ |           | +-------------------------+ |
| |Applications & Services | |           | | Applications & Services | |
| +----------^-------------+ |           | +-----------^-------------+ |
|            |               |           |             |               |
| +----------v-------------+ |           | +-----------v-------------+ |
| | DTNMA  +-------------+ | |           | | +-----------+   DTNMA   | |
| | AGENT  | Monitor and | | |Commanding | | |  Policy   |  MANAGER  | |
| |        |   Control   | | |<==========| | | Encoding  |           | |
| | +------+-------------+ | |           | | +-----------+-------+   | |
| | |Admin | Data Fusion | | |==========>| | | Reporting | Admin |   | |
| | +------+-------------+ | | Reporting | | +-----------+-------+   | |
| +------------------------+ |           | +-------------------------+ |
+----------------------------+           +-----------------------------+
           ^                                             ^
           |            Pre-Shared Definitions           |
           |        +---------------------------+        |
           +--------| - Autonomy Model          |--------+
                    | - Application Data Models |
                    | - Runtime Data Stores     |
                    +---------------------------+

This model preserves the familiar concept of "managers" resident on managing devices and "agents" resident on managed devices. However, the DTNMA model is unique in how the DM and DA operate. The DM is used to pre-configure DAs in the network with management policies. it is expected that the DAs, themselves, perform monitoring and control functions on their own. In this way, a properly configured DA may operate without a reliable connection back to a DM.¶

7.3. Functional Elements

The reference model illustrated in Figure 2 implies the existence of certain logical components whose roles and responsibilities are discussed in this section.¶

8.1. Local Monitoring and Control

DTNMA monitoring is associated with the agent autonomy engine. The term monitoring implies regular access to information such that state changes may be acted upon within some response time period. Within the DTNMA, connections between a managed and managing device are unable to provide such a connection and, thus, monitoring functions are performed on the managed device.¶

Predicate autonomy on a managed device should collect state associated with the device at regular intervals and evaluate that collected state for any changes that require a preventative or corrective action. Similarly, this monitoring may cause the device to generate one or more reports destined to the managing device.¶

Similar to monitoring, DTNMA control results in actions by the agent to change the state or behavior of the managed device. All control in the DTNMA is local control. In cases where there exists a timely connection to a manager, received Controls are still run through the autonomy engine. In this case, the stimulus is the direct receipt of the Control and the response is to immediately run the Control. In this way, there is never a dependency on a session or other stateful exchange with any remote entity.¶

8.2. Local Data Fusion

DTNMA Fusion services produce new data products from existing state on the managed device. These fusion products can be anything from simple summations of sampled counters to complex calculations of behavior over time.¶

Fusion is an important service in the DTNMA because fusion products are part of the overall state of a managed device. Complete knowledge of this overall state is important for the management of the device, particularly in a stimulus-response system whose stimuli are evaluated against this state. In particular, the predicates of rules on a DA may refer to fused data.¶

In-situ data fusion is an important function as it allows for the construction of intermediate summary data, the reduction of stored and transmitted raw data, possibly fewer predicates in rule definitions, and otherwise insulates the data source from conclusions drawn from that data.¶

While some fusion is performed in any management system, the DTNMA requires fusion to occur on the managed device itself. If the network is partitioned such that no connection to a managing device is available, fusion happens locally. Similarly, connections to a managing device might not remain active long enough for round-trip data exchange or may not have the bandwidth to send all sampled data.¶

8.3. Remote Configuration

DTNMA configuration services update the local configuration of a managed device with the intent to impact the behavior and capabilities of that device. The change of device configurations is a common service provided by many network management systems. The DTNMA has a unique approach to configuration for the following reasons.¶

The DTNMA configuration service is unique in that the selection of managed device configurations occurs, itself, as a function of the state of the device. This implies that management proxies on the device store multiple configuration functions that can be applied as needed without consultation from a managing device.¶

When detecting stimuli, the agent autonomy engine supports a mechanism for evaluating whether application monitoring data or runtime data values are recent enough to indicate a change of state. In cases where data has not been updated recently, it may be considered stale and not used to reliably indicate that some stimulus has occurred.¶

8.4. Remote Reporting

DTNMA reporting services collect information known to the managed device and prepare it for eventual transmission to one or more managing devices. The contents of these reports, and the frequency at which they are generated, occurs as a function of the state of the managed device, independent of the managing device.¶

Once generated, it is expected that reports might be queued pending a connection back to a managing device. Therefore, reports need to be differentiable as a function of the time they were generated.¶

When reports are sent to a managing device over a challenged network, they may arrive out of order due to taking different paths through the network or being delayed due to retransmissions. A managing device should not infer meaning from the order in which reports are received.¶

Reports may or may not be associated with a specific Control. Some reports may be annotated with the Control that caused the report to be generated. Sometimes, a single report will represent the end state of applying multiple Controls.¶

8.5. Authorization

Both local and remote services provided by the DTNMA affect the behavior of multiple applications on a managed device and may interface with multiple managing devices.¶

Authorization services enforce the potentially complex mapping of other DTNMA services amongst managed and managing devices in the network. For example, fine-grained access control can determine which managing devices receive which reports, and what Controls can be used to alter which managed applications.¶

This is particularly beneficial in networks that either deal with multiple administrative entities or overlay networks that cross administrative boundaries. Allowlists, blocklists, key-based infrastructures, or other schemes may be used for this purpose.¶

10.1. Notation

The use cases presented in this section are documented with a shorthand notation to describe the types of data sent between managers and agents. This notation, outlined in Table 1, leverages the definitions of autonomy model components defined in Section 9.¶

These notations do not imply any implementation approach. They only provide a succinct syntax for expressing the data flows in the use case diagrams in the remainder of this section.¶

10.3. Intermittent Connectivity

Building from the nominal configuration in Section 10.2, this scenario shows a challenged network in which connectivity between DTNMA Agent B and the DM is temporarily lost. Control flows for this case are outlined in Figure 5.¶

Challenged Management Control Flow¶

+-----------+           +---------+           +---------+
|   DTNMA   |           |  DTNMA  |           |  DTNMA  |
| Manager A |           | Agent A |           | Agent B |
+----+------+           +----+----+           +----+----+
    |                       |                     |
    |-----PROD(1s, EDD1)--->|                     | (1)
    |----------------------------PROD(1s, EDD1)-->|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     | (2)
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |                       |            RPT(EDD1)| (3)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |                       |            RPT(EDD1)| (4)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------RPT(EDD1), RPT(EDD1)--------| (5)
    |                       |                     |

In a challenged network, DAs store reports pending a transmit opportunity.¶

In this figure, DTNMA Manager A sends a policy to DTNMA Agents A and B to produce an EDD (EDD1) every second in (step 1). Each DA receives this policy and configures their respective autonomy engines for this production. Produced reports are transmitted when there is connectivity between the DA and DM (step 2).¶

At some point, DTNMA Agent B loses the ability to transmit in the network (steps 3 and 4). During this time period, DA B continues to produce reports, but they are queued for transmission. This queuing might be done by the DA itself or by a supporting transport such as BP. Eventually (and before the next scheduled production of EDD1), DTNMA Agent B is able to transmit in the network again (step 5) and all queued reports are sent at that time. DTNMA Agent A maintains connectivity with the DM during steps 3-5, and continues to send reports as they are generated.¶

10.4. Open-Loop Reporting

This scenario illustrates the DTNMA open-loop control paradigm, where DAs manage themselves in accordance with policies provided by DMs, and provide reports to DMs based on these policies.¶

The control flow shown in Figure 6, includes an example of data fusion, where multiple policies configured by a DM result in a single report from a DA.¶

Consolidated Management Control Flow¶

+-----------+           +---------+           +---------+
|   DTNMA   |           |  DTNMA  |           |  DTNMA  |
| Manager A |           | Agent A |           | Agent B |
+----+------+           +----+----+           +----+----+
    |                       |                     |
    |-----PROD(1s, EDD1)--->|                     | (1)
    |----------------------------PROD(1s, EDD1)-->|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     | (2)
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |----------------------------PROD(1s, EDD2)-->| (3)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<--------------------------RPT(EDD1,EDD2)----| (4)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<--------------------------RPT(EDD1,EDD2)----|
    |                       |                     |

A many-to-one mapping between management policy and device state reporting is supported by the DTNMA.¶

In this figure, DTNMA Manager A sends a policy statement in the form of a rule to DTNMA Agents A and B, which instructs the DAs to produce a report with EDD1 every second (step 1). Each DA receives this policy, which is stored in its respective Rule Database, and configures its Autonomy Engine. Reports are transmitted by each DA when produced (step 2).¶

At a later time, DTNMA Manager A sends an additional policy to DTNMA Agent B, requesting the production of a report for EDD2 every second (step 3). This policy is added to DTNMA Agent B's Rule Database.¶

Following this policy update, DTNMA Agent A will continue to produce EDD1 and DTNMA Agent B will produce both EDD1 and EDD2 (step 4). However, DTNMA Agent B may provide these values to the DM in a single report rather than as 2 independent reports. In this way, there is no direct mapping between the single consolidated report sent by DTNMA Agent B (step 4) and the two different policies sent to DTNMA Agent B that caused that report to be generated (steps 1 and 3).¶

10.5. Multiple Administrative Domains

The managed applications on a DA may be controlled by different administrative entities in a network. The DTNMA allows DAs to communicate with multiple DMs in the network, such as in cases where there is one DM per administrative domain.¶

Whenever a DM sends a policy expression to a DA, that policy expression may be associated with authorization information. One method of representing this is an ACL.¶

The ability of one DM to access the results of policy expressions configured by some other DM will be limited to the authorization annotations of those policy expressions.¶

An example of multi-manager authorization is illustrated in Figure 7.¶

Multiplexed Management Control Flow¶

+-----------+               +---------+                 +-----------+
|   DTNMA   |               |  DTNMA  |                 |   DTNMA   |
| Manager A |               | Agent A |                 | Manager B |
+-----+-----+               +----+----+                 +-----+-----+
     |                          |                            |
     |---DEF(ACL1,V1,EDD1*2)--->|<---DEF(ACL2, V2, EDD2*2)---| (1)
     |                          |                            |
     |---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2)
     |                          |                            |
     |<--------RPT(V1)----------|                            | (3)
     |                          |--------RPT(V2)------------>|
     |<--------RPT(V1)----------|                            |
     |                          |--------RPT(V2)------------>|
     |                          |                            |
     |                          |<---PROD(1s, V1)------------| (4)
     |                          |                            |
     |                          |----ERR(V1 no perm.)------->|
     |                          |                            |
     |--DEF(NULL,V3,EDD3*3)---->|                            | (5)
     |                          |                            |
     |---PROD(1s, V3)---------->|                            | (6)
     |                          |                            |
     |                          |<----PROD(1s, V3)-----------|
     |                          |                            |
     |<--------RPT(V3)----------|--------RPT(V3)------------>| (7)
     |<--------RPT(V1)----------|                            |
     |                          |--------RPT(V2)------------>|
     |<-------RPT(V3)-----------|--------RPT(V3)------------>|
     |<-------RPT(V1)-----------|                            |
     |                          |--------RPT(V2)------------>|

Multiple DMs may interface with a single DA, particularly in complex networks.¶

In this figure, both DTNMA Managers A and B send policies to DTNMA Agent A (step 1). DM A defines a variable (V1) whose value is given by the mathematical expression (EDD1 * 2) and is associated with an ACL (ACL1) that restricts access to V1 to DM A only. Similarly, DM B defines a variable (V2) whose value is given by the mathematical expression (EDD2 * 2) and associated with an ACL (ACL2) that restricts access to V2 to DM B only.¶

Both DTNMA Managers A and B also send policies to DTNMA Agent A to report on the values of their variables at 1 second intervals (step 2). Since DM A can access V1 and DM B can access V2, there is no authorization issue with these policies and they are both accepted by the autonomy engine on Agent A. Agent A produces reports as expected, sending them to their respective managers (step 3).¶

Later (step 4) DM B attempts to configure DA A to also report to it the value of V1. Since DM B does not have authorization to view this variable, DA A does not include this in the configuration of its autonomy engine and, instead, some indication of permission error is included in any regular reporting back to DM B.¶

DM A also sends a policy to Agent A (step 5) that defines a variable (V3) whose value is given by the mathematical expression (EDD3 * 3) and is not associated with an ACL, indicating that any DM can access V3. In this instance, both DM A and DM B can then send policies to DA A to report the value of V3 (step 6). Since there is no authorization restriction on V3, these policies are accepted by the autonomy engine on Agent A and reports are sent to both DM A and B over time (step 7).¶

10.6. Cascading Management

There are times where a single network device may serve as both a DM for other DAs in the network and, itself, as a device managed by someone else. This may be the case on nodes serving as gateways or proxies. The DTNMA accommodates this case by allowing a single device to run both a DA and DM.¶

An example of this configuration is illustrated in Figure 8.¶

Data Fusion Control Flow¶

               ---------------------------------------
               |                Node B               |
               |                                     |
+-----------+  |   +-----------+       +---------+   |    +---------+
|   DTNMA   |  |   |   DTNMA   |       |  DTNMA  |   |    |  DTNMA  |
| Manager A |  |   | Manager B |       | Agent B |   |    | Agent C |
+---+-------+  |   +-----+-----+       +----+----+   |    +----+----+
    |          |         |                  |        |         |
    |--------------DEF(NULL,V0,EDD1+EDD2)-->|        |         | (1)
    |--------------PROD(1s,V0)------------->|        |         |
    |          |         |                  |        |         |
    |          |         |--PROD(1s,EDD1)-->|        |         | (2)
    |          |         |---------------------PROD(1s,EDD2)-->| (2)
    |          |         |                  |        |         |
    |          |         |                  |        |         |
    |          |         |<----RPT(EDD1)----|        |         | (3)
    |          |         |<--------------------RPT(EDD2)-------| (3)
    |          |         |                  |        |         |
    |<-------------RPT(V0)------------------|        |         | (4)
    |          |         |                  |        |         |
    |          |         |                  |        |         |
               |                                     |
               |                                     |
               ---------------------------------------

A device can operate as both a DTNMA Manager and an Agent.¶

In this example, we presume that DA B is able to sample a given EDD (EDD1) and that DA C is able to sample a different EDD (EDD2). Node B houses DM B (which controls DA C) and DA B (which is controlled by DM A). DM A must periodically receive some new value that is calculated as a function of both EDD1 and EDD2.¶

First, DM A sends a policy to DA B to define a variable (V0) whose value is given by the mathematical expression (EDD1 + EDD2) without a restricting ACL. Further, DM A sends a policy to DA B to report on the value of V0 every second (step 1).¶

DA B can require the ability to monitor both EDD1 and EDD2. However, the only way to receive EDD2 values is to have them reported back to Node B by DA C and included in the Node B runtime data stores. Therefore, DM B sends a policy to DA C to report on the value of EDD2 (step 2).¶

DA C receives the policy in its autonomy engine and produces reports on the value of EDD2 every second (step 3).¶

DA B may locally sample EDD1 and EDD2 and uses that to compute values of V0 and report on those values at regular intervals to DM A (step 4).¶

While a trivial example, the mechanism of associating fusion with the Agent function rather than the Manager function scales with fusion complexity. Within the DTNMA, DAs and DMs are not required to be separate software implementations. There may be a single software application running on Node B implementing both DM B and DA B roles.¶