< draft-ietf-dtn-ama-02.txt   draft-ietf-dtn-ama-03.txt >
Delay-Tolerant Networking E.B. Birrane Delay-Tolerant Networking E.J. Birrane
Internet-Draft E. Annis Internet-Draft E. Annis
Intended status: Informational S.E. Heiner Intended status: Informational S.E. Heiner
Expires: 27 April 2022 Johns Hopkins Applied Physics Laboratory Expires: 28 April 2022 Johns Hopkins Applied Physics Laboratory
October 2021 October 2021
Asynchronous Management Architecture Asynchronous Management Architecture
draft-ietf-dtn-ama-02 draft-ietf-dtn-ama-03
Abstract Abstract
This document describes a management architecture suitable for This document describes a management architecture suitable for
deployment in challenged networking environments for the deployment in challenged networking environments for the
configuration, monitoring, and local control of application services. configuration, monitoring, and local control of application services.
Challenged networking environments exhibit interruptions in end-to- Challenged networking environments exhibit interruptions in end-to-
end connectivity and communications delays that are both long-lived end connectivity and communications delays that are both long-lived
and unpredictable. Even in these challenging conditions, such and unpredictable. Even in these challenging conditions, such
networks must provide some type of end-to-end information transport networks must provide some type of end-to-end information transport
skipping to change at page 2, line 38 skipping to change at page 2, line 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.3. Organization . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Organization . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Challenged Networks . . . . . . . . . . . . . . . . . . . 9 3.1. Challenged Networks . . . . . . . . . . . . . . . . . . . 9
3.2. Current Approaches and Their Limitations . . . . . . . . 10 3.2. Current Approaches and Their Limitations . . . . . . . . 10
3.2.1. Simple Network Management Protocol (SNMP) . . . . . . 10 3.2.1. Simple Network Management Protocol (SNMP) . . . . . . 10
3.2.2. YANG, NETCONF, and RESTCONF . . . . . . . . . . . . . 11 3.2.2. YANG, NETCONF, and RESTCONF . . . . . . . . . . . . . 11
3.2.3. Constrained RESTful Network Management . . . . . . . 12 3.2.3. Constrained RESTful Network Management . . . . . . . 13
3.2.4. Autonomous Network Management . . . . . . . . . . . . 12 4. Services Provided by an AMA . . . . . . . . . . . . . . . . . 13
4. Desirable Properties of Challenged Network Management . . . . 12 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Intelligent Push of Information . . . . . . . . . . . . . 12 4.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Minimize Message Size Not Node Processing . . . . . . . . 13 4.3. Autonomous Parameterized Procedure Calls . . . . . . . . 15
4.3. Absolute Data Identification . . . . . . . . . . . . . . 13 4.4. Administration . . . . . . . . . . . . . . . . . . . . . 16
4.4. Custom Data Definition . . . . . . . . . . . . . . . . . 14 5. Desirable Properties of an AMA . . . . . . . . . . . . . . . 16
4.5. Autonomous Operation . . . . . . . . . . . . . . . . . . 14 5.1. Intelligent Push of Information . . . . . . . . . . . . . 16
5. Roles and Responsibilities . . . . . . . . . . . . . . . . . 15 5.2. Minimize Message Size Not Node Processing . . . . . . . . 17
5.1. Agent Responsibilities . . . . . . . . . . . . . . . . . 15 5.3. Absolute Data Identification . . . . . . . . . . . . . . 17
5.2. Manager Responsibilities . . . . . . . . . . . . . . . . 16 5.4. Custom Data Definition . . . . . . . . . . . . . . . . . 18
6. Service Definitions . . . . . . . . . . . . . . . . . . . . . 17 5.5. Autonomous Operation . . . . . . . . . . . . . . . . . . 18
6.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 17 6. AMA Roles and Responsibilities . . . . . . . . . . . . . . . 19
6.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Agent Responsibilities . . . . . . . . . . . . . . . . . 19
6.3. Autonomous Parameterized Procedure Calls . . . . . . . . 18 6.2. Manager Responsibilities . . . . . . . . . . . . . . . . 20
6.4. Administration . . . . . . . . . . . . . . . . . . . . . 19
7. Logical Data Model . . . . . . . . . . . . . . . . . . . . . 19 7. Logical Data Model . . . . . . . . . . . . . . . . . . . . . 21
7.1. Data Representations: Constants, Externally Defined Data, 7.1. Data Representations: Constants, Externally Defined Data,
and Variables . . . . . . . . . . . . . . . . . . . . . . 20 and Variables . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Data Collections: Reports and Tables . . . . . . . . . . 20 7.2. Data Collections: Reports and Tables . . . . . . . . . . 22
7.2.1. Report Templates and Reports . . . . . . . . . . . . 21 7.2.1. Report Templates and Reports . . . . . . . . . . . . 22
7.2.2. Table Templates and Tables . . . . . . . . . . . . . 21 7.2.2. Table Templates and Tables . . . . . . . . . . . . . 23
7.3. Command Execution: Controls and Macros . . . . . . . . . 22 7.3. Command Execution: Controls and Macros . . . . . . . . . 23
7.4. Autonomy: Time and State-Based Rules . . . . . . . . . . 23 7.4. Autonomy: Time and State-Based Rules . . . . . . . . . . 24
7.4.1. State-Based Rule (SBR) . . . . . . . . . . . . . . . 23 7.4.1. State-Based Rule (SBR) . . . . . . . . . . . . . . . 24
7.4.2. Time-Based Rule (TBR) . . . . . . . . . . . . . . . . 23 7.4.2. Time-Based Rule (TBR) . . . . . . . . . . . . . . . . 25
7.5. Calculations: Expressions, Literals, and Operators . . . 24 7.5. Calculations: Expressions, Literals, and Operators . . . 25
8. System Model . . . . . . . . . . . . . . . . . . . . . . . . 24 8. System Model . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Control and Data Flows . . . . . . . . . . . . . . . . . 24 8.1. Control and Data Flows . . . . . . . . . . . . . . . . . 26
8.2. Control Flow by Role . . . . . . . . . . . . . . . . . . 25 8.2. Control Flow by Role . . . . . . . . . . . . . . . . . . 27
8.2.1. Notation . . . . . . . . . . . . . . . . . . . . . . 25 8.2.1. Notation . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. Serialized Management . . . . . . . . . . . . . . . . 26 8.2.2. Serialized Management . . . . . . . . . . . . . . . . 27
8.2.3. Multiplexed Management . . . . . . . . . . . . . . . 27 8.2.3. Multiplexed Management . . . . . . . . . . . . . . . 28
8.2.4. Data Fusion . . . . . . . . . . . . . . . . . . . . . 29 8.2.4. Data Fusion . . . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The Asynchronous Management Architecture (AMA) provides a novel The Asynchronous Management Architecture (AMA) provides a novel
approach for the configuration, monitoring, and local control of approach for the configuration, monitoring, and local control of
application services on a managed device over a challenged network. application services on a managed device over a challenged network.
The unique properties of a challenged network are as defined in The unique properties of a challenged network are as defined in
[RFC7228] and include cases where an end-to-end transport path may [RFC7228] and include cases where an end-to-end transport path may
not be feasible at any moment in time and delivery delays may prevent not be feasible at any moment in time and delivery delays may prevent
timely communications between a network operator and a managed timely communications between a network operator and a managed
skipping to change at page 4, line 35 skipping to change at page 4, line 35
manager, at times never expecting a reply, and with knowledge that manager, at times never expecting a reply, and with knowledge that
commands and queries may be delivered much later than the initial commands and queries may be delivered much later than the initial
request. request.
More generally, the AMA approach is designed such that it can be More generally, the AMA approach is designed such that it can be
deployed in all environments in which the Delay/Disruption-Tolerant deployed in all environments in which the Delay/Disruption-Tolerant
(DTN) Bundle Protocol (BPv7) [I-D.ietf-dtn-bpbis] may be deployed. (DTN) Bundle Protocol (BPv7) [I-D.ietf-dtn-bpbis] may be deployed.
1.1. Scope 1.1. Scope
This document describes the motivation, service definitions, This document describes the motivation, services, desirable
desirable properties, roles/responsibilities, system model, and properties, roles/responsibilities, logical data model, and system
logical data model that form the AMA. These descriptions comprise a model that form the AMA. These descriptions comprise a concept of
concept of operations for management in challenged networks with operations for management in challenged networks with sufficient
sufficient specificity that implementations conformant with this specificity that implementations conformant with this architecture
architecture will operate successfully in a challenged networking will operate successfully in a challenged networking environment.
environment.
The AMA described herein is strictly a framework for application The AMA described herein is strictly a framework for application
management over a challenged network. The document is not a management over a challenged network. The document is not a
prescriptive standardization of a physical data model or any prescriptive standardization of a physical data model or any
protocol. Instead, it serves as informative guidance to authors and protocol. Instead, it serves as informative guidance to authors and
users of such models and protocols. users of such models and protocols.
The AMA is independent of transport and network layers. It does not, The AMA is independent of transport and network layers. It does not,
for example, require the use of TCP or UDP. Similarly, the AMA does for example, require the use of TCP or UDP. Similarly, the AMA does
not pre-suppose the use of IPv4 or IPv6. not pre-suppose the use of IPv4 or IPv6.
skipping to change at page 5, line 36 skipping to change at page 5, line 36
* Terminology - This section identifies those terms critical to * Terminology - This section identifies those terms critical to
understanding the proper operation of the AMA. Whenever possible, understanding the proper operation of the AMA. Whenever possible,
these terms align in both word selection and meaning with their these terms align in both word selection and meaning with their
analogs from other management protocols. analogs from other management protocols.
* Motivation - This section provides an overall motivation for this * Motivation - This section provides an overall motivation for this
work as providing a novel and useful alternative to other network work as providing a novel and useful alternative to other network
management approaches. management approaches.
* Service Definitions - This section identifies and defines those * Services - This section identifies and defines the services that
management services characteristic of managed and managing devices an AMA will provide to network and mission operators that are
that are unique to operating in a challenged environment. unique to operating in a challenged environment.
* Desirable Properties - This section identifies those properties of * Desirable Properties - This section identifies those properties of
a challenged network management system required to effectively a challenged network management system required to effectively
implement needed services. These properties guide the subsequent implement needed services. These properties guide the subsequent
definition of the system and logical models that comprise the AMA. definition of the system and logical models that comprise the AMA.
* Roles and Responsibilities - This section identifies roles in the * Roles and Responsibilities - This section identifies roles in the
AMA and their associated responsibilities. It provides the AMA and their associated responsibilities. It provides the
context for discussing how management services interact. context for discussing how services are provided by both managers
and agents.
* Logical Data Model - This section describes the kinds of data, * Logical Data Model - This section describes the kinds of data,
procedures, autonomy, and associated hierarchal structure inherent procedures, autonomy, and associated hierarchal structure inherent
to the AMA. to the AMA.
* System Model - This section describes data flows amongst various * System Model - This section describes data flows amongst various
defined AMA roles. These flows capture how the AMA system works defined AMA roles. These flows capture how the AMA system works
to manage devices across a challenged network. to manage devices across a challenged network.
2. Terminology 2. Terminology
skipping to change at page 7, line 16 skipping to change at page 7, line 16
behavior, configuration, or state of an application or protocol behavior, configuration, or state of an application or protocol
being asynchronously managed. Controls may also be used to being asynchronously managed. Controls may also be used to
request data from an agent and define the rules associated with request data from an agent and define the rules associated with
generation and delivery. generation and delivery.
* Literals (LITs) - A literal represents a typed value without a * Literals (LITs) - A literal represents a typed value without a
semantic name. Literals are used in cases where adding a semantic semantic name. Literals are used in cases where adding a semantic
name to a fixed value provides no useful semantic information. name to a fixed value provides no useful semantic information.
For example, the number 4 is a literal value. For example, the number 4 is a literal value.
* Macros (MACs) - A named, ordered collection of Controls and/or * Macros (MACROs) - A named, ordered collection of Controls and/or
other macros. other Macros.
* Manager Role (or Manager) - A role associated with a managing * Manager Role (or Manager) - A role associated with a managing
device responsible for configuring the behavior of, and eventually device responsible for configuring the behavior of, and eventually
receiving information from, AMA Agents. AMA Managers interact receiving information from, AMA Agents. AMA Managers interact
with one or more AMA Agents located on the same device and/or on with one or more AMA Agents located on the same device and/or on
remote devices in the network. remote devices in the network.
* Operator (OP) - The enumeration and specification of a * Operator (OP) - The enumeration and specification of a
mathematical function used to calculate variable values and mathematical function used to calculate variable values and
construct expressions to evaluate AMA Agent state. construct expressions to evaluate AMA Agent state.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
* Report Template (RPTT) - A named, typed, ordered collection of * Report Template (RPTT) - A named, typed, ordered collection of
data types that represent the structure of a report (RPT). This data types that represent the structure of a report (RPT). This
is the schema for a report, generated by an AMA Manager and is the schema for a report, generated by an AMA Manager and
communicated to one or more AMA Agents. communicated to one or more AMA Agents.
* Rule - A unit of autonomous specification that provides a * Rule - A unit of autonomous specification that provides a
stimulus-response relationship between time or state on an AMA stimulus-response relationship between time or state on an AMA
Agent and the actions or operations to be run as a result of that Agent and the actions or operations to be run as a result of that
time or state. A rule might trigger updating a variable, time or state. A rule might trigger updating a variable,
populating a report, executing a control, or initiating the populating a report/table, executing a control, or initiating the
transmission of a report. transmission of a report/table.
* State-Based Rule (SBR) - A state-based rule is any rule in which * State-Based Rule (SBR) - A state-based rule is any rule in which
the rule stimulus is triggered by the calculable internal state of the rule stimulus is triggered by the calculable internal state of
data model associated with the AMA Agent. data model associated with the AMA Agent.
* Synchronous Management - Management that assumes messages will be * Synchronous Management - Management that assumes messages will be
delivered and acted upon in real or near-real-time. Synchronous delivered and acted upon in real or near-real-time. Synchronous
management often involves immediate replies of acknowledgment or management often involves immediate replies of acknowledgment or
error status. Synchronous management is often bound to underlying error status. Synchronous management is often bound to underlying
transport protocols and network protocols to ensure reliability or transport protocols and network protocols to ensure reliability or
skipping to change at page 8, line 41 skipping to change at page 8, line 41
The unique nature of challenged networks requires new network The unique nature of challenged networks requires new network
capabilities to deliver expected network functions. For example, the capabilities to deliver expected network functions. For example, the
unique nature of DTNs required the development of the Bundle Protocol unique nature of DTNs required the development of the Bundle Protocol
for transport functions and the Bundle Protocol Security Protocol for transport functions and the Bundle Protocol Security Protocol
(BPSec) is required to secure bundles in certain types of DTNs. (BPSec) is required to secure bundles in certain types of DTNs.
Similarly, new management capabilities are needed to implement Similarly, new management capabilities are needed to implement
management in challenged environments, such as those defined as DTNs. management in challenged environments, such as those defined as DTNs.
The AMA provides a method of configuring AMA Agents with local, The AMA provides a method of configuring AMA Agents with local,
autonomous management functions to achieve expected behavior when autonomous management functions, such as rules-based execution of
managed devices exist over a challenged network. This architecture procedures and generation of reports, to achieve expected behavior
when managed devices exist over a challenged network. It further
allows for dynamic instantiation and population of Variables and
reports through local operations defined by the manager, as well as
custom formatting of tables and reports to be sent back. This gives
the AMA significant flexibility to operate over challenged networks,
both providing new degrees of freedom over existing configuration
based data models used in synchronous networks and allowing for more
concise formatting over constrained networks. This architecture
makes very few assumptions on the nature of the network and allow for makes very few assumptions on the nature of the network and allow for
continuous operation through periods of connectivity and lack of continuous operation through periods of connectivity and lack of
connectivity. The AMA deviates from synchronous management connectivity. The AMA deviates from synchronous management
approaches because it never requires periods of bi-directional approaches because it never requires periods of bi-directional
connectivity. connectivity, and provides the manager flexibility to describe agent
behavior that was unpredicted at the time of the data model creation.
To understand the unique motivations for the architecture, this To understand the unique motivations for the architecture, this
section discusses motivating characteristics of challenged networks, section discusses motivating characteristics of challenged networks,
current network management approaches, and how they might behave in a current network management approaches, and how they might behave in a
challenged environment. challenged environment.
3.1. Challenged Networks 3.1. Challenged Networks
A challenged network is one that "has serious trouble maintaining A challenged network is one that "has serious trouble maintaining
what an application would today expect of the end-to-end IP model" ( what an application would today expect of the end-to-end IP model"
[RFC7228]). This includes cases where there is never simultaneous ([RFC7228]). This includes cases where there is never simultaneous
end-to-end connectivity, when such connectivity is interrupted at end-to-end connectivity, when such connectivity is interrupted at
planned or unplanned intervals, or when delays exceed those that planned or unplanned intervals, or when delays exceed those that
could be accommodated by IP-based transport. Links in such networks could be accommodated by IP-based transport. Links in such networks
are often unavailable due to attenuations, propagation delays, are often unavailable due to attenuations, propagation delays,
mobility, occultation, and other limitations imposed by energy and mobility, occultation, and other limitations imposed by energy and
mass considerations. mass considerations.
Challenged networks exhibit the following properties that impact the Challenged networks exhibit the following properties that impact the
way in which the function of network management is considered. way in which the function of network management is considered.
* No end-to-end path is guaranteed to exist at any given time * No end-to-end path is guaranteed to exist at any given time
between any two nodes. between any two nodes.
* Round-trip communications between any two nodes within any given * Round-trip communications between any two nodes within any given
time window may be impossible. time window may be impossible.
* Latencies on the order of seconds, hours, or days may be must be * Latencies on the order of seconds, hours, or days must be
tolerated. tolerated.
* Links may be uni-directional. * Links may be uni-directional.
* Bi-directional links may have asymmetric data rates. * Bi-directional links may have asymmetric data rates.
One way in which constrained networks differ from challenged networks One way in which constrained networks differ from challenged networks
is the way in which the topology and, otherwise, roles and is the way in which the topology and, otherwise, roles and
responsibilities of the network may evolve over time. From the time responsibilities of the network may evolve over time. From the time
at which data is generated on a source node to the time at which the at which data is generated on a source node to the time at which the
skipping to change at page 11, line 48 skipping to change at page 12, line 8
asynchronous notifications within the model. asynchronous notifications within the model.
YANG by itself serves no purpose other than to organize data and YANG by itself serves no purpose other than to organize data and
describe the allowed configuration parameters on the managed device. describe the allowed configuration parameters on the managed device.
The Network Configuration Protocol (NETCONF) [RFC6241] and the The Network Configuration Protocol (NETCONF) [RFC6241] and the
RESTCONF protocol [RFC8040] provide the mechanisms to install, RESTCONF protocol [RFC8040] provide the mechanisms to install,
manipulate, and delete the configuration of network devices, using manipulate, and delete the configuration of network devices, using
the YANG modules. NETCONF is a stateful, XML-based protocol that the YANG modules. NETCONF is a stateful, XML-based protocol that
provides the RPC syntax to retrieve, edit, copy, or delete any data provides the RPC syntax to retrieve, edit, copy, or delete any data
nodes or exposed functionality on the server. NETCONF connections nodes or exposed functionality on the server. NETCONF connections
are required to provide authentication, data integreity, are required to provide authentication, data integrity,
confidentiality, and replay protection through secure transport confidentiality, and replay protection through secure transport
protocols such as SSH or TLS. RESTCONF is a stateless RESTful protocols such as SSH or TLS. RESTCONF is a stateless RESTful
protocol based on HTTP that uses JSON encoding to GET, POST, PUT, protocol based on HTTP that uses JSON encoding to GET, POST, PUT,
PATCH, or DELETE data nodes within the YANG modules similar to PATCH, or DELETE data nodes within the YANG modules similar to
NETCONF. RESTCONF, while stateless, still requires secure transport NETCONF. RESTCONF, while stateless, still requires secure transport
such as TLS. Both NETCONF and RESTCONF place no specific functional such as TLS. Both NETCONF and RESTCONF place no specific functional
requirements or constraints on the capabilities of the server, which requirements or constraints on the capabilities of the server, which
makes it a very flexible tool for configuring a homogeneous network makes it a very flexible tool for configuring a homogeneous network
of devices, however they are limting in challenged networks due to of devices, however they are limiting in challenged networks due to
their requirements of underlying transport and dependence on the YANG their requirements of underlying transport and dependence on the YANG
data models. data models.
NETCONF places specific constraints on any underlying transport NETCONF places specific constraints on any underlying transport
protocol: a long-lived, reliable, low-latency sequenced data delivery protocol: a long-lived, reliable, low-latency sequenced data delivery
session. This is a fundamental requirement given the RPC-nature of session. No data is transferred without first establishing this bi-
the operating concept, and it is unsustainable in a challenged directional NETCONF session. RESTCONF relaxes this constraint
network. Aspects of the data modeling associated with NETCONF may however is limited to requesting or configuring individual data
apply to an asynchronous network management system, such that some elements or entire containers within the YANG data model. It is
modeling tools may be used, even if the network control plane cannot. therefore quite verbose and limited by the structure previously
defined in the YANG module and any autonomous behavior depends on
client slide orchestration similar to SNMP.
As previously noted, YANG allows for the definition of RPCs within
the model and notification elements for asynchronous messaging. The
RPCs provide both the definition of input and output parameters
however are strictly allowed in NETCONF and RESTCONF to be sent as
sequential procedures. Even if multiple procedures are sent, the
server is required to execute them and reply in the order they were
received. There is also no flexibility for the state-based execution
of those procedures on the server. The RPCs are executed as soon as
they are received, ultimately limiting the degrees of autonomy of the
server. YANG notifications are quite promising for asynchronous
network management, defined as both subscriptions to YANG
notifications [RFC8639] and YANG PUSH notifications [RFC8641].
Notification containers must first be defined within the YANG module
declaring the containers or data nodes of interest. The events can
be filtered according to XPATH filtering defined in [RFC8639]
Section 6, however generation of events are streamed and generally
limited to the external changing state of a data node. YANG PUSH
allows for both periodic and on-change event notification but
supports no rules-based triggering. While the YANG data model offers
many great features, the features today are simply limiting for the
autonomous behavior required by challenged network management.
YANG is additionally limiting for challenged networks because of its
non-hierarchal schema. While the YANG model flexibility is great for
the management of nodes and applications of any type in an
unchallenged network, it becomes a burden in challenged networks
where concise encoding is necessary. All the data nodes within a
YANG model are referenced by verbose string based path of the module,
sub-module, container, and any data nodes such as lists, leaf-lists,
or leafs. Recent efforts are underway which allow for CBOR encoding
of YANG models [I-D.ietf-core-yang-cbor] and addressing of data nodes
through integer value YANG Schema Item iDentifiers (SIDs)
[I-D.ietf-core-sid], however these lack any formal hierarchal
structure. All mapping of SIDs to YANG modules and data nodes is
preformed manually which limits the portability of models and further
increases the size of any encoding scheme.
3.2.3. Constrained RESTful Network Management 3.2.3. Constrained RESTful Network Management
To talk about COAP and COMI (CoreConf) Due to the advent and ubiquity of the Internet of Things (IoT), the
Constrained Application Protocol (CoAP) [RFC7252] has been recently
developed for communicating with nodes and applications in
constrained networks. CoAP is merely the messaging framework
designed to limit message size and fragmentation, operating over IP
networks. Because constrained networks could experience interruption
similar to those in DTNs, the protocol provides for application layer
store-and-forward as well as proxy delivery of messages, but is bound
to UDP transport. An approach to network management has been
authored that uses CoAP for transport and YANG as the data model, and
is defined as CORECONF [I-D.ietf-core-comi]. This proposed protocol
makes use of the YANG to CBOR encoding including the use of SIDs to
limit message size, however is currently bound to UDP/IP transport of
CoAP and further defines security requirements including DTLS or
OSCORE. This explicit binding to transport and security protocols is
limiting when applied to novel DTN approaches designed for challenged
networks.
3.2.4. Autonomous Network Management 4. Services Provided by an AMA
To talk about work in anima and nmrg This section identifies the services that an AMA would provide for
management of challenged network resources. These services include
configuration, reporting, parameterized control, and administration.
4. Desirable Properties of Challenged Network Management 4.1. Configuration
Configuration services update Agent data associated with managed
applications and protocols. Some configuration data might be defined
in the context of an application or protocol, such that any network
using that application or protocol would understand that data. Other
configuration data may be defined tactically for use in a specific
network deployment and not available to other networks even if they
use the same applications or protocols.
New configurations received by an Agent must be validated to ensure
that they do not conflict with other configurations or would
otherwise prevent the Agent from effectively working with other
Actors in its region. With no guarantee of round-trip data exchange,
Agents cannot rely on remote Managers to correct erroneous or stale
configurations from harming the flow of data through a challenged
network.
Examples of configuration service behavior include the following.
* Creating a new datum as a function of other well-known data:
C = A + B.
* Creating a new report as a unique, ordered collection of known
data:
RPT = {A, B, C}.
* Storing predefined, parameterized responses to potential future
conditions:
IF (X > 3) THEN RUN CMD(PARM).
4.2. Reporting
Reporting services populate report templates with values collected or
computed by an Agent. The resultant reports are sent to one or more
Managers by the Agent. The term "reporting" is used in place of the
term "monitoring", as monitoring implies a timeliness and regularity
that cannot be guaranteed by a challenged network. Reports sent by
an Agent provide best-effort information to receiving Managers.
Since a Manager is not actively "monitoring" an Agent, the Agent must
make its own determination on when to send what Reports based on its
own local time and state information. Agents should produce Reports
of varying fidelity and with varying frequency based on thresholds
and other information set as part of configuration services.
Examples of reporting service behavior include the following.
* Generate Report R1 every hour (time-based production).
* Generate Report R2 when X > 3 (state-based production).
4.3. Autonomous Parameterized Procedure Calls
Similar to an RPC call, some mechanism MUST exist which allows a
procedure to be run on an Agent in order to affect its behavior or
otherwise change its internal state. Since there is no guarantee
that a Manager will be in contact with an Agent at any given time,
the decisions of whether and when a procedure should be run MUST be
made locally and autonomously by the Agent. Two types of automation
triggers are identified in the AMA: triggers based on the internal
state of the Agent and triggers based on an Agent's notion of time.
As such, the autonomous execution of procedures can be viewed as a
stimulus-response system, where the stimulus is the positive
evaluation of a state or time based predicate and the response is the
function to be executed.
The autonomous nature of procedure execution by an Agent implies that
the full suite of information necessary to run a procedure may not be
known by a Manager in advance. To address this situation, a
parameterization mechanism MUST be available so that required data
can be provided at the time of execution on the Agent rather than at
the time of definition/configuration by the Manager.
Autonomous, parameterized procedure calls provide a powerful
mechanism for Managers to "manage" an Agent asynchronously during
periods of no communication by pre-configuring responses to events
that may be encountered by the Agent at a future time.
Examples of potential behavior include the following.
* Updating local routing information based on instantaneous link
analysis.
* Managing storage on the device to enforce quotas.
* Applying or modifying local security policy.
4.4. Administration
Administration services enforce the potentially complex mapping of
configuration, reporting, and control services amongst Agents and
Managers in the network. Fine-grained access controls that specify
which Managers may apply which services to which Agents may be
necessary in networks that either deal with multiple administrative
entities or overlay networks that cross administrative boundaries.
Whitelists, blacklists, key-based infrastructures, or other schemes
may be used for this purpose.
Examples of administration service behavior include the following.
* Agent A1 only Sends reports for Protocol P1 to Manager M1.
* Agent A2 only accepts a configurations for Application Y from
Managers M2 and M3.
* Agent A3 accepts services from any Manager providing the proper
authentication token.
Note that the administrative enforcement of access control is
different from security services provided by the networking stack
carrying such messages.
5. Desirable Properties of an AMA
This section describes those design properties that are desirable This section describes those design properties that are desirable
when defining an architecture that must operate across challenged when defining an architecture that must operate 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 AMA. principles for the AMA.
4.1. Intelligent Push of Information 5.1. Intelligent Push of Information
Pull management mechanisms require that a Manager send a query to an Pull management mechanisms require that a Manager send a query to an
Agent and then wait for the response to that query. This practice Agent and then wait for the response to that query. This practice
implies a control-session between entities and increases the overall implies a control-session between entities and increases the overall
message traffic in the network. Challenged networks cannot guarantee message traffic in the network. Challenged networks cannot guarantee
that the roundtrip data-exchange will occur in a timely fashion. In that the round-trip data-exchange will occur in a timely fashion. In
extreme cases, networks may be comprised of solely uni-directional extreme cases, networks may be comprised of solely uni-directional
links which drastically increases the amount of time needed for a links which drastically increases the amount of time needed for a
roundtrip data exchange. Therefore, pull mechanisms must be avoided round-trip data exchange. Therefore, pull mechanisms must be avoided
in favor of push mechanisms. in favor of push mechanisms.
Push mechanisms, in this context, refer to the ability of Agents to Push mechanisms, in this context, refer to the ability of Agents to
make their own determinations in relation to the information that leverage rule-based criteria to determine when and what information
should be sent to Managers. Such mechanisms do not require round- should be sent to managers. This could be based solely off logic
trip communications as Managers do not request each reporting applied to existing VARs or EDDs, or based off operations applied to
instance; Managers need only request once, in advance, that data elements. Such mechanisms do not require round-trip
information be produced in accordance with a predetermined schedule communications as Managers do not request each reporting instance;
or in response to a predefined state on the Agent. In this way Managers need only request once, in advance, that information be
information is "pushed" from Agents to Managers and the push is produced in accordance with a predetermined schedule or in response
"intelligent" because it is based on some internal evaluation to a predefined state on the Agent. In this way information is
performed by the Agent. "pushed" from Agents to Managers and the push is "intelligent"
because it is based on some internal evaluation performed by the
Agent.
4.2. Minimize Message Size Not Node Processing 5.2. Minimize Message Size Not Node Processing
Protocol designers must balance message size versus message Protocol designers must balance message size versus message
processing time at sending and receiving nodes. Verbose processing time at sending and receiving nodes. Verbose
representations of data simplify node processing whereas compact representations of data simplify node processing whereas compact
representations require additional activities to generate/parse the representations require additional activities to generate/parse the
compacted message. There is no asynchronous management advantage to compacted message. There is no asynchronous management advantage to
minimizing node processing time in a challenged network. However, minimizing node processing time in a challenged network. However,
there is a significant advantage to smaller message sizes in such there is a significant advantage to smaller message sizes in such
networks. Compact messages require smaller periods of viable networks. Compact messages require smaller periods of viable
transmission for communication, incur less re-transmission cost, and transmission for communication, incur less re-transmission cost, and
consume less resources when persistently stored en-route in the consume less resources when persistently stored en-route in the
network. AMPs should minimize PDUs whenever practical, to include network. An Asynchronous Management Protocol (AMP) should minimize
packing and unpacking binary data, variable-length fields, and pre- PDUs whenever practical, to include packing and unpacking binary
configured data definitions. data, variable-length fields, and pre-configured data definitions.
4.3. Absolute Data Identification 5.3. Absolute Data Identification
Elements within the management system must be uniquely identifiable Elements within the management system must be uniquely identifiable
so that they can be individually manipulated. Identification schemes so that they can be individually manipulated. Identification schemes
that are relative to system configuration make data exchange between that are relative to system configuration make data exchange between
Agents and Managers difficult as system configurations may change Agents and Managers difficult as system configurations may change
faster than nodes can communicate. faster than nodes can communicate.
Consider the following common technique for approximating an Consider the following common technique for approximating an
associative array lookup. A manager wishing to do an associative associative array lookup. A manager wishing to do an associative
lookup for some key K1 will (1) query a list of array keys from the lookup for some key K1 will (1) query a list of array keys from the
agent, (2) find the key that matches K1 and infer the index of K1 agent, (2) find the key that matches K1 and infer the index of K1
from the returned key list, and (3) query the discovered index on the from the returned key list, and (3) query the discovered index on the
agent to retrieve the desired data. agent to retrieve the desired data.
Ignoring the inefficiency of two pull requests, this mechanism fails Ignoring the inefficiency of two pull requests, this mechanism fails
when the Agent changes its key-index mapping between the first and when the Agent changes its key-index mapping between the first and
second query. Rather than constructing an artificial mapping from K1 second query. Rather than constructing an artificial mapping from K1
to an index, an AMP must provide an absolute mechanism to lookup the to an index, an AMP must provide an absolute mechanism to lookup the
value K1 without an abstraction between the Agent and Manager. value K1 without an abstraction between the Agent and Manager.
4.4. Custom Data Definition 5.4. Custom Data Definition
Custom definition of new data from existing data (such as through 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. Specifically, an Agent should not be required to transmit possible. Specifically, an Agent should not be required to transmit
a large data set for a Manager that only wishes to calculate a a large data set for a Manager that only wishes to calculate a
smaller, inferred data set. The Agent should calculate the smaller smaller, inferred data set. These new defined data elements could be
data set on its own and transmit that instead. Since the calculated and used both as parameters for local stimulus-response
identification of custom data sets is likely to occur in the context rules-based criteria or simply serve to populate custom reports and
of a specific network deployment, AMPs must provide a mechanism for tables. Since the identification of custom data sets is likely to
their definition. occur in the context of a specific network deployment, AMPs must
provide a mechanism for their definition.
4.5. Autonomous Operation Aggregation of controls and custom formatting of reports and tables
are is equally important. Custom reporting provides the flexibility
allowing the manager to define the desired format of all information
to be sent over the challenged network from the agents, serving to
both save link capacity and increase the value of returned
information. Aggregation of controls allows a manager to specify a
set of controls to execute, specifying both the order and criteria of
execution. This aggregate set of controls can be sent as a single
command rather than a series of sequential operands. In this case it
is additionally possible to use outputs of one command to serve as an
input to the next at the agent.
5.5. Autonomous Operation
AMA network functions must be achievable using only knowledge local AMA network functions must be achievable using only knowledge local
to the Agent. Rather than directly controlling an Agent, a Manager to the Agent. Rather than directly controlling an Agent, a Manager
configures an engine of the Agent to take its own action under the configures an engine of the Agent to take its own action under the
appropriate conditions in accordance with the Agent's notion of local appropriate conditions in accordance with the Agent's notion of local
state and time. state and time.
Such an engine may be used for simple automation of predefined tasks Such an engine may be used for simple automation of predefined tasks
or to support semi-autonomous behavior in determining when to run or to support semi-autonomous behavior in determining when to run
tasks and how to configure or parameterize tasks when they are run. tasks and how to configure or parameterize tasks when they are run.
skipping to change at page 15, line 11 skipping to change at page 19, line 28
of a frequently-out-of-contact Manager to predict the state of an of a frequently-out-of-contact Manager to predict the state of an
Agent with more reliability than cases where Agents implement Agent with more reliability than cases where Agents implement
independent and fully autonomous systems. independent and fully autonomous systems.
* Engine-Based Behavior - Several operational systems are unable to * Engine-Based Behavior - Several operational systems are unable to
deploy "mobile code" based solutions due to network bandwidth, deploy "mobile code" based solutions 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
types of concerns associated with mobile code. types of concerns associated with mobile code.
5. Roles and Responsibilities 6. AMA Roles and Responsibilities
By definition, Agents reside on managed devices and Managers reside By definition, Agents reside on managed devices and Managers reside
on managing devices. This section describes how these roles on managing devices. There is however no pre-supposed architecture
participate in the network management functions outlined in the prior that connects managers and agents and therefore a single device could
section. assume both roles. This section describes the responsibilities
associated with each role and how these roles participate in network
management.
5.1. Agent Responsibilities 6.1. Agent Responsibilities
Application Support Application Support
Agents MUST collect all data, execute all procedures, Agents MUST collect all data, execute all procedures,
populate all reports and run operations required by each populate all reports and run operations required by each
application which the Agent manages. Agents MUST report application which the Agent manages. Agents MUST report
supported applications so that Managers in a network supported applications so that Managers in a network
understands what information is understood by what Agent. understands what information is understood by what Agent.
Local Data Collection Local Data Collection
Agents MUST collect from local firmware (or other on-board Agents MUST collect from local firmware (or other on-board
mechanisms) and report all data defined for the management of mechanisms) and report all data defined for the management of
applications for which they have been configured. applications for which they have been configured.
Autonomous Control Autonomous Control
Agents MUST determine, without Manager intervention, whether Agents MUST determine, as previously prescribed by a manager,
a procedure should be invoked. Agents MAY also invoke whether a procedure should be invoked.
procedures on other devices for which they act as proxy.
User Data Definition User Data Definition
Agents MUST provide mechanisms for operators in the network Agents MUST provide mechanisms for operators in the network
to use configuration services to create customized data to use configuration services to create customized data
definitions in the context of a specific network or network definitions in the context of a specific network or network
use-case. Agents MUST allow for the creation, listing, and use-case. Agents MUST allow for the creation, listing, and
removal of such definitions in accordance with whatever removal of such definitions in accordance with whatever
security models are deployed within the particular network. security models are deployed within the particular network.
Where applicable, Agents MUST verify the validity of these Where applicable, Agents MUST verify the validity of these
skipping to change at page 16, line 17 skipping to change at page 20, line 34
intervention, whether and when to populate and transmit a intervention, whether and when to populate and transmit a
given report targeted to one or more Managers in the network. given report targeted to one or more Managers in the network.
Consolidate Messages Consolidate Messages
Agents SHOULD produce as few messages as possible when Agents SHOULD produce as few messages as possible when
sending information. For example, rather than sending sending information. For example, rather than sending
multiple messages, each with one report to a Manager, an multiple messages, each with one report to a Manager, an
Agent SHOULD prefer to send a single message containing Agent SHOULD prefer to send a single message containing
multiple reports. multiple reports.
Regional Proxy 6.2. Manager Responsibilities
Agents MAY perform any of their responsibilities on behalf of
other network nodes that, themselves, do not have an Agent.
In such a configuration, the Agent acts as a proxy for these
other network nodes.
5.2. Manager Responsibilities
Agent Capabilities Mapping Agent Capabilities Mapping
Managers MUST understand what applications are managed by the Managers MUST understand what applications are managed by the
various Agents with which they communicate. Managers should various Agents with which they communicate. Managers should
not attempt to request, invoke, or refer to application not attempt to request, invoke, or refer to application
information for applications not managed by an Agent. information for applications not managed by an Agent.
Data Collection Data Collection
Managers MUST receive information from Agents by Managers MUST receive information from Agents by
asynchronously configuring the production of reports and then asynchronously configuring the production of reports and then
skipping to change at page 17, line 12 skipping to change at page 21, line 22
parts of the network from which data may be pulled by low- parts of the network from which data may be pulled by low-
latency parts of the network. latency parts of the network.
Data Fusion Data Fusion
Managers MAY support the fusion of data from multiple Agents Managers MAY support the fusion of data from multiple Agents
with the purpose of transmitting fused data results to other with the purpose of transmitting fused data results to other
Managers within the network. Managers MAY receive fused Managers within the network. Managers MAY receive fused
reports from other Managers pursuant to appropriate security reports from other Managers pursuant to appropriate security
and administrative configurations. and administrative configurations.
6. Service Definitions
This section identifies the services that must exist between Managers
and Agents within an AMA. These services include configuration,
reporting, parameterized control, and administration.
6.1. Configuration
Configuration services update Agent data associated with managed
applications and protocols. Some configuration data might be defined
in the context of an application or protocol, such that any network
using that application or protocol would understand that data. Other
configuration data may be defined tactically for use in a specific
network deployment and not available to other networks even if they
use the same applications or protocols.
New configurations received by an Agent must be validated to ensure
that they do not conflict with other configurations or would
otherwise prevent the Agent from effectively working with other
Actors in its region. With no guarantee of round-trip data exchange,
Agents cannot rely on remote Managers to correct erroneous or stale
configurations from harming the flow of data through a challenged
network.
Examples of configuration service behavior include the following.
* Creating a new datum as a function of other well-known data:
C = A + B.
* Creating a new report as a unique, ordered collection of known
data:
RPT = {A, B, C}.
* Storing predefined, parameterized responses to potential future
conditions:
IF (X > 3) THEN RUN CMD(PARM).
6.2. Reporting
Reporting services populate report templates with values collected or
computed by an Agent. The resultant reports are sent to one or more
Managers by the Agent. The term "reporting" is used in place of the
term "monitoring", as monitoring implies a timeliness and regularity
that cannot be guaranteed by a challenged network. Reports sent by
an Agent provide best-effort information to receiving Managers.
Since a Manager is not actively "monitoring" an Agent, the Agent must
make its own determination on when to send what Reports based on its
own local time and state information. Agents should produce Reports
of varying fidelity and with varying frequency based on thresholds
and other information set as part of configuration services.
Examples of reporting service behavior include the following.
* Generate Report R1 every hour (time-based production).
* Generate Report R2 when X > 3 (state-based production).
6.3. Autonomous Parameterized Procedure Calls
Similar to an RPC call, some mechanism MUST exist which allows a
procedure to be run on an Agent in order to affect its behavior or
otherwise change its internal state. Since there is no guarantee
that a Manager will be in contact with an Agent at any given time,
the decisions of whether and when a procedure should be run MUST be
made locally and autonomously by the Agent. Two types of automation
triggers are identified in the AMA: triggers based on the internal
state of the Agent and triggers based on an Agent's notion of time.
As such, the autonomous execution of procedures can be viewed as a
stimulus-response system, where the stimulus is the positive
evaluation of a state or time based predicate and the response is the
function to be executed.
The autonomous nature of procedure execution by an Agent implies that
the full suite of information necessary to run a procedure may not be
known by a Manager in advance. To address this situation, a
parameterization mechanism MUST be available so that required data
can be provided at the time of execution on the Agent rather than at
the time of definition/configuration by the Manager.
Autonomous, parameterized procedure calls provide a powerful
mechanism for Managers to "manage" an Agent asynchronously during
periods of no communication by pre-configuring responses to events
that may be encountered by the Agent at a future time.
Examples of potential behavior include the following.
* Updating local routing information based on instantaneous link
analysis.
* Managing storage on the device to enforce quotas.
* Applying or modifying local security policy.
6.4. Administration
Administration services enforce the potentially complex mapping of
configuration, reporting, and control services amongst Agents and
Managers in the network. Fine-grained access controls that specify
which Managers may apply which services to which Agents may be
necessary in networks that either deal with multiple administrative
entities or overlay networks that cross administrative boundaries.
Whitelists, blacklists, key-based infrastructures, or other schemes
may be used for this purpose.
Examples of administration service behavior include the following.
* Agent A1 only Sends reports for Protocol P1 to Manager M1.
* Agent A2 only accepts a configurations for Application Y from
Managers M2 and M3.
* Agent A3 accepts services from any Manager providing the proper
authentication token.
Note that the administrative enforcement of access control is
different from security services provided by the networking stack
carrying such messages.
7. Logical Data Model 7. Logical Data Model
The AMA logical data model captures the types of information that The AMA logical data model captures the types of information that
should be collected and exchanged to implement necessary roles and should be collected and exchanged to implement necessary roles and
responsibilities. The data model presented in this section does not responsibilities. The data model presented in this section does not
presuppose a specific mapping to a physical data model or encoding presuppose a specific mapping to a physical data model or encoding
technique; it is included to provide a way to logically reason about technique; it is included to provide a way to logically reason about
the types of data that should be exchanged in an asynchronously the types of data that should be exchanged in an asynchronously
managed network. managed network.
skipping to change at page 22, line 26 skipping to change at page 24, line 6
procedure call", CTRLs differ in that they do not provide numeric procedure call", CTRLs differ in that they do not provide numeric
return codes. The concept of a return code when running a procedure return codes. The concept of a return code when running a procedure
implies a synchronous relationship between the caller of the implies a synchronous relationship between the caller of the
procedure and the procedure being called, which is disallowed in an procedure and the procedure being called, which is disallowed in an
asynchronous management system. Instead, CTRLs may create reports asynchronous management system. Instead, CTRLs may create reports
which describe the status and other summarizations of their which describe the status and other summarizations of their
operation, and these reports may be sent to the Manager(s) calling operation, and these reports may be sent to the Manager(s) calling
the CTRL. the CTRL.
Parameters can be provided when running a command from a Manager, Parameters can be provided when running a command from a Manager,
pre-configured as part of an autonomy response on the Agent, or auto- pre-configured as part of a response to a time-based or state-based
generated as needed on the Agent. The success or failure of a rule on the Agent, or auto-generated as needed on the Agent. The
control MAY be inferred by reports generated for that purpose. success or failure of a control MAY be inferred by reports generated
for that purpose.
NOTE: The AMA term control is derived in part from the concept of NOTE: The AMA term control is derived in part from the concept of
Command and Control (C2) where control implies the operational Command and Control (C2) where control implies the operational
instructions that must be undertaken to implement (or maintain) a instructions that must be undertaken to implement (or maintain) a
commanded objective. An asynchronous management function controls an commanded objective. An asynchronous management function controls an
Agent to allow it to fulfill its commanded purpose in a variety of Agent to allow it to fulfill its commanded purpose in a variety of
operational scenarios. For example, attempting to maintain a safe operational scenarios. For example, attempting to maintain a safe
internal thermal environment for a spacecraft is considered "thermal internal thermal environment for a spacecraft is considered "thermal
control" (not "thermal commanding") even though thermal control control" (not "thermal commanding") even though thermal control
involves "commanding" heaters, louvers, radiators, and other involves "commanding" heaters, louvers, radiators, and other
skipping to change at page 23, line 12 skipping to change at page 24, line 36
nesting levels MUST be included in any actual data model or nesting levels MUST be included in any actual data model or
implementation. implementation.
7.4. Autonomy: Time and State-Based Rules 7.4. Autonomy: Time and State-Based Rules
The AMA data model contains EDDs and VARs that capture the state of The AMA data model contains EDDs and VARs that capture the state of
applications on an Agent. The model also contains controls and applications on an Agent. The model also contains controls and
macros to perform actions on an Agent. A mechanism is needed to macros to perform actions on an Agent. A mechanism is needed to
relate these two capabilities: to perform an action on the Agent in relate these two capabilities: to perform an action on the Agent in
response to the state of the Agent. This mechanism in the AMA is the response to the state of the Agent. This mechanism in the AMA is the
"rule" and can be activated based on Agent state (state-based rule) "rule" and can be activated based on Agent internal state (state-
or based on the Agent's notion of relative time (time-based rule). based rule) or based on the Agent's notion of relative time (time-
based rule).
7.4.1. State-Based Rule (SBR) 7.4.1. State-Based Rule (SBR)
State-Based Rules (SBRs) perform actions based on the Agent's State-Based Rules (SBRs) perform actions based on the Agent's
internal state, as identified by EDD and VAR values. An SBR internal state, as identified by EDD and VAR values. An SBR
represents a stimulus-response pairing in the following form: IF represents a stimulus-response pairing in the following form: IF
predicate THEN response The predicate is a logical expression that predicate THEN response The predicate is a logical expression that
evaluates to true if the rule stimulus is present and evaluates to evaluates to true if the rule stimulus is present and evaluates to
false otherwise. The response may be any control or macro known to false otherwise. The response may be any control or macro known to
the Agent. the Agent.
skipping to change at page 28, line 50 skipping to change at page 29, line 50
from multiple Managers. Variable definitions may include an ACL that from multiple Managers. Variable definitions may include an ACL that
describes who may query and otherwise understand these definitions. describes who may query and otherwise understand these definitions.
In (1), Manager A defines V1 only for A while Manager B defines V2 In (1), Manager A defines V1 only for A while Manager B defines V2
only for B. Managers may, then, request the production of Report only for B. Managers may, then, request the production of Report
Entries containing these definitions, as shown in (2). Agents Entries containing these definitions, as shown in (2). Agents
produce different data for different Managers in accordance with produce different data for different Managers in accordance with
configured production rules, as shown in (3). If a Manager requests configured production rules, as shown in (3). If a Manager requests
the production of a custom definition for which the Manager has no the production of a custom definition for which the Manager has no
permissions, a response consistent with the configured logging policy permissions, a response consistent with the configured logging policy
on the Agent should be implemented, as shown in (4). Alternatively, on the Agent should be implemented, as shown in (4). Alternatively,
as shown in (5), a Manager may define custom data with no as shown in (5), a Manager may define custom data with no access
restrictions allowing all other Managers to request and use this restrictions, allowing all other Managers to request and use this
definition. This allows all Managers to request the production of definition. This allows all Managers to request the production of
Report Entries containing this definition, shown in (6) and have all Report Entries containing this definition, shown in (6) and have all
Managers receive this and other data going forward, as shown in (7). Managers receive this and other data going forward, as shown in (7).
8.2.4. Data Fusion 8.2.4. Data Fusion
Data fusion reduces the number and size of messages in the network Data fusion reduces the number and size of messages in the network
which can lead to more efficient utilization of networking resources. which can lead to more efficient utilization of networking resources.
The AMA supports fusion of NM reports by co-locating Agents and The AMA supports fusion of NM reports by co-locating Agents and
Managers on nodes and offloading fusion activities to the Manager. Managers on nodes and offloading fusion activities to the Manager.
skipping to change at page 30, line 37 skipping to change at page 31, line 37
Tolerant Networks: A Systems Engineering Approach", 2010. Tolerant Networks: A Systems Engineering Approach", 2010.
[BIRRANE2] Birrane, E.B., Burleigh, S.B., and V.C. Cerf, "Defining [BIRRANE2] Birrane, E.B., Burleigh, S.B., and V.C. Cerf, "Defining
Tolerance: Impacts of Delay and Disruption when Managing Tolerance: Impacts of Delay and Disruption when Managing
Challenged Networks", 2011. Challenged Networks", 2011.
[BIRRANE3] Birrane, E.B. and H.K. Kruse, "Delay-Tolerant Network [BIRRANE3] Birrane, E.B. and H.K. Kruse, "Delay-Tolerant Network
Management: The Definition and Exchange of Infrastructure Management: The Definition and Exchange of Infrastructure
Information in High Delay Environments", 2011. Information in High Delay Environments", 2011.
[I-D.ietf-core-comi]
Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and
I. Petrov, "CoAP Management Interface (CORECONF)", Work in
Progress, Internet-Draft, draft-ietf-core-comi-11, 17
January 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-comi-11>.
[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Petrov, I., and C. Bormann,
"YANG Schema Item iDentifier (YANG SID)", Work in
Progress, Internet-Draft, draft-ietf-core-sid-16, 24 June
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-
core-sid-16>.
[I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., Pelov, A., and C. Bormann,
"CBOR Encoding of Data Modeled with YANG", Work in
Progress, Internet-Draft, draft-ietf-core-yang-cbor-16, 24
June 2021, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-yang-cbor-16>.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
Version 7", Work in Progress, Internet-Draft, draft-ietf- Protocol Version 7", Work in Progress, Internet-Draft,
dtn-bpbis-31, 25 January 2021, <https://www.ietf.org/ draft-ietf-dtn-bpbis-31, 25 January 2021,
internet-drafts/draft-ietf-dtn-bpbis-31.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpbis-31>.
[I-D.irtf-dtnrg-dtnmp] [I-D.irtf-dtnrg-dtnmp]
Birrane, E. and V. Ramachandran, "Delay Tolerant Network Birrane, E. J. and V. Ramachandran, "Delay Tolerant
Management Protocol", Work in Progress, Internet-Draft, Network Management Protocol", Work in Progress, Internet-
draft-irtf-dtnrg-dtnmp-01, 31 December 2014, Draft, draft-irtf-dtnrg-dtnmp-01, 31 December 2014,
<http://www.ietf.org/internet-drafts/draft-irtf-dtnrg- <https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-
dtnmp-01.txt>. dtnmp-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)", for the Simple Network Management Protocol (SNMP)",
STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
<https://www.rfc-editor.org/info/rfc3416>. <https://www.rfc-editor.org/info/rfc3416>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
<http://www.rfc-editor.org/rfc/rfc4838.txt>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
Authors' Addresses Authors' Addresses
Edward J. Birrane Edward J. Birrane
Johns Hopkins Applied Physics Laboratory Johns Hopkins Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
Emery Annis Emery Annis
Johns Hopkins Applied Physics Laboratory Johns Hopkins Applied Physics Laboratory
 End of changes. 46 change blocks. 
251 lines changed or deleted 359 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/