Delay-Tolerant Networking Research Group E. Birrane
Internet-Draft V. Ramachandran
Intended status: ExperimentalJohns Hopkins University Applied Physics La
Expires: April 04, 2014 October 01, 2013
Delay Tolerant Network Management Protocol
draft-irtf-dtnrg-dtnmp-00
Abstract
This draft describes the Delay/Disruption Tolerant Network Management
Protocol (DTNMP). The DTNMP provides monitoring and configuration
features between managing devices and those managed devices operating
on the far side of high-delay or high-disruption links. The protocol
is designed to minimize the number of transmitted bytes, operate
without sessions or (concurrent) two-way links, and to function
autonomously when there is no timely contact with a network operator.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 04, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Birrane & Ramachandran Expires April 04, 2014 [Page 1]
Internet-Draft DTNMP October 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Technical Notes . . . . . . . . . . . . . . . . . . . . . 4
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Protocol Scope . . . . . . . . . . . . . . . . . . . 4
1.3.2. Specification Scope . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. System Model . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Roles and Responsibilities . . . . . . . . . . . . . . . 8
3.3. Data Flows . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Control Flow by Role . . . . . . . . . . . . . . . . . . 11
3.4.1. Notation . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Serialized Management . . . . . . . . . . . . . . . . 11
3.4.3. Multiplexed Management . . . . . . . . . . . . . . . 12
3.4.4. Data Fusion . . . . . . . . . . . . . . . . . . . . . 14
4. Component Model . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Data Representation . . . . . . . . . . . . . . . . . . . 15
4.1.1. Types . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Categories . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. Data Model . . . . . . . . . . . . . . . . . . . . . 16
4.2. Primitive Types . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Self-Delimiting Numeric Value (SDNV) . . . . . . . . 17
4.2.2. Timestamp (TS) . . . . . . . . . . . . . . . . . . . 17
4.2.3. Data Collections (DC) . . . . . . . . . . . . . . . . 17
4.3. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Special Types . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1. MID Collections (MC) . . . . . . . . . . . . . . . . 21
4.4.2. Expressions (EXPR) . . . . . . . . . . . . . . . . . 21
4.4.3. Predicate (PRED) . . . . . . . . . . . . . . . . . . 22
5. Functional Specification . . . . . . . . . . . . . . . . . . 22
5.1. Message Group Format . . . . . . . . . . . . . . . . . . 22
5.2. Message Format . . . . . . . . . . . . . . . . . . . . . 23
5.3. Administrative Messages (0x00 - 0x07) . . . . . . . . . . 25
5.3.1. Register Agent (0x00) . . . . . . . . . . . . . . . . 25
5.3.2. Status Reporting Policy (0x01) . . . . . . . . . . . 26
5.3.3. Status Message (0x02) . . . . . . . . . . . . . . . . 26
5.4. Definition Messages (0x08 - 0x0F) . . . . . . . . . . . . 27
5.4.1. Define Custom Report (0x08) . . . . . . . . . . . . . 27
5.4.2. Define Computed Data (0x09) . . . . . . . . . . . . . 28
5.4.3. Define Macro (0x0A) . . . . . . . . . . . . . . . . . 28
5.5. Reporting Messages (0x10 - 0x17) . . . . . . . . . . . . 28
Birrane & Ramachandran Expires April 04, 2014 [Page 2]
Internet-Draft DTNMP October 2013
5.5.1. Data List (0x10) . . . . . . . . . . . . . . . . . . 28
5.5.2. Data Definitions (0x11) . . . . . . . . . . . . . . . 29
5.5.3. Data Report (0x12) . . . . . . . . . . . . . . . . . 29
5.5.4. Production Schedule Report (0x13) . . . . . . . . . . 30
5.6. Control Messages (0x18 - 0x1F) - 0xFF) . . . . . . . . . 31
5.6.1. Periodic Production Message (0x18) . . . . . . . . . 31
5.6.2. Predicate Production Message (0x19) . . . . . . . . . 32
5.6.3. Perform Control (0x20) . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Normative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
This RFC presents the Delay/Disruption Tolerant Network Management
Protocol (DTNMP) used to perform application-layer network management
functions over Delay/Disruption Tolerant Networks (DTNs) [RFC4838].
1.1. Overview
A network management protocol defines the messages that implement
management functions amongst managed and managing devices in a
network. Management functions include the definition, production,
and reporting of performance data, the application of administrative
and security policy, and the configuration of behavior based on local
time and state measurements.
DTNs contain nodes whose communication links are characterized by
signal propagation delays and/or transmission disruptions that make
timely data exchange difficult or impossible. Protocols that rely on
timely data exchange, such as those that rely on negotiated sessions
or other synchronized acknowledgment, do not function in the DTN
environment. The Internet approach of network management via closed-
loop, synchronous messaging fits this pattern and, therefore, does
not work when network disruptions increase in frequency and severity.
While no protocol delivers data in the absence of a networking link,
protocols that eliminate or drastically reduce overhead and end-point
coordination require much smaller transmission windows and continue
to function when confronted with large delays and disruptions in the
network.
DTNMP accomplishes the network management function using open-loop,
intelligent-push, asynchronous mechanisms that better scale as link
challenges scale. The protocol is designed to support five desirable
properties:
Intelligent Push of Information
Birrane & Ramachandran Expires April 04, 2014 [Page 3]
Internet-Draft DTNMP October 2013
The intelligent push of information eliminates the need for round-
trip data exchange in the management protocol. This is a
necessary consequence of operating in open-loop systems where
reliable round-trip communication may not exist. DTNMP is
designed to operate even in uni-directional networks.
Small Message Sizes
Smaller messages require smaller periods of viable transmission
for communication, incur less re-transmission cost, and consume
less resources when persistently stored en-route in the network.
DTNMP minimizes the size of a message whenever practical, to
include packing and unpacking binary data, variable-length fields,
and pre-configured data definitions.
Fine-grained, Flexible Data Identification
Fine-grained identification allows data in the system to be
explicitly addressed while flexible data identification allows
users to define their own customized, addressed data collections.
In both cases, the ability to define precisely the data required
removes the need to query and transmit large data sets only to
filter/downselect desired data at a receiving device.
Asynchronous Operation
DTNMP does not rely on session establishment or round-trip data
exchange to perform network management functions. Wherever
possible, the DTNMP is designed to be stateless. Where state is
required, the DTNMP provides mechanisms to support transactions
and graceful degredation when nodes in the network fail to
synchronize on common definitions.
Compatibility with Low-Latency Network Management Protocols
DTNMP adopts an identifier approach compatible with the Managed
Information Base (MIB) format used by Internet management
protocols such as the Simple Network Management Protocol (SNMP),
thus enabling management interfaces between DTNs and other types
of networks.
1.2. Technical Notes
All multi-byte values are assumed to be communicated in network-byte
order. Bit-fields are specified in Little-Endian format with bit
position 0 holding the least-significant bit (LSB). When illustrated
in this manuscript, the LSB appears on the right.
1.3. Scope
1.3.1. Protocol Scope
Birrane & Ramachandran Expires April 04, 2014 [Page 4]
Internet-Draft DTNMP October 2013
The DTNMP provides data monitoring, administration, and configuration
for applications operating above the data link layer of the OSI
networking model. While the DTNMP may be configured to support the
management of network layer protocols (such as the Internet Protocol
and Bundle Protocol) it also uses these protocols stacks to
encapsulate and communicate its own DTNMP messages. It is assumed
that the protocols used to carry DTNMP messages provide addressing,
confidentiality, integrity, security, fragmentation support and other
network/session layer functions.
1.3.2. Specification Scope
This document describes the format of the DTNMP messages exchanged
amongst managing and managed devices in a DTN. This document further
describes the rationale behind key design decisions to the extent
that such a description informs the operational deployment and
configuration of DTNMP implementations. This document does not
address specific data configurations of DTNMP-enabled devices, nor
does it discuss the interface between DTNMP and other management
protocols, such as SNMP.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology
This section identifies those terms critical to understanding the
proper operation of the DTNMP. Whenever possible, these terms align
in both word selection and meaning with their analogs from other
management protocols.
Actor
A software service running on either managed or managing
devices implementing an end-point in the DTNMP. Actors may
implement the "Manager" role, "Agent" role, or both.
Agent Role
A role within the DTNMP, associated with a managed device,
responsible for reporting performance data, enforcing
administrative policies, and accepting/performing actions.
Agents exchange information with DTNMP managers operating
either on the same device or on a remote managing device.
Application Data Model (ADM)
Birrane & Ramachandran Expires April 04, 2014 [Page 5]
Internet-Draft DTNMP October 2013
The set of predefined data definitions, reports, literals,
operations, and controls given to a DTNMP actor to manage a
particular application or protocol. DTNMP actors support
multiple ADMs, one for each application/protocol being
managed.
Atomic Data
Globally unique, managed data definitions, similar to those
defined in a Management Information Base (MIB), whose
definition does not change based on the configuration of a
DTNMP actor. Atomic data comprise the "lingua franca" within
the DTNMP. All messages in the protocol operate either
directly on atomic data or on data derived from atomic data.
Computed Data
Data items that are computed dynamically by a DTNMP actor
from some combination of Atomic Data and other Computed Data.
Controls
Operations that may be undertaken by a DTNMP actor to change
the behavior, configuration, or state of an application
managed by the DTNMP.
Macros
A named, ordered collection of controls.
Managed Item Definition (MID)
A parameterized structure used to uniquely identify all data
and control definitions within the DTNMP. MIDs are a super-
set of Object Identifiers (OIDs) and the mechanism by which
the DTNMP maintains data compatibility with other management
protocols.
Manager
A role within the DTNMP associated with a managing device
responsible for configuring the behavior of, and receiving/
processing/visualizing information from, DTNMP agents. DTNMP
managers also provide gateways to non-DTNMP management
protocols as part of conditioning the data returned from
agents. Managers interact with one or more agents located on
the same device and/or on remote devices in the network.
Report
Birrane & Ramachandran Expires April 04, 2014 [Page 6]
Internet-Draft DTNMP October 2013
A named, ordered collection of data items gathered by one or
more DTNMP agents and provided to one or more DTNMP managers.
Reports may contain atomic data, computed data, and other
reports. Individual data within a report are not named; the
report itself is named to reduce the size of the report
message.
3. System Model
3.1. Overview
DTNMP performs the core network management functions of
configuration, performance reporting, control, and administration, as
follows.
Configuration
The configuration function synchronizes definitions amongst
DTNMP actors in the DTN. Managers and Agents must agree on
what ADMs are supported by what nodes. Further, these Actors
must agree on the definitions of customized information, such
as data production schedules, report definitions, and state-
based autonomous actions.
Performance Reporting
Since DTNMP operates asynchronously, performance *monitoring*
is replaced by performance *reporting*. As there is no
expectation of closed-loop control of a managed device across
a delayed/disrupted link, the best action that a managing
device can undertake is to collect and operate on whatever
data is received by managed devices.
Reporting the performance of a managed device involves the
local collection of reports and the communication of those
reports to appropriate managing devices.
Control
Part of the ADM for a supported application/protocol includes
a list of controls/commands that may be run by a DTNMP actor
based on local time or local state. Controls comprise the
basic autonomy mechanism within the DTNMP.
Administration
The mappings amongst agents and managers within a network may
be complex, especially in networks comprising multiple
administrative domains. The administrative management
function defines what managers may control what agents, for
what types of information.
Birrane & Ramachandran Expires April 04, 2014 [Page 7]
Internet-Draft DTNMP October 2013
3.2. Roles and Responsibilities
By definition, DTNMP agents reside on managed devices and DTNMP
managers reside on managing devices. These roles naturally map to
the transmit and receipt of various DTNMP messages. This section
describes how each of these roles participate in the network
management functions outlined in the prior section.
Agent Responsibilities
Local Data Collection
Agents MUST collect and report the data defined in
all ADMs for which they have been configured for the
local managed device. Agents MAY also collect data
for network nodes that do not have their own DTNMP
agents. In this scenario, the DTNMP agent acts as a
proxy agent.
Autonomous Control
Agents MUST determine, without manager intervention,
whether a configured control should be invoked.
Agents MUST periodically evaluate the conditions
associated with configured controls and invoke those
controls based on local state. Agents MAY also
invoke controls on other devices within a regional,
low-latency network.
Data Conditioning
DTNMP agents MUST accept computed data definitions
that specify how a single data value may be
constructed from the transformation of one or more
other data values in the system, using the expression
syntax specified in this manuscript. Further, agents
MUST produce this data when requested by Managers
with the appropriate security persmissions. Agents
MUST produce the list of computer data definitions
when requested by a Manager. Agents MUST detect when
a computed data definition references other data
definitions that are unknown to the agent and respond
in a way consistent with the logging/error-handling
configuration of the agent.
Report Definition
Agents MUST support the ability to accept and store
definitions for custom report definitions. Agents
MUST conform to the security policies associated with
custom reports when determining if a Manager may
request a report defined by a different Manager in
Birrane & Ramachandran Expires April 04, 2014 [Page 8]
Internet-Draft DTNMP October 2013
the network. Agents MUST provide a listing of custom
report definitions to appropriate managing devices
when requested. Agents MUST detect requests for
custom reports that are not configured on the agent,
or are not appropriate for the requesting Manager,
and respond in a way consistent with the logging/
error-handling configuration of the agent.
Consolidate Messages
Agents SHOULD produce as few messages as possible
when sending information. For example, rather than
sending multiple report messages to a manager, an
agent SHOULD prefer to send a single message
containing multiple reports.
Regional Proxy
Agents MAY perform any of their responsibilities on
behalf of other network nodes that, themselves, do
not have a DTNMP agent. In such a configuration, the
DTNMP agent acts as a proxy agent for these other
network nodes.
Manager Responsibilities
Agent/ADM Mapping
Managers MUST understand what ADMs are supported by
the various agents with which they communicate.
Managers SHOULD NOT attempt to request, invoke, or
refer to ADM information for ADMs unsupported by an
agent.
Data Collection
Managers MUST receive information from agents by
asynchronously configuring the production of data
reports and then waiting for, and collecting,
responses from agents over time. Managers SHOULD
implement internal time-outs to detect conditions
where agent information has not been received within
network-specific timespans.
Custom Definitions
Managers SHOULD provide the ability to define custom
data and report definitions. Any defined custom
definitions MUST be transmitted to appropriate agents
and these definitions MUST be remembered to interpret
the reporting of these custom values from an agent in
the future.
Birrane & Ramachandran Expires April 04, 2014 [Page 9]
Internet-Draft DTNMP October 2013
Data Translation
Managers SHOULD provide some interface to other
network management protocols, such as the SNMP.
Managers MAY accomplish this by accumulating a
repository of push-data from high-latency parts of
the network from which data may be pulled by low-
latency parts of the network.
Data Fusion
Managers MAY support the fusion of data from multiple
agents with the purpose of transmitting fused data
results to other managers within the network.
Managers MAY receive fused reports from other
managers pursuant to appropriate security and
administrative configurations.
3.3. Data Flows
We identify three significant data flows within the DTNMP: control
flows from managers to agents, reports flows from agents to managers,
and fusion reports from managers to other managers. These data flows
are illustrated in Figure 1.
DTNMP Data Flows
+---------+ +------------------------+ +---------+
| Node A | | Node B | | Node C |
| | | | | |
|+-------+| |+-------+ +-------+| |+-------+|
|| ||=====>>|| DTNMP |====>>| DTNMP ||====>>|| ||
|| ||<<=====|| Mgr B |<<====|Agent B||<<====|| ||
|| DTNMP || |+--++---+ +-------+| || DTNMP ||
|| Agent || +---||-------------------+ || Mgr C ||
|| A || || || ||
|| ||<<=========||==========================|| ||
|| ||===========++========================>>|| ||
|+-------+| |+-------+|
+---------+ +---------+
Figure 1
In this data flow, the agent on node A receives configurations from
managers on nodes B and C, and replies with reports back to these
managers. Similarly, the agent on node B interacts with the local
manager on node B and the remote manager on node C. Finally, the
manager on node B may fuse data reports received from agents at nodes
A and B and send these fused reports back to the manager on node C.
Birrane & Ramachandran Expires April 04, 2014 [Page 10]
Internet-Draft DTNMP October 2013
From this figure, we see many-to-many relationships amongst managers,
amongst agents, and between agents and managers. Note that agents
and managers are roles, not necessarily differing software
applications. Node A may represent a single software application
fulfilling only the agent role, whereas node B may have a single
software application fulfilling both the agent and manager roles.
The specifics of how these roles are realized is an implementation
matter.
3.4. Control Flow by Role
This section describes three common configurations of DTNMP agents
and managers and the flow of messages between them. These
configurations involve local and remote management and data fusion.
3.4.1. Notation
The notation outlined in Table 1 describes the types of control
messages exchanged between DTNMP agents and managers.
+----------------+---------------------------------+----------------+
| Term | Definition | Example |
+----------------+---------------------------------+----------------+
| AD# | Atomic data definition, from | AD1 |
| | ADM. | |
| CD# | Custom data definition. | CD1 = AD1 + |
| | | CD0. |
| DEF([ACL], | Define id from expression. | DEF([*], CD1, |
| ID,EXPR) | Allow managers in access | AD1 + AD2) |
| | control list (ACL) to request | |
| | this id. | |
| PROD(P,ID) | Produce ID according to | PROD(1s, AD1) |
| | predicate P. P may be a time | |
| | period (1s) or an expression | |
| | (AD1 > 10). | |
| RPT(ID) | A report identified by ID. | RPT(AD1) |
+----------------+---------------------------------+----------------+
Table 1: Terminology
3.4.2. Serialized Management
This is a nominal configuration of network management where a
managing device interacts with a set of managed devices, with a DTNMP
manager installed on the managing device and a DTNMP agent installed
on each managed device. The control flows for this are outlined in
Figure 2.
Birrane & Ramachandran Expires April 04, 2014 [Page 11]
Internet-Draft DTNMP October 2013
Serialized Management Control Flow
+----------+ +---------+ +---------+
| Manager | | Agent A | | Agent B |
+----+-----+ +----+----+ +----+----+
| | |
|-----PROD(1s, AD1)---->| |(Step 1)
|----------------------------PROD(1s, AD1)--->|
| | |
| | |
|<-------RPT(AD1)-------| |(Step 2)
|<-----------------------------RPT(AD1)-------|
| | |
| | |
|<-------RPT(AD1)-------| |
|<-----------------------------RPT(AD1)-------|
| | |
| | |
|<-------RPT(AD1)-------| |
|<-----------------------------RPT(AD1)-------|
| | |
In a simple network, a manager interacts with multiple agents.
Figure 2
In this figure, the manager configures agents A and B to produce
atomic data AD1 every second in (Step 1). At some point in the
future, upon receiving and configuring this message, agents A and B
then build a report containing AD1 and send those reports back to the
manager in (Step 2).
3.4.3. Multiplexed Management
Networks spanning multiple administrative domains may require
multiple managing devices (for example, one per domain). When a
manager defines custom reports/data to an agent, that definition may
be tagged with an access control list (ACL) to limit what other
managers will be privy to this information. Managers in such
networks SHOULD synchronize with those other managers granted access
to their custom data definitions. When agents generate messages,
they MUST only send messages to managers according to these ACLs, if
present. The control flows in this scenario are outlined in Figure
3.
Multiplexed Management Control Flow
Birrane & Ramachandran Expires April 04, 2014 [Page 12]
Internet-Draft DTNMP October 2013
+-----------+ +-------+ +-----------+
| Manager A | | Agent | | Manager B |
+-----+-----+ +---+---+ +-----+-----+
| | |
|--DEF(A,CD1,AD1*2)--->|<--DEF(B, CD2, AD2*2)-|(Step 1)
| | |
|---PROD(1s, CD1)----->|<---PROD(1s, CD2)-----|(Step 2)
| | |
|<-------RPT(CD1)------| |(Step 3)
| |--------RPT(CD2)----->|
|<-------RPT(CD1)------| |
| |--------RPT(CD2)----->|
| | |
| |<---PROD(1s, CD1)-----|(Step 4)
| | |
| |--ERR(CD1 no perm.)-->|
| | |
|--DEF(*,CD3,AD3*3)--->| |(Step 5)
| | |
|---PROD(1s, CD3)----->| |(Step 6)
| | |
| |<---PROD(1s, CD3)-----|
| | |
|<-------RPT(CD3)------|--------RPT(CD3)----->|(Step 7)
|<-------RPT(CD1)------| |
| |--------RPT(CD2)----->|
|<-------RPT(CD3)------|--------RPT(CD3)----->|
|<-------RPT(CD1)------| |
| |--------RPT(CD2)----->|
Complex networks require multiple managers interfacing with agents.
Figure 3
In more complex networks, managers may choose to define custom
reports and data definitions, and agents may need to accept such
definitions from multiple managers. Custom data definitions may
include an ACL that describes who may query and otherwise understand
the custom definition. In (Step 1), Manager A defines CD1 only for A
while Manager B defines CD2 only for B. Managers may, then, request
the production of reports containing these custom definitions, as
shown in (Step 2). Agents produce different data for different
managers in accordance with configured production rules, as shown in
(Step 3). If a manager requests an operation, such as a production
rule, for a custom data definition for which the manager has no
permissions, a response consistent with the configured logging policy
on the agent should be implemented, as shown in (Step 4).
Alternatively, as shown in (Step 5), a manager may define custom data
Birrane & Ramachandran Expires April 04, 2014 [Page 13]
Internet-Draft DTNMP October 2013
with no restrictions allowing all other managers to request and use
this definition. This allows all managers to request the production
of reports containing this definition, shown in (Step 6) and have all
managers receive this and other data going forward, as shown in (Step
7).
3.4.4. Data Fusion
In many networks, agents do not want to individually transmit their
data to a manager, preferring instead to fuse reporting data with
local nodes prior to transmission. This approach reduces the number
and size of messages in the network and reduces overall transmission
energy expenditure. DTNMP supports fusion of NM reports by co-
locating agents and managers on managed devices and offloading fusion
activities to the manager. This process is illustrated in Figure 4.
Data Fusion Control Flow
+-----------+ +-----------+ +---------+ +---------+
| Manager A | | Manager B | | Agent B | | Agent C |
+---+-------+ +-----+-----+ +----+----+ +----+----+
| | | |
|--DEF(A,CD0,AD1+AD2)->| | |(Step 1)
|--PROD(AD1&AD2, CD0)->| | |
| | | |
| |--PROD(1s,AD1)-->| |(Step 2)
| |-------------------PROD(1s, AD2)->|
| | | |
| |<---RPT(AD1)-----| |(Step 3)
| |<-------------------RPT(AD2)------|
| | | |
|<-----RPT(A,CD0)------| | |(Step 4)
| | | |
Data fusion in DTNMP accours amongst managers in the network.
Figure 4
In this example, Manager A requires the production of a computed data
set, CD0, from node B, as shown in (Step 1). The manager role
understands what data is available from what agents in the subnetwork
local to B, understanding that AD1 is available locally and AD2 is
available remotely. Production messages are produced in (Step 2) and
data collected in (Step 3). This allows the manager at node B to
fuse the collected data reports into CD0 and return it in (Step 4).
While a trivial example, the mechanism of associating fusion with the
manager function rather than the agent function scales with fusion
complexity, though it is important to reiterate that agent and
Birrane & Ramachandran Expires April 04, 2014 [Page 14]
Internet-Draft DTNMP October 2013
manager designations are roles, not individual software components.
There may be a single software application running on node B
implementing both Manager B and Agent B roles.
4. Component Model
This section identifies the components that comprise the data
communicated within the DTNMP, the way in which these components are
named, and those special types associated with DTNMP messages.
4.1. Data Representation
4.1.1. Types
Components within the DTNMP are represented as one of four basic data
types: Data, Controls, Literals, and Operators:
Data Data consist of values collected by an agent and reported to
managers within the DTNMP. This includes definitions from an
ADM, derived data as configured from managers, and reports
which are collections of data elements.
Controls Controls consist of actions that may be invoked on agents
and managers to change behavior in response to some external
event (such as local state changes or time). Controls
include application-specific functions specified as part of
an ADM and macros which are collections of these controls.
Literals Literals are constant numerical values that may be used in
the evaluation of expressions and predicates.
Operator Operators are those mathematical functions that operate on
series of Data and Literals, such as addition, subtraction,
multiplication, and division.
4.1.2. Categories
Components within the DTNMP can be categorized as Atomic, Computed,
or Collection.
Atomic
Atomic components are those components that are directly
implemented by the underlying software/firmware of a network
node. Atomic components may also refer to components whose
definitions may not be changed. Examples of atomic
components are Data, Controls, Literals, and Operators
specified by an ADM. Atomic component identifiers MUST be
unique and SHOULD be managed by a registration authority,
Birrane & Ramachandran Expires April 04, 2014 [Page 15]
Internet-Draft DTNMP October 2013
similar to the mechanisms used to assign Object Identifiers
(OIDs). Atomic components must be understood by both DTNMP
managers and agents in a network.
Computed
Computed components are those components that are not
directly implemented by the underlying software/firmware of a
network node. The definition of a computed component MAY be
dynamically defined by DTNMP managers and communicated to one
or more DTNMP agents in a network. The definition of a
computed component may include other computed components or
other atomic components. The identifier of a computed
component is not guaranteed to be universally unique but
SHOULD be unique within the context of a particular network
or internetwork.
Collection
A collection component is a set of other components (to
include other collection components). DTNMP implementations
MUST prevent circular definitions when implementing
collections that include other collections.
4.1.3. Data Model
Each component of the DTNMP data model can be identified as a
combination of type and category, as illustrated in Table 2. In this
table type/catgory combinations that are unsupported are listed as N/
A. Specifically, DTNMP does not support user-defined controls,
constants, or operations; any value that specifies action on an agent
MUST be pre-configured as part of an ADM.
+------------+------------------+----------+----------+----------+
| | Data | Controls | Literals | Operator |
+------------+------------------+----------+----------+----------+
| Atomic | Measured Value | Control | Constant | Operator |
| Computed | Calculated Value | N/A | N/A | N/A |
| Collection | Report | Macro | N/A | N/A |
+------------+------------------+----------+----------+----------+
Table 2
4.2. Primitive Types
Birrane & Ramachandran Expires April 04, 2014 [Page 16]
Internet-Draft DTNMP October 2013
4.2.1. Self-Delimiting Numeric Value (SDNV)
The data type "SDNV" refers to a Self-Delimiting Numerical Value
(SDNV) described in [RFC6256]. SDNVs are used in the DTNMP to
capture any data items that are expected to be 8 bytes or less in
total length. DTNMP actors MAY reject any SDNV value that is greater
than 8 bytes in length.
4.2.2. Timestamp (TS)
For compatibility with a variety of protocols, the use of UTC time is
selected to represent all time values in the DTNMP. However,
timestamps in DTNMP may represent either absolute or relative time
based on the associated epoch. DTNMP uses September 9th, 2012 as the
timestamp epoch (UTC time 1348025776). Values less than this value
MUST be considered as relative times. Values greater than or equal
to this epoch MUST be considered as absolute times. In all cases,
the DTNMP timestamp is encoded as an SDNV.
4.2.3. Data Collections (DC)
A Data collection is comprised of a value identifiying the number of
bytes in the collection, followed by each byte, as illustrated in
Figure 5. Data collections are used in the DTNMP to capture variable
data sets that are too large to place in an SDNV.
Data Collection
+---------+--------+--------+ +--------+
| # Bytes | BYTE 1 | BYTE 2 | ... | BYTE N |
| [SDNV] | [BYTE] | [BYTE] | | [BYTE] |
+---------+--------+--------+ +--------+
Figure 5
4.3. Naming
All components within the DTNMP are identified using a Managed
Identifier (MID). A MID is a variable-length structure that
encapsulates an Object Identifier (OID) and augments it with
information about the type and category of the component being
identified and, optionally, information about who defined it. The
MID structure, illustrated in Figure 6, is comprised of up to four
fields. In this illustration, each field is named, the type of each
field is given in []'s, and the string "(opt.)" indicates that the
field is optional, pending on the values found in the flags bytes.
Birrane & Ramachandran Expires April 04, 2014 [Page 17]
Internet-Draft DTNMP October 2013
MID format
+--------+--------+--------+--------+
| Flags | Issuer | OID | Tag |
| [BYTE] | [SDNV] |[VARIED]| [SDNV] |
| | (opt.) | | (opt.) |
+--------+--------+--------+--------+
Figure 6
The MID fields are defined as follows.
Flags
Flags are used to describe the type of component identified
by the MID, identify which optional fields in the MID are
present, and the encoding used to capture the component's
OID. The layout of the flag byte is illustrated in Figure 7.
MID Flag Format
+-----+---+---+-----+------+
| OID |TAG|ISS| CAT | TYPE |
+-----+---+---+-----+------+
| 7 6 | 5 | 4 | 3 2 | 1 0 |
+-----+---+---+-----+------+
MSB LSB
Figure 7
MID Type (TYPE)
The type of the component encapsulated by the MID,
enumerated as data (0), control (1), literal (2), or
operator (3).
MID Category (CAT)
The category of the component encapsulated by the
MID, enumerated as atomic (0), computed (1), and
collection (2).
Issuer Present (ISS)
Whether the issuer field is present (1) or not (0)
for this MID. If this flag has a value of 1 then the
issuer field MUST be present in the MID. Otherwise,
the issuer field MUST NOT be present in the MID.
Tag Present (TAG)
Whether the tag field is present (1) or not (0) for
this MID. If this flag has a value of 1 then the tag
Birrane & Ramachandran Expires April 04, 2014 [Page 18]
Internet-Draft DTNMP October 2013
field MUST be present in the MID. Otherwise, the tag
field MUST NOT be present.
OID Type (OID)
Whether the contained OID field represents an full
OID (0), a parameterized OID (1), a compressed full
OID (2), or a compressed, parameterized OID (3).
For example, a MID flag byte of 0x00 indicates an atomic data
value with no issuer or tag field encapsulating a full OID.
A MID flag byte of 0x94 indicates a computed data value with
an issuer field, but no tag field encapsulating a compressed
OID.
Issuer
This is a binary identifier representing a predetermined
issuer name. The DTNMP protocol does not parse or validate
this identifier, using it only as a distinguishing bit
pattern to assure MID uniqueness. This value, for example,
may come from a global registry of organizations, an issuing
node address, or some other network-unique marking.
OID
The core of a MID is its encapsulated Object Identifier
(OID). Aside from the flag byte, this is the only other
mandatory element within a MID. The DTNMP defines four types
of OID references for this part of the MID structure: Full
OIDs, Parameterized OIDs, Compressed Full OIDs, and
Compressed Parameterized OIDs.
Full OID
This is a binary representation of the full OID
associated with the named value. The OID is encoded
using a modified form of the ASN.1 Basic Encoding
Rules (BER) for Object Identifiers (type value of
0x06). In the standard ASN.1 encoding, four octet
sets are defined: identifier octets, length octets,
contents octets, and end-of-contents octets. A DTNMP
Full OID does not use the identifier, length, or end-
of-contents octets. Instead, a DTNMP Full OID is
comprised of two fields: the length in bytes of the
encoded OID captured in an SDNV followed by the OID
contents octets, as illustrated in Figure 8.
Full OID Format
Birrane & Ramachandran Expires April 04, 2014 [Page 19]
Internet-Draft DTNMP October 2013
+------------+--------------------+
| OID Length | OID Content Octets |
| [SDNV] | [ASN.1 BER] |
+------------+--------------------+
Figure 8
Parameterized OID
The parameterized OID is represented as the non-
parameterized portions of the OID followed by one or
more parameters. Parameterized OIDs are used to
templatize the specification of data items and
otherwise provide parameters to controls without
requiring potentially unmanagable growth of a Full
OID namespace. The format of a parameterized OID is
given in Figure 9.
Parameterized OID Format
+----------+---------+--------+ +--------+
| Base OID | # Parms | Parm 1 | ... | Parm N |
| [VAR] | [SDNV] | [DC] | | [DC] |
+----------+---------+--------+ +--------+
Figure 9
Compressed Full OID
Since many related OIDs share a common and lengthy
hierarchy there is opportunity for significant
message size savings by defining a shorthand for
commonly-used portions of the OID tree. A partial
OID is a tuple consisting of a nickname for a pre-
defined portion of the OID tree (as an SDNV),
followed by a relative OID.
Compressed Parameterized OID
A compressed, parameterized OID is similar to a
compressed OID. In this instance, the tuple
contained in this field is the nickname for the pre-
defined portion of the OID tree (as an SDNV) followed
by a parameterized OID whose hierarchy begins at the
place identified by the nickname.
Tag
A value used to disambiguate multiple MIDs with the same OID/
Issuer combination. The definition of the tag is left to the
discretion of the MID issuer. Proper name objects do not
require a tag as their OIDs are guaranteed to be globally
Birrane & Ramachandran Expires April 04, 2014 [Page 20]
Internet-Draft DTNMP October 2013
unique. Options for tag values include an issuer-known
version number or a hashing of the data associated with a
non-proper-name MIDs. The tag field MUST NOT be present for
the atomic category.
4.4. Special Types
In addition to the primitive data types already mentioned, the
following special data types are also defined.
4.4.1. MID Collections (MC)
A MID collection is comprised of a value identifiying the number of
MIDs in the collection, followed by each MID, as illustrated in
Figure 10.
MID Collection
+--------+-------+ +-------+
| # MIDs | MID 1 | ... | MID N |
| [SDNV] | [MID] | | [MID] |
+--------+-------+ +-------+
Figure 10
4.4.2. Expressions (EXPR)
Expressions apply operations to data and literal values to generate
new data values. The expression type in DTNMP is a collection of
MIDs that represent a postfix notation stack of Data, Literal, and
Operation types. For example, the infix expression A * (B * C) is
represented as the sequence A B C * *. The format of an expression is
illustrated in Figure 11.
Expression Format
+----------+------------+
| Priority | Expression |
| [SDNV] | [MC] |
+----------+------------+
Figure 11
Priority
The priority of this expression relative to any other
expression configured on the DTNMP actor. Priorities are
used when one expression MUST be evaluated before some other
expression is evaluated. This field represents an unsigned
Birrane & Ramachandran Expires April 04, 2014 [Page 21]
Internet-Draft DTNMP October 2013
integer value with larger values indicating higher priority.
Unless otherwise specified, a default priority value of 0
SHALL be used for any defined expression.
Expression
An expression is represented in the DTNMP as a MID
collection, where each MID in the ordered collection
represents the data, literals, and operations that comprise
the expression.
4.4.3. Predicate (PRED)
Predicates are expressions whose values are interpretted as a
Boolean. The value of zero MUST be considered "false" and all other
values MUST be considered "true". Similar to an expression, a
predicate is represented as a MID collection.
5. Functional Specification
This section describes the format of the messages that comprise the
DTNMP protocol. When discussing the format/types of data that
comprise message fields, the following conventions are used.
+-----------+---------------------------------+
| Type Name | Description |
+-----------+---------------------------------+
| BYTE | Unsigned, 8-bit byte. |
| DC | Data Collection |
| EXPR | Expression |
| MC | MID Collection |
| MID | Managed Identifier |
| PRED | Predicate |
| SDNV | Self-Delimiting Numerical Value |
| TS | Timestamp |
| VAR | Variable field. |
+-----------+---------------------------------+
5.1. Message Group Format
Individual messages within the DTNMP are combined into a single group
for communication with another DTNMP actor. Messages within a group
MUST be received and applied as an atomic unit. The format of a
message group is illustrated in Figure 12. These message groups are
assumed communicated amongst agents and managers as the payloads of
encapsulating protocols, such as the Bundle Protocol or Internet
Protocol, which MAY provide additional security and data integrity
features.
Birrane & Ramachandran Expires April 04, 2014 [Page 22]
Internet-Draft DTNMP October 2013
DTNMP Message Group Format
+--------+-----------+-----------+ +-----------+
| # Msgs | Timestamp | Message 1 | ... | Message N |
| [SDNV] | [TS] | [VAR] | | [VAR] |
+--------+-----------+-----------+ +-----------+
Figure 12
# Msgs
The number of messages that are together in this message
group.
Timestamp
The creation time for this messaging group. This timestamp
MUST be an absolute time. Individual messages may have their
own creation timestamps based on their type, but the group
timestamp also serves as the default creation timestamp for
every message in the group.
Message N
The Nth message in the group.
5.2. Message Format
Each message identified in the DTNMP specification adheres to a
common message format, illustrated in Figure 13, consisting of a
message header, a message body, and an optional trailer.
DTNMP Message Format
+--------+-------+---------+
| Header | Body | Trailer |
| [BYTE] | [VAR] | [VAR] |
| | | (opt.) |
+--------+-------+---------+
Figure 13
Birrane & Ramachandran Expires April 04, 2014 [Page 23]
Internet-Draft DTNMP October 2013
+-----------------+-------+-------+
| Message Context | Bit 0 | Bit 1 |
+-----------------+-------+-------+
| Administrative | 0 | 0 |
| Definition | 0 | 1 |
| Reporting | 1 | 0 |
| Control | 1 | 1 |
+-----------------+-------+-------+
Table 3: Message Type Allocations
Header
The message header byte is shown in Figure 14. The header
identifies a message context and opcode as well as flags that
control whether a report should be generated on message
success (Ack) and whether a report should be generated on
message failure (Nack).
DTNMP Common Message Header
+--------+----+---+---------+-------+
|ACL Used|Nack|Ack| Context |Opcode |
+--------+----+---+---------+-------+
| 7 | 6 | 5 | 4 3 | 2 1 0 |
+--------+----+---+---------+-------+
MSB LSB
Figure 14
Opcode
The opcode field identifies the opcode of the
message, within the associated message context.
Context
The context field segments messages into one of four
logical groupings, as listed in Table 3.
ACK Flag
The ACK flag describes whether successfull
application of the message must generate an
ackowledgement back to the message sender. If this
flag is set (1) then the receiving actor MUST
generate a report communicating this status.
Otherwise, the actor MAY generate such a report based
on other criteria.
NACK Flag
Birrane & Ramachandran Expires April 04, 2014 [Page 24]
Internet-Draft DTNMP October 2013
The NACK flag describes whether a failure applying
the message must generate an error notice back to the
message sender. If this flag is set (1) then the
receiving actor MUST generate a report communicating
this status. Otherwise, the actor MAY generate such
a report based on other criteria.
ACL Used Flag
The ACL used flag indicates whether the message has a
trailer associated with it that specifies the list of
DTNMP actors that may participate in the actions or
definitions associated with the message. This area
is still under development.
Body
The message body contains the information associated with the
given message.
Trailer
An OPTIONAL access control list (ACL) may be appended as a
trailer to a message. When present, the ACL for a message
identifiers the agents and managers that can be affected by
the definitions and actions contained within the message.
The explicit impact of an ACL is described in the context of
each message below. When an ACL trailer is not present, the
message results may be visible to any DTNMP actor in the
network, pursuant to other security protocol implementations.
5.3. Administrative Messages (0x00 - 0x07)
Administrative messages configure the exchange of information amongst
agents and managers in the DTNMP. Additionally, they are used to
report on the operation and state of the agent and manager.
5.3.1. Register Agent (0x00)
The Register Agent message is used to inform a DTNMP manager of the
presence of another agent in the network.
+----------+
| Agent ID |
| [SDNV] |
+----------+
Figure 15: Register Agent Message Body
Agent ID
Birrane & Ramachandran Expires April 04, 2014 [Page 25]
Internet-Draft DTNMP October 2013
The Agent ID MUST represent the unique address of the agent
in whatever protocol is used to communicate with the agent.
For example, when DTNMP is run over Bundle Protocol, the
Agent ID should be the Endpoint Identifier (EID) of the agent
being added.
5.3.2. Status Reporting Policy (0x01)
Agents and managers in the network may periodically emit logging
messages based on protocol-level events. The logging policy
configures each DTNMP actor to produce or suppress messages in the
network.
+--------+
| MASK |
| [BYTE] |
+--------+
Figure 16: Reporting Policy Message Body
Mask
This bitmask identifies which types of administrative log
messages should be produced by the DTNMP actor. If a bit in
the mask is set, the log message associated with the bit MUST
be produced by the actor.
+----------+-------+-------+-------+-------+
| Reserved | Log | Error | Warn | Alert |
+----------+-------+-------+-------+-------+
| 7 6 5 4 | 3 | 2 | 1 | 0 |
+----------+-------+-------+-------+-------+
MSB LSB
Figure 17
5.3.3. Status Message (0x02)
Status messages are sent in response to local alerts, warnings, and
errors that occur at a DTNMP actor. The messages may include a body
field, the presence and format of which is indicated by the status
code.
+------+------+------------+
| Code | Time | Generators |
|[MID] | [TS] | [MC] |
+------+------+------------+
Figure 18
Birrane & Ramachandran Expires April 04, 2014 [Page 26]
Internet-Draft DTNMP October 2013
Code
This field is a literal data type identifying the type of
status being communicated. Status codes are defined as
constants within the ADMs for various protocols and
applications, to include those status codes defined in a
DTNMP ADM.
Time
The timestamp identifying when the status message was
generated. This single timestamp holds for all status
messages in the message.
Generators
The collection of MIDs that caused the generation of the
error code. For example, if the error code specifies an
unknown MID encountered while processing a computed data
definition, then the generator could be the MID identifying
the computed data element.
5.4. Definition Messages (0x08 - 0x0F)
Definition messages establish new identifiers on DTNMP actors that
define new information not already pre-configured as part of
supported ADMs. These definitions include computed data, report
definitions, and macros.
5.4.1. Define Custom Report (0x08)
A custom report assigns a single MID value to represent an ordered
collection of other MID values, with some administrative information
that identifies what other nodes in the network may request and
process this report.
Custom Report Definition
+-----------+------------+
| Report ID | Contents |
| [MID] | [MC] |
+-----------+------------+
Figure 19
Report ID
The MID value identifying the custom report.
Contents
The contents of a report defintion as the ordered collection
of MIDs that comprise the report.
Birrane & Ramachandran Expires April 04, 2014 [Page 27]
Internet-Draft DTNMP October 2013
5.4.2. Define Computed Data (0x09)
A computed data item uses an expression to assign a data value.
Computed Data Definition
+--------+------------+
| New ID | Expression |
| [MID] | [EXPR] |
+--------+------------+
Figure 20
New ID
The MID value identifying the computed data object.
Expression
The expression used to calculate the value of this data item.
5.4.3. Define Macro (0x0A)
A macro is a series of controls that should be run in sequence.
Macro Definition
+--------+------------+
| New ID | Controls |
| [MID] | [MC] |
+--------+------------+
Figure 21
New ID
The MID value identifying the macro.
Controls
The series of controls that are run sequentially as part of
the macro.
5.5. Reporting Messages (0x10 - 0x17)
Reporting messages are those message generated by DTNMP agents
representing state on a managed device.
5.5.1. Data List (0x10)
This message lists one or more configured data items on the producing
DTNMP actor for which the requesting actor has access permissions.
Birrane & Ramachandran Expires April 04, 2014 [Page 28]
Internet-Draft DTNMP October 2013
+---------------+
| Configured ID |
| [MC] |
+---------------+
Figure 22
Configured ID
The list of MIDs representing computed data defined on the
actor for which the requesting actor has access permissions.
The individual MIDs identify the associated types of data.
5.5.2. Data Definitions (0x11)
This message contains a list of one or more configured item
definitions on the producing DTNMP actor and accessible to the
requesting actor.
+--------+------+----------+ +------+----------+
| # Defs | ID 1 | Def 1 | ... | ID N | Def N |
| [SDNV] |[MID] | [MC] | |[MID] | [MC] |
+--------+------+----------+ +------+----------+
Figure 23
# Definitions
The number of definitions included in this report.
ID N
The MID identifier of the Nth definition in the message. The
MID is used to contain the data type.
Definition N
The definition of the Nth item. For computed data this is an
expression. For macros, this is a MID list of controls. For
reports, this is a MID list of data and other reports.
5.5.3. Data Report (0x12)
Data reports include a listing of one or more data items collected
from a managed device. These reports may include atomic data,
computed data, or any report definition known to the generating
device. Each message is a concatenation of ID/Data definitions with
the overall message length assumed to be captured in the underlying
transport container.
+------+------+-----+------+-------+ +-----+------+-------+
| Time | Num |ID 1 |Size 1|Data 1 | |ID N |Size N|Data N |
Birrane & Ramachandran Expires April 04, 2014 [Page 29]
Internet-Draft DTNMP October 2013
| [TS] |[SDNV]|[MID]|[SDNV]|[BYTES]|...|[MID]|[SDNV]|[BYTES]|
+------+------+-----+------+-------+ +-----+------+-------+
Figure 24
Time
The time at which the report was generated by the DTNMP
actor.
Num
The number of reports in the data report message.
ID N
The MID identifying the Nth report.
Size N
The size of the Nth report.
Data N
The contents of the Nth report.
5.5.4. Production Schedule Report (0x13)
This message contains a list of all production rules configured on
the DTNMP actor that can be accessed by the querying actor.
+---------+--------+ +--------+
| # Rules | Rule 1 | ... | Rule N |
| [SDNV] | [VAR] | | [VAR] |
+---------+--------+ +--------+
Figure 25
# Rules
The number of production rules included in this report.
Rule N
The Nth rule report in the list. A rule report is as
follows.
+-------+-------+-----------+--------+---------+
| Type | Start | Condition | Count | Results |
| [BYTE]| [TS] | [PRED/TS] | [SDNV] | [MC] |
+-------+-------+-----------+--------+---------+
Figure 26
Type
Birrane & Ramachandran Expires April 04, 2014 [Page 30]
Internet-Draft DTNMP October 2013
The type of rule being reported. Currently a Time
Rule (0) or a Predicate Rule (1)
Start
The start time for the production rule. If a
relative time, then this is interpretted as relative
to message receipt.
Condition
The condition which, when true, causes the report to
be produced. If a Time Rule then this is
interpretted as a period measured in seconds. If a
Predicate Rule, then this is interpretted an a
predicate.
Count
The number of times the rule can fire before being
disabled.
Results
The collection of MIDs produced by this rule.
5.6. Control Messages (0x18 - 0x1F) - 0xFF)
Control messages cause pre-configured, vetted commands on the DTNMP
agents to be issued.
5.6.1. Periodic Production Message (0x18)
The periodic production message instructs an agent to produce a set
of MID values periodically over time. MID values may represent any
type of data value, including atomic data, computed data, or reports.
Periodic Production Message Body
+--------+------------+--------+---------+
| Start | Period (s) | Count | Results |
| [TS] | [SDNV] | [SDNV] | [MC] |
+--------+------------+--------+---------+
Figure 27
Start
The time at which the production should commence.
Period
The number of seconds to wait between report message
generation.
Birrane & Ramachandran Expires April 04, 2014 [Page 31]
Internet-Draft DTNMP October 2013
Count
The number of reports to be generated by this configuration.
The special value of 0 indicates production should continue
indefinitely.
Results
The collection of MIDs to be included in the report.
5.6.2. Predicate Production Message (0x19)
The predicate production message instructs an agent to produce a set
of MID values whenever some condition is true on the agent.
Predicate Production Message
+-------+-----------+--------+---------+
| Start | Predicate | Count | Results |
| [TS] | [PRED] | [SDNV] | [MC] |
+-------+-----------+--------+---------+
Figure 28
Start
The time at which the production should commence.
Predicate
The predicate that must evaluate to generate this report.
Count
The number of reports to be generated by this configuration.
The special value of 0 indicates production should continue
indefinitely.
Results
The collection of MIDs to be included in the report.
5.6.3. Perform Control (0x20)
The perform control method causes the receiving DTNMP actor to apply
one or more pre-configured controls.
Birrane & Ramachandran Expires April 04, 2014 [Page 32]
Internet-Draft DTNMP October 2013
Predicate Production Message
+-------+-----------+
| Start | Controls |
| [TS] | [MC] |
+-------+-----------+
Figure 29
Start
The time at which the control should be run.
Controls
The collection of controls to be applied by the DTNMP actor.
6. IANA Considerations
At this time, this protocol has no fields registered by IANA.
7. Security Considerations
Transport security is handled by the transport layer, for example the
Bundle Security Protocol [RFC6257] when using the Bundle Protocol
[RFC5050].
Finer grain application security is done via ACLs which are defined
via configuration messages and implementation specific.
8. Normative References
[DTNM] Birrane, E. and H. Kruse, "DTN Network management: The
Definition and Exchange of Infrastructure Information in
High Delay Environments", .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
Values in Protocols", RFC 6256, May 2011.
Birrane & Ramachandran Expires April 04, 2014 [Page 33]
Internet-Draft DTNMP October 2013
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257, May
2011.
[tolerance]
Birrane, E., Burleigh, S., and V. Cerf, "Defining
Tolerance: Impacts of Delay and Didruption when Managing
Challenged Networks", 2001.
Authors' Addresses
Edward J. Birrane
Johns Hopkins University Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu
Vignesh Ramachandran
Johns Hopkins University Applied Physics Laboratory
Email: Vinny.Ramachandran@jhuapl.edu
Birrane & Ramachandran Expires April 04, 2014 [Page 34]
