rfc9675.original   rfc9675.txt 
Delay-Tolerant Networking E.J. Birrane Internet Engineering Task Force (IETF) E. Birrane, III
Internet-Draft S.E. Heiner Request for Comments: 9675 S. Heiner
Intended status: Informational E. Annis Category: Informational E. Annis
Expires: 30 October 2024 Johns Hopkins Applied Physics Laboratory ISSN: 2070-1721 JHU/APL
28 April 2024 November 2024
DTN Management Architecture Delay-Tolerant Networking Management Architecture (DTNMA)
draft-ietf-dtn-dtnma-14
Abstract Abstract
The Delay-Tolerant Networking (DTN) architecture describes a type of The Delay-Tolerant Networking (DTN) architecture describes a type of
challenged network in which communications may be significantly challenged network in which communications may be significantly
affected by long signal propagation delays, frequent link affected by long signal propagation delays, frequent link
disruptions, or both. The unique characteristics of this environment disruptions, or both. The unique characteristics of this environment
require a unique approach to network management that supports require a unique approach to network management that supports
asynchronous transport, autonomous local control, and a small asynchronous transport, autonomous local control, and a small
footprint (in both resources and dependencies) so as to deploy on footprint (in both resources and dependencies) so as to deploy on
constrained devices. constrained devices.
This document describes a DTN management architecture (DTNMA) This document describes a DTN Management Architecture (DTNMA)
suitable for managing devices in any challenged environment but, in suitable for managing devices in any challenged environment but, in
particular, those communicating using the DTN Bundle Protocol (BP). particular, those communicating using the DTN Bundle Protocol (BP).
Operating over BP requires an architecture that neither presumes Operating over BP requires an architecture that neither presumes
synchronized transport behavior nor relies on query-response synchronized transport behavior nor relies on query-response
mechanisms. Implementations compliant with this DTNMA should expect mechanisms. Implementations compliant with this DTNMA should expect
to successfully operate in extremely challenging conditions, such as to successfully operate in extremely challenging conditions, such as
over uni-directional links and other places where BP is the preferred over unidirectional links and other places where BP is the preferred
transport. transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 30 October 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9675.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope
1.3. Organization . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Organization
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology
3. Challenged Network Overview . . . . . . . . . . . . . . . . . 8 3. Challenged Network Overview
3.1. Challenged Network Constraints . . . . . . . . . . . . . 8 3.1. Challenged Network Constraints
3.2. Topology and Service Implications . . . . . . . . . . . . 9 3.2. Topology and Service Implications
3.2.1. Tiered Management . . . . . . . . . . . . . . . . . . 10 3.2.1. Tiered Management
3.2.2. Remote and Local Manager Associations . . . . . . . . 11 3.2.2. Remote and Local Manager Associations
3.3. Management Special Cases . . . . . . . . . . . . . . . . 12 3.3. Management Special Cases
4. Desirable Design Properties . . . . . . . . . . . . . . . . . 12 4. Desirable Design Properties
4.1. Dynamic Architectures . . . . . . . . . . . . . . . . . . 13 4.1. Dynamic Architectures
4.2. Hierarchically Modeled Information . . . . . . . . . . . 13 4.2. Hierarchically Modeled Information
4.3. Adaptive Push of Information . . . . . . . . . . . . . . 14 4.3. Adaptive Push of Information
4.4. Efficient Data Encoding . . . . . . . . . . . . . . . . . 15 4.4. Efficient Data Encoding
4.5. Universal, Unique Data Identification . . . . . . . . . . 15 4.5. Universal, Unique Data Identification
4.6. Runtime Data Definitions . . . . . . . . . . . . . . . . 16 4.6. Runtime Data Definitions
4.7. Autonomous Operation . . . . . . . . . . . . . . . . . . 17 4.7. Autonomous Operation
5. Current Remote Management Approaches . . . . . . . . . . . . 18 5. Current Remote Management Approaches
5.1. SNMP and SMI Models . . . . . . . . . . . . . . . . . . . 19 5.1. SNMP and SMI Models
5.1.1. The SMI Modeling Language . . . . . . . . . . . . . . 19 5.1.1. The SMI Modeling Language
5.1.2. SNMP Protocol and Transport . . . . . . . . . . . . . 20 5.1.2. SNMP and Transport
5.2. XML-Infoset-Based Protocols and YANG Models . . . . . . . 20 5.2. XML-Infoset-Based Protocols and YANG Data Models
5.2.1. The YANG Modeling Language . . . . . . . . . . . . . 20 5.2.1. The YANG Modeling Language
5.2.2. NETCONF Protocol and Transport . . . . . . . . . . . 22 5.2.2. NETCONF Protocol and Transport
5.2.3. RESTCONF Protocol and Transport . . . . . . . . . . . 23 5.2.3. RESTCONF Protocol and Transport
5.2.4. CORECONF Protocol and Transport . . . . . . . . . . . 23 5.2.4. CORECONF Protocol and Transport
5.3. gRPC Network Management Interface (gNMI) . . . . . . . . 23 5.3. gRPC Network Management Interface (gNMI)
5.3.1. The Protobuf Modeling Language . . . . . . . . . . . 24 5.3.1. The Protobuf Modeling Language
5.3.2. gRPC Protocol and Transport . . . . . . . . . . . . . 24 5.3.2. gRPC Protocol and Transport
5.4. Intelligent Platform Management Interface (IPMI) . . . . 24 5.4. Intelligent Platform Management Interface (IPMI)
5.5. Autonomic Networking . . . . . . . . . . . . . . . . . . 24 5.5. Autonomic Networking
5.6. Deep Space Autonomy . . . . . . . . . . . . . . . . . . . 25 5.6. Deep Space Autonomy
6. Motivation for New Features . . . . . . . . . . . . . . . . . 25 6. Motivation for New Features
7. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 26 7. Reference Model
7.1. Important Concepts . . . . . . . . . . . . . . . . . . . 26 7.1. Important Concepts
7.2. Model Overview . . . . . . . . . . . . . . . . . . . . . 27 7.2. Model Overview
7.3. Functional Elements . . . . . . . . . . . . . . . . . . . 28 7.3. Functional Elements
7.3.1. Managed Applications and Services . . . . . . . . . . 28 7.3.1. Managed Applications and Services
7.3.2. DTNMA Agent (DA) . . . . . . . . . . . . . . . . . . 29 7.3.2. DTNMA Agent (DA)
7.3.3. Managing Applications and Services . . . . . . . . . 31 7.3.3. Managing Applications and Services
7.3.4. DTNMA Manager (DM) . . . . . . . . . . . . . . . . . 32 7.3.4. DTNMA Manager (DM)
7.3.5. Pre-Shared Definitions . . . . . . . . . . . . . . . 34 7.3.5. Pre-Shared Definitions
8. Desired Services . . . . . . . . . . . . . . . . . . . . . . 34 8. Desired Services
8.1. Local Monitoring and Control . . . . . . . . . . . . . . 35 8.1. Local Monitoring and Control
8.2. Local Data Fusion . . . . . . . . . . . . . . . . . . . . 35 8.2. Local Data Fusion
8.3. Remote Configuration . . . . . . . . . . . . . . . . . . 36 8.3. Remote Configuration
8.4. Remote Reporting . . . . . . . . . . . . . . . . . . . . 36 8.4. Remote Reporting
8.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 37 8.5. Authorization
9. Logical Autonomy Model . . . . . . . . . . . . . . . . . . . 37 9. Logical Autonomy Model
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Overview
9.2. Model Characteristics . . . . . . . . . . . . . . . . . . 40 9.2. Model Characteristics
9.3. Data Value Representation . . . . . . . . . . . . . . . . 42 9.3. Data Value Representation
9.4. Data Reporting . . . . . . . . . . . . . . . . . . . . . 42 9.4. Data Reporting
9.5. Command Execution . . . . . . . . . . . . . . . . . . . . 43 9.5. Command Execution
9.6. Predicate Autonomy Rules . . . . . . . . . . . . . . . . 44 9.6. Predicate Autonomy Rules
10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. Use Cases
10.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Notation
10.2. Serialized Management . . . . . . . . . . . . . . . . . 45 10.2. Serialized Management
10.3. Intermittent Connectivity . . . . . . . . . . . . . . . 46 10.3. Intermittent Connectivity
10.4. Open-Loop Reporting . . . . . . . . . . . . . . . . . . 48 10.4. Open-Loop Reporting
10.5. Multiple Administrative Domains . . . . . . . . . . . . 49 10.5. Multiple Administrative Domains
10.6. Cascading Management . . . . . . . . . . . . . . . . . . 51 10.6. Cascading Management
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations
12. Security Considerations . . . . . . . . . . . . . . . . . . . 53 12. Security Considerations
13. Informative References . . . . . . . . . . . . . . . . . . . 53 13. Informative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 59 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses
1. Introduction 1. Introduction
This document describes a logical, informational DTN management This document describes a logical, informational Delay-Tolerant
architecture (DTNMA) suitable for operating devices in a challenged Networking Management Architecture (DTNMA) suitable for operating
architecture - such as those communicating using the DTN Bundle devices in a challenged architecture, such as those communicating
Protocol (BPv7) [RFC9171]. using the DTN Bundle Protocol version 7 (BPv7) [RFC9171].
Challenged networks have certain properties that differentiate them Challenged networks have certain properties that differentiate them
from other kinds of networks. These properties, outlined in from other kinds of networks. These properties, outlined in
Section 2.2.1 of [RFC7228], include lacking end-to-end IP Section 2.2.1 of [RFC7228], include lacking end-to-end IP
connectivity, having "serious interruptions" to end-to-end connectivity, having "serious interruptions" to end-to-end
connectivity, and exhibiting delays longer than can be tolerated by connectivity, and exhibiting delays longer than can be tolerated by
end-to-end synchronization mechanisms (such as TCP). end-to-end synchronization mechanisms (such as TCP).
These challenged properties can be caused by a variety of factors These challenged network properties can be caused by a variety of
such as physical constraints (e.g., long signal propagation delays factors such as physical constraints (e.g., long signal propagation
and frequent link disruptions), administrative policies (e.g., delays and frequent link disruptions), administrative policies (e.g.,
quality-of-service prioritization, service-level agreements, and quality-of-service prioritization, service-level agreements, and
traffic management and scheduling), and off-nominal behaviors (e.g., traffic management and scheduling), and off-nominal behaviors (e.g.,
active attackers and misconfigurations). Since these challenges are active attackers and misconfigurations). Since these challenges are
not solely caused by sparseness, instances of challenged networks not solely caused by sparseness, instances of challenged networks
will persist even in increasingly connected environments. will persist even in increasingly connected environments.
The Delay-Tolerant Networking (DTN) architecture, described in The DTN architecture, described in [RFC4838], has been designed for
[RFC4838], has been designed for data exchange in challenged data exchange in challenged networks. Just as the DTN architecture
networks. Just as the DTN architecture requires new capabilities for requires new capabilities for transport and transport security,
transport and transport security, special consideration is needed for special consideration is needed for the operation of devices in a
the operation of devices in a challenged network. challenged network.
1.1. Purpose 1.1. Purpose
This document describes how challenged network properties affect the This document describes how challenged network properties affect the
operation of devices in those networks. This description is operation of devices in such networks. This description is presented
presented as a logical architecture formed from a union of best as a logical architecture formed from a union of best practices for
practices for operating devices deployed in challenged environments. operating devices deployed in challenged environments.
One important practice captured in this document is the concept of One important practice captured in this document is the concept of
self-operation. Self-operation involves operating a device without self-operation. Self-operation involves operating a device without
human interactivity, without system-in-the-loop synchronous function, human interactivity, without system-in-the-loop synchronous
and without a synchronous underlying transport layer. This means functions, and without a synchronous underlying transport layer.
that devices determine their own schedules for data reporting, their This means that devices determine their own schedules for data
own operational configuration, and perform their own error discovery reporting, determine their own operational configuration, and perform
and mitigation. their own error discovery and mitigation.
1.2. Scope 1.2. Scope
This document includes the information necessary to document existing This document includes the information necessary to document existing
practices for operating devices in a challenged network in the practices for operating devices in a challenged network in the
context of a logical architecture. A logical architecture describes context of a logical architecture. A logical architecture describes
the logical operation of a system by identifying components of the the logical operation of a system by identifying components of the
system (such as in a reference model), the behaviors they enable, and system (such as in a reference model), the behaviors they enable, and
use cases describing how those behaviors result in the desired use cases describing how those behaviors result in the desired
operation of the system. operation of the system.
Logical architectures are not functional architectures. Therefore, Logical architectures are not functional architectures. Therefore,
any functional design for achieving desired behaviors is out of scope any functional design for achieving desired behaviors is out of scope
for this document. The set of architectural principles presented for this document. The set of architectural principles presented
here is not meant to completely specify interfaces between here is not meant to completely specify interfaces between
components. components.
The selection of any particular transport or network layer is outside 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 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, any specific protocol such as IP, BP, TCP, or UDP. In particular,
the DTNMA design does not presume the use of BPv7, IPv4 or IPv6. the DTNMA design does not presume the use of BPv7, IPv4, or IPv6.
| NOTE: As BPv7 is the preferred transport for networks | NOTE: As BPv7 is the preferred transport for networks
| conforming to the DTN architecture, the DTNMA should be | conforming to the DTN architecture, the DTNMA should be
| considered for any BPv7 network deployment. However, the DTNMA | considered for any BPv7 network deployment. However, the DTNMA
| may also be used in other networks that have similar needs for | may also be used in other networks that have similar needs for
| this particular style of self-operation. For this reason, the | this particular style of self-operation. For this reason, the
| DTNMA does not require the use of BPv7 to transport management | DTNMA does not require the use of BPv7 to transport management
| information. | information.
Network features such as naming, addressing, routing, and Network features such as naming, addressing, routing, and
communications security are out of scope of the DTNMA. It is communications security are out of scope for the DTNMA. It is
presumed that any operational network communicating DTNMA messages presumed that any operational network communicating DTNMA messages
would implement these services for any payloads carried by that would implement these services for any payloads carried by that
network. network.
The interactions between and amongst the DTNMA and other management The interactions between and amongst the DTNMA and other management
approaches are outside of the scope of this document. approaches are outside of the scope of this document.
1.3. Organization 1.3. Organization
The remainder of this document is organized into the following nine The following nine sections provide details regarding the DTNMA.
sections, described as follows.
Terminology: This section identifies terms fundamental to Terminology: Section 2 identifies terms fundamental to understanding
understanding DTNMA concepts. Whenever possible, these terms DTNMA concepts. Whenever possible, these terms align in both word
align in both word selection and meaning with their use in other selection and meaning with their use in other management
management protocols. protocols.
Challenged Network Overview: This section describes important Challenged Network Overview: Section 3 describes important aspects
aspects of challenged networks and necessary approaches for their of challenged networks and necessary approaches for their
management. management.
Desirable Design Properties: This section defines those properties Desirable Design Properties: Section 4 defines those properties of
of the DTNMA needed to operate within the constraints of a the DTNMA needed to operate within the constraints of a challenged
challenged network. These properties are similar to the network. These properties are similar to the specification of
specification of system-level requirements of a DTN management system-level requirements of a DTN management solution.
solution.
Current Remote Management Approaches: This section provides a brief Current Remote Management Approaches: Section 5 provides a brief
overview of existing remote management approaches. Where overview of existing remote management approaches. Where
possible, the DTNMA adopts concepts from these approaches. possible, the DTNMA adopts concepts from these approaches.
Motivation for New Features: This section provides an overall Motivation for New Features: Section 6 provides an overall
motivation for this work, to include explaining why a management motivation for this work. It also explains why a management
architecture for challenged networks is useful and necessary. architecture for challenged networks is useful and necessary.
Reference Model: This section defines a reference model that can be Reference Model: Section 7 defines a reference model that can be
used to reason about the DTNMA independent of an implementation or used to analyze the DTNMA independently of an implementation or
implementation architecture. This model identifies the logical implementation architecture. This model identifies the logical
components of the system and the high-level relationships and components of the system and the high-level relationships and
behaviors amongst those components. behaviors amongst those components.
Desired Services: This section identifies and defines the DTNMA Desired Services: Section 8 identifies and defines the DTNMA
services provided to network and mission operators. services provided to network and mission operators.
Logical Autonomy Model: This section provides an exemplar data model Logical Autonomy Model: Section 9 provides an example data model
that can be used to reason about DTNMA control and data flows. that can be used to analyze DTNMA control and data flows. This
This model is based on the DTNMA reference model. model is based on the DTNMA reference model.
Use Cases: This section presents multiple use cases accommodated by Use Cases: Section 10 presents multiple use cases accommodated by
the DTNMA architecture. Each use case is presented as a set of the DTNMA. Each use case is presented as a set of control and
control and data flows referencing the DTNMA reference model and data flows referencing the DTNMA reference model and logical
logical autonomy model. autonomy model.
2. Terminology 2. Terminology
This section defines terminology that either is unique to the DTNMA This section defines terminology that is either unique to the DTNMA
or is necessary for understanding the concepts defined in this or necessary for understanding the concepts defined in this
specification. specification.
Timely Data Exchange: The ability to communicate information between Timely Data Exchange: The ability to communicate information between
two (or more) entities within a required period of time. In some two (or more) entities within a required period of time. In some
cases, a 1-second exchange may not be timely and in other cases cases, a 1-second exchange may not be timely; in other cases, a
1-hour exchange may be timely. 1-hour exchange may be timely.
Local Operation: The operation of a device by an application co- Local Operation: The operation of a device by an application co-
resident on that device. Local operators are applications running resident on that device. Local operators are applications running
on a device, and there might be one or more of these applications on a device, and there might be one or more of these applications
working independently or as one to perform the local operations working independently or as one to perform the local operations
function. Absent error conditions, local operators are always function. Absent error conditions, local operators are always
expected to be available to the devices they manage. expected to be available to the devices they manage.
Remote Operation: The operation of a device by an application Remote Operation: The operation of a device by an application
running on a separate device. Remote operators communicate with running on a separate device. Remote operators communicate with
operated devices over a network. Remote operators are not always operated devices over a network. Remote operators are not always
expected to be availabe to the devices they operate. expected to be available to the devices they operate.
DTN Management: The management, monitoring, and control of a device DTN Management: The management, monitoring, and control of a device
that does not depend on stateful connections, timely data exchange that does not depend on stateful connections, timely data exchange
of management messages, or system-in-the-loop synchronous of management messages, or system-in-the-loop synchronous
functions. DTN management is accomplished as a fusion of local functions. DTN management is accomplished as a fusion of local
operation and remote operation techniques; remote operators manage operation and remote operation techniques; remote operators manage
the configuration of local operators who provide monitoring and the configuration of local operators who provide monitoring and
control of their co-resident devices. control of their co-resident devices.
DTNMA Agent (DA): A role associated with a managed device, DTNMA Agent (DA): A role associated with a managed device
responsible for reporting performance data, accepting policy responsible for reporting performance data, accepting policy
directives, performing autonomous local control, error-handling, directives, performing autonomous local control, error handling,
and data validation. DAs exchange information with DMs operating and data validation. DAs exchange information with DTNMA Managers
either on the same device and/or on remote devices in the network. (DMs) operating on the same device and/or on remote devices in the
A DA is a type of local operator. network. A DA is a type of local operator.
DTNMA Manager (DM): A role associated with a managing device DTNMA Manager (DM): A role associated with a managing device
responsible for configuring the behavior of, and eventually responsible for configuring the behavior of, and eventually
receiving information from, DAs. DMs interact with one or more receiving information from, DAs. DMs interact with one or more
DAs located on the same device and/or on remote devices in the DAs located on the same device and/or on remote devices in the
network. A DM is a type of remote operator. network. A DM is a type of remote operator.
Controls: Procedures run by a DA to change the behavior, Controls: Procedures run by a DA to change the behavior,
configuration, or state of an application or protocol managed by configuration, or state of an application or protocol managed by
that DA. This includes procedures to manage the DA itself, such that DA. These include procedures to manage the DA itself, such
as to have the DA produce performance reports or to apply new as having the DA produce performance reports or applying new
management policies. management policies.
Externally Defined Data (EDD): Typed information made available to a Externally Defined Data (EDD): Typed information made available to a
DA by its hosting device, but not computed directly by the DA DA by its hosting device but not computed directly by the DA
itself. itself.
Data Reports: Typed, ordered collections of data values gathered by Data Report: A typed, ordered collection of data values gathered by
one or more DAs and provided to one or more DMs. Reports comply one or more DAs and provided to one or more DMs. Reports comply
to the format of a given Data Report Schema. with the format of a given data report schema.
Data Report Schemas: Named, ordered collection of data elements that Data Report Schema: A named, ordered collection of data elements
represent the schema of a Data Report. that represent the schema of a data report.
Rules: Unit of autonomous specification that provides a stimulus- Rule: Unit of autonomous specification that provides a stimulus-
response relationship between time or state on a DA and the response relationship between time or state on a DA and the
actions or operations to be run as a result of that time or state. actions or operations to be run as a result of that time or state.
3. Challenged Network Overview 3. Challenged Network Overview
The DTNMA provides network management services able to operate in a The DTNMA provides network management services able to operate in
challenged network environment, such as envisioned by the DTN challenged network environments for which the DTN architecture was
architecture. This section describes what is meant by the term created. This section describes what is meant by the term
"challenged network", the important properties of such a network, and "challenged network", the important properties of such a network, and
observations on impacts to management approaches. observations on impacts to management approaches.
3.1. Challenged Network Constraints 3.1. Challenged Network Constraints
Constrained networks are defined as networks where "some of the Constrained networks are defined as networks where "some of the
characteristics pretty much taken for granted with link layers in characteristics pretty much taken for granted with link layers in
common use in the Internet at the time of writing are not common use in the Internet at the time of writing are not attainable"
attainable." [RFC7228]. This broad definition captures a variety of [RFC7228]. This broad definition captures a variety of potential
potential issues relating to physical, technical, and regulatory issues relating to physical, technical, and regulatory constraints on
constraints on message transmission. Constrained networks typically message transmission. Constrained networks typically include nodes
include nodes that regularly reboot or are otherwise turned off for that regularly reboot or are otherwise turned off for long periods of
long periods of time, transmit at low or asynchronous bitrates, and/ time, transmit at low or asynchronous bitrates, and/or have very
or have very limited computational resources. limited computational resources.
Separately, a challenged network is defined as one that "has serious Separately, a challenged network is defined as one that "has serious
trouble maintaining what an application would today expect of the trouble maintaining what an application would today expect of the
end-to-end IP model" [RFC7228]. Links in such networks may be end-to-end IP model" [RFC7228]. Links in such networks may be
impacted by attenuation, propagation delays, mobility, occultation, impacted by attenuation, propagation delays, mobility, occultation,
and other limitations imposed by energy and mass considerations. and other limitations imposed by energy and mass considerations.
Therefore, systems relying on such links cannot guarantee timely end- Therefore, systems relying on such links cannot guarantee timely end-
to-end data exchange. to-end data exchange.
| NOTE: Because challenged networks might not provide services | NOTE: Because challenged networks might not provide services
| expected of the end-to-end IP model, devices in such networks | expected of the end-to-end IP model, devices in such networks
| might not implement networking stacks associated with the end- | might not implement networking stacks associated with the end-
| to-end IP model. This means that devices might not include | to-end IP model. This means that devices might not include
| support for certain transport protocols (TCP/QUIC/UDP), web | support for certain transport protocols (TCP/QUIC/UDP), web
| protocols (HTTP), or internetworking protocols (IPv4/IPv6). | protocols (HTTP), or internetworking protocols (IPv4/IPv6).
By these definitions, a "challenged" network is a special type of By these definitions, a "challenged" network is a special type of
"constrained" network, where constraints prevent timely end-to-end "constrained" network, where constraints prevent timely end-to-end
data exchange. As such, "all challenged networks are constrained data exchange. As such, "All challenged networks are constrained
networks ... but not all constrained networks are challenged networks networks ... but not all constrained networks are challenged networks
... Delay-Tolerant Networking (DTN) has been designed to cope with ... Delay-Tolerant Networking (DTN) has been designed to cope with
challenged networks" [RFC7228]. challenged networks" [RFC7228].
Solutions that work in constrained networks might not be solutions Solutions that work in constrained networks might not be solutions
that work in challenged networks. In particular, challenged networks that work in challenged networks. In particular, challenged networks
exhibit the following properties that impact the way in which the exhibit the following properties that impact the way in which the
function of network management is considered. function of network management is considered.
* Timely end-to-end data exchange cannot be guaranteed to exist at * Timely end-to-end data exchange cannot be guaranteed to exist at
any given time between any two nodes. any given time between any two nodes.
* Latencies on the order of seconds, hours, or days must be * Latencies on the order of seconds, hours, or days must be
tolerated. tolerated.
* Managed devices cannot be guaranteed to always be powered so as to * Managed devices cannot be guaranteed to always be powered so as to
receive ad-hoc management requests (even requests with receive ad hoc management requests (even requests with
artificially extended timeout values). artificially extended timeout values).
* Individual links may be uni-directional. * Individual links may be unidirectional.
* Bi-directional links may have asymmetric data rates. * Bidirectional links may have asymmetric data rates.
* The existence of external infrastructure, services, systems, or * The existence of external infrastructure, services, systems, or
processes such as a Domain Name Service (DNS) or a Certificate processes such as a Domain Name System (DNS) or a Certificate
Authority (CA) cannot be guaranteed. Authority (CA) cannot be guaranteed.
3.2. Topology and Service Implications 3.2. Topology and Service Implications
The set of constraints that might be present in a challenged network The set of constraints that might be present in a challenged network
impact both the topology of the network and the services active impacts both the topology of the network and the services active
within that network. within that network.
Operational networks handle cases where nodes join and leave the Operational networks handle cases where nodes join and leave the
network over time. These topology changes may or may not be planned, 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 they may or may not represent errors, and they may or may not impact
network services. Challenged networks differ from other networks not network services. Challenged networks differ from other networks not
in the presence of topological change, but in the likelihood that in the presence of topological change but in the likelihood that
impacts to topology result in impacts to network services. impacts to topology result in impacts to network services.
The difference between topology impacts and service impacts can be The difference between topology impacts and service impacts can be
expressed in terms of connectivity. Topological connectivity usually expressed in terms of connectivity. Topological connectivity usually
refers to the existence of a path between an application message refers to the existence of a path between an application message
source and destination. Service connectivity, alternatively, refers source and destination. Service connectivity, alternatively, refers
to the existence of a path between a node and one or more services to the existence of a path between a node and one or more services
needed to process (often just-in-time) application messaging. needed to process -- often just in time -- application messaging.
Examples of service connectivity include access to infrastructure Examples of service connectivity include access to infrastructure
services such as a Domain Name System (DNS) or a Certificate services such as a Domain Name System (DNS) or a CA.
Authority (CA).
In networks that might be partitioned most of the time, it is less In networks that might be partitioned most of the time, it is less
likely that a node would concurrently access both an application likely that a node would concurrently access both an application
endpoint and one or more network service endpoints. For this reason, endpoint and one or more network service endpoints. For this reason,
network services in a challenged network should be designed to allow network services in a challenged network should be designed to allow
for asynchronous operation. Accommodating this use case often for asynchronous operation. Accommodating this use case often
involves the use of local caching, pre-placing information, and not involves the use of local caching, pre-placing information, and not
hard-coding message information at a source that might change when a hard-coding message information at a source that might change when a
message reaches its destination. message reaches its destination.
| NOTE: One example of rethinking services in a challenged | NOTE: One example of rethinking services in a challenged
| network is the securing of BPv7 bundles. The BPSec [RFC9172] | network is the securing of BPv7 bundles. The Bundle Protocol
| security extensions to BPv7 do not encode security destinations | Security (BPSec) [RFC9172] security extensions to BPv7 do not
| when applying security. Instead, BPSec requires nodes in a | encode security destinations when applying security. Instead,
| network to identify themselves as security verifiers or | BPSec requires nodes in a network to identify themselves as
| acceptors when receiving and processing secured messages. | security verifiers or acceptors when receiving and processing
| secured messages.
3.2.1. Tiered Management 3.2.1. Tiered Management
Network operations and management approaches need to adapt to the Network operations and management approaches need to adapt to the
topology and service impacts encountered in challenged networks. In topology and service impacts encountered in challenged networks. In
particular, the roles and responsibilities of "managers" and "agents" particular, the roles and responsibilities of "managers" and "agents"
need to be different than what would be expected of unchallenged need to be different than what would be expected of unchallenged
networks. networks.
When connectivity to a manager cannot be guaranteed, agents will need When connectivity to a manager cannot be guaranteed, agents will need
skipping to change at page 10, line 48 skipping to change at line 456
This approach creates a two-tiered management architecture. The This approach creates a two-tiered management architecture. The
first tier is the management of the local operator configuration first tier is the management of the local operator configuration
using any one of a variety of standard mechanisms, models, and using any one of a variety of standard mechanisms, models, and
protocols. The second tier is the operation of the local device protocols. The second tier is the operation of the local device
through the local operator. through the local operator.
The DTNMA defines the DTNMA Manager (DM) as a remote operator The DTNMA defines the DTNMA Manager (DM) as a remote operator
application and the DTNMA Agent (DA) as an agent acting as a local application and the DTNMA Agent (DA) as an agent acting as a local
operator application. In this model, which is illustrated in operator application. In this model, which is illustrated in
Figure 1, the DM and DA can be viewed as applications with the DM Figure 1, the DM and DA can be viewed as applications, with the DM
producing new configurations and the DA receiving those producing new configurations and the DA receiving those
configurations from an underlying management mechanism. configurations from an underlying management mechanism.
Two-Tiered Management Architecture
_ _
/ /
/ +------------+ +-----------+ Local +---------+ / +------------+ +-----------+ Local +---------+
TIER / | DM (Remote | | DA (Local | Operation | Managed | TIER / | DM (Remote | | DA (Local | Operation | Managed |
2 \ | Operator) | | Operator) | <---------> | Apps | 2 \ | Operator) | | Operator) | <---------> | Apps |
MGMT \ +------------+ +-----------+ +---------+ MGMT \ +------------+ +-----------+ +---------+
\_ ^ ^ \_ ^ ^
| configs | configs | configs | configs
_ | | _ | |
/ V V / V V
/ +------------+ Remote +------------+ / +------------+ Remote +------------+
TIER / | Management | Management | Management | TIER / | Management | Management | Management |
1 \ | Client | <----------> | Server | 1 \ | Client | <----------> | Server |
MGMT \ +------------+ +------------+ MGMT \ +------------+ +------------+
\_ \_
Figure 1 Figure 1: Two-Tiered Management Architecture
In this approach, the configurations produced by the DM are based on In this approach, the configurations produced by the DM are based on
the DA features and associated data model. How those configurations the DA features and associated data model. How those configurations
are transported between the DM and the DA, and how results are are transported between the DM and the DA, and how results are
communicated back from the DA to the DM, can be accomplished using communicated back from the DA to the DM, can be accomplished using
whatever mechanism is most appropriate for the network and the device whatever mechanism is most appropriate for the network and the device
platforms. For example, the use of a NETCONF, RESTCONF, or SNMP platforms -- for example, the use of a Network Configuration Protocol
(NETCONF), RESTCONF, or Simple Network Management Protocol (SNMP)
server on the managed device to provide configurations to a DA. server on the managed device to provide configurations to a DA.
3.2.2. Remote and Local Manager Associations 3.2.2. Remote and Local Manager Associations
In addition to disconnectivity, topological change can alter the In addition to disconnectivity, topological change can alter the
associations amongst managed and managing devices. Different associations amongst managed and managing devices. Different
managing devices might be active in a network at different times or managing devices might be active in a network at different times or
in different partitions. Managed devices might communicate with in different partitions. Managed devices might communicate with
some, all, or none of these managing devices as a function of their some, all, or none of these managing devices as a function of their
own local configuration and policy. own local configuration and policy.
| NOTE: These concepts relate to practices in conventional | NOTE: These concepts relate to practices in conventional
| networks. For example, supporting multiple managing devices is | networks. For example, supporting multiple managing devices is
| similar to deploying multiple instances of a network service -- | similar to deploying multiple instances of a network service
| such as a DNS server or CA node. Selecting from a set of | such as a DNS server or CA node. Selecting from a set of
| managing devices is similar to a sensor node practice of | managing devices is similar to a sensor node's practice of
| electing cluster heads to act as privileged nodes for data | electing cluster heads to act as privileged nodes for data
| storage and exfiltration. | storage and exfiltration.
Therefore, a network management architecture for challenged networks Therefore, a network management architecture for challenged networks
should: should:
1. Support a many-to-many association amongst managing and managed 1. Support a many-to-many association amongst managing and managed
devices, and devices, and
2. Allow "control from" and "reporting to" managing devices to 2. Allow "control from" and "reporting to" managing devices to
function independent of one another. function independently of one another.
3.3. Management Special Cases 3.3. Management Special Cases
The following special cases illustrate some of the operational The following special cases illustrate some of the operational
situations that can be encountered in the management of devices in a situations that can be encountered in the management of devices in a
challenged network. challenged network.
One-Way Management: A managed device can only be accessed via a uni- One-Way Management: A managed device can only be accessed via a
directional link, or a via a link whose duration is shorter than a unidirectional link or via a link whose duration is shorter than a
single round-trip propagation time. Results of this management single round-trip propagation time. Results of this management
may come back at a different time, over a different path, and/or may come back at a different time, over a different path, and/or
as observable from out-of-band changes to device behavior. as observable from out-of-band changes to device behavior.
Summary Data: A managing device might only receive summary data of a Summary Data: A managing device might only receive summary data
managed device's state because a link or path is constrained by regarding a managed device's state because a link or path is
capacity or reliability. constrained by capacity or reliability.
Bulk Historical Reporting: A managing device receives a large volume Bulk Historical Reporting: A managing device receives a large volume
of historical report data for a managed device. This can occur of historical report data for a managed device. This can occur
when a managed device rejoins a network or has temporary access to when a managed device rejoins a network or has temporary access to
a high capacity link (or path) to the managed device. a high-capacity link (or path) between itself and the managing
device.
Multiple Managers A managed device tracks multiple managers in the Multiple Managers: A managed device tracks multiple managers in the
network and communicates with them as a function of time, local network and communicates with them as a function of time, local
state, or network topology. This includes challenged networks state, or network topology. This scenario would also apply to
that interconnect two or more unchallenged networks such that challenged networks that interconnect two or more unchallenged
managed and managing devices exist in different networks. networks such that managed and managing devices exist in different
networks.
These special cases highlight the need for managed devices to operate These special cases highlight the need for managed devices to operate
without presupposing a dedicated connection to a single managing without presupposing a dedicated connection to a single managing
device. Managing devices in a challenged network might never expect device. Managing devices in a challenged network might never expect
a reply to a command, and communications from managed devices may be a reply to a command, and communications from managed devices may be
delivered much later than the events being reported. delivered much later than the events being reported.
4. Desirable Design Properties 4. Desirable Design Properties
This section describes those design properties that are desirable This section describes those design properties that are desirable
when defining a management architecture operating across challenged when defining a management architecture operating across challenged
links in a network. These properties ensure that network management links in a network. These properties ensure that network management
capabilities are retained even as delays and disruptions in the capabilities are retained even as delays and disruptions in the
network scale. Ultimately, these properties are the driving design network scale. Ultimately, these properties are the driving design
principles for the DTNMA. principles for the DTNMA.
| NOTE: These properties may influence the design, construction, | NOTE: These properties may influence the design, construction,
| and adaptation of existing management tools for use in | and adaptation of existing management tools for use in
| challenged networks. For example, the properties of the DTN | challenged networks. For example, the properties of the DTN
| architecture [RFC4838] resulted in the development of BPv7 | architecture [RFC4838] resulted in the development of BPv7
| [RFC9171] and BPSec [RFC9172]. The DTNMA may result in the | [RFC9171] and BPSec [RFC9172]. Implementing the DTNMA model
| construction of new management data models, policy expressions, | may result in the construction of new management data models,
| and/or protocols. | policy expressions, and/or protocols.
4.1. Dynamic Architectures 4.1. Dynamic Architectures
The DTNMA should be agnostic of the underlying physical topology, The DTNMA should be agnostic to the underlying physical topology,
transport protocols, security solutions, and supporting transport protocols, security solutions, and supporting
infrastructure of a given network. Due to the likelihood of infrastructure of a given network. Due to the likelihood of
operating in a frequently partitioned environment, the topology of a operating in a frequently partitioned environment, the topology of a
network may change over time. Attempts to stabilize an architecture network may change over time. Attempts to stabilize an architecture
around individual nodes can result in a brittle management framework around individual nodes can result in a brittle management framework
and the creation of congestion points during periods of connectivity. and the creation of congestion points during periods of connectivity.
The DTNMA should not prescribe any association between a DM and a DA The DTNMA should not prescribe any association between a DM and a DA
other than those defined in this document. There should be no other than those defined in this document. There should be no
logical limitation to the number of DMs that can control a DA, the logical limitation on the number of DMs that can control a DA, the
number of DMs that a DA should report to, or any requirement that a number of DMs that a DA should report to, or any requirement that a
DM and DA relationship implies a pair. DM and DA relationship imply a pair.
| NOTE: Practical limitations on the relationships between and | NOTE: Practical limitations on the relationships between and
| amongst DMs and DAs will exist as a function of the | amongst DMs and DAs will exist as a function of the
| capabilities of networked devices. These limitations derive | capabilities of networked devices. These limitations derive
| from processing and storage constraints, performance | from processing and storage constraints, performance
| requirements, and other engineering factors. While this | requirements, and other engineering factors. Implementors of
| information is vital to the proper engineering of a managed and | managed and managing devices must account for these limitations
| managing device, they are implementation considerations, and | in their device designs.
| not otherwise design constraints on the DTNMA.
4.2. Hierarchically Modeled Information 4.2. Hierarchically Modeled Information
The DTNMA should use data models to define the syntactic and semantic 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 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 should have the ability to "inherit" the contents of other models to
form hierarchical data relationships. form hierarchical data relationships.
| NOTE: The term data model in this context refers to a schema | NOTE: The term "data model" in this context refers to a schema
| that defines a contract between a DA and a DM for how | that defines a contract between a DA and a DM regarding how
| information is represented and validated. | information is represented and validated.
Many network management solutions use data models to specify the Many network management solutions use data models to specify the
semantic and syntactic representation of data exchanged between semantic and syntactic representation of data exchanged between
managed and managing devices. The DTNMA is not different in this managed and managing devices. The DTNMA is not different in this
regard - information exchanged between DAs and DMs should conform to regard; information exchanged between DAs and DMs should conform to
one or more pre-defined, normative data models. one or more predefined, normative data models.
A common best practice when defining a data model is to make it A common best practice when defining a data model is to make it
cohesive. A cohesive model is one that includes information related cohesive. A cohesive model is one that includes information related
to a single purpose such as managing a single application or to a single purpose such as managing a single application or
protocol. When applying this practice, it is not uncommon to develop protocol. When applying this practice, it is not uncommon to develop
a large number of small data models that, together, describe the a large number of small data models that, together, describe the
information needed to manage a device. information needed to manage a device.
Another best practice for data model development is the use of Another best practice for data model development is the use of
inclusion mechanisms to allow one data model to include information inclusion mechanisms to allow one data model to include information
from another data model. This ability to include a data model avoids from another data model. This ability to include a data model avoids
repeating information in different data models. When one data model repeating information in different data models. When one data model
includes information from another data model, there is an implied includes information from another data model, there is an implied
model hierarchy. model hierarchy.
Data models in the DTNMA should allow for the construction of both Data models in the DTNMA should allow for the construction of both
cohesive models and hierarchically related models. These data models cohesive models and hierarchically related models. These data models
should be used to define all sources of information that can be should be used to define all sources of information that can be
retrieved, configured, or executed in the DTNMA. This includes retrieved, configured, or executed in the DTNMA. These actions would
supporting DA autonomy functions such as parameterization, filtering, include supporting DA autonomy functions such as parameterization,
and event driven behaviors. These models will be used to both filtering, and event-driven behaviors. These models will be used to
implement interoperable autonomy engines on DAs and define both implement interoperable autonomy engines on DAs and define
interoperable report parsing mechanisms on DMs. interoperable report parsing mechanisms on DMs.
| NOTE: While data model hierarchies can result in a more concise | NOTE: While data model hierarchies can result in a more concise
| data model, arbitrarily complex nesting schemes can also result | data model, arbitrarily complex nesting schemes can also result
| in very verbose encodings. Where possible, data identification | in very verbose encodings. Where possible, data identification
| schemes should be constructed that allow for both hierarchical | schemes should be constructed that allow for both hierarchical
| data and highly compressible data identification. | data and highly compressible data identification.
4.3. Adaptive Push of Information 4.3. Adaptive Push of Information
DAs in the DTNMA architecture should determine when to push DAs in the DTNMA should determine when to push information to DMs as
information to DMs as a function of their local state. a function of their local state.
Pull management mechanisms require a managing device to send a query "Pull" management mechanisms require a managing device to send a
to a managed device and then wait for a response to that specific query to a managed device and then wait for a response to that
query. This practice implies some knowledge synchronization between specific query. This practice implies some knowledge synchronization
entities (which may be as simple as knowing when a managed device between entities (which may be as simple as knowing when a managed
might be powered). However, challenged networks cannot guarantee device might be powered). However, challenged networks cannot
timely round-trip data exchange. For this reason, pull mechanisms guarantee timely round-trip data exchange. For this reason, pull
should be avoided in the DTNMA. mechanisms should be avoided in the DTNMA.
Push mechanisms, in this context, refer to the ability of DAs to "Push" mechanisms, in this context, indicate the ability of DAs to
leverage local autonomy to determine when and what information should leverage local autonomy to determine when and what information should
be sent to which DMs. The push is considered adaptive because a DA be sent to which DMs. The push is considered adaptive because a DA
determines what information to push (and when) as an adaptation to determines what information to push (and when) as an adaptation to
changes to the DA's internal state. Once pushed, information might changes to the DA's internal state. Once pushed, information might
still be queued pending connectivity of the DA to the network. still be queued, pending connectivity of the DA to the network.
| NOTE: Even in cases where a round-trip exchange can occur, pull Even in cases where a round-trip exchange can occur, pull mechanisms
| mechanisms increase the overall amount of traffic in the increase the overall amount of traffic in the network and preclude
| network and preclude the use of autonomy at managed devices. the use of autonomy at managed devices. So, even when pull
| So even when pull mechanisms are feasible they should not be mechanisms are feasible, they should not be considered a pragmatic
| considered a pragmatic alternative to push mechanisms. alternative to push mechanisms.
4.4. Efficient Data Encoding 4.4. Efficient Data Encoding
Messages exchanged between a DA and a DM in the DTNMA should be 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. defined in a way that allows for efficient on-the-wire encoding.
DTNMA design decisions that result in smaller message sizes should be DTNMA design decisions that result in smaller message sizes should be
preferred over those that result in larger message sizes. preferred over those that result in larger message sizes.
There is a relationship between message encoding and message There is a relationship between message encoding and message
processing time at a node. Messages with little or no encodings may processing time at a node. Messages with few or no encodings may
simplify node processing whereas more compact encodings may require simplify node processing, whereas more compact encodings may require
additional activities to generate/parse encoded messages. Generally, additional activities to generate/parse encoded messages. Generally,
compressing a message takes processing time at the sender and compressing a message takes processing time at the sender and
decompressing a message takes processing time at a receiver. decompressing a message takes processing time at a receiver.
Therefore, there is a design tradeoff between minimizing message Therefore, there is a design trade-off between minimizing message
sizes and minimizing node processing. sizes and minimizing node processing.
There is a significant advantage to smaller DTNMA message sizes in a There is a significant advantage to smaller DTNMA message sizes in a
challenged network. Smaller messages require smaller periods of challenged network. Smaller messages require shorter periods of
viable transmission for communication, they incur less re- viable transmission for communication, they incur less retransmission
transmission cost, and they consume less resources when persistently cost, and they consume fewer resources when persistently stored en
stored en-route in the network. route in the network.
| NOTE: Naive approaches to minimizing message size through | NOTE: Naive approaches to minimizing message size through
| general purpose compression algorithms do not produce minimal | general-purpose compression algorithms do not produce minimal
| encodings. Data models can, and should, be designed for | encodings. Data models can, and should, be designed for
| compact encoding from the beginning. Design strategies for | compact encoding from the beginning. Design strategies for
| compact encodings involve using structured data, hierarchical | compact encodings involve using structured data, hierarchical
| data models, and common sub-structures within data models. | data models, and common substructures within data models.
| These strategies allow for compressibility beyond what would | These strategies allow for compressibility beyond what would
| otherwise be achieved by computing large hash values over | otherwise be achieved by computing large hash values over
| generalized data structures. | generalized data structures.
4.5. Universal, Unique Data Identification 4.5. Universal, Unique Data Identification
Data elements within the DTNMA should be uniquely identifiable so Data elements within the DTNMA should be uniquely identifiable so
that they can be individually manipulated. Further, these that they can be individually manipulated. Further, these
identifiers should be universal - the identifier for a data element identifiers should be universal -- the identifier for a data element
should be the same regardless of role, implementation, or network should be the same, regardless of role, implementation, or network
instance. instance.
Identification schemes that would be relative to a specific DA or Identification schemes that would be relative to a specific DA or
specific system configuration might change over time and should be specific system configuration might change over time and should be
avoided. Relying on relative identification schemes would require avoided. Relying on relative identification schemes would require
resynchronizing relative state when nodes in a challenge network resynchronizing relative state when nodes in a challenged network
reconnect after periods of partition. This type of resynchronization reconnect after periods of partition. This type of resynchronization
should be avoided whenever possible. should be avoided whenever possible.
| NOTE: Consider a common management technique for approximating | NOTE: Consider a common management technique for approximating
| an associative array lookup. If a managed device tracks the | an associative array lookup. If a managed device tracks the
| number of bytes passed by multiple named interfaces, then the | number of bytes passed by multiple named interfaces, then the
| number of bytes through a specific named interface ("int_foo"), | number of bytes through a specific named interface ("int_foo")
| would be retrieved in the following way: | would be retrieved in the following way:
| |
| 1. Query a list of ordered interface names from an agent. | 1. Query a list of ordered interface names from an agent.
| |
| 2. Find the name that matches "int_foo" and infer the | 2. Find the name that matches "int_foo", and infer the
| agent's index of "int_foo" from the ordered interface | agent's index of "int_foo" from the ordered interface
| list. In this instance, assume "int_foo" is the 4th | list. In this instance, assume that "int_foo" is the
| interface in the list. | fourth interface in the list.
| |
| 3. Query the agent (again) to now return the number of | 3. Query the agent (again) to now return the number of
| bytes passed through the 4th interface. | bytes passed through the fourth interface.
| |
| Ignoring the inefficiency of two round-trip exchanges, this | Ignoring the inefficiency of two round-trip exchanges, this
| mechanism will fail if an agent implementation changes its | mechanism will fail if an agent implementation changes its
| index mapping between the first and second query. | index mapping between the first and second queries.
| |
| The desired data being queried, "number of bytes through | The desired data being queried, "number of bytes through
| int_foo" should be uniquely and universally identifiable and | 'int_foo'", should be uniquely and universally identifiable and
| independent of how that data exists in any agent's custom | independent of how that data exists in any agent's custom
| implementation. | implementation.
4.6. Runtime Data Definitions 4.6. Runtime Data Definitions
The DTNMA allows for the addition of new data elements to a data The DTNMA allows for the addition of new data elements to a data
model as part of the runtime operation of the management system. model as part of the runtime operation of the management system.
These definitions may represent custom data definitions that are These definitions may represent custom data definitions that are
applicable only for a particular device or network. Custom applicable only for a particular device or network. Custom
definitions should also be able to be removed from the system during definitions should also be able to be removed from the system during
runtime. runtime.
The goal of this approach is to dynamically add or remove data The goal of this approach is to dynamically add or remove data
elements to the local runtime schemas as needed - such as the elements to the local runtime schemas as needed, such as the
definition of new counters, new reports, or new rules. definition of new counters, new reports, or new rules.
The custom definition of new data from existing data (such as through The custom definition of new data from existing data (such as through
data fusion, averaging, sampling, or other mechanisms) provides the data fusion, averaging, sampling, or other mechanisms) provides the
ability to communicate desired information in as compact a form as ability to communicate desired information in as compact a form as
possible. possible.
| NOTE: A DM could, for example, define a custom data report that | NOTE: A DM could, for example, define a custom data report that
| includes only summary information around a specific operational | includes only summary information about a specific operational
| event or as part of specific debugging. DAs could then produce | event or as part of specific debugging. DAs could then produce
| this smaller report until it is no longer necessary, at which | this smaller report until it is no longer necessary, at which
| point the custom report could be removed from the management | point the custom report could be removed from the management
| system. | system.
Custom data elements should be calculated and used both as parameters Custom data elements should be calculated and used both as parameters
for DA autonomy and for more efficient reporting to DMs. Defining for DA autonomy and for more efficient reporting to DMs. Defining
new data elements allows for DAs to perform local data fusion and new data elements allows for DAs to perform local data fusion, and
defining new reporting templates allows for DMs to specify desired defining new reporting templates allows for DMs to specify desired
formats and generally save on link capacity, storage, and processing formats and generally save on link capacity, storage, and processing
time. time.
4.7. Autonomous Operation 4.7. Autonomous Operation
The management of applications by a DA should be achievable using The management of applications by a DA should be achievable using
only knowledge local to the DA because DAs might need to operate only knowledge local to the DA because DAs might need to operate
during times when they are disconnected from a DM. during times when they are disconnected from a DM.
DA autonomy may be used for simple automation of predefined tasks or DA autonomy may be used for simple automation of predefined tasks or
to support semi-autonomous behavior in determining when to run tasks to support semi-autonomous behavior in determining when to run tasks
and how to configure or parameterize tasks when they are run. and how to configure or parameterize tasks when they are run.
Important features provided by the DA are listed below. These Important features provided by the DA are listed below. These
features work together to accomplish tasks. As such, there is features work together to accomplish tasks. As such, there is
commonality amongst their definitions and nature of their benefits. commonality amongst their definitions and nature of their benefits.
Stand-alone Operation: Pre-configuration allows DAs to operate Standalone Operation: Preconfiguration allows DAs to operate without
without regular contact with other nodes in the network. Updates regular contact with other nodes in the network. Updates for
for configurations remain difficult in a challenged network, but configurations remain difficult in a challenged network, but this
this approach removes the requirement that a DM be in-the-loop approach removes the requirement that a DM be in the loop during
during regular operations. Preconfiguring stimuli-and-responses regular operations. Preconfiguring stimuli and responses on a DA
on a DA during periods of connectivity allows DAs to self-manage during periods of connectivity allows DAs to self-manage during
during periods of disconnectivity. periods of disconnectivity.
Deterministic Behavior: Operational systems might need to act in a Deterministic Behavior: Operational systems might need to act in a
deterministic way even in the absence of an operator in-the-loop. deterministic way, even in the absence of an operator in the loop.
Deterministic behavior allows an out-of-contact DM to predict the 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 of a DA and to determine how a DA got into a particular
state. state.
Engine-Based Behavior: Operational systems might not be able to Engine-Based Behavior: Operational systems might not be able to
deploy "mobile code" [RFC4949] solutions due to network bandwidth, deploy "mobile code" solutions [RFC4949] due to network bandwidth,
memory or processor loading, or security concerns. Engine-based memory or processor loading, or security concerns. Engine-based
approaches provide configurable behavior without incurring these approaches provide configurable behavior without incurring these
concerns. concerns.
Authorization and Accounting: The DTNMA does not require a specific Authorization and Accounting: The DTNMA does not require a specific
underlying transport protocol, network infrastructure, or network underlying transport protocol, a specific network infrastructure,
services. Therefore, mechanisms for authorization and accounting or specific network services. Therefore, mechanisms for
need to be present in a standard way at DAs and DMs to provide authorization and accounting need to be present in a standard way
these functions if the underlying network does not. This is at DAs and DMs to provide these functions if the underlying
particularly true in cases where multiple DMs may be active network does not. This is particularly true in cases where
concurrently in the network. multiple DMs may be active concurrently in the network.
To understand the contributions of these features to a common To understand the contributions of these features to a common type of
behavior, consider the example of a managed device coming online with behavior, consider the example of a managed device coming online with
a set of pre-installed configuration. In this case, the device's a set of preinstalled configurations. In this case, the device's
stand-alone operation comes from the pre-configuration of its local standalone operation comes from the preconfiguration of its local
autonomy engine. This engine-based behavior allows the system to autonomy engine. This engine-based behavior allows the system to
behave in a deterministic way and any new configurations will need to behave in a deterministic way, and any new configurations will need
be authorized before being adopted. to be authorized before being adopted.
Features such as deterministic processing and engine-based behavior Features such as deterministic processing and engine-based behavior
are separate from (but do not preclude the use of) other Artificial are separate from (but do not preclude the use of) other Artificial
Intelligence (AI) and Machine Learning (ML) approaches for device Intelligence (AI) and Machine Learning (ML) approaches for device
management. management.
5. Current Remote Management Approaches 5. Current Remote Management Approaches
Several remote management solutions have been developed for both Several remote management solutions have been developed for both
local-area and wide-area networks. Their capabilities range from local area networks and wide area networks. Their capabilities range
simple configuration and report generation to complex modeling of from simple configuration and report generation to complex modeling
device settings, state, and behavior. Each of these approaches are of device settings, state, and behavior. All of these approaches are
successful in the domains for which they have been built, but are not successful in the domains for which they have been built but are not
all equally functional when deployed in a challenged network. all equally functional when deployed in a challenged network.
This section describes some of the well-known protocols for remote This section describes some of the well-known protocols for remote
management and contrasts their purposes with the desirable properties management and contrasts their purposes with the desirable properties
of the DTNMA. The purpose of this comparison is to identify parts of of the DTNMA. The purpose of this comparison is to identify parts of
existing approaches that can be adopted or adapted for use in existing approaches that can be adopted or adapted for use in
challenged networks and where new capabilities should be created challenged networks and where new capabilities should be created
specifically for this environment. specifically for such environments.
5.1. SNMP and SMI Models 5.1. SNMP and SMI Models
An early and widely used example of a remote management protocol is An early and widely used example of a remote management protocol is
the Simple Network Management Protocol (SNMP) currently at Version 3 SNMP, which is currently at version 3 [RFC3410]. SNMP utilizes a
[RFC3410]. The SNMP utilizes a request/response model to get and set request-response model to get and set data values within an
data values within an arbitrarily deep object hierarchy. Objects are arbitrarily deep object hierarchy. Objects are used to identify data
used to identify data such as host identifiers, link utilization such as host identifiers, link utilization metrics, error rates, and
metrics, error rates, and counters between application software on counters between application software on managing and managed devices
managing and managed devices [RFC3411]. Additionally, SNMP supports [RFC3411]. Additionally, SNMP supports a model for unidirectional
a model for unidirectional push messages, called event notifications, push messages, called event notifications, based on agent-defined
based on agent-defined triggering events. triggering events.
SNMP relies on logical sessions with predictable round-trip latency SNMP relies on logical sessions with predictable round-trip latency
to support its "pull" mechanism but a single activity is likely to to support its pull mechanism, but a single activity is likely to
require many round-trip exchanges. Complex management can be require many round-trip exchanges. Complex management can be
achieved, but only through careful orchestration of real-time, end- achieved, but only through careful orchestration of real-time, end-
to-end, managing-device-generated query-and-response logic. to-end, managing-device-generated query-and-response logic.
There is existing work that uses the SNMP data model to support some There is existing work that uses the SNMP data model to support some
low-fidelity Agent-side processing, to include the Distributed low-fidelity agent-side processing; this work includes using
Management Expression MIB [RFC2982] and Definitions of Managed "Distributed Management Expression MIB" [RFC2982] and "Definitions of
Objects for the Delegation of Management Scripts [RFC3165]. However, Managed Objects for the Delegation of Management Scripts" [RFC3165].
Agent autonomy is not an SNMP mechanism, so support for a local agent However, agent autonomy is not an SNMP mechanism, so support for a
response to an initiating event is limited. In a challenged network local agent response to an initiating event is limited. In a
where the delay between a managing device receiving an alert and challenged network where the delay between a managing device
sending a response can be significant, SNMP is insufficient for receiving an alert and sending a response can be significant, SNMP is
autonomous event handling. insufficient for autonomous event handling.
5.1.1. The SMI Modeling Language 5.1.1. The SMI Modeling Language
SNMP separates the representations for managed data models from SNMP separates the representations for managed data models from
Manager--Agent messaging, sequencing and encoding. Each data model messaging, sequencing, and encoding between managers and agents.
is termed a Management Information Base (MIB) [RFC3418] and uses the Each data model is termed a "Management Information Base" (or "MIB")
Structure of Management Information (SMI) modeling language [RFC3418] and uses the Structure of Management Information (SMI)
[RFC2578]. Additionally, the SMI itself is based on the ASN.1 Syntax modeling language [RFC2578]. Additionally, the SMI itself is based
[ASN.1] which is used not just for SMI but for other, unrelated data on the ASN.1 syntax [ASN.1], which is used not just for SMI but for
structure specification such as the Cryptographic Message Syntax other, unrelated data structure specifications such as the
(CMS) [RFC5652]. Separating data models from messaging and encoding Cryptographic Message Syntax (CMS) [RFC5652]. Separating data models
is a best practice in remote management protocols and is also from messaging and encoding is a best practice in remote management
necessary for the DTNMA. protocols and is also necessary for the DTNMA.
Each SNMP MIB is composed of managed object definitions each of which Each SNMP MIB is composed of managed object definitions, each of
is associated with a hierarchical Object Identifier (OID). Because which is associated with a hierarchical Object Identifier (OID).
of the arbitrarily deep nature of MIB object trees, the size of OIDs Because of the arbitrarily deep nature of MIB object trees, the size
is not strictly bounded by the protocol (though may be bounded by of OIDs is not strictly bounded by the protocol (though it may be
implementations). bounded by implementations).
5.1.2. SNMP Protocol and Transport 5.1.2. SNMP and Transport
The SNMP protocol itself, which is at version 2 [RFC3416], can SNMPv2 [RFC3416] [RFC3417] and SNMPv3 [RFC3414] can operate over a
operate over a variety of transports, including plaintext UDP/IP variety of transports, including plaintext UDP/IP [RFC3417], SSH/TCP/
[RFC3417], SSH/TCP/IP [RFC5592], and DTLS/UDP/IP or TLS/TCP/IP IP [RFC5592], and DTLS/UDP/IP or TLS/TCP/IP [RFC6353].
[RFC6353].
SNMP uses an abstracted security model to provide authentication, SNMP uses an abstracted security model to provide authentication,
integrity, and confidentiality. There are options for user-based integrity, and confidentiality. There are options for the User-based
security model (USM) of [RFC3414], which uses in-message security, Security Model (USM) [RFC3414], which uses in-message security, and
and transport security model (TSM) [RFC5591], which relies on the the Transport Security Model (TSM) [RFC5591], which relies on the
transport to provide security functions and interfaces. transport to provide security functions and interfaces.
5.2. XML-Infoset-Based Protocols and YANG Models 5.2. XML-Infoset-Based Protocols and YANG Data Models
Several network management protocols, including NETCONF [RFC6241], Several network management protocols, including NETCONF [RFC6241],
RESTCONF [RFC8040], and CORECONF [I-D.ietf-core-comi], share the same RESTCONF [RFC8040], and the Constrained Application Protocol (CoAP)
XML information set [xml-infoset] for its hierarchical managed Management Interface (CORECONF) [CORE-COMI], share the same XML
information and [XPath] expressions to identify nodes of that Information Set [xml-infoset] for the information set's hierarchical
information model. Since they share the same information model and managed information and XPath expressions [XPath] to identify nodes
the same data manipulation operations, together they will be referred of that information model. Since they share the same information
to as "*CONF" protocols. Each protocol, however, provides a model and the same data manipulation operations, together they will
different encoding of that information set and its related operation- be referred to as "*CONF" protocols. Each protocol, however,
specific data. 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 The YANG modeling language as defined in [RFC7950] is used to define
model for these management protocols. Currently, YANG represents the the data model for these management protocols. Currently, YANG
IETF standard for defining managed information models. represents the IETF standard for defining managed information models.
5.2.1. The YANG Modeling Language 5.2.1. The YANG Modeling Language
The YANG modeling language defines a syntax and modular semantics for The YANG modeling language defines a syntax and modular semantics for
organizing and accessing a device's configuration or operational organizing and accessing a device's configuration or operational
information. YANG allows subdividing a full managed configuration information. YANG allows subdividing a full managed configuration
into separate namespaces defined by separate YANG modules. Once a into separate namespaces defined by separate YANG modules. Once a
module is developed, it is used (directly or indirectly) on both the module is developed, it is used (directly or indirectly) on both the
client and server to serve as a contract between the two. A YANG client and server to serve as a contract between the two. A YANG
module can be complex, describing a deeply nested and inter-related module can be complex, describing a deeply nested and interrelated
set of data nodes, actions, and notifications. set of data nodes, actions, and notifications.
Unlike the separation in Section 5.1.1 between ASN.1 syntax and Unlike the separation between ASN.1 syntax and module semantics from
module semantics from higher-level SMI data model semantics, YANG higher-level SMI data model semantics as discussed in Section 5.1.1,
defines both a text syntax and module semantics together with data YANG defines both a text syntax and module semantics together with
model semantics. data model semantics.
The YANG language provides flexibility in the organization of model The YANG modeling language provides flexibility in the organization
objects to the model developer. The YANG supports a broad range of of model objects to the model developer. YANG supports a broad range
data types noted in [RFC6991]. YANG supports the definition of of data types as noted in [RFC6991]. YANG also supports the
parameterized Remote Procedure Calls (RPCs) and actions to be definition of parameterized Remote Procedure Calls (RPCs) and actions
executed on managed devices as well as the definition of event to be executed on managed devices as well as the definition of event
notifications within the model. notifications within the model.
| Current *CONF notification logic allows a client to subscribe Current *CONF notification logic allows a client to subscribe to the
| to the delivery of specific containers or data nodes defined in delivery of specific containers or data nodes defined in the model,
| the model, either on a periodic or "on change" basis [RFC8641]. on either a periodic or "on-change" basis [RFC8641]. These
| These notification events can be filtered according to XPath notification events can be filtered according to XPath or subtree
| [XPath] or subtree [RFC6241] filtering as described in filtering [XPath] [RFC6241] as described in Section 2.2 of [RFC8639].
| Section 2.2 of [RFC8639].
The use of YANG for data modeling necessarily comes with some side- The use of YANG for data modeling necessarily comes with some side
effects, some of which are described here. effects, some of which are described here.
Text Naming: Data nodes, RPCs, and notifications within a YANG model Text Naming: Data nodes, RPCs, and notifications within a YANG data
are named by a namespace-qualified, text-based path of the module, model are named by a namespace-qualified, text-based path of the
sub-module, container, and any data nodes such as lists, leaf- module, submodule, container, and any data nodes such as lists,
lists, or leaves, without any explicit hierarchical organization leaf-lists, or leaves, without any explicit hierarchical
based on data or object type. organization based on data or object type.
Existing efforts to make compressed names for YANG objects, such Existing efforts to make compressed names for YANG objects, such
as the YANG Schema Item iDentifiers (SID) from Section 3.2 of as the YANG Schema Item iDentifiers (SIDs) as discussed in
[RFC9254], allow a node to be named by an globally unique integer Section 3.2 of [RFC9254], allow a node to be named by a globally
value but are still relatively verbose (up to 8 bytes per item) unique integer value but are still relatively verbose (up to 8
and still must be translated into text form for things like bytes per item) and still must be translated into text form for
instance identification (see below). Additionally, when things like instance identification (see below). Additionally,
representing a tree of named instances the child elements can use when representing a tree of named instances, the child elements
differential encoding of SID integer values as "delta" integers. can use differential encoding of SID integer values as "delta"
The mechanisms for assigning SIDs and the lifecycle of those SIDs integers. The mechanisms for assigning SIDs and the lifecycle of
are still in development [I-D.ietf-core-sid]. those SIDs are discussed in [RFC9595].
Text Values and Built-In Types: Because the original use of YANG Text Values and Built-In Types: Because the original use of YANG
with NETCONF was to model XML information sets, the values and with NETCONF was to model XML Information Sets, the values and
built-in types are necessarily text based. The JSON encoding of built-in types are necessarily text based. JSON encoding of YANG
YANG data [RFC7951] allows for optimized representations of many data [RFC7951] allows for optimized representations of many built-
built-in types, and similarly the CBOR encoding [RFC9254] allows in types; similarly, Concise Binary Object Representation (CBOR)
for different optimized representations. encoding [RFC9254] allows for different optimized representations.
In particular, the YANG built-in types natively support a fixed In particular, the YANG built-in types support a fixed range of
range of decimal fractions (Section 9.3 of [RFC7950]) but decimal fractions (Section 9.3 of [RFC7950]) but purposefully do
purposefully do not support floating point numbers. There are not support floating-point numbers. There are alternatives, such
alternatives, such as the type bandwidth-ieee-float32 from as the type bandwidth-ieee-float32 [RFC8294] or using the "binary"
[RFC8294] or using the "binary" type with one of the IEEE-754 type with one of the IEEE-754 encodings.
encodings.
Deep Hierarchy: YANG allows for, and current YANG modules take Deep Hierarchy: YANG allows for, and current YANG modules take
advantage of, the ability to deeply nest a model hierarchy to advantage of, the ability to deeply nest a model hierarchy to
represent complex combinations and compositions of data nodes. represent complex combinations and compositions of data nodes.
When a model uses a deep hierarchy of nodes this necessarily means When a model uses a deep hierarchy of nodes, this necessarily
that the qualified paths to name those nodes and instances is means that the qualified paths to name those nodes and instances
longer than a flat hierarchy would be. are longer than they would be in a flat namespace.
Instance Identification: The node instances in a YANG module Instance Identification: The node instances in a YANG module
necessarily use XPath expressions for identification. Some necessarily use XPath expressions for identification. Some
identification is constrained to be strictly within the YANG identification is constrained to be strictly within the YANG
domain, such as "must" "when", "augment", or "deviation" domain, such as "must", "when", "augment", or "deviation"
statements. Other identification needs to be processed by a statements. Other identification needs to be processed by a
managed device, such as in "instance-identifier" built-in type. managed device -- for example, via the "instance-identifier"
This means any implementation of a managed device must include built-in type. This means that any implementation of a managed
XPath processing and related information model handling of device must include XPath processing and related information model
Section 6.4 of [RFC7950] and its referenced documents. handling per Section 6.4 of [RFC7950] and its referenced
documents.
Protocol Coupling: A significant amount of existing YANG tooling or Protocol Coupling: A significant amount of existing YANG tooling or
modeling presumes the use of YANG data within a management modeling presumes the use of YANG data within a management
protocol with specific operations available. For example, the protocol with specific operations available. For example, the
access control model of [RFC8341] relies on those operations access control model defined in [RFC8341] relies on those
specific to the *CONF protocols for proper behavior. operations specific to the *CONF protocols for proper behavior.
The emergence of multiple NETCONF-derived protocols may make these The emergence of multiple NETCONF-derived protocols may make these
presumptions less problematic in the future. Work to more presumptions less problematic in the future. Work to more
consistently identify different types of YANG modules and their consistently identify different types of YANG modules and their
use has been undertaken to disambiguate how YANG modules should be use has been undertaken to disambiguate how YANG modules should be
treated [RFC8199]. treated [RFC8199].
Manager-Side Control: YANG RPCs and actions execute on a managed Manager-Side Control: YANG RPCs and actions execute on a managed
device and generate an expected, structured response. RPC device and generate an expected, structured response. RPC
execution is strictly limited to those issued by the manager. execution is strictly limited to those issued by the manager.
skipping to change at page 22, line 49 skipping to change at line 1021
The YANG modeling language continues to evolve as new features are The YANG modeling language continues to evolve as new features are
needed by adopting management protocols. needed by adopting management protocols.
5.2.2. NETCONF Protocol and Transport 5.2.2. NETCONF Protocol and Transport
NETCONF is a stateful, XML-encoding-based protocol that provides a NETCONF is a stateful, XML-encoding-based protocol that provides a
syntax to retrieve, edit, copy, or delete any data nodes or exposed syntax to retrieve, edit, copy, or delete any data nodes or exposed
functionality on a server. It requires that underlying transport functionality on a server. It requires that underlying transport
protocols support long-lived, reliable, low-latency, sequenced data protocols support long-lived, reliable, low-latency, sequenced data
delivery sessions. A bi-directional NETCONF session needs to be delivery sessions. A bidirectional NETCONF session needs to be
established before any data transfer (or notification) can occur. established before any data transfer (or notification) can occur.
The XML exchanged within NETCONF messages is structured according to The XML exchanged within NETCONF messages is structured according to
YANG modules supported by the NETCONF agent, and the data nodes YANG modules supported by the NETCONF agent, and the data nodes
reside within one of possibly many datastores in accordance with the reside within one of possibly many datastores in accordance with the
Network Management Datastore Architecture (NMDA) of [RFC8342]. Network Management Datastore Architecture (NMDA) [RFC8342].
NETCONF transports are required to provide authentication, data NETCONF transports are required to provide authentication, data
integrity, confidentiality, and replay protection. Currently, integrity, confidentiality, and replay protection. Currently,
NETCONF can operate over SSH/TCP/IP [RFC6242] or TLS/TCP/IP NETCONF can operate over SSH/TCP/IP [RFC6242] or TLS/TCP/IP
[RFC7589]. [RFC7589].
5.2.3. RESTCONF Protocol and Transport 5.2.3. RESTCONF Protocol and Transport
RESTCONF is a stateless, JSON-encoding-based protocol that provides RESTCONF is a stateless, JSON-encoding-based protocol that provides
the same operations as NETCONF, using the same YANG modules for the same operations as NETCONF, using the same YANG modules for
structure and same NMDA datastores, but using RESTful exchanges over structure and the same NMDA datastores, but using RESTful exchanges
HTTP. It uses HTTP-native methods to express its allowed operations: over HTTP. It uses HTTP methods to express its allowed operations:
GET, POST, PUT, PATCH, or DELETE data nodes within a datastore. GET, POST, PUT, PATCH, or DELETE data nodes within a datastore.
Although RESTCONF is a logically stateless protocol, it does rely on Although RESTCONF is a logically stateless protocol, it does rely on
state within its transport protocol to achieve behaviors such as state within its transport protocol to achieve behaviors such as
authentication and security sessions. Because RESTCONF uses the same authentication and security sessions. Because RESTCONF uses the same
data node semantics of NETCONF, a typical activity can involve the data node semantics as NETCONF, a typical activity can involve the
use of several sequential round-trips of exchanges to first discover use of several sequential round trips of exchanges to first discover
managed device state and then act upon it. managed device state and then act upon it.
5.2.4. CORECONF Protocol and Transport 5.2.4. CORECONF Protocol and Transport
CORECONF is an emerging stateless protocol built atop the Constrained CORECONF is an emerging stateless protocol built atop CoAP [RFC7252]
Application Protocol (CoAP) [RFC7252] that defines a messaging that defines a messaging construct developed to operate specifically
construct developed to operate specifically on constrained devices on constrained devices and networks by limiting message size and
and networks by limiting message size and fragmentation. CoAP also fragmentation. CoAP also implements a request-response system and
implements a request/response system and methods for GET, POST, PUT, methods for GET, POST, PUT, and DELETE.
and DELETE.
5.3. gRPC Network Management Interface (gNMI) 5.3. gRPC Network Management Interface (gNMI)
Another emerging but not-IETF-affiliated management protocol is the Another emerging, but not IETF-affiliated, management protocol is the
gRPC Network Management Interface (gNMI) [gNMI] which is based on gRPC Network Management Interface (gNMI) [gNMI], which is based on
gRPC messaging and uses Protobuf data modeling. gRPC messaging and uses Google protobuf data modeling.
The same limitations of RESTCONF listed above apply to gNMI because The same limitations as those listed above for RESTCONF apply to gNMI
of its reliance on synchronous HTTP exchanges and TLS security for because of its reliance on synchronous HTTP exchanges and TLS for
normal operations, as well as the likely deep nesting of data normal operations, as well as the likely deep nesting of data
schemas. There is a capability for gNMI to transport JSON-encoded schemas. gNMI is capable of transporting JSON-encoded YANG-modeled
YANG-modeled data, but this composing is not fully standardized and data, but how to compose such data is not yet fully standardized.
relies on specific tool integrations to operate.
5.3.1. The Protobuf Modeling Language 5.3.1. The Protobuf Modeling Language
The data managed and exchanged via gNMI is encoded and modeled using The data managed and exchanged via gNMI is encoded and modeled using
Google Protobuf, an encoding and modeling syntax not affiliated with Google protobuf, an encoding and modeling syntax not affiliated with
the IETF (although an attempt has been made and abandoned the IETF (although an attempt has been made and abandoned
[I-D.rfernando-protocol-buffers]). [PROTOCOL-BUFFERS]).
Because the Protobuf modeling syntax is relatively low-level (around Because the protobuf modeling syntax is a relatively low-level syntax
the same as ASN.1 or CBOR), there are some efforts as part of the (about the same as ASN.1 or CBOR), there are some efforts as part of
OpenConfig work [gNMI] to translate YANG modules into Protobuf the OpenConfig work [gNMI] to translate YANG modules into protobuf
schemas (similar to translation to XML or JSON schemas for NETCONF schemas (similar to translation to XML or JSON schemas for NETCONF
and RESTCONF respectively) but there is no required interoperabilty and RESTCONF, respectively), but there is no required
between management via gRPC or any of the *CONF protocols. interoperability between management via gRPC or any of the *CONF
protocols.
5.3.2. gRPC Protocol and Transport 5.3.2. gRPC Protocol and Transport
The message encoding and exchange for gNMI, as the name implies, is The message encoding and exchange for gNMI, as the name implies, is
gRPC protocol [gRPC]. gRPC exclusively uses HTTP/2 [RFC9113] for the gRPC protocol [gRPC]. gRPC exclusively uses HTTP/2 [RFC9113] for
transport and relies on some aspects specific to HTTP/2 for its transport and relies on some aspects specific to HTTP/2 for its
operations (such as HTTP trailer fields). While not mandated by operations (such as HTTP trailer fields). While not mandated by
gRPC, when used to transport gNMI data TLS is required for transport gRPC, when used to transport gNMI data, TLS is required for transport
security. security.
5.4. Intelligent Platform Management Interface (IPMI) 5.4. Intelligent Platform Management Interface (IPMI)
A lower-level remote management protocol, intended to be used to A lower-level remote management protocol, intended to be used to
manage hardware devices and network appliances below the operating manage hardware devices and network appliances below the operating
system (OS), is the Intelligent Platform Management Interface (IPMI) system (OS), is the Intelligent Platform Management Interface (IPMI),
standardized in [IPMI]. The IPMI is focused on health monitoring, standardized in [IPMI]. The IPMI is focused on health monitoring,
event logging, firmware management, and serial-over-LAN (SOL) remote event logging, firmware management, and Serial over LAN (SOL) remote
console access in a "pre-OS or OS-absent" host environment. The IPMI console access in a "pre-OS or OS-absent" host environment. The IPMI
operates over a companion Remote Management Control Protocol (RMCP) operates over a companion Remote Management Control Protocol (RMCP)
for messaging, which itself can use UDP for transport. for messaging, which itself can use UDP for transport.
Because the IPMI and RCMP are tailored to low-level and well- Because the IPMI and RCMP are tailored to low-level and well-
connected devices within a datacenter, with typical workflows connected devices within a data center, with typical workflows
requiring many messaging round trips or low-latency interactive requiring many messaging round trips or low-latency interactive
sessions, they are not suitable for operation over a challenged sessions, they are not suitable for operation over a challenged
network. network.
5.5. Autonomic Networking 5.5. Autonomic Networking
The future of network operations requires more autonomous behavior The future of network operations requires more autonomous behavior,
including self-configuration, self-management, self-healing, and including self-configuration, self-management, self-healing, and
self-optimization. One approach to support this is termed Autonomic self-optimization. One approach to support this is termed "Autonomic
Networking [RFC7575]. Networking" [RFC7575].
There is a large and growing set of work within the IETF focused on There is a large and growing set of work within the IETF focused on
developing an Autonomic Networking Integrated Model and Approach developing an Autonomic Networking Integrated Model and Approach
(ANIMA). The ANIMA work has developed a comprehensive reference (ANIMA). The ANIMA work has developed a comprehensive reference
model for distributing autonomic functions across multiple nodes in model for distributing autonomic functions across multiple nodes in
an autonomic networking infrastructure [RFC8993]. an Autonomic Networking infrastructure [RFC8993].
This work, focused on learning the behavior of distributed systems to This work, focused on learning the behavior of distributed systems to
predict future events, is an emerging network management capability. predict future events, is an emerging network management capability.
This includes the development of signalling protocols such as GRASP This includes the development of signaling protocols such as the
[RFC8990] and the autonomic control plane (ACP) [RFC8368]. GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] and the
Autonomic Control Plane (ACP) [RFC8368].
Both autonomic and challenged networks require similar degrees of Both autonomic and challenged networks require similar degrees of
autonomy. However, challenged networks cannot provide the complex autonomy. However, challenged networks cannot provide the complex
coordination between nodes and distributed supporting infrastructure coordination between nodes and distributed supporting infrastructure
necessary for the frequent data exchanges for negotiation, learning, necessary for the frequent data exchanges for negotiation, learning,
and bootstrapping associated with the above capabilities. and bootstrapping associated with the above capabilities.
There is some emerging work in ANIMA as to how disconnected devices There is some emerging work in ANIMA as to how disconnected devices
might join and leave the autonomic control plane over time. However, might join and leave the ACP over time. However, this work is
this work is addressing a different problem than that encountered by addressing a different problem than that encountered by challenged
challenged networks. networks.
5.6. Deep Space Autonomy 5.6. Deep Space Autonomy
Outside of the terrestrial networking community, there are existing Outside of the terrestrial networking community, there are existing
and established remote management systems used for deep space mission and established remote management systems used for deep space mission
operations. Examples of two of these are for the New Horizons operations. Two examples of such systems are the New Horizons
mission to Pluto [NEW-HORIZONS] and the DART mission to the asteroid mission to Pluto [NEW-HORIZONS] and the Double Asteroid Redirection
Dimorphos [DART]. Test (DART) mission to the asteroid Dimorphos [DART].
The DTNMA has some heritage in the concepts of deep space autonomy, The DTNMA has some heritage in the concepts of deep space autonomy,
but each of those mission instantiations use mission-specific data but each of those mission instantiations uses mission-specific data
encoding, messaging, and transport as well as mission-specific (or encoding, messaging, and transport as well as mission-specific (or
heavily mission-tailored) modeling concepts and languages. Part of heavily mission-tailored) modeling concepts and languages. Part of
the goal of the DTNMA is to take the proven concepts from these the goal of the DTNMA is to take the proven concepts from these
missions and standardize a messaging syntax as well as a modular data missions and standardize a messaging syntax as well as a modular data
modeling method. modeling method.
6. Motivation for New Features 6. Motivation for New Features
Management mechanisms that provide the complete set of DTNMA Management mechanisms that provide the complete set of DTNMA
desirable properties do not currently exist. This is not surprising desirable properties do not currently exist. This is not surprising,
since autonomous management in the context of a challenged networking since autonomous management in the context of a challenged networking
environment is a new and emerging use case. environment is a new and emerging use case.
In particular, a management architecture is needed that integrates In particular, a management architecture is needed that integrates
the following motivating features. the following motivating features.
Open Loop Control: Freedom from a request-response architecture, Open-Loop Control: Freedom from a request-response architecture,
API, or other presumption of timely round-trip communications. API, or other presumption of timely round-trip communications.
This is particularly important when managing networks that are not This is particularly important when managing networks that are not
built over an HTTP or TCP/TLS infrastructure. built over an HTTP or TCP/TLS infrastructure.
Standard Autonomy Model: An autonomy model that allows for standard Standard Autonomy Model: An autonomy model that allows for standard
expressions of policy to guarantee deterministic behavior across expressions of policy to guarantee deterministic behavior across
devices and vendor implementations. devices and vendor implementations.
Compressible Model Structure: A data model that allows for very Compressible Model Structure: A data model that allows for very
compact encodings by defining and exploiting common structures for compact encodings by defining and exploiting common structures for
data schemas. data schemas.
Combining these new features with existing mechanisms for message Combining these new features with existing mechanisms for message
data exchange (such as BP), data representations (such as CBOR) and data exchange (such as BP), data representations (such as CBOR), and
data modeling languages (such as YANG) will form a pragmatic approach data modeling languages (such as YANG) will form a pragmatic approach
to defining challenged network management. to defining challenged network management.
7. Reference Model 7. Reference Model
This section describes a reference model for reasoning about network This section describes a reference model for analyzing network
management concepts for challenged networks (generally) and those management concepts for challenged networks (generally) and those
conforming to the DTN architecture (in particular). The goal of this conforming to the DTN architecture (in particular). The goal of this
section is to describe how DTNMA services provide DTNMA desirable section is to describe how DTNMA services provide DTNMA desirable
properties. properties.
7.1. Important Concepts 7.1. Important Concepts
Similar to other network management architectures, the DTNMA draws a Like other network management architectures, the DTNMA draws a
logical distinction between a managed device and a managing device. logical distinction between a managed device and a managing device.
Managed devices use a DA to manage resident applications. Managing Managed devices use a DA to manage resident applications. Managing
devices use a DM to both monitor and control DAs. devices use a DM to both monitor and control DAs.
| NOTE: The terms "managing" and "managed" represent logical The terms "managing" and "managed" represent logical characteristics
| characteristics of a device and are not, themselves, mutually of a device and are not, themselves, mutually exclusive. For
| exclusive. For example, a managed device might, itself, also example, a managed device might, itself, also manage some other
| manage some other device in the network. Therefore, a device device in the network. Therefore, a device may support either or
| may support either or both of these characteristics. both of these characteristics.
The DTNMA differs from some other management architectures in three The DTNMA differs from some other management architectures in three
significant ways, all related to the need for a device to self-manage significant ways, all related to the need for a device to self-manage
when disconnected from a managing device. when disconnected from a managing device.
Pre-shared Definitions: Managing and managed devices should operate Pre-Shared Definitions: Managing and managed devices should operate
using pre-shared data definitions and models. This implies that using pre-shared data definitions and models. This implies that
static definitions should be standardized whenever possible and static definitions should be standardized whenever possible and
that managing and managed devices may need to negotiate that managing and managed devices may need to negotiate
definitions during periods of connectivity. definitions during periods of connectivity.
Agent Self-Management: A managed device may find itself disconnected Agent Self-Management: A managed device may find itself disconnected
from its managing device. In many challenged networking from its managing device. In many challenged networking
scenarios, a managed device may spend the majority of its time scenarios, a managed device may spend the majority of its time
without a regular connection to a managing device. In these without a regular connection to a managing device. In these
cases, DAs manage themselves by applying pre-shared policies cases, DAs manage themselves by applying pre-shared policies
received from managing devices. received from managing devices.
Command-Based Interface: Managing devices communicate with managed Command-Based Interface: Managing devices communicate with managed
devices through a command-based interface. Instead of exchanging devices through a command-based interface. Instead of exchanging
variables, objects, or documents, a managing device issues variables, objects, or documents, a managing device issues
commands to be run by a managed device. These commands may create commands to be run by a managed device. These commands may create
or update variables, change data stores, or impact the managed or update variables, change datastores, or impact the managed
device in ways similar to other network management approaches. device in ways similar to other network management approaches.
The use of commands is, in part, driven by the need for DAs to The use of commands is, in part, driven by the need for DAs to
receive updates from both remote management devices and local receive updates from both remote management devices and local
autonomy. The use of controls for the implementation of commands autonomy. The use of Controls for the implementation of commands
is discussed in more detail in Section 9.5. is discussed in more detail in Section 9.5.
7.2. Model Overview 7.2. Model Overview
A DTNMA reference model is provided in Figure 2 below. In this A DTNMA reference model is provided in Figure 2 below. In this
reference model, applications and services on a managing device reference model, applications and services on a managing device
communicate with a DM which uses pre-shared definitions to create a communicate with a DM that uses pre-shared definitions to create a
set of policy directives that can be sent to a managed device's DA 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 via a command-based interface. The DA provides local monitoring and
control (commanding) of the applications and services resident on the control (commanding) of the applications and services resident on the
managed device. The DA also performs local data fusion as necessary managed device. The DA also performs local data fusion as necessary
to synthesize data products (such as reports) that can be sent back to synthesize data products (such as reports) that can be sent back
to the DM when appropriate. to the DM when appropriate.
DTNMA Reference Model
Managed Device Managing Device Managed Device Managing Device
+----------------------------+ +-----------------------------+ +----------------------------+ +-----------------------------+
| +------------------------+ | | +-------------------------+ | | +------------------------+ | | +-------------------------+ |
| |Applications & Services | | | | Applications & Services | | | |Applications & Services | | | | Applications & Services | |
| +----------^-------------+ | | +-----------^-------------+ | | +----------^-------------+ | | +-----------^-------------+ |
| | | | | | | | | | | |
| +----------v-------------+ | | +-----------v-------------+ | | +----------v-------------+ | | +-----------v-------------+ |
| | DTNMA +-------------+ | | | | +-----------+ DTNMA | | | | DTNMA +-------------+ | | | | +-----------+ DTNMA | |
| | AGENT | Monitor and | | |Commanding | | | Policy | MANAGER | | | | AGENT | Monitor and | | |Commanding | | | Policy | MANAGER | |
| | | Control | | |<==========| | | Encoding | | | | | | Control | | |<==========| | | Encoding | | |
| | +------+-------------+ | | | | +-----------+-------+ | | | | +------+-------------+ | | | | +-----------+-------+ | |
| | |Admin | Data Fusion | | |==========>| | | Reporting | Admin | | | | | |Admin | Data Fusion | | |==========>| | | Reporting | Admin | | |
| | +------+-------------+ | | Reporting | | +-----------+-------+ | | | | +------+-------------+ | | Reporting | | +-----------+-------+ | |
| +------------------------+ | | +-------------------------+ | | +------------------------+ | | +-------------------------+ |
+----------------------------+ +-----------------------------+ +----------------------------+ +-----------------------------+
^ ^ ^ ^
| Pre-Shared Definitions | | Pre-Shared Definitions |
| +---------------------------+ | | +---------------------------+ |
+--------| - Autonomy Model |--------+ +--------| - Autonomy Model |--------+
| - Application Data Models | | - Application Data Models |
| - Runtime Data Stores | | - Runtime Datastores |
+---------------------------+ +---------------------------+
Figure 2 Figure 2: DTNMA Reference Model
This model preserves the familiar concept of "managers" resident on This model preserves the familiar concept of "managers" resident on
managing devices and "agents" resident on managed devices. However, managing devices and "agents" resident on managed devices. However,
the DTNMA model is unique in how the DM and DA operate. The DM is 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. used to preconfigure DAs in the network with management policies. It
it is expected that the DAs, themselves, perform monitoring and is expected that the DAs, themselves, perform monitoring and control
control functions on their own. In this way, a properly configured functions on their own. In this way, a properly configured DA may
DA may operate without a reliable connection back to a DM. operate without a reliable connection back to a DM.
7.3. Functional Elements 7.3. Functional Elements
The reference model illustrated in Figure 2 implies the existence of The reference model illustrated in Figure 2 implies the existence of
certain logical components whose roles and responsibilities are certain logical components whose roles and responsibilities are
discussed in this section. discussed in this section.
7.3.1. Managed Applications and Services 7.3.1. Managed Applications and Services
By definition, managed applications and services reside on a managed By definition, managed applications and services reside on a managed
device. These software entities can be controlled through some device. These software entities can be controlled through some
interface by the DA and their state can be sampled as part of interface by the DA, and their state can be sampled as part of
periodic monitoring. It is presumed that the DA on the managed periodic monitoring. It is presumed that the DA on the managed
device has the proper data model, control interface, and permissions device has the proper data model, control interface, and permissions
to alter the configuration and behavior of these software to alter the configuration and behavior of these software
applications. applications.
7.3.2. DTNMA Agent (DA) 7.3.2. DTNMA Agent (DA)
A DA resides on a managed device. As is the case with other network A DA resides on a managed device. As is the case with other network
management approaches, this agent is responsible for the monitoring management approaches, this agent is responsible for the monitoring
and control of the applications local to that device. Unlike other and control of the applications local to that device. Unlike other
network management approaches, the agent accomplishes this task network management approaches, the agent accomplishes this task
without a regular connection to a DTNMA Manager. without a regular connection to a DM.
The DA performs three major functions on a managed device: the The DA performs three major functions on a managed device: the
monitoring and control of local applications, production of data monitoring and control of local applications, production of data
analytics, and the administrative control of the agent itself. analytics, and the administrative control of the agent itself.
7.3.2.1. Monitoring and Control 7.3.2.1. Monitoring and Control
DAs monitor the status of applications running on their managed DAs monitor the status of applications running on their managed
device and selectively control those applications as a function of device and selectively control those applications as a function of
that monitoring. The following components are used to perform that monitoring. The following components are used to perform
monitoring and control on an agent. monitoring and control on an agent.
Rules Database: Rule Database:
Each DA maintains a database of policy expressions that form Each DA maintains a database of policy expressions that form rules
rules of behavior of the managed device. Within this regarding the behavior of the managed device. Within this
database, each rule of behavior is a tuple of a stimulus and database, each rule regarding behavior is a tuple of a stimulus
a response. Within the DTNMA, these rules are the embodiment and a response. Within the DTNMA, these rules are the embodiment
of policy expressions received from DMs and evaluated at of policy expressions received from DMs and evaluated at regular
regular intervals by the autonomy engine. The rules database intervals by the autonomy engine. The rule database is the
is the collection of active rules known to the DA. collection of active rules known to the DA.
Autonomy Engine: Autonomy Engine:
The DA autonomy engine monitors the state of the managed The DA autonomy engine monitors the state of the managed device,
device looking for pre-defined stimuli and, when encountered, looking for predefined stimuli and, when such stimuli are
issuing a pre-defined response. To the extent that this encountered, issuing a predefined response. To the extent that
function is driven by the rules database, this engine acts as this function is driven by the rule database, this engine acts as
a policy execution engine. This engine may also be directly a policy execution engine. This engine may also be directly
configured by managers during periods of connectivity for configured by managers during periods of connectivity for actions
actions separate from those in the rules database (such as separate from those in the rule database (such as enabling or
enabling or disabling sets of rules). Once configured, the disabling sets of rules). Once configured, the engine may
engine may function without other access to any managing function without other access to any managing device. This engine
device. This engine may also reconfigure itself as a may also reconfigure itself as a function of policy.
function of policy.
Application Control Interfaces: Application Control Interfaces:
DAs support control interfaces for all managed applications. DAs support control interfaces for all managed applications.
Control interfaces are used to alter the configuration and Control interfaces are used to alter the configuration and
behavior of an application. These interfaces may be custom behavior of an application. These interfaces may be custom for
for each application, or as provided through a common each application or as provided through a common framework,
framework such as provided by an operating system. protocol, or OS.
7.3.2.2. Data Fusion 7.3.2.2. Data Fusion
DAs generate new data elements as a function of the current state of DAs generate new data elements as a function of the current state of
the managed device and its applications. These new data products may the managed device and its applications. These new data products may
take the form of individual data values, or new collections of data take the form of individual data values or of new collections of data
used for reporting. The logical components responsible for these used for reporting. The logical components responsible for these
behaviors are as follows. behaviors are as follows.
Application Data Interfaces: Application Data Interfaces:
DAs support mechanisms by which important state is retrieved DAs support mechanisms by which important state is retrieved from
from various applications resident on the managed device. various applications resident on the managed device. These data
These data interfaces may be custom for each application, or interfaces may be custom for each application or as provided
as provided through a common framework such as provided by an through a common framework, protocol, or OS.
operating system.
Data Value Generators: Data Value Generators:
DAs may support the generation of new data values as a DAs may support the generation of new data values as a function of
function of other values collected from the managed device. other values collected from the managed device. These data
These data generators may be configured with descriptions of generators may be configured with descriptions of data values, and
data values and the data values they generate may be included the data values they generate may be included in the overall
in the overall monitoring and reporting associated with the monitoring and reporting associated with the managed device.
managed device.
Report Generators: Report Generators:
DAs may, as appropriate, generate collections of data values DAs may, as appropriate, generate collections of data values and
and provide them to whatever local mechanism takes provide them to whatever local mechanism takes responsibility for
responsibility for their eventual transmission (or expiration their eventual transmission (or expiration and removal). Reports
and removal). Reports can be generated as a matter of policy can be generated as a matter of policy or in response to the
or in response to the handling of critical events (such as handling of critical events (such as errors) or other logging
errors), or other logging needs. The generation of a report needs. The generation of a report is independent of whether there
is independent of whether there exists any connectivity exists any connectivity between a DA and a DM.
between a DA and a DM.
7.3.2.3. Administration 7.3.2.3. Administration
DAs perform a variety of administrative services in support of their DAs perform a variety of administrative services in support of their
configuration, such as the following. configuration, such as the following.
Manager Mapping: Manager Mapping:
The DTNMA allows for a many-to-many relationship amongst The DTNMA allows for a many-to-many relationship amongst DAs and
DTNMA Agents and Managers. A single DM may configure DMs. A single DM may configure multiple DAs, and a single DA may
multiple DAs, and a single DA may be configured by multiple be configured by multiple DMs. Multiple managers may exist in a
DMs. Multiple managers may exist in a network for at least network for at least the following two reasons. First, different
two reasons. First, different managers may exist to control managers may exist to control different applications on a device.
different applications on a device. Second, multiple Second, multiple managers increase the likelihood of an agent
managers increase the likelihood of an agent encountering a encountering a manager when operating in a sparse or challenged
manager when operating in a sparse or challenged environment. environment.
While the need for multiple managers is required for While multiple managers are needed for proper operation in a
operating in a dynamically partitioned network, this dynamically partitioned network, conflicting information from
situation allows for the possibility of conflicting different managers can result. Implementations of the DTNMA
information from different managers. Implementations of the should consider conflict resolution mechanisms. Such mechanisms
DTNMA should consider conflict resolution mechanisms. Such might include analyzing managed content, time, agent location, or
mechanisms might include analyzing managed content, time, other relevant information to select one manager input over other
agent location, or other relevant information to select one manager inputs.
manager input over other manager inputs.
Data Verifiers: Data Verifiers:
DAs might handle large amounts of data produced by various DAs might handle large amounts of data produced by various
sources, to include data from local managed applications, sources, to include data from local managed applications, remote
remote managers, and self-calculated values. DAs should managers, and self-calculated values. DAs should ensure, when
ensure, when possible, that externally generated data values possible, that externally generated data values have the proper
have the proper syntax and semantic constraints (e.g., data syntax and semantic constraints (e.g., data type and ranges) and
type and ranges) and any required authorization. any required authorization.
Access Controllers: Access Controllers:
DAs support authorized access to the management of individual DAs support authorized access to the management of individual
applications, to include the administrative management of the applications, to include the administrative management of the
agent itself. This means that a manager may only set policy agent itself. This means that a manager may only set policy on
on the agent pursuant to verifying that the manager is the agent pursuant to verifying that the manager is authorized to
authorized to do so. do so.
7.3.3. Managing Applications and Services 7.3.3. Managing Applications and Services
Managing applications and services reside on a managing device and Managing applications and services reside on a managing device and
serve as the both the source of DA policy statements and the target serve as both the source of DA policy statements and the target of DA
of DA reporting. They may operate with or without an operator in the reporting. They may operate with or without an operator in the loop.
loop.
Unlike management applications in unchallenged networks, these Unlike management applications in unchallenged networks, these
applications cannot exert closed-loop control over any managed device applications cannot exert closed-loop control over any managed device
application. Instead, they exercise open-loop control by producing application. Instead, they exercise open-loop control by producing
policies that can be configured and enforced on managed devices by policies that can be configured and enforced on managed devices by
DAs. DAs.
| NOTE: Closed-loop control in this context refers to the | NOTE: Closed-loop control in this context refers to the
| practice of waiting for a response from a managed device prior | practice of waiting for a response from a managed device prior
| to issuing new commands to that device. These "loops" may be | to issuing new commands to that device. These "loops" may be
| closed quickly (in milliseconds) or over much longer periods ( | closed quickly (in milliseconds) or over much longer periods
| hours, days, years). The alternative to closed-loop control is | (hours, days, years). The alternative to closed-loop control
| open-loop control, where the issuance of new commands is not | is open-loop control, where the issuance of new commands is not
| dependent on receiving responses to previous commands. | dependent on receiving responses to previous commands.
| Additionally, there might not be a 1-1 mapping between commands | Additionally, there might not be a one-to-one mapping between
| and responses. A DA may, for example, produce a single | commands and responses. A DA may, for example, produce a
| response that captures the end state from applying multiple | single response that represents the end state of applying
| commands. | multiple commands.
7.3.4. DTNMA Manager (DM) 7.3.4. DTNMA Manager (DM)
A DM resides on a managing device. This manager provides an A DM resides on a managing device. This manager provides an
interface between various managing applications and services and the interface between various managing applications and services and the
DAs that enforce their policies. In providing this interface, DMs DAs that enforce their policies. In providing this interface, DMs
translate between whatever native interface exists to various translate between whatever innate interface exists to various
managing applications and the autonomy models used to encode managing applications and the autonomy models used to encode
management policy. management policy.
The DM performs three major functions on a managing device: policy The DM performs three major functions on a managing device: policy
encoding, reporting, and administration. encoding, reporting, and administration.
7.3.4.1. Policy Encoding 7.3.4.1. Policy Encoding
DMs translate policy directives from managing applications and DMs translate policy directives from managing applications and
services into standardized policy expressions that can be recognized services into standardized policy expressions that can be recognized
by DAs. The following logical components are used to perform this by DAs. The following logical components are used to perform this
policy encoding. policy encoding.
Application Control Interfaces: Application Control Interfaces:
DMs support control interfaces for managing applications. DMs support control interfaces for managing applications. These
These control interfaces are used to receive desired policy control interfaces are used to receive desired policy statements
statements from applications. These interfaces may be custom from applications. These interfaces may be custom for each
for each application, or provided through a common framework, application or as provided through a common framework, protocol,
protocol, or operating system. or OS.
Policy Encoders: Policy Encoders:
DAs implement a standardized autonomy model comprising DAs implement a standardized autonomy model comprising
standardized data elements. This allows the open-loop standardized data elements. This allows the open-loop control
control structures provided by managing applications to be structures provided by managing applications to be represented in
represented in a common language. Policy encoders perform a common language. Policy encoders perform this encoding
this encoding function. function.
Policy Aggregators: Policy Aggregators:
DMs collect multiple encoded policies into messages that can DMs collect multiple encoded policies into messages that can be
be sent to DAs over the network. This implies the proper sent to DAs over the network. This implies the proper addressing
addressing of agents and the creation of messages that of agents and the creation of messages that support store-and-
support store-and-forward operations. It is recommended that forward operations. It is recommended that control messages be
control messages be packaged using BP bundles when there may packaged using BP bundles when there may be intermittent
be intermittent connectivity between DMs and DAs. connectivity between DMs and DAs.
7.3.4.2. Reporting 7.3.4.2. Reporting
DMs receive reports on the status of managed devices during periods DMs receive reports on the status of managed devices during periods
of connectivity with the DAs on those devices. The following logical of connectivity with the DAs on those devices. The following logical
components are needed to implement reporting capabilities on a DM. components are needed to implement reporting capabilities on a DM.
Report Collectors: Report Collectors:
DMs receive reports from DAs in an asynchronous manner. This DMs receive reports from DAs in an asynchronous manner. This
means that reports may be received out of chronological order means that reports may be received out of chronological order and
and in ways that are difficult or impossible to associate in ways that are difficult or impossible to associate with a
with a specific policy from a managing application. DMs specific policy from a managing application. DMs collect these
collect these reports and extract their data in support of reports and extract their data in support of subsequent data
subsequent data analytics. analytics.
Data Analyzers: Data Analyzers:
DMs review sets of data reports from DAs with the purpose of DMs review sets of data reports from DAs with the purpose of
extracting relevant data to communicate with managing extracting relevant data to communicate with managing
applications. This may include simple data extraction or may applications. This may include simple data extraction or may
include more complex processing such as data conversion, data include more complex processing such as data conversion, data
fusion, and appropriate data analytics. fusion, and appropriate data analytics.
Application Data Interfaces: Application Data Interfaces:
DMs support mechanisms by which data retrieved from DAs may DMs support mechanisms by which data retrieved from DAs may be
be provided back to managing devices. These interfaces may provided back to managing devices. These interfaces may be custom
be custom for each application, or as provided through a for each application or as provided through a common framework,
common framework, protocol, or operating system. protocol, or OS.
7.3.4.3. Administration 7.3.4.3. Administration
Managers in the DTNMA perform a variety of administrative services, DMs in the DTNMA perform a variety of administrative services, such
such as the following. as the following.
Agent Mappings: Agent Mappings:
The DTNMA allows DMs to communicate with multiple DAs. The DTNMA allows DMs to communicate with multiple DAs. However,
However, not every agent in a network is expected to support not every agent in a network is expected to support the same set
the same set of Application Data Models or otherwise have the of application data models or otherwise have the same set of
same set of managed applications running. For this reason, managed applications running. For this reason, DMs determine
DMs determine individual DA capabilities to ensure that only individual DA capabilities to ensure that only appropriate
appropriate Controls are sent to a DA. Controls are sent to a DA.
Data Verifiers: Data Verifiers:
DMs handle large amounts of data produced by various sources, DMs handle large amounts of data produced by various sources, to
to include data from managing applications and DAs. DMs include data from managing applications and DAs. DMs should
should ensure, when possible, that data values received from ensure, when possible, that data values received from DAs over a
DAs over a network have the proper syntax and semantic network have the proper syntax and semantic constraints (e.g.,
constraints (e.g., data type and ranges) and any required data type and ranges) and any required authorization.
authorization.
Access Controllers: Access Controllers:
DMs should only send Controls to agents when the manager is DMs should only send Controls to DAs when the manager is
configured with appropriate access to both the agent and the configured with appropriate access to both the agent and the
applications being managed. applications being managed.
7.3.5. Pre-Shared Definitions 7.3.5. Pre-Shared Definitions
A consequence of operating in a challenged environment is the A consequence of operating in a challenged environment is the
potential inability to negotiate information in real-time. For this potential inability to negotiate information in real time. For this
reason, the DTNMA requires that managed and managing devices operate reason, the DTNMA requires that managed and managing devices operate
using pre-shared definitions rather than relying on data definition using pre-shared definitions rather than relying on data definition
negotiation. negotiation.
The three types of pre-shared definitions in the DTNMA are the DA The three types of pre-shared definitions in the DTNMA are the DA
autonomy model, managed application data models, and any runtime data autonomy model, managed application data models, and any runtime data
shared by managers and agents. shared by managers and agents.
Autonomy Model: Autonomy Model:
A DTNMA autonomy model represents the data elements and A DTNMA autonomy model represents the data elements and associated
associated autonomy structures that define the behavior of autonomy structures that define the behavior of the agent autonomy
the agent autonomy engine. A standardized autonomy model engine. A standardized autonomy model allows for individual
allows for individual implementations of DAs, and DMs to implementations of DAs and DMs to interoperate. A standardized
interoperate. A standardized model also provides guidance to model also provides guidance to the design and implementation of
the design and implementation of both managed and managing both managed and managing applications.
applications.
Application Data Models: Application Data Models:
As with other network management architectures, the DTNMA As with other network management architectures, the DTNMA
pre-supposes that managed applications (and services) define presupposes that managed applications (and services) define their
their own data models. These data models include the data own data models. These data models include the data produced by,
produced by, and Controls implemented by, the application. and Controls implemented by, the application. These models are
These models are expected to be static for individual expected to be static for individual applications and standardized
applications and standardized for applications implementing for applications implementing standard protocols.
standard protocols.
Runtime Data Stores: Runtime Datastores:
Runtime data stores, by definition, include data that is Runtime datastores, by definition, include data that is defined at
defined at runtime. As such, the data is not pre-shared runtime. As such, the data is not pre-shared prior to the
prior to the deployment of DMs and DAs. Pre-sharing in this deployment of DMs and DAs. Pre-sharing in this context means that
context means that DMs and DAs are able to define and DMs and DAs are able to define and synchronize data elements prior
synchronize data elements prior to their operational use in to their operational use in the system. This synchronization
the system. This synchronization happens during periods of happens during periods of connectivity between DMs and DAs.
connectivity between DMs and DAs.
8. Desired Services 8. Desired Services
This section describes the services provided by DTNMA components on This section describes the services provided by DTNMA components on
both managing and managed devices. Many of the services discussed in both managing and managed devices. Most of the services discussed in
this section attempt to provide continuous operation of a managed this section attempt to provide continuous operation of a managed
device through periods of no connectivity with a managing device. device through periods of no connectivity with a managing device.
8.1. Local Monitoring and Control 8.1. Local Monitoring and Control
DTNMA monitoring is associated with some DA autonomy engine. The DTNMA monitoring is associated with some DA autonomy engine. The
term monitoring implies regular access to information such that state term "monitoring" implies regular access to information such that
changes may be acted upon within some response time period. state changes may be acted upon within some response time period.
Predicate autonomy on a managed device should collect state Predicate autonomy on a managed device should collect state
associated with the device at regular intervals and evaluate that associated with the device at regular intervals and evaluate that
collected state for any changes that require a preventative or collected state for any changes that require a preventative or
corrective action. Similarly, this monitoring may cause the device corrective action. Similarly, this monitoring may cause the device
to generate one or more reports destined to a managing device. to generate one or more reports destined to a managing device.
Similar to monitoring, DTNMA control results in actions by the agent Like monitoring, DTNMA control results in actions by the agent to
to change the state or behavior of the managed device. All control change the state or behavior of the managed device. All control in
in the DTNMA is local control. In cases where there exists a timely the DTNMA is local control. In cases where there exists a timely
connection to a manager, received Controls are still evaluated and connection to a DM, received Controls are still evaluated and run
run locally as part of local autonomy. In this case, the autonomy locally as part of local autonomy. In this case, the autonomy
stimulus is the receipt of the Control and the response is to stimulus is the receipt of the Control, and the response is to
immediately run the Control. In this way, there is never a immediately run the Control. In this way, there is never a
dependency on a session or other stateful exchange with any remote dependency on a session or other stateful exchange with any remote
entity. entity.
8.2. Local Data Fusion 8.2. Local Data Fusion
DTNMA Fusion services produce new data products from existing state DTNMA fusion services produce new data products from existing state
on the managed device. These fusion products can be anything from on the managed device. These fusion products can be anything from
simple summations of sampled counters to complex calculations of simple summations of sampled counters to complex calculations of
behavior over time. behavior over time.
Fusion is an important service in the DTNMA because fusion products Fusion is an important service in the DTNMA because fusion products
are part of the overall state of a managed device. Complete are part of the overall state of a managed device. Complete
knowledge of this overall state is important for the management of knowledge of this overall state is important for the management of
the device and the predicates of rules on a DA may refer to fused the device, and the predicates of rules on a DA may refer to fused
data. data.
In-situ data fusion is an important function as it allows for the In situ data fusion is an important function, as it allows for the
construction of intermediate summary data, the reduction of stored construction of intermediate summary data, the reduction of stored
and transmitted raw data, possibly fewer predicates in rule and transmitted raw data, and possibly fewer predicates in rule
definitions, and otherwise insulates the data source from conclusions definitions; this type of data fusion insulates the data source from
drawn from that data. conclusions drawn from that data.
The DTNMA requires fusion to occur on the managed device itself. If The DTNMA requires fusion to occur on the managed device itself. If
the network is partitioned such that no connection to a managing the network is partitioned such that no connection to a managing
device is available, then fusion needs to happen locally. Similarly, device is available, then fusion needs to happen locally. Similarly,
connections to a managing device might not remain active long enough connections to a managing device might not remain active long enough
for round-trip data exchange or may not have the bandwidth to send for round-trip data exchange or may not have the bandwidth to send
all sampled data. all sampled data.
| NOTE: The DTNMA does not restrict the storage and transmission | NOTE: The DTNMA does not restrict the storage and transmission
| of raw (pre-fused) data. Such raw data can be useful for | of raw (pre-fused) data. Such raw data can be useful for
| debugging managed devices, understanding complex interactions | debugging managed devices, understanding complex interactions
| and underlying conditions, and tuning for better performance | and underlying conditions, and tuning for better performance
| and/or better outcomes. | and/or better outcomes.
8.3. Remote Configuration 8.3. Remote Configuration
DTNMA configuration services update the local configuration of a DTNMA configuration services update the local configuration of a
managed device with the intent to impact the behavior and managed device with the intent of impacting the behavior and
capabilities of that device. capabilities of that device.
The DTNMA configuration service is unique in that the selection of The DTNMA configuration service is unique in that the selection of
managed device configurations occurs as a function of the state of managed device configurations occurs as a function of the state of
the device. This implies that management proxies on the device store the device. This implies that management proxies on the device store
multiple configuration functions that can be applied as needed multiple configuration functions that can be applied as needed
without consultation from a managing device. without consultation from a managing device.
| This approach differs from other management concepts of This approach differs from other management concepts of selecting
| selecting from multiple datastores. DTNMA configuration from multiple datastores. DTNMA configuration functions can target
| functions can target individual data elements and can calculate individual data elements and can calculate new values from local
| new values from local device state. device state.
When detecting stimuli, the agent autonomy engine supports a When detecting stimuli, the agent autonomy engine supports a
mechanism for evaluating whether application monitoring data or mechanism for evaluating whether application monitoring data or
runtime data values are recent enough to indicate a change of state. runtime data values are recent enough to indicate a change of state.
In cases where data has not been updated recently, it may be In cases where data has not been updated recently, it may be
considered stale and not used to reliably indicate that some stimulus considered stale and therefore not used to reliably indicate that
has occurred. some stimulus has occurred.
8.4. Remote Reporting 8.4. Remote Reporting
DTNMA reporting services collect information known to the managed DTNMA reporting services collect information known to the managed
device and prepare it for eventual transmission to one or more device and prepare it for eventual transmission to one or more
managing devices. The contents of these reports, and the frequency managing devices. The contents of these reports, and the frequency
at which they are generated, occurs as a function of the state of the at which they are generated, occur as a function of the state of the
managed device, independent of the managing device. managed device, independent of the managing device.
Once generated, it is expected that reports might be queued pending a Once generated, it is expected that reports might be queued, pending
connection back to a managing device. Therefore, reports need to be a connection back to a managing device. Therefore, reports need to
differentiable as a function of the time they were generated. be differentiable as a function of the time they were generated.
| NOTE: When reports are queued pending transmission, the overall | NOTE: When reports are queued pending transmission, the overall
| storage capacity at the queuing device needs to be considered. | storage capacity at the queuing device needs to be considered.
| There may be cases where queued reports can be considered | There may be cases where queued reports can be considered
| expired either because they have been queued for too long, or | expired because they have been either queued for too long or
| because they have been replaced by a newer report. When a | replaced by a newer report. When a report is considered
| report is considered expired, it may be considered for removal | expired, it may be considered for removal and, thus, never
| and, thus, never transmitted. This consideration is expected | transmitted. This consideration is expected to be part of the
| to be part of the implementation of the queuing device and not | implementation of the queuing device and not the responsibility
| the responsibility of the reporting function within the DTNMA. | of the reporting function within the DTNMA.
When reports are sent to a managing device over a challenged network, When reports are sent to a managing device over a challenged network,
they may arrive out of order due to taking different paths through they may arrive out of order due to taking different paths through
the network or being delayed due to retransmissions. A managing the network or being delayed due to retransmissions. A managing
device should not infer meaning from the order in which reports are device should not infer meaning from the order in which reports are
received. received.
Reports may or may not be associated with a specific Control. Some Reports may or may not be associated with a specific Control. Some
reports may be annotated with the Control that caused the report to reports may be annotated with the Control that caused the report to
be generated. Sometimes, a single report will represent the end be generated. Sometimes, a single report will represent the end
skipping to change at page 37, line 31 skipping to change at line 1692
Both local and remote services provided by the DTNMA affect the Both local and remote services provided by the DTNMA affect the
behavior of multiple applications on a managed device and may behavior of multiple applications on a managed device and may
interface with multiple managing devices. interface with multiple managing devices.
Authorization services enforce the potentially complex mapping of Authorization services enforce the potentially complex mapping of
other DTNMA services amongst managed and managing devices in the other DTNMA services amongst managed and managing devices in the
network. For example, fine-grained access control can determine network. For example, fine-grained access control can determine
which managing devices receive which reports, and what Controls can which managing devices receive which reports, and what Controls can
be used to alter which managed applications. be used to alter which managed applications.
This is particularly beneficial in networks that either deal with This is particularly beneficial in networks that deal with either
multiple administrative entities or overlay networks that cross multiple administrative entities or overlay networks that cross
administrative boundaries. Allowlists, blocklists, key-based administrative boundaries. Allowlists, blocklists, key-based
infrastructures, or other schemes may be used for this purpose. infrastructures, or other schemes may be used for this purpose.
9. Logical Autonomy Model 9. Logical Autonomy Model
An important characteristic of the DTNMA is the shift in the role of An important characteristic of the DTNMA is the shift in the role of
a managing device. One way to describe the behavior of the agent a managing device. One way to describe the behavior of the agent
autonomy engine is to describe the characteristics of the autonomy autonomy engine is to describe the characteristics of the autonomy
model it implements. model it implements.
skipping to change at page 38, line 16 skipping to change at line 1721
A managing autonomy capability on a potentially disconnected device A managing autonomy capability on a potentially disconnected device
needs to behave in both an expressive and deterministic way. needs to behave in both an expressive and deterministic way.
Expressivity allows for the model to be configured for a wide range Expressivity allows for the model to be configured for a wide range
of future situations. Determinism allows for the forensic of future situations. Determinism allows for the forensic
reconstruction of device behavior as part of debugging or recovery reconstruction of device behavior as part of debugging or recovery
efforts. It also is necessary to ensure predictable behavior. efforts. It also is necessary to ensure predictable behavior.
| NOTE: The use of predicate logic and a stimulus-response system | NOTE: The use of predicate logic and a stimulus-response system
| does not conflict with the use of higher-level autonomous | does not conflict with the use of higher-level autonomous
| function or the incorporation of machine learning. | functions or the incorporation of Machine Learning (ML).
| Specifically, the DTNMA deterministic autonomy model can | Specifically, the DTNMA deterministic autonomy model can
| coexist with other autonomous functions managing applications | coexist with other autonomous functions managing applications
| and network services. | and network services.
| |
| An example of such co-existence is the use of the DTNMA model | An example of such coexistence is the use of the DTNMA model to
| to ensure a device stays within safe operating parameters while | ensure that a device stays within safe operating parameters
| a less deterministic machine learning model directs smaller | while a less deterministic ML model directs other behaviors for
| behaviors for the device. | the device.
The DTNMA autonomy model is a rule-based model in which individual The DTNMA autonomy model is a rule-based model in which individual
rules associate a pre-identified stimulus with a pre-configured rules associate a pre-identified stimulus with a preconfigured
response to that stimulus. response to that stimulus.
Stimuli are identified using one or more predicate logic expressions Stimuli are identified using one or more predicate logic expressions
that examine aspects of the state of the managed device. Responses that examine aspects of the state of the managed device. Responses
are implemented by running one or more procedures on the managed are implemented by running one or more procedures on the managed
device. device.
In its simplest form, a stimulus is a single predicate expression of In its simplest form, a stimulus is a single predicate expression of
a condition that examines some aspect of the state of the managed a condition that examines some aspect of the state of the managed
device. When the condition is met, a predetermined response is device. When the condition is met, a predetermined response is
applied. This behavior can be captured using the construct: applied. This behavior can be captured using the construct:
IF <condition 1> THEN <response 1>; IF <condition 1> THEN <response 1>
In more complex forms, a stimulus may include both a common condition In more complex forms, a stimulus may include both a common condition
shared by multiple rules and a specific condition for each individual shared by multiple rules and a specific condition for each individual
rule. If the common condition is not met, the evaluation of the rule. If the common condition is not met, the evaluation of the
specific condition of each rule sharing the common condition can be specific condition of each rule sharing the common condition can be
skipped. In this way, the total number of predicate evaluations can skipped. In this way, the total number of predicate evaluations can
be reduced. This behavior can be captured using the construct: be reduced. This behavior can be captured using the construct:
IF <common condition> THEN IF <common condition> THEN
IF <specific condition 1> THEN <response 1> IF <specific condition 1> THEN <response 1>
IF <specific condition 2> THEN <response 2> IF <specific condition 2> THEN <response 2>
IF <specific condition 3> THEN <response 3> IF <specific condition 3> THEN <response 3>
| NOTE: The DTNMA model remains a stimulus-response system, | NOTE: The DTNMA model remains a stimulus-response system,
| regardless of whether a common condition is part of the | regardless of whether a common condition is part of the
| stimulus. However, it is recommended that implementations | stimulus. However, it is recommended that implementations
| incorporate a common condition because of the efficiency | incorporate a common condition because of the efficiency
| provided by such a bulk evaluation. | provided by such a bulk evaluation.
| |
| NOTE: One use of a stimulus "common condition" is to associated | NOTE: One use of a stimulus "common condition" is to associate
| the condition with an on-board event such as the expiring of a | the condition with an onboard event such as the expiring of a
| timer or the changing of a monitored value. | timer or the changing of a monitored value.
|
| NOTE: The DTNMA does not prescribe when to evaluate rule
| stimuli. Implementations may choose to evaluate rule stimuli
| at periodic intervals (such as 1Hz or 100Hz). When stimuli
| include on-board events, implementations may choose to perform
| an immediate evaluation at the time of the event rather than
| waiting for a periodic evaluation.
DTNMA Autonomy Model The DTNMA does not prescribe when to evaluate rule stimuli.
Implementations may choose to evaluate rule stimuli at periodic
intervals (such as 1 Hz or 100 Hz). When stimuli include onboard
events, implementations may choose to perform an immediate evaluation
at the time of the event rather than waiting for a periodic
evaluation.
The flow of data into and out of the agent autonomy engine is
illustrated in Figure 3.
Managed Applications | DTNMA Agent | DTNMA Manager Managed Applications | DTNMA Agent | DTNMA Manager
+---------------------+--------------------------------+--------------+ +---------------------+--------------------------------+--------------+
| +---------+ | | +---------+ |
| | Local | | Encoded | | Local | | Encoded
| | Rule DB |<-------------------- Policy | | Rule DB |<-------------------- Policy
| +---------+ | Expressions | +---------+ | Expressions
| ^ | | ^ |
| | | | | |
| v | | v |
| +----------+ +---------+ | | +----------+ +---------+ |
Monitoring Data------>| Agent | | Runtime | | Monitoring Data------>| Agent | | Runtime | |
| | Autonomy |<-->| Data |<---- Definitions | | Autonomy |<-->| Data- |<---- Definitions
Application Control<------| Engine | | Store | | Application Control<------| Engine | | store | |
| +----------+ +---------+ | | +----------+ +---------+ |
| | | | | |
| +-------------------------> Reports | +-------------------------> Reports
| | | |
Figure 3 Figure 3: DTNMA Autonomy Model
The flow of data into and out of the agent autonomy engine is In the model shown in Figure 3, the autonomy engine stores the
illustrated in Figure 3. In this model, the autonomy engine stores combination of stimulus conditions and associated responses as a set
the combination of stimulus conditions and associated responses as a of "rules" in a rule database. This database is updated through the
set of "rules" in a rules database. This database is updated through execution of the autonomy engine and as configured from policy
the execution of the autonomy engine and as configured from policy statements received by DMs.
statements received by managers.
Stimuli are detected by examining the state of applications as Stimuli are detected by examining the state of applications as
reported through application monitoring interfaces and through any reported through application monitoring interfaces and through any
locally-derived data. Local data is calculated in accordance with locally derived data. Local data is calculated in accordance with
definitions also provided by managers as part of the runtime data definitions also provided by DMs as part of the runtime datastore.
store.
Responses to stimuli may include updates to the rules database, Responses to stimuli may include updates to the rule database,
updates to the runtime data store, Controls sent to applications, and updates to the runtime datastore, Controls sent to applications, and
the generation of reports. the generation of reports.
9.2. Model Characteristics 9.2. Model Characteristics
There are several practical challenges to the implementation of a There are several practical challenges to the implementation of a
distributed rule-based system. Large numbers of rules may be distributed rule-based system. Large numbers of rules may be
difficult to understand, deconflict, and debug. Rules whose difficult to understand, deconflict, and debug. Rules whose
conditions are given by fused or other dynamic data may require data conditions are given by fused or other dynamic data may require data
logging and reporting for deterministic offline analysis. Rule logging and reporting for deterministic offline analysis. Rule
differences across managed devices may lead to oscillating effects. differences across managed devices may lead to oscillating effects.
This section identifies those characteristics of an autonomy model This section identifies those characteristics of an autonomy model
that might help implementations mitigate some of these challenges. that might help implementations mitigate some of these challenges.
There are a number of ways to represent data values, and many data There are a number of ways to represent data values, and many data
modeling languages exist for this purpose. When considering how to modeling languages exist for this purpose. When considering how to
model data in the context of the DTNMA autonomy model there are some model data in the context of the DTNMA autonomy model, there are some
modeling features that should be present to enable functionality. modeling features that should be present to enable functionality.
There are also some modeling features that should be prevented to There are also some modeling features that should be prevented to
avoid ambiguity. avoid ambiguity.
Traditional network management approaches favor flexibility in their Conventional network management approaches favor flexibility in their
data models. The DTNMA stresses deterministic behavior that supports data models. The DTNMA stresses deterministic behavior that supports
forensic analysis of agent activities "after the fact". As such, the forensic analysis of agent activities "after the fact". As such, the
following statements should be true of all data representations following statements should be true of all data representations
relating to DTNMA autonomy. relating to DTNMA autonomy.
Strong Typing: The predicates and expressions that comprise the Strong Typing: The predicates and expressions that comprise the
autonomy services in the DTNMA should require strict data typing. autonomy services in the DTNMA should require strict data typing.
This avoids errors associated with implicit data conversions and This avoids errors associated with implicit data conversions and
helps detect misconfiguration. helps detect misconfigurations.
Acyclic Dependency: Many dependencies exist in an autonomy model, Acyclic Dependency: Many dependencies exist in an autonomy model,
particularly when combining individual expressions or results to particularly when combining individual expressions or results to
create complex behaviors. Implementations that conform to the create complex behaviors. Implementations that conform to the
DTNMA need to prevent circular dependencies. DTNMA need to prevent circular dependencies.
Fresh Data: Autonomy models operating on data values presume that Fresh Data: Autonomy models operating on data values presume that
their data inputs represent the actionable state of the managed their data inputs represent the actionable state of the managed
device. If a data value has failed to be refreshed within a time device. If a data value has failed to be refreshed within a time
period, autonomy might incorrectly infer an operational state. period, autonomy might incorrectly infer an operational state.
Regardless of whether a data value has changed, DTNMA Regardless of whether a data value has changed, DTNMA
implementations should provide some indicator of whether the data implementations should provide some indicator of whether the data
value is "fresh" meaning that it still represents the current value is "fresh", i.e., meaning that it still represents the
state of the device. current state of the device.
Pervasive Parameterization: Where possible, autonomy model objects Pervasive Parameterization: Where possible, autonomy model objects
should support parameterization to allow for flexibility in the should support parameterization to allow for flexibility in the
specification. Parameterization allows for the definition of specification. Parameterization allows for the definition of
fewer unique model objects and also can support the substitution fewer unique model objects and also can support the substitution
of local device state when exercising device control or data of local device state when exercising device control or data
reporting. reporting.
Configurable Cardinality: The number of data values that can be Configurable Cardinality: The number of data values that can be
supported in a given implementation is finite. For devices supported in a given implementation is finite. For devices
operating in challenged environments, the number of supported operating in challenged environments, the number of supported
objects may be far fewer than that which can be supported by objects may be far fewer than the number of objects that can be
devices in well-resourced environments. DTNMA implementations supported by devices in well-resourced environments. DTNMA
should define limits to the number of supported objects that can implementations should define limits to the number of supported
be active in a system at one time, as a function of the resources objects that can be active in a system at one time, as a function
available to the implementation. of the resources available to the implementation.
Control-Based Updates: The agent autonomy engine changes the state Control-Based Updates: The agent autonomy engine changes the state
of the managed device by running Controls on the device. This is of the managed device by running Controls on the device. This is
different from approaches where the behavior of a managed device different from approaches where the behavior of a managed device
is influenced by updating configuration values, such as in a table is influenced by updating configuration values, such as in a table
or datastore. Altering behavior via one or more Controls allows or datastore. Altering behavior via one or more Controls allows
checking all pre-conditions before making changes as well as checking all preconditions before making changes as well as
providing more granularity in the way in which the device is providing more granularity in the way in which the device is
updated. Where necessary, Controls can be defined to perform bulk updated. Where necessary, Controls can be defined to perform bulk
updates of configuration data so as not to lose that update updates of configuration data so as not to lose that update
modality. One important update pre-condition is that the system modality. One important update precondition is that the system is
is not performing an action that would prevent the update (such as not performing an action that would prevent the update (such as
currently applying a competing update). currently applying a competing update).
9.3. Data Value Representation 9.3. Data Value Representation
The expressive representation of simple data values is fundamental to The expressive representation of simple data values is fundamental to
the successful construction and evaluation of predicates in the DTNMA the successful construction and evaluation of predicates in the DTNMA
autonomy model. When defining such values, there are useful autonomy model. When defining such values, there are useful
distinctions regarding how values are identified and whether values distinctions regarding how values are identified and whether values
are generated internal or external to the autonomy model. are generated in a way that is internal or external to the autonomy
model.
A DTNMA data value should combine a base type (e.g., integer, real, A DTNMA data value should combine a base type (e.g., integer, real,
string) representation with relevant semantic information. Base string) representation with relevant semantic information. Base
types are used for proper storage and encoding. Semantic information types are used for proper storage and encoding. Semantic information
allows for additional typing, constraint definitions, and mnemonic allows for additional typing, constraint definitions, and mnemonic
naming. This expanded definition of data value allows for better naming. This expanded definition of data values allows for better
predicate construction and evaluation and early type checking. predicate construction, better evaluation, and early type checking.
Data values may further be annotated based on whether their value is Data values may further be annotated based on whether their value is
the result of a DA calculation or the result of some external process the result of a DA calculation or the result of some external process
on the managed device. For example, operators may with to know which on the managed device. For example, operators may wish to know which
values can be updated by actions on the DA versus which values (such values can be updated by actions on the DA versus which values (such
as sensor readings) cannot be reliably changed because they are as sensor readings) cannot be reliably changed because they are
calculated external to the DA. calculated in a way that is external to the DA.
9.4. Data Reporting 9.4. Data Reporting
The DTNMA autonomy model should, as required, report on the state of The DTNMA autonomy model should, as required, report on the state of
its managed device (to include the state of the model itself). This its managed device (to include the state of the model itself). This
reporting should be done as a function of the changing state of the reporting should be done as a function of the changing state of the
managed device, independent of the connection to any managing device. managed device, independent of the connection to any managing device.
Queuing reports allows for later forensic analysis of device Queuing reports allows for later forensic analysis of device
behavior, which is a desirable property of DTNMA management. behavior; this feature is a desirable property of DTNMA management.
DTNMA data reporting consists of the production of some data report DTNMA data reporting consists of the production of some data report
instance conforming to a data report schema. The use of schemas instance conforming to a data report schema. The use of schemas
allows a report instance to identify the schema to which it conforms allows a report instance to identify the schema to which it conforms
instead of carrying the structure in the report itself. This instead of carrying the structure in the report itself. This
approach can significantly reduce the size of generated reports. approach can significantly reduce the size of generated reports.
| NOTE: The DTNMA data reporting concept is intentionally The DTNMA data reporting concept is intentionally distinct from the
| distinct from the concept of exchanging data stores across a concept of exchanging datastores across a network. It is envisioned
| network. It is envisioned that a DA might generate a data that a DA might generate a data report instance of a data report
| report instance of a data report schema at regular intervals or schema at regular intervals or in response to local events. In this
| in response to local events. In this model, many report model, many report schemas may be defined to capture unique, relevant
| schemas may be defined to capture unique, relevant combinations combinations of known data values rather than sending bulk datastores
| of known data values rather than sending bulk data stores off- off-platform for analysis.
| platform for analysis.
|
| NOTE: It is not required that data report schemas be tabular in | NOTE: It is not required that data report schemas be tabular in
| nature. Individual implementations might define tabular | nature. Individual implementations might define tabular
| schemas for table-like data and other report schemas for more | schemas for table-like data and other report schemas for more
| heterogeneous reporting. | heterogeneous reporting.
9.5. Command Execution 9.5. Command Execution
The agent autonomy engine requires that managed devices issue The agent autonomy engine requires that managed devices issue
commands on themselves as if they were otherwise being controlled by commands on themselves as if they were otherwise being controlled by
a managing device. The DTNMA implements commanding through the use a managing device. The DTNMA implements commanding through the use
of Controls and macros. of Controls and macros.
Controls represent parameterized, predefined procedures run by the DA Controls represent parameterized, predefined procedures run by the DA
either as directed by the DM or as part of a rule response from the either as directed by the DM or as part of a rule response from the
DA autonomy engine. Macros represent ordered sequences of Controls. DA autonomy engine. Macros represent ordered sequences of Controls.
Controls are conceptually similar to RPCs in that they represent Controls are conceptually similar to RPCs in that they represent
parameterized functions run on the managed device. However, they are parameterized functions run on the managed device. However, they are
conceptually dissimilar from RPCs in that they do not have a concept conceptually dissimilar to RPCs in that they do not have a concept of
of a return code because they operate over an asynchronous transport. a return code because they operate over an asynchronous transport.
The concept of return code in an RPC implies a synchronous The concept of a return code in an RPC implies a synchronous
relationship between the caller of the procedure and the procedure relationship between the caller of the procedure and the procedure
being called, which might not be possible within the DTNMA. being called, which might not be possible within the DTNMA.
The success or failure of a Control may be handled locally by the The success or failure of a Control may be handled locally by the
agent autonomy engine. Local error handling is particularly agent autonomy engine. Local error handling is particularly
important in this architecture given the potential for long periods important in this architecture, given the potential for long periods
of disconnectivity between a DA and a DM. The failure of one or more of disconnectivity between a DA and a DM. The failure of one or more
Controls is part of the state of the DA and can be used to trigger Controls is part of the state of the DA and can be used to trigger
rules within the DA autonomy engine. rules within the DA autonomy engine.
The impact of a Control is externally observable via the generation The impact of a Control is externally observable via the generation
and eventual examination of data reports produced by the managed and eventual examination of data reports produced by the managed
device. device.
The failure of certain Controls might leave a managed device in an The failure of certain Controls might leave a managed device in an
undesired state. Therefore, it is important that there be undesirable state. Therefore, it is important that there be
consideration for Control-specific recovery mechanisms (such as a consideration for Control-specific recovery mechanisms (such as a
rollback or safing mechanism). When a Control that is part of a rollback or safing mechanism). When a Control that is part of a
macro (such as in an autonomy response) fails, there may be a need to macro (such as in an autonomy response) fails, there may be a need to
implement a safe state for the managed device based on the nature of implement a safe state for the managed device based on the nature of
the failure. the failure.
| NOTE: The use of the term Control in the DTNMA is derived in | NOTE: The use of the term "Control" in the DTNMA is derived in
| part from the concept of Command and Control (C2) where control | part from the concept of Command and Control (C2), where
| implies the operational instructions undertaken to implement | control implies the operational instructions undertaken to
| (or maintain) a commanded objective. The DA autonomy engine | implement (or maintain) a commanded objective. The DA autonomy
| implements controls on a managed device to allow it to fulfill | engine implements controls on a managed device to allow it to
| some commanded objective known by a (possibly disconnected) | fulfill some commanded objective known by a (possibly
| managing device. | disconnected) managing device.
| |
| For example, a device might be commanded to maintain a safe | For example, a device might be commanded to maintain a safe
| internal thermal environment. Actions taken by a DA to manage | internal thermal environment. Actions taken by a DA to manage
| heaters, louvers, and other temperature-effecting components | heaters, louvers, and other temperature-affecting components
| are controls taken in service of that commanded objective. | are controls taken in service of that commanded objective.
9.6. Predicate Autonomy Rules 9.6. Predicate Autonomy Rules
As discussed in Section 9.1, the DTNMA rule-based stimulus-response As discussed in Section 9.1, the DTNMA rule-based stimulus-response
system associates stimulus detection with a predetermined response. system associates stimulus detection with a predetermined response.
Rules may be categorized based on whether their stimuli include Rules may be categorized based on whether (1) their stimuli include
generic statements of managed device state or whether they are generic statements of managed device state or (2) they are optimized
optimized to only consider the passage of time on the device. to only consider the passage of time on the device.
State-based rules are those whose stimulus is based on the evaluated State-based rules are those whose stimulus is based on the evaluated
state of the managed device. Time-based rules are a unique subset of state of the managed device. Time-based rules are a unique subset of
state-based rules whose stimulus is given only by a time-based event. state-based rules whose stimulus is given only by a time-based event.
Implementations might create different structures and evaluation Implementations might create different structures and evaluation
mechanisms for these two different types of rules to achieve more mechanisms for these two different types of rules to achieve more
efficient processing on a platform. efficient processing on a platform.
10. Use Cases 10. Use Cases
Using the autonomy model defined in Section 9, this section describes Using the autonomy model defined in Section 9, this section describes
flows through sample configurations conforming to the DTNMA. These flows through sample configurations conforming to the DTNMA. These
use cases illustrate remote configuration, local monitoring and use cases illustrate remote configuration, local monitoring and
control, multiple manager support, and data fusion. control, support for multiple DMs, and data fusion.
10.1. Notation 10.1. Notation
The use cases presented in this section are documented with a The use cases presented in this section are documented with a
shorthand notation to describe the types of data sent between shorthand notation to describe the types of data sent between
managers and agents. This notation, outlined in Table 1, leverages managers and agents. This notation, outlined in Table 1, leverages
the definitions of autonomy model components defined in Section 9. the definitions of the autonomy model components defined in
Section 9.
+==================+===================================+===========+ +==============+=======================================+===========+
| Term | Definition | Example | | Term | Definition | Example |
+==================+===================================+===========+ +==============+=======================================+===========+
| EDD# | Externally Defined Data - a data | EDD1, | | EDD# | Externally Defined Data -- a data | EDD1, |
| | value defined external to the DA. | EDD2 | | | value defined in a way that is | EDD2 |
+------------------+-----------------------------------+-----------+ | | external to the DA. | |
| V# | Variable - a data value defined | V1 = EDD1 | +--------------+---------------------------------------+-----------+
| | internal to the DA. | + 7 | | V# | Variable -- a data value defined in a | V1 = EDD1 |
+------------------+-----------------------------------+-----------+ | | way that is internal to the DA. | + 7 |
| EXPR | Predicate expression - used to | V1 > 5 | +--------------+---------------------------------------+-----------+
| | define a rule stimulus. | | | EXPR | Predicate expression -- used to | V1 > 5 |
+------------------+-----------------------------------+-----------+ | | define a rule stimulus. | |
| ID | DTNMA Object Identifier. | V1, EDD2 | +--------------+---------------------------------------+-----------+
+------------------+-----------------------------------+-----------+ | ID | DTNMA Object Identifier. | V1, EDD2 |
| ACL# | Enumerated Access Control List. | ACL1 | +--------------+---------------------------------------+-----------+
+------------------+-----------------------------------+-----------+ | ACL# | Enumerated Access Control List. | ACL1 |
| DEF(ACL,ID,EXPR) | Define ID from expression. Allow | DEF(ACL1, | +--------------+---------------------------------------+-----------+
| | managers in ACL to see this ID. | V1, EDD1 | | DEF(ACL, ID, | Define "ID" from expression. Allow | DEF(ACL1, |
| | | + EDD2) | | EXPR) | DMs in ACL to see this ID. | V1, EDD1 |
+------------------+-----------------------------------+-----------+ | | | + EDD2) |
| PROD(P,ID) | Produce ID according to predicate | PROD(1s, | +--------------+---------------------------------------+-----------+
| | P. P may be a time period (1s) | EDD1) | | PROD(P, ID) | Produce "ID" according to predicate | PROD(1s, |
| | or an expression (EDD1 > 10). | | | | P. P may be a time period (1 second, | EDD1) |
+------------------+-----------------------------------+-----------+ | | or 1s) or an expression (EDD1 > 10). | |
| RPT(ID) | A report instance containing data | RPT(EDD1) | +--------------+---------------------------------------+-----------+
| | named ID. | | | RPT(ID) | A report instance containing data | RPT(EDD1) |
+------------------+-----------------------------------+-----------+ | | named "ID". | |
+--------------+---------------------------------------+-----------+
Table 1: Terminology Table 1: Terminology
These notations do not imply any implementation approach. They only These notations do not imply any implementation approach. They only
provide a succinct syntax for expressing the data flows in the use provide a succinct syntax for expressing the data flows in the use
case diagrams in the remainder of this section. case diagrams in the remainder of this section.
10.2. Serialized Management 10.2. Serialized Management
This nominal configuration shows a single DM interacting with This nominal configuration shows a single DM interacting with
multiple DAs. The control flows for this scenario are outlined in multiple DAs. The control flow for this scenario is outlined in
Figure 4. Figure 4.
Serialized Management Control Flow
+-----------+ +---------+ +---------+ +-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B | | Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+ +----+------+ +----+----+ +----+----+
| | | | | |
|-----PROD(1s, EDD1)--->| | (1) |-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->| |----------------------------PROD(1s, EDD1)-->|
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | (2) |<-------RPT(EDD1)------| | (2)
skipping to change at page 46, line 25 skipping to change at line 2080
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
|<----------------------------RPT(EDD1)-------| |<----------------------------RPT(EDD1)-------|
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
|<----------------------------RPT(EDD1)-------| |<----------------------------RPT(EDD1)-------|
| | | | | |
Figure 4 Figure 4: Serialized Management Control Flow
In a serialized management scenario, a single DM interacts with In a serialized management scenario, a single DM interacts with
multiple DAs. multiple DAs.
In this figure, the DTNMA Manager A sends a policy to DTNMA Agents A In this figure, DM A sends a policy to DAs A and B to report the
and B to report the value of an EDD (EDD1) every second in (step 1). value of an EDD (EDD1) every second (step 1). Each DA receives this
Each DA receives this policy and configures their respective autonomy policy and configures their respective autonomy engines for this
engines for this production. Thereafter, (step 2) each DA produces a production. Thereafter (step 2), each DA produces a report
report containing data element EDD1 and sends those reports back to containing data element EDD1; each such report is then sent back to
the DM. the DM.
This behavior continues without any additional communications from This behavior continues without any additional communications from
the DM. the DM.
10.3. Intermittent Connectivity 10.3. Intermittent Connectivity
Building from the nominal configuration in Section 10.2, this Building on the nominal configuration discussed in Section 10.2, this
scenario shows a challenged network in which connectivity between scenario shows a challenged network in which connectivity between DA
DTNMA Agent B and the DM is temporarily lost. Control flows for this B and the DM is temporarily lost. The control flow for this case is
case are outlined in Figure 5. outlined in Figure 5.
Challenged Management Control Flow
+-----------+ +---------+ +---------+ +-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B | | Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+ +----+------+ +----+----+ +----+----+
| | | | | |
|-----PROD(1s, EDD1)--->| | (1) |-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->| |----------------------------PROD(1s, EDD1)-->|
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | (2) |<-------RPT(EDD1)------| | (2)
skipping to change at page 47, line 33 skipping to change at line 2131
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
| | RPT(EDD1)| (4) | | RPT(EDD1)| (4)
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
|<----------------RPT(EDD1), RPT(EDD1)--------| (5) |<----------------RPT(EDD1), RPT(EDD1)--------| (5)
| | | | | |
Figure 5 Figure 5: Challenged Management Control Flow
In a challenged network, DAs store reports pending a transmit In a challenged network, DAs store reports, pending a transmit
opportunity. opportunity.
In this figure, DTNMA Manager A sends a policy to DTNMA Agents A and In this figure, DM A sends a policy to DAs A and B to produce an EDD
B to produce an EDD (EDD1) every second in (step 1). Each DA (EDD1) every second (step 1). Each DA receives this policy and
receives this policy and configures their respective autonomy engines configures their respective autonomy engines for this production.
for this production. Produced reports are transmitted when there is Produced reports are transmitted when there is connectivity between
connectivity between the DA and DM (step 2). the DA and DM (step 2).
At some point, DTNMA Agent B loses the ability to transmit in the At some point, DA B loses the ability to transmit in the network
network (steps 3 and 4). During this time period, DA B continues to (steps 3 and 4). During this time period, DA B continues to produce
produce reports, but they are queued for transmission. This queuing reports, but they are queued for transmission. This queuing might be
might be done by the DA itself or by a supporting transport such as done by the DA itself or by a supporting transport such as BP.
BP. Eventually (and before the next scheduled production of EDD1), Eventually (and before the next scheduled production of EDD1), DA B
DTNMA Agent B is able to transmit in the network again (step 5) and is able to transmit in the network again (step 5), and all queued
all queued reports are sent at that time. DTNMA Agent A maintains reports are sent at that time. DA A maintains connectivity with the
connectivity with the DM during steps 3-5, and continues to send DM during steps 3-5 and continues to send reports as they are
reports as they are generated. generated.
10.4. Open-Loop Reporting 10.4. Open-Loop Reporting
This scenario illustrates the DTNMA open-loop control paradigm, where This scenario illustrates the DTNMA open-loop control paradigm, where
DAs manage themselves in accordance with policies provided by DMs, DAs manage themselves in accordance with policies provided by DMs and
and provide reports to DMs based on these policies. provide reports to DMs based on these policies.
The control flow shown in Figure 6, includes an example of data The control flow shown in Figure 6 includes an example of data
fusion, where multiple policies configured by a DM result in a single fusion, where multiple policies configured by a DM result in a single
report from a DA. report from a DA.
Consolidated Management Control Flow
+-----------+ +---------+ +---------+ +-----------+ +---------+ +---------+
| DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Agent B | | Manager A | | Agent A | | Agent B |
+----+------+ +----+----+ +----+----+ +----+------+ +----+----+ +----+----+
| | | | | |
|-----PROD(1s, EDD1)--->| | (1) |-----PROD(1s, EDD1)--->| | (1)
|----------------------------PROD(1s, EDD1)-->| |----------------------------PROD(1s, EDD1)-->|
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | (2) |<-------RPT(EDD1)------| | (2)
|<----------------------------RPT(EDD1)-------| |<----------------------------RPT(EDD1)-------|
| | | | | |
| | | | | |
|----------------------------PROD(1s, EDD2)-->| (3) |----------------------------PROD(1s, EDD2)-->| (3)
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
|<--------------------------RPT(EDD1,EDD2)----| (4) |<-------------------------RPT(EDD1, EDD2)----| (4)
| | | | | |
| | | | | |
|<-------RPT(EDD1)------| | |<-------RPT(EDD1)------| |
|<--------------------------RPT(EDD1,EDD2)----| |<-------------------------RPT(EDD1, EDD2)----|
| | | | | |
Figure 6 Figure 6: Consolidated Management Control Flow
A many-to-one mapping between management policy and device state A many-to-one mapping between management policy and device state
reporting is supported by the DTNMA. reporting is supported by the DTNMA.
In this figure, DTNMA Manager A sends a policy statement in the form In this figure, DM A sends a policy statement in the form of a rule
of a rule to DTNMA Agents A and B, which instructs the DAs to produce to DAs A and B, which instructs the DAs to produce a report for EDD1
a report with EDD1 every second (step 1). Each DA receives this every second (step 1). Each DA receives this policy, which is stored
policy, which is stored in its respective Rule Database, and in its respective rule database, and configures its autonomy engine.
configures its Autonomy Engine. Reports are transmitted by each DA Reports are transmitted by each DA when produced (step 2).
when produced (step 2).
At a later time, DTNMA Manager A sends an additional policy to DTNMA At a later time, DM A sends an additional policy to DA B, requesting
Agent B, requesting the production of a report for EDD2 every second the production of a report for EDD2 every second (step 3). This
(step 3). This policy is added to DTNMA Agent B's Rule Database. policy is added to DA B's rule database.
Following this policy update, DTNMA Agent A will continue to produce Following this policy update, DA A will continue to produce EDD1, and
EDD1 and DTNMA Agent B will produce both EDD1 and EDD2 (step 4). DA B will produce both EDD1 and EDD2 (step 4). However, DA B may
However, DTNMA Agent B may provide these values to the DM in a single provide these values to the DM in a single report rather than as two
report rather than as 2 independent reports. In this way, there is independent reports. In this way, there is no direct mapping between
no direct mapping between the single consolidated report sent by the consolidated reports sent by DA B (from step 4 onwards) and the
DTNMA Agent B (step 4) and the two different policies sent to DTNMA two different policies sent to DA B (steps 1 and 3) that produce the
Agent B that caused that report to be generated (steps 1 and 3). information included in those consolidated reports.
10.5. Multiple Administrative Domains 10.5. Multiple Administrative Domains
The managed applications on a DA may be controlled by different The managed applications on a DA may be controlled by different
administrative entities in a network. The DTNMA allows DAs to administrative entities in a network. The DTNMA allows DAs to
communicate with multiple DMs in the network, such as in cases where communicate with multiple DMs in the network, such as in cases where
there is one DM per administrative domain. there is one DM per administrative domain.
Whenever a DM sends a policy expression to a DA, that policy Whenever a DM sends a policy expression to a DA, that policy
expression may be associated with authorization information. One expression may be associated with authorization information. One
method of representing this is an ACL. method of representing this is an ACL.
| The use of an ACL in this use case does not imply the DTNMA The use of an ACL in this use case does not imply that the DTNMA
| requires ACLs to annotate policy expressions. ACLs and their requires ACLs to annotate policy expressions. ACLs and their
| representation in this context are for example purposes only. representation in this context are for example purposes only.
The ability of one DM to access the results of policy expressions The ability of one DM to access the results of policy expressions
configured by some other DM will be limited to the authorization configured by some other DM will be limited to the authorization
annotations of those policy expressions. annotations of those policy expressions.
An example of multi-manager authorization is illustrated in Figure 7. An example of multi-manager authorization is illustrated in Figure 7.
Multiplexed Management Control Flow
+-----------+ +---------+ +-----------+ +-----------+ +---------+ +-----------+
| DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA | | DTNMA |
| Manager A | | Agent A | | Manager B | | Manager A | | Agent A | | Manager B |
+-----+-----+ +----+----+ +-----+-----+ +-----+-----+ +----+----+ +-----+-----+
| | | | | |
|---DEF(ACL1,V1,EDD1*2)--->|<---DEF(ACL2, V2, EDD2*2)---| (1) |--DEF(ACL1, V1, EDD1*2)-->|<---DEF(ACL2, V2, EDD2*2)---| (1)
| | | | | |
|---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2) |---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2)
| | | | | |
|<--------RPT(V1)----------| | (3) |<--------RPT(V1)----------| | (3)
| |--------RPT(V2)------------>| | |--------RPT(V2)------------>|
|<--------RPT(V1)----------| | |<--------RPT(V1)----------| |
| |--------RPT(V2)------------>| | |--------RPT(V2)------------>|
| | | | | |
| |<---PROD(1s, V1)------------| (4) | |<---PROD(1s, V1)------------| (4)
| | | | | |
| |----ERR(V1 no perm.)------->| | |---ERR(V1 not permitted)--->|
| | | | | |
|--DEF(NULL,V3,EDD3*3)---->| | (5) |--DEF(NULL, V3, EDD3*3)-->| | (5)
| | | | | |
|---PROD(1s, V3)---------->| | (6) |---PROD(1s, V3)---------->| | (6)
| | | | | |
| |<----PROD(1s, V3)-----------| | |<----PROD(1s, V3)-----------|
| | | | | |
|<--------RPT(V3)----------|--------RPT(V3)------------>| (7) |<--------RPT(V3)----------|--------RPT(V3)------------>| (7)
|<--------RPT(V1)----------| | |<--------RPT(V1)----------| |
| |--------RPT(V2)------------>| | |--------RPT(V2)------------>|
|<-------RPT(V3)-----------|--------RPT(V3)------------>| |<-------RPT(V3)-----------|--------RPT(V3)------------>|
|<-------RPT(V1)-----------| | |<-------RPT(V1)-----------| |
| |--------RPT(V2)------------>| | |--------RPT(V2)------------>|
Figure 7 Figure 7: Multiplexed Management Control Flow
Multiple DMs may interface with a single DA, particularly in complex Multiple DMs may interface with a single DA, particularly in complex
networks. networks.
In this figure, both DTNMA Managers A and B send policies to DTNMA In this figure, both DM A and DM B send policies to DA A (step 1).
Agent A (step 1). DM A defines a variable (V1) whose value is given DM A defines a variable (V1) whose value is given by the mathematical
by the mathematical expression (EDD1 * 2) and is associated with an expression (EDD1 * 2) and is associated with an ACL (ACL1) that
ACL (ACL1) that restricts access to V1 to DM A only. Similarly, DM B restricts access to V1 to DM A only. Similarly, DM B defines a
defines a variable (V2) whose value is given by the mathematical variable (V2) whose value is given by the mathematical expression
expression (EDD2 * 2) and associated with an ACL (ACL2) that (EDD2 * 2) and is associated with an ACL (ACL2) that restricts access
restricts access to V2 to DM B only. to V2 to DM B only.
Both DTNMA Managers A and B also send policies to DTNMA Agent A to Both DM A and DM B also send policies to DA A to report on the values
report on the values of their variables at 1 second intervals (step of their variables at 1-second intervals (step 2). Since DM A can
2). Since DM A can access V1 and DM B can access V2, there is no access V1 and DM B can access V2, there is no authorization issue
authorization issue with these policies and they are both accepted by with these policies, and they are both accepted by the autonomy
the autonomy engine on Agent A. Agent A produces reports as engine on DA A. DA A produces reports as expected, sending them to
expected, sending them to their respective managers (step 3). their respective managers (step 3).
Later (step 4) DM B attempts to configure DA A to also report to it 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 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 variable, DA A does not include this in the configuration of its
autonomy engine and, instead, some indication of permission error is autonomy engine; instead, some indication of a permission error is
included in any regular reporting back to DM B. included in any regular reporting back to DM B.
DM A also sends a policy to Agent A (step 5) that defines a variable DM A also sends a policy to DA A (step 5) that defines a variable
(V3) whose value is given by the mathematical expression (EDD3 * 3) (V3) whose value is given by the mathematical expression (EDD3 * 3)
and is not associated with an ACL, indicating that any DM can access 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 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 DA A to report the value of V3 (step 6). Since there is no
authorization restriction on V3, these policies are accepted by the 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 autonomy engine on DA A, and reports are sent to both DM A and DM B
over time (step 7). over time (step 7).
10.6. Cascading Management 10.6. Cascading Management
There are times where a single network device may serve as both a DM There are times when a single network device may serve as both a DM
for other DAs in the network and, itself, as a device managed by 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 someone else. This may be the case on nodes serving as gateways or
proxies. The DTNMA accommodates this case by allowing a single proxies. The DTNMA accommodates this case by allowing a single
device to run both a DA and DM. device to run both a DA and a DM.
An example of this configuration is illustrated in Figure 8. An example of this configuration is illustrated in Figure 8.
Cascading Management Control Flow
--------------------------------------- ---------------------------------------
| Node B | | Node B |
| | | |
+-----------+ | +-----------+ +---------+ | +---------+ +-----------+ | +-----------+ +---------+ | +---------+
| DTNMA | | | DTNMA | | DTNMA | | | DTNMA | | DTNMA | | | DTNMA | | DTNMA | | | DTNMA |
| Manager A | | | Manager B | | Agent B | | | Agent C | | Manager A | | | Manager B | | Agent B | | | Agent C |
+---+-------+ | +-----+-----+ +----+----+ | +----+----+ +---+-------+ | +-----+-----+ +----+----+ | +----+----+
| | | | | | | | | | | |
|--------------DEF(NULL,V0,EDD1+EDD2)-->| | | (1) |----------DEF(NULL, V0, EDD1 + EDD2)-->| | | (1)
|--------------PROD(1s,V0)------------->| | | |-------------PROD(1s, V0)------------->| | |
| | | | | | | | | | | |
| | |--PROD(1s,EDD1)-->| | | (2) | | |-PROD(1s, EDD1)-->| | | (2)
| | |---------------------PROD(1s,EDD2)-->| (2) | | |--------------------PROD(1s, EDD2)-->| (2)
| | | | | | | | | | | |
| | | | | | | | | | | |
| | |<----RPT(EDD1)----| | | (3) | | |<----RPT(EDD1)----| | | (3)
| | |<--------------------RPT(EDD2)-------| (3) | | |<--------------------RPT(EDD2)-------| (3)
| | | | | | | | | | | |
|<-------------RPT(V0)------------------| | | (4) |<-------------RPT(V0)------------------| | | (4)
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | |
| | | |
--------------------------------------- ---------------------------------------
Figure 8 Figure 8: Cascading Management Control Flow
A device can operate as both a DTNMA Manager and an Agent. A device can operate as both a DM and a DA.
In this example, we presume that DA B is able to sample a given EDD 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 (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 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 DM A). DM A must periodically receive some new value that is
calculated as a function of both EDD1 and EDD2. calculated as a function of both EDD1 and EDD2.
First, DM A sends a policy to DA B to define a variable (V0) whose 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 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 restricting ACL. Further, DM A sends a policy to DA B to report on
the value of V0 every second (step 1). the value of V0 every second (step 1).
DA B needs the ability to monitor both EDD1 and EDD2. However, the DA B needs the ability to monitor both EDD1 and EDD2 to produce V0.
only way to receive EDD2 values is to have them reported back to Node DA B is able to sample EDD1, so DM B sends a policy to DA B to report
B by DA C and included in the Node B runtime data stores. Therefore, on the value of EDD1. However, the only way to receive EDD2 values
DM B sends a policy to DA C to report on the value of EDD2 (step 2). is to have them reported back to Node B by DA C and included in the
Node B runtime datastores. Therefore, DM B also 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 DA B receives the policy in its autonomy engine and produces reports
on the value of EDD2 every second (step 3). on the value of EDD2 every second. Similarly, 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 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 of V0 and report on those values at regular intervals to DM A (step
4). 4).
While a trivial example, the mechanism of associating fusion with the While a trivial example, the mechanism of associating fusion with the
Agent function rather than the Manager function scales with fusion DA function rather than the DM function scales with fusion
complexity. Within the DTNMA, DAs and DMs are not required to be complexity. Within the DTNMA, DAs and DMs are not required to be
separate software implementations. There may be a single software separate software implementations. There may be a single software
application running on Node B implementing both DM B and DA B roles. application running on Node B implementing both DM B and DA B roles.
11. IANA Considerations 11. IANA Considerations
This document requires no IANA actions. This document has no IANA actions.
12. Security Considerations 12. Security Considerations
Security within a DTNMA exists in at least two layers: security in Security within a DTNMA exists in at least the following two layers:
the data model and security in the messaging and encoding of the data security in the data model and security in the messaging and encoding
model. of the data model.
Data model security refers to the validity and accessibility of data Data model security refers to the validity and accessibility of data
elements. For example, a data element might be available to certain elements. For example, a data element might be available to certain
DAs or DMs in a system, whereas the same data element may be hidden DAs or DMs in a system, whereas the same data element may be hidden
from other DAs or DMs. Both verification and authorization from other DAs or DMs. Both verification and authorization
mechanisms at DAs and DMs are important to achieve this type of mechanisms at DAs and DMs are important to achieve this type of
security. security.
| NOTE: One way to provide finer-grained application security is | NOTE: One way to provide finer-grained application security is
| through the use of Access Control Lists (ACLs) that would be | through the use of ACLs that would be defined as part of the
| defined as part of the configuration of DAs and DMs. It is | configuration of DAs and DMs. It is expected that many common
| expected that many common data model tools provide mechanisms | data model tools provide mechanisms for the definition of ACLs
| for the definition of ACLs and best practices for their | and best practices for their operational use.
| operational use.
The exchange of information between and amongst DAs and DMs in the The exchange of information between and amongst DAs and DMs in the
DTNMA is expected to be accomplished through some secured messaging DTNMA is expected to be accomplished through some secured messaging
transport. transport.
13. Informative References 13. Informative References
[ASN.1] International Organization for Standardization, [ASN.1] ITU-T, "Information technology - Abstract Syntax Notation
"Information processing systems - Open Systems One (ASN.1): Specification of basic notation", ITU-T
Interconnection - Specification of Abstract Syntax Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
Notation One (ASN.1)", International Standard 8824, <https://www.itu.int/rec/T-REC-X.680>.
December 1987.
[CORE-COMI]
Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Ed.,
Bierman, A., and C. Bormann, Ed., "CoAP Management
Interface (CORECONF)", Work in Progress, Internet-Draft,
draft-ietf-core-comi-19, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
comi-19>.
[DART] Tropf, B. T., Haque, M., Behrooz, N., and C. Krupiarz, [DART] Tropf, B. T., Haque, M., Behrooz, N., and C. Krupiarz,
"The DART Autonomy System", 2023, "The DART Autonomy System", DOI 10.1109/SMC-
IT56444.2023.00020, August 2023,
<https://ieeexplore.ieee.org/abstract/document/10207457>. <https://ieeexplore.ieee.org/abstract/document/10207457>.
[gNMI] OpenConfig, "gRPC Network Management Interface (gNMI)", [gNMI] Borman, P., Hines, M., Lebsack, C., Morrow, C., Shaikh,
May 2023, <https://www.openconfig.net/docs/gnmi/gnmi- A., Shakir, R., Li, W., and D. Loher, "gRPC Network
Management Interface (gNMI)", Version 10.0, May 2023,
<https://www.openconfig.net/docs/gnmi/gnmi-
specification/>. specification/>.
[gRPC] gRPC Authors, "gRPC Documentation", 2024, [gRPC] gRPC Authors, "gRPC Documentation", 2024,
<https://grpc.io/docs/>. <https://grpc.io/docs/>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "CoAP Management Interface (CORECONF)",
Work in Progress, Internet-Draft, draft-ietf-core-comi-17,
4 March 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-comi-17>.
[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M.
Richardson, "YANG Schema Item iDentifier (YANG SID)", Work
in Progress, Internet-Draft, draft-ietf-core-sid-24, 22
December 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-sid-24>.
[I-D.rfernando-protocol-buffers]
Stuart, S. and R. Fernando, "Encoding rules and MIME type
for Protocol Buffers", Work in Progress, Internet-Draft,
draft-rfernando-protocol-buffers-00, 11 October 2012,
<https://datatracker.ietf.org/doc/html/draft-rfernando-
protocol-buffers-00>.
[IPMI] Intel, Hewlett-Packard, NEC, and Dell, "Intelligent [IPMI] Intel, Hewlett-Packard, NEC, and Dell, "Intelligent
Platform Management Interface Specification, Second Platform Management Interface Specification, Second
Generation", October 2013, Generation", Version 2.0, October 2013,
<https://www.intel.la/content/dam/www/public/us/en/ <https://www.intel.la/content/dam/www/public/us/en/
documents/specification-updates/ipmi-intelligent-platform- documents/specification-updates/ipmi-intelligent-platform-
mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf>. mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf>.
[NEW-HORIZONS] [NEW-HORIZONS]
Moore, R. C., "Autonomous safeing and fault protection for Moore, R. C., "Autonomous safeing and fault protection for
the New Horizons mission to Pluto", March 2007, the New Horizons mission to Pluto", Acta Astronautica,
Volume 61, Issues 1-6, June-August 2007, Pages 398-405,
DOI 10.1016/j.actaastro.2007.01.009, August 2007,
<https://www.sciencedirect.com/science/article/pii/ <https://www.sciencedirect.com/science/article/pii/
S0094576507000604>. S0094576507000604>.
[PROTOCOL-BUFFERS]
Stuart, S. and R. Fernando, "Encoding rules and MIME type
for Protocol Buffers", Work in Progress, Internet-Draft,
draft-rfernando-protocol-buffers-00, 8 October 2012,
<https://datatracker.ietf.org/doc/html/draft-rfernando-
protocol-buffers-00>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999, DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>. <https://www.rfc-editor.org/info/rfc2578>.
[RFC2982] Kavasseri, R., Ed., "Distributed Management Expression [RFC2982] Kavasseri, R., Ed., "Distributed Management Expression
MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000, MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000,
<https://www.rfc-editor.org/info/rfc2982>. <https://www.rfc-editor.org/info/rfc2982>.
skipping to change at page 58, line 48 skipping to change at line 2631
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>. 2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, [RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "Encoding of Data Modeled with YANG C., and M. Richardson, "Encoding of Data Modeled with YANG
in the Concise Binary Object Representation (CBOR)", in the Concise Binary Object Representation (CBOR)",
RFC 9254, DOI 10.17487/RFC9254, July 2022, RFC 9254, DOI 10.17487/RFC9254, July 2022,
<https://www.rfc-editor.org/info/rfc9254>. <https://www.rfc-editor.org/info/rfc9254>.
[RFC9595] Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed.,
Bormann, C., and M. Richardson, "YANG Schema Item
iDentifier (YANG SID)", RFC 9595, DOI 10.17487/RFC9595,
July 2024, <https://www.rfc-editor.org/info/rfc9595>.
[xml-infoset] [xml-infoset]
World Wide Web Consortium, "XML Information Set (Second Cowan, J., Ed. and R. Tobin, Ed., "XML Information Set
Edition)", February 2004, (Second Edition)", W3C Recommendation REC-xml-infoset-
20040204, February 2004,
<https://www.w3.org/TR/2004/REC-xml-infoset-20040204/>. <https://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[XPath] World Wide Web Consortium, "XML Path Language (XPath) [XPath] Robie, J., Ed., Dyck, M., Ed., and J. Spiegel, Ed., "XML
Version 1.0", November 1999, Path Language (XPath) 3.1", March 2017,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <https://www.w3.org/TR/2017/REC-xpath-31-20170321/>.
Latest version available at
<https://www.w3.org/TR/xpath-31/>.
Acknowledgements Acknowledgements
Brian Sipos of the Johns Hopkins University Applied Physics Brian Sipos of the Johns Hopkins University Applied Physics
Laboratory (JHU/APL) provided excellent technical review of the DTNMA Laboratory (JHU/APL) provided excellent technical review of the DTNMA
concepts presented in this document and additional information concepts presented in this document and additional information
related to existing network management techniques. related to existing network management techniques.
Authors' Addresses Authors' Addresses
Edward J. Birrane Edward J. Birrane, III
Johns Hopkins Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
Sarah E. Heiner Sarah Heiner
Johns Hopkins Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
Email: Sarah.Heiner@jhuapl.edu Email: Sarah.Heiner@jhuapl.edu
Emery Annis Emery Annis
Johns Hopkins Applied Physics Laboratory The Johns Hopkins University Applied Physics Laboratory
Email: Emery.Annis@jhuapl.edu Email: Emery.Annis@jhuapl.edu
 End of changes. 296 change blocks. 
914 lines changed or deleted 903 lines changed or added

This html diff was produced by rfcdiff 1.48.