One document matched: draft-irtf-dtnrg-dtnmp-01.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC6256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6256.xml">
<!ENTITY RFC4838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">
<!ENTITY RFC6257 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6257.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdep"4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-dtnmp-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DTNMP">Delay Tolerant Network Management Protocol</title>
<author fullname="Edward J. Birrane" initials="E.B." surname="Birrane">
<organization>Johns Hopkins Applied Physics
Laboratory</organization>
<address>
<email>Edward.Birrane@jhuapl.edu</email>
</address>
</author>
<author fullname="Vignesh Ramachandran" initials="V.R." surname="Ramachandran">
<organization>Johns Hopkins Applied Physics
Laboratory</organization>
<address>
<email>Vinny.Ramachandran@jhuapl.edu</email>
</address>
</author>
<date year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Delay-Tolerant Networking Research Group</workgroup>
<keyword>DTN</keyword>
<keyword>Network Management</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This draft describes the Delay/Disruption Tolerant Network Management Protocol
(DTNMP). The DTNMP provides monitoring and configuration services
between managing devices and managed devices, some of which may operate on the far
side of high-delay or high-disruption links. The protocol is designed to
minimize the number of transmitted bytes, to operate without sessions or
(concurrent) two-way links, and to function autonomously when there is no
timely contact with a network operator. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>This document presents the Delay/Disruption Tolerant Network Management Protocol
(DTNMP) providing application-layer network management services over links
where propagation delays or link disruptions prevent timely communications
between a network operator and a managed device.<xref target="RFC4838" pageno="false" format="default" />. </t>
<section title="Overview" toc="default">
<t>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.</t>
<t>DTNs contain nodes whose communication links are characterized by
signal propagation delays and/or transmission disruptions that make
timely data exchange difficult or impossible. Management 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. For example, the Internet approach of network
management via closed-loop, synchronous messaging 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 smaller transmission
windows and continue to function when confronted with scaling delays and
disruptions in the network.</t>
<t>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:
<list style="hanging"><t hangText="Intelligent Push of Information"><vspace blankLines="0" /> 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.</t><t hangText="Small Message Sizes"><vspace blankLines="0" /> 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.</t><t hangText="Fine-grained, Flexible Data Identification"><vspace blankLines="0" />
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.</t><t hangText="Asynchronous Operation"><vspace blankLines="0" /> 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.
</t><t hangText="Compatibility with Low-Latency Network Management Protocols"><vspace blankLines="0" />
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.</t></list></t>
</section>
<section title="Technical Notes" toc="default">
<t>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. </t>
</section>
<section title="Scope" toc="default">
<section title="Protocol Scope" toc="default">
<t> 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.
</t>
<t>It is assumed that the protocols used to carry DTNMP messages provide
addressing, confidentiality, integrity, security, fragmentation support
and other network/session layer functions. Therefore, these items are not
discussed in the scope of this document.
</t>
</section>
<section title="Specification Scope" toc="default">
<t>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. </t>
</section>
</section>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119" pageno="false" format="default">RFC 2119</xref>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>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. <list hangIndent="8" style="hanging"><t hangText="Actor"><vspace blankLines="0" /> 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.
</t><t hangText="Agent Role"><vspace blankLines="0" /> 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.</t><t hangText="Application Data Model (ADM)"><vspace blankLines="0" /> 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.
</t><t hangText="Atomic Data"><vspace blankLines="0" /> 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.</t><t hangText="Computed Data"><vspace blankLines="0" /> Data items that are computed
dynamically by a DTNMP actor from some
combination of Atomic Data and other Computed Data.</t><t hangText="Controls"><vspace blankLines="0" /> Operations that may be undertaken
by a DTNMP actor to change the behavior, configuration, or state of
an application managed by the DTNMP.</t><t hangText="Macros"><vspace blankLines="0" /> A named, ordered collection of
controls.</t><t hangText="Managed Item Definition (MID)"><vspace blankLines="0" /> 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.</t><t hangText="Manager"><vspace blankLines="0" /> 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.</t><t hangText="Report"><vspace blankLines="0" /> 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.</t></list></t>
</section>
<section title="System Model" toc="default">
<section title="Overview" toc="default">
<t>DTNMP performs the core network management functions of
configuration, performance reporting, control, and administration, as
follows. <list hangIndent="8" style="hanging"><t hangText="Configuration"><vspace blankLines="0" /> 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. </t><t hangText="Performance Reporting"><vspace blankLines="0" /> 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. <vspace blankLines="0" /> Reporting the performance
of a managed device involves the local collection of reports and
the communication of those reports to appropriate managing
devices. </t><t hangText="Control"><vspace blankLines="0" /> 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. </t><t hangText="Administration"><vspace blankLines="0" /> 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.</t></list></t>
</section>
<section title="Roles and Responsibilities" toc="default">
<t>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. <list hangIndent="8" style="hanging"><t hangText="Agent Responsibilities"><list hangIndent="8" style="hanging"><t hangText="Local Data Collection"><vspace blankLines="0" />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.</t><t hangText="Autonomous Control"><vspace blankLines="0" />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.</t><t hangText="Data Conditioning"><vspace blankLines="0" />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.</t><t hangText="Report Definition"><vspace blankLines="0" /> 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 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.</t><t hangText="Consolidate Messages"><vspace blankLines="0" />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.</t><t hangText="Regional Proxy"><vspace blankLines="0" />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.</t></list></t><t hangText="Manager Responsibilities"><list hangIndent="8" style="hanging"><t hangText="Agent/ADM Mapping"><vspace blankLines="0" />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.</t><t hangText="Data Collection"><vspace blankLines="0" />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.</t><t hangText="Custom Definitions"><vspace blankLines="0" /> 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.</t><t hangText="Data Translation"><vspace blankLines="0" /> 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.</t><t hangText="Data Fusion"><vspace blankLines="0" /> 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.</t></list></t></list></t>
</section>
<section title="Data Flows" toc="default">
<t>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 <xref target="system_overview" pageno="false" format="default" />.</t>
<figure align="center" anchor="system_overview" title="" suppress-title="false" alt="" width="" height="">
<preamble>DTNMP Data Flows</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------+ +------------------------+ +---------+
| Node A | | Node B | | Node C |
| | | | | |
|+-------+| |+-------+ +-------+| |+-------+|
|| ||=====>>|| DTNMP |====>>| DTNMP ||====>>|| ||
|| ||<<=====|| Mgr B |<<====|Agent B||<<====|| ||
|| DTNMP || |+--++---+ +-------+| || DTNMP ||
|| Agent || +---||-------------------+ || Mgr C ||
|| A || || || ||
|| ||<<=========||==========================|| ||
|| ||===========++========================>>|| ||
|+-------+| |+-------+|
+---------+ +---------+
</artwork>
</figure>
<t>
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.
<vspace blankLines="0" />
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.
</t>
</section>
<section title="Control Flow by Role" toc="default">
<t>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.</t>
<section title="Notation" toc="default">
<t> The notation outlined in <xref target="ctrl_macros" pageno="false" format="default" />
describes the types of control messages exchanged
between DTNMP agents and managers.</t>
<texttable anchor="ctrl_macros" title="Terminology" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Term</ttcol>
<ttcol align="center" width="80%">Definition</ttcol>
<ttcol align="center" width="20%">Example</ttcol>
<c>AD#</c>
<c>Atomic data definition, from ADM.</c>
<c>AD1</c>
<c>CD#</c>
<c>Custom data definition.</c>
<c>CD1 = AD1 + CD0.</c>
<c>DEF([ACL], ID,EXPR)</c>
<c>Define id from expression. Allow managers
in access control list (ACL) to request this id.</c>
<c>DEF([*], CD1, AD1 + AD2)</c>
<c>PROD(P,ID)</c>
<c>Produce ID according to predicate
P. P may be a time period (1s) or an expression (AD1 > 10).</c>
<c>PROD(1s, AD1)</c>
<c>RPT(ID)</c>
<c>A report identified by ID.</c>
<c>RPT(AD1)</c>
</texttable>
</section>
<section title="Serialized Management" toc="default">
<t>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 <xref target="serial_mgmt_ctrl_flow" pageno="false" format="default" />.</t>
<figure align="center" anchor="serial_mgmt_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
<preamble>Serialized Management Control Flow</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+ +---------+ +---------+
| 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)-------|
| | |
</artwork>
<postamble>In a simple network, a manager interacts with multiple
agents.</postamble>
</figure>
<t>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).</t>
</section>
<section title="Multiplexed Management" toc="default">
<t>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 <xref target="multi_mgmt_ctrl_flow" pageno="false" format="default" />.</t>
<figure align="center" anchor="multi_mgmt_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
<preamble>Multiplexed Management Control Flow</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+-----------+ +-------+ +-----------+
| 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)----->|
</artwork>
<postamble>Complex networks require multiple managers interfacing
with agents.</postamble>
</figure>
<t>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 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).</t>
</section>
<section title="Data Fusion" toc="default">
<t>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
<xref target="fusion_ctrl_flow" pageno="false" format="default" />.</t>
<figure align="center" anchor="fusion_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
<preamble>Data Fusion Control Flow</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+-----------+ +-----------+ +---------+ +---------+
| 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)
| | | |
</artwork>
<postamble>Data fusion in DTNMP accours amongst managers in the
network.</postamble>
</figure>
<t>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
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.</t>
</section>
</section>
</section>
<section title="Component Model" toc="default">
<t>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.</t>
<section title="Data Representation" toc="default">
<section title="Types" toc="default">
<t>Components within the DTNMP are represented as one of four basic
data types: Data, Controls, Literals, and Operators: <list hangIndent="8" style="hanging"><t hangText="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.</t><t hangText="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. </t><t hangText="Literals">Literals are constant numerical values
that may be used in the evaluation of expressions and predicates.</t><t hangText="Operator">Operators are those mathematical
functions that operate on series of Data and Literals, such as
addition, subtraction, multiplication, and division.</t></list></t>
</section>
<section title="Categories" toc="default">
<t>Components within the DTNMP can be categorized as Atomic,
Computed, or Collection. <list hangIndent="8" style="hanging"><t hangText="Atomic"><vspace blankLines="0" />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, similar to the mechanisms used to
assign Object Identifiers (OIDs). Atomic components must be
understood by both DTNMP managers and agents in a network. </t><t hangText="Computed"><vspace blankLines="0" />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.</t><t hangText="Collection"><vspace blankLines="0" />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.</t></list></t>
</section>
<section title="Data Model" toc="default">
<t>Each component of the DTNMP data model can be identified as a
combination of type and category, as illustrated in <xref target="model_ref" pageno="false" format="default" />. 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.</t>
<texttable anchor="model_ref" title="" suppress-title="false" align="center" style="full">
<ttcol align="center" />
<ttcol align="center">Data</ttcol>
<ttcol align="center">Controls</ttcol>
<ttcol align="center">Literals</ttcol>
<ttcol align="center">Operator</ttcol>
<c>Atomic</c>
<c>Measured Value</c>
<c>Control</c>
<c>Constant</c>
<c>Operator</c>
<c>Computed</c>
<c>Calculated Value</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>Collection</c>
<c>Report</c>
<c>Macro</c>
<c>N/A</c>
<c>N/A</c>
</texttable>
</section>
</section>
<section title="Primitive Types" toc="default">
<section title="Self-Delimiting Numeric Value (SDNV)" toc="default">
<t> The data type "SDNV" refers to a Self-Delimiting Numerical Value
(SDNV) described in <xref target="RFC6256" pageno="false" format="default" />. 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.</t>
</section>
<section title="Timestamp (TS)" toc="default">
<t>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. </t>
</section>
<section title="Data Collections (DC)" toc="default">
<t>A Data collection is comprised of a value identifiying the number
of bytes in the collection, followed by each byte, as illustrated in
<xref target="data_list" pageno="false" format="default" />. Data collections are used in the DTNMP
to capture variable data sets that are too large to place in an
SDNV. <figure align="center" anchor="data_list" title="" suppress-title="false" alt="" width="" height=""><preamble>Data Collection</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------+--------+--------+ +--------+
| # Bytes | BYTE 1 | BYTE 2 | ... | BYTE N |
| [SDNV] | [BYTE] | [BYTE] | | [BYTE] |
+---------+--------+--------+ +--------+
</artwork></figure></t>
</section>
</section>
<section title="Naming and Identification" toc="default">
<t>
While all components within the DTNMP can be uniquely identified by an
Object Identifier (OID), several annotations exist to assist with the
filtering and access control associated with components beyond what is
efficiently represented in the OID structure. These annotations include
the type and category of the component, an optional identifier naming
the issuer of the component, and an optional tag value holding
issuer-specific information about the component.
</t>
<t>
The DTNMP Managed Identifier (MID) provides a single, variable length
structure that encapsulates all of the information necessary to identify
a DTNMP component and its useful annotations.
</t>
<t>
The MID structure, illustrated in <xref target="mid" pageno="false" format="default" />, 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 byte.</t>
<figure align="center" anchor="mid" title="" suppress-title="false" alt="" width="" height="">
<preamble>MID format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+--------+--------+--------+
| Flags | Issuer | OID | Tag |
| [BYTE] | [SDNV] |[VARIED]| [SDNV] |
| | (opt.) | | (opt.) |
+--------+--------+--------+--------+
</artwork>
</figure>
<t>The MID fields are defined as follows.
<list hangIndent="8" style="hanging"><t hangText="Flags"><vspace blankLines="0" /> 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 <xref target="mid_flag" pageno="false" format="default" />.
<figure align="center" anchor="mid_flag" title="" suppress-title="false" alt="" width="" height=""><preamble>MID Flag Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+-----+---+---+-----+------+
| OID |TAG|ISS| CAT | TYPE |
+-----+---+---+-----+------+
| 7 6 | 5 | 4 | 3 2 | 1 0 |
+-----+---+---+-----+------+
MSB LSB
</artwork></figure><list hangIndent="8" style="hanging"><t hangText="MID Type (TYPE)"><vspace blankLines="0" /> The type of the component
encapsulated by the MID, enumerated as data (0), control (1),
literal (2), or operator (3).</t><t hangText="MID Category (CAT)"><vspace blankLines="0" />The category of the
component encapsulated by the MID, enumerated as atomic (0),
computed (1), and collection (2). </t><t hangText="Issuer Present (ISS)"><vspace blankLines="0" /> 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.</t><t hangText="Tag Present (TAG)"><vspace blankLines="0" /> Whether the tag
field is present (1) or not (0) for this MID. If this flag has
a value of 1 then the tag field MUST be present in the MID.
Otherwise, the tag field MUST NOT be present.</t><t hangText="OID Type (OID)"><vspace blankLines="0" /> 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).</t></list>
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.</t><t hangText="Issuer"><vspace blankLines="0" /> 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.</t><t hangText="OID"><vspace blankLines="0" /> 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. <list hangIndent="8" style="hanging"><t hangText="Full OID"><vspace blankLines="0" />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 <xref target="full_oid_fmt" pageno="false" format="default" />.
<figure align="center" anchor="full_oid_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Full OID Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+------------+--------------------+
| OID Length | OID Content Octets |
| [SDNV] | [ASN.1 BER] |
+------------+--------------------+
</artwork></figure></t><t hangText="Parameterized OID"><vspace blankLines="0" />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 <xref target="parm_oid_fmt" pageno="false" format="default" />. <figure align="center" anchor="parm_oid_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Parameterized OID Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+---------+--------+ +--------+
| Base OID | # Parms | Parm 1 | ... | Parm N |
| [VAR] | [SDNV] | [DC] | | [DC] |
+----------+---------+--------+ +--------+
</artwork></figure></t><t hangText="Compressed Full OID"><vspace blankLines="0" />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.</t><t hangText="Compressed Parameterized OID"><vspace blankLines="0" />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.</t></list></t><t hangText="Tag"><vspace blankLines="0" /> 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 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.</t></list></t>
</section>
<section title="Special Types" toc="default">
<t>In addition to the primitive data types already mentioned, the
following special data types are also defined.</t>
<section title="MID Collections (MC)" toc="default">
<t>A MID collection is comprised of a value identifiying the number
of MIDs in the collection, followed by each MID, as illustrated in
<xref target="mid_list" pageno="false" format="default" />. <figure align="center" anchor="mid_list" title="" suppress-title="false" alt="" width="" height=""><preamble>MID Collection</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+ +-------+
| # MIDs | MID 1 | ... | MID N |
| [SDNV] | [MID] | | [MID] |
+--------+-------+ +-------+
</artwork></figure></t>
</section>
<section title="Expressions (EXPR)" toc="default">
<t>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 <xref target="expr_fmt" pageno="false" format="default" />. <figure align="center" anchor="expr_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Expression Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+------------+
| Priority | Expression |
| [SDNV] | [MC] |
+----------+------------+
</artwork></figure><list hangIndent="8" style="hanging"><t hangText="Priority"><vspace blankLines="0" /> 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 integer value with
larger values indicating higher priority. Unless otherwise specified,
a default priority value of 0 SHALL be used for any defined expression.</t><t hangText="Expression"><vspace blankLines="0" />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. </t></list></t>
</section>
<section title="Predicate (PRED)" toc="default">
<t>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. </t>
</section>
</section>
</section>
<section title="Functional Specification" toc="default">
<t>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.</t>
<texttable title="" suppress-title="false" align="center" style="full">
<ttcol align="left">Type Name</ttcol>
<ttcol align="left">Description</ttcol>
<c>BYTE</c>
<c>Unsigned, 8-bit byte.</c>
<c>DC</c>
<c>Data Collection</c>
<c>EXPR</c>
<c>Expression</c>
<c>MC</c>
<c>MID Collection</c>
<c>MID</c>
<c>Managed Identifier</c>
<c>PRED</c>
<c>Predicate</c>
<c>SDNV</c>
<c>Self-Delimiting Numerical Value</c>
<c>TS</c>
<c>Timestamp</c>
<c>VAR</c>
<c>Variable field.</c>
</texttable>
<section title="Message Group Format" toc="default">
<t>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 <xref target="msg_grp" pageno="false" format="default" />.
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.
<figure align="center" anchor="msg_grp" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Message Group Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-----------+-----------+ +-----------+
| # Msgs | Timestamp | Message 1 | ... | Message N |
| [SDNV] | [TS] | [VAR] | | [VAR] |
+--------+-----------+-----------+ +-----------+
</artwork></figure><list hangIndent="8" style="hanging"><t hangText="# Msgs"><vspace blankLines="0" /> The number of messages that
are together in this message group.</t><t hangText="Timestamp"><vspace blankLines="0" />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. </t><t hangText="Message N"><vspace blankLines="0" /> The Nth message in the group.</t></list></t>
</section>
<section title="Message Format" toc="default">
<t> Each message identified in the DTNMP specification adheres to a
common message format, illustrated in <xref target="msg_fmt" pageno="false" format="default" />, consisting
of a message header, a message body, and an optional trailer.
<figure align="center" anchor="msg_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Message Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+---------+
| Header | Body | Trailer |
| [BYTE] | [VAR] | [VAR] |
| | | (opt.) |
+--------+-------+---------+
</artwork></figure></t>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Header">
<vspace blankLines="0" /> The message header byte is shown
in <xref target="cmn_hdr" pageno="false" format="default" />. 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).
<figure align="center" anchor="cmn_hdr" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Common Message Header</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+----+---+---------+-------+
|ACL Used|Nack|Ack| Context |Opcode |
+--------+----+---+---------+-------+
| 7 | 6 | 5 | 4 3 | 2 1 0 |
+--------+----+---+---------+-------+
MSB LSB
</artwork></figure><list hangIndent="8" style="hanging"><t hangText="Opcode"><vspace blankLines="0" /> The opcode field identifies the
opcode of the message, within the associated message context.</t><t hangText="ACK Flag"><vspace blankLines="0" /> 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.</t><t hangText="NACK Flag"><vspace blankLines="0" /> 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.</t><t hangText="ACL Used Flag"><vspace blankLines="0" /> 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.</t></list></t>
<t hangText="Body">
<vspace blankLines="0" />
The message body contains the information associated with the given
message. </t>
<t hangText="Trailer">
<vspace blankLines="0" /> 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.</t>
</list>
</t>
</section>
<section title="Register Agent (0x00)" toc="default">
<t>The Register Agent message is used to inform a DTNMP manager of
the presence of another agent in the network. <figure align="center" anchor="register_agent_msg" title="Register Agent Message Body" suppress-title="false" alt="" width="" height=""><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+
| Agent ID |
| [SDNV] |
+----------+
</artwork></figure><list hangIndent="8" style="hanging"><t hangText="Agent ID"><vspace blankLines="0" /> 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.</t></list></t>
</section>
<section title="Data Report (0x12)" toc="default">
<t>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.
<figure align="center" anchor="data_rpt_msg" title="" suppress-title="false" alt="" width="" height="">
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+------+------+-------+--------+ +-------+--------+
| Time | Num | ID 1 | Data 1 | | ID N | Data N |
| [TS] |[SDNV]| [MID] | [DC] |...| [MID] | [DC] |
+------+------+-------+--------+ +-------+--------+
</artwork>
</figure>
<list hangIndent="8" style="hanging">
<t hangText="Time">
<vspace blankLines="0" /> The time at which the report was
generated by the DTNMP actor.</t>
<t hangText="Num">
<vspace blankLines="0" /> The number of reports in the data
report message.</t>
<t hangText="ID N">
<vspace blankLines="0" /> The MID identifying the Nth report.</t>
<t hangText="Data N"><vspace blankLines="0" /> The contents of the Nth report.</t>
</list>
</t>
</section>
<section title="Perform Control (0x20)" toc="default">
<t>The perform control method causes the receiving DTNMP actor to
apply one or more pre-configured controls.</t>
<figure align="center" anchor="run_ctlr_msg" title="" suppress-title="false" alt="" width="" height="">
<preamble>Predicate Production Message</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-------+-----------+
| Start | Controls |
| [TS] | [MC] |
+-------+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Start">
<vspace blankLines="0" /> The time at which the control
should be run.</t>
<t hangText="Controls">
<vspace blankLines="0" /> The collection of controls to
be applied by the DTNMP actor. The MID identifying a control will contain the
parameters for the control (if any) through the use of a parameterized OID
captured within the MID.</t>
</list>
</t>
</section>
</section>
<section anchor="AGENT_TMPL" title="Appliation Data Model Template" toc="default">
<section anchor="ADM_OVERVIEW" title="Overview" toc="default">
<t>
An application data model (ADM) specifies the set of DTNMP components associated with
a particular application/protocol. The purpose of the
ADM is to provide a guaranteed interface for the management of an application or protocol
over DTNMP that is independent of the nuances of its software implementation. In this
respect, the ADM is conceptually similar to the Managed Information Base (MIB) used by SNMP,
but contains additional information relating to command opcodes and more expressive syntax for
automated behavior.
</t>
<t>
Currently, the ADM is an organizing document and not used to automatically generate software.
As such, the ADM template lists the kind of information that must be present in an ADM
definition but does not address mechanisms for automating implementations.
</t>
<t>
Each ADM specifies the globally unique identifiers and descriptions for all data, controls,
literals, and operators associated with the application or protocol maanged by the ADM. Any
implementation claiming compliance with a given ADM must compute all identified data,
perform identified controls, and understand identified literals and operators.
</t>
</section>
<section title="ADM Types">
<t>
ADMs must specify data types when defining data items and parameters. In addition to the standard DTNMP Types
(SDNV, TS, DC, MID, OID, P_OID, MC, EXPR, and PRED) ADMs support the following additional data types.
</t>
<texttable anchor="adm_datatype" title="ADM Data Types" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Data Type</ttcol>
<ttcol align="center" width="10%">ID</ttcol>
<ttcol align="center" width="60%">Description</ttcol>
<ttcol align="center" width="10%">Encapsulating DTNMP Type</ttcol>
<c>Integer</c>
<c>INT</c>
<c>A signed or unsigned integer up to 64 bits in width encoded using Google Protocol Buffer VARINT rules.
Booleans, enumerations, and all integer values are captured using this data type.</c>
<c> SDNV </c>
<c>Float</c>
<c>FLOAT</c>
<c>A 32-bit fixed-width number stored according to the IEEE-754 float standard. </c>
<c> SDNV </c>
<c>Double</c>
<c>DOUBLE</c>
<c>A 64-bit fixed-width number stored according to the IEEE-754 double standard. </c>
<c> SDNV </c>
<c>STRING</c>
<c>STR</c>
<c>An array of characters preceeded by the character count. Strings are not required to be NULL-terminated. </c>
<c> DC </c>
<c>Binary Large Object</c>
<c>BLOB</c>
<c>An undefined series of user-defined bytes preceeded by the length of the binary object. This
data type is captured . </c>
<c> DC </c>
</texttable>
</section>
<section anchor="ADM_TMPL_DEF" title="Template" toc="default">
<t>
ADM definitions specify the metadata, data, controls, literals, and operators associated with
a managed application or protocol.
</t>
<section title="ADM Metadata">
<t>
ADM metadata consist of the items necessary to uniquely identify the ADM itself. The
required metadata items include the following.
</t>
<texttable anchor="adm_metadata" title="ADM Terminology" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Item</ttcol>
<ttcol align="center" width="10%">Type</ttcol>
<ttcol align="center" width="65%">Description</ttcol>
<ttcol align="center" width="5%">Req.</ttcol>
<c>Name</c>
<c>STR</c>
<c>The human-readible name of the ADM. </c>
<c>Y</c>
<c>Version</c>
<c>STR</c>
<c>Version of the ADM encoded as a string. </c>
<c>Y</c>
<c>OID Nickname N</c>
<c>OID</c>
<c> ADMs provide an ordered list of nicknames that can be used by other MIDs in the ADM definition
to defined compressed OIDs. There can an arbitratry number of nicknames defined for an ADM. </c>
<c>N</c>
</texttable>
</section>
<section title="ADM Information Capture">
<t>
The ADM Data Section consist of all components in the "data" category associated with the
managed application or protocol. The information that must be provided for each of these
items is as follows.
<list style="hanging">
<t hangText="Name"><vspace blankLines="0" /> Every component in an ADM MUST be given
a human-readable, consistent name that unqiuely identifies the component in the
context of the application or protocol. These names will be used by human-computer
interfaces for manipulating components.</t>
<t hangText="MID"><vspace blankLines="0" /> The managed identifier that describes this
data item. MIDs in components identified by an ADM MUST NOT contain an issuer or
a tag value. In cases where a partial OID is specified, the ADM OID prefix is presumed
as the base. In cases where the OID is parameterized, the parameter values are not included
in the MID definition in the ADM as parameters are provided at runtime by implementations.</t>
<t hangText="OID"><vspace blankLines="0" /> A human-readible version of the OID encapsulated
in the MID for the component (e.g., 1.2.3.4). When a nickname is used to represent an
compressed OID, the nickname enumeration is included in this field enclosed by square brackets.
For example, if OID nickname 0 refers to the OID prefix 1.2.3.4.5, then the OID 1.2.3.4.5.6 may be
listed more compactly as [0].6</t>
<t hangText="Description"><vspace blankLines="0" /> Every component in an ADM MUST be given a
human-readable, consistent description that provides a potential user with a compact,
effective summary of the component.</t>
<t hangText="Type"><vspace blankLines="0" /> For components that evaluate to a data value, the
data type for that value must be represented.</t>
<t hangText="# Parameters"><vspace blankLines="0" /> For components with a parameterized OID, the
ADM MUST provide the expected number of parameters. A value of 0 indicates that the OID has no
parameters and MUST NOT be used for any MID which has a parameterized OID. When ommitted,
the number of parameters is considered 0.</t>
<t hangText="Parameter N Name"><vspace blankLines="0" /> Each parameter of a parameterized component
must be given a name.</t>
<t hangText="Parameter N Description"><vspace blankLines="0" /> Each parameter of a parameterized
component must be given a summary that describes how the parameter will be used by the
application or protocol.</t>
<t hangText="Parameter N Type"><vspace blankLines="0" /> Each parameter of a parameterized component
must be given a type that describes the structre capturing the parameter value. Notably, while
parameters in the OID form something similar to a function prototype, there is no sense of
function call or stack and therefore all parameters should be considered as pass-by-value.</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="AGENT_ADM" title="DTNMP Agent Application Data Model" toc="default">
<section anchor="AGENT_ADM_OVERVIEW" title="Data Definitions" toc="default">
<t>
This section provides the ADM for a DTNMP Agent. This ADM may eventually be removed from the
DTNMP specification into its own standards document. All DTNMP agents MUST support the
items described in this section.
</t>
</section>
<section anchor="AGENT_ADM_META" title="Metadata Definitions" toc="default">
<texttable anchor="agent_adm_metadata" title="DTNMP Agent Metadata" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Item</ttcol>
<ttcol align="center" width="10%">Type</ttcol>
<ttcol align="center" width="10%">Value</ttcol>
<ttcol align="center" width="60%">Comment</ttcol>
<c>Name</c>
<c>STR</c>
<c>DTNMP Agent ADM</c>
<c></c>
<c>Version</c>
<c>STR</c>
<c>2014-12-31</c>
<c></c>
<c>OID Nickname 0</c>
<c>OID</c>
<c>1.1</c>
<c>1.1 is currently used only as a non-operational example of an ADM base.</c>
</texttable>
</section>
<section anchor="ADM_DATA" title="Data Definitions" toc="default">
<t>
The DTNMP Agent ADM defines the following atomic data definitions that represent the
set of data that MUST be collected by any DTNMP agent implementation.
</t>
<section title="Atomic Data">
<texttable anchor="agent_adm_atomicdata" title="DTNMP Agent Atomic Data" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Name</ttcol>
<ttcol align="center" width="10%">MID</ttcol>
<ttcol align="center" width="10%">OID</ttcol>
<ttcol align="center" width="60%">Description</ttcol>
<ttcol align="center" width="60%">Type</ttcol>
<c>DefinedReports</c>
<c>0x800200</c>
<c>[0].0.0</c>
<c># Reports Defined</c>
<c>INT</c>
<c>SentReports</c>
<c>0x800201</c>
<c>[0].0.1</c>
<c># Reports Sent</c>
<c>INT</c>
<c>DefinedTimeRules</c>
<c>0x800202</c>
<c>[0].0.2</c>
<c># Active Time-Based Production Rules</c>
<c>INT</c>
<c>RunTimeRules</c>
<c>0x800203</c>
<c>[0].0.3</c>
<c># Run Time-Based Production Rules</c>
<c>INT</c>
<c>DefinedConsts</c>
<c>0x800204</c>
<c>[0].0.4</c>
<c># Constants Defined</c>
<c>INT</c>
<c>DefinedCustom</c>
<c>0x800205</c>
<c>[0].0.5</c>
<c># Computed Data Definitions</c>
<c>INT</c>
<c>DefinedMacros</c>
<c>0x800206</c>
<c>[0].0.6</c>
<c># Macros Defined</c>
<c>INT</c>
<c>RunMacros</c>
<c>0x800207</c>
<c>[0].0.7</c>
<c># Macros Run</c>
<c>INT</c>
<c>DefinedCtrls</c>
<c>0x800208</c>
<c>[0].0.8</c>
<c># Controls Defined</c>
<c>INT</c>
<c>RunCtrls</c>
<c>0x800209</c>
<c>[0].0.9</c>
<c># Controls Defined</c>
<c>INT</c>
</texttable>
</section>
<section title="Computed Data">
<t>
The DTNMP Agent ADM does not define any computed data items.
</t>
</section>
<section title="Reports">
<texttable anchor="agent_adm_reports" title="DTNMP Agent Reports" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Name</ttcol>
<ttcol align="center" width="10%">MID</ttcol>
<ttcol align="center" width="10%">OID</ttcol>
<ttcol align="center" width="60%">Description</ttcol>
<ttcol align="center" width="60%">Type</ttcol>
<c>FullReport</c>
<c>0x880220</c>
<c>[0].2.0</c>
<c>Report of all atomic data items</c>
<c>DC</c>
</texttable>
</section>
</section>
<section title="Operators">
<t>
This section describes the standard set of operators available to all DTNMP agents. Applications and
protocols do not need to redefine these operators, as they may be used in any expressions evaluated
by any agent.
</t>
<texttable anchor="agent_adm_op" title="DTNMP Agent Atomic Data" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Name</ttcol>
<ttcol align="center" width="10%">MID</ttcol>
<ttcol align="center" width="10%">OID</ttcol>
<ttcol align="center" width="60%">Description</ttcol>
<c>+</c>
<c>0x830260</c>
<c>[0].6.0</c>
<c>Addition</c>
<c>-</c>
<c>0x830261</c>
<c>[0].6.1</c>
<c>Subtraction</c>
<c>*</c>
<c>0x830262</c>
<c>[0].6.2</c>
<c>Multiplication</c>
<c>/</c>
<c>0x830263</c>
<c>[0].6.3</c>
<c>Division</c>
<c>%</c>
<c>0x830264</c>
<c>[0].6.4</c>
<c>Modulo</c>
<c>^</c>
<c>0x830265</c>
<c>[0].6.5</c>
<c>Exponentiation</c>
<c>&</c>
<c>0x830266</c>
<c>[0].6.6</c>
<c>Bitwise AND</c>
<c>|</c>
<c>0x830267</c>
<c>[0].6.7</c>
<c>Bitwise OR</c>
<c>#</c>
<c>0x830268</c>
<c>[0].6.8</c>
<c>Bitwise XOR</c>
<c>~</c>
<c>0x830269</c>
<c>[0].6.9</c>
<c>Bitwise NOT</c>
<c>&&</c>
<c>0x83026A</c>
<c>[0].6.A</c>
<c>Logical AND</c>
<c>||</c>
<c>0x83026B</c>
<c>[0].6.B</c>
<c>Logical OR</c>
<c>##</c>
<c>0x83026C</c>
<c>[0].6.C</c>
<c>Logical XOR</c>
<c>!</c>
<c>0x83026D</c>
<c>[0].6.D</c>
<c>Logical NOT</c>
<c>abs</c>
<c>0x83026E</c>
<c>[0].6.E</c>
<c>Absolute Value</c>
<c><</c>
<c>0x83026F</c>
<c>[0].6.F</c>
<c>Less than</c>
<c>></c>
<c>0x8303610</c>
<c>[0].6.10</c>
<c>Greater than</c>
<c><=</c>
<c>0x8303611</c>
<c>[0].6.11</c>
<c>Less than or equal to</c>
<c>>=</c>
<c>0x8303612</c>
<c>[0].6.12</c>
<c>Greater than or equal to</c>
<c>!=</c>
<c>0x8303613</c>
<c>[0].6.13</c>
<c>Not equal</c>
<c>==</c>
<c>0x8303614</c>
<c>[0].6.14</c>
<c>Equal to</c>
</texttable>
</section>
<section title="Controls">
<t>
This section describes the controls available for use on any DTNMP agent. Since this
section essentially provides a functional specification for the DTNMP agent, it is presented
in two sections. First, a summary section provides a quick reference for the controls
available on a DTNMP agent. Second, a full control specification provides detailed information
on each individual DTNMP agent control.
</t>
<section title="Control Summary">
<texttable anchor="agent_adm_ctrls" title="DTNMP Agent Controls Summary" suppress-title="false" align="center" style="full">
<ttcol align="center" width="20%">Name</ttcol>
<ttcol align="center" width="10%">MID</ttcol>
<ttcol align="center" width="10%">OID</ttcol>
<ttcol align="center" width="50%">Description</ttcol>
<c>ListADMs</c>
<c>0x810230</c>
<c>[0].3.0</c>
<c>List all ADMs known to the agent.</c>
<c>ListAtomicIDs</c>
<c>0x810231</c>
<c>[0].3.1</c>
<c>List all Atomic MIDs known to the agent.</c>
<c>DescAtomicData</c>
<c>0xC10232</c>
<c>[0].3.2</c>
<c>Dump information for given Atomic MIDs.</c>
<c>AddCompData</c>
<c>0xC10233</c>
<c>[0].3.3</c>
<c>Define a computed data definition on the agent.</c>
<c>DelCompData</c>
<c>0xC10234</c>
<c>[0].3.4</c>
<c>Remove a computed data definition from the agent.</c>
<c>ListCompData</c>
<c>0x810235</c>
<c>[0].3.5</c>
<c>List known computed data MIDs.</c>
<c>DescCompData</c>
<c>0xC10236</c>
<c>[0].3.6</c>
<c>Dump information for given computed data MIDs.</c>
<c>AddRptDef</c>
<c>0xC10237</c>
<c>[0].3.7</c>
<c>Define a custom report.</c>
<c>DelRptDef</c>
<c>0xC10238</c>
<c>[0].3.8</c>
<c>Forget a custom report.</c>
<c>ListRpts</c>
<c>0x810239</c>
<c>[0].3.9</c>
<c>List known custom report MIDs.</c>
<c>DescRpts</c>
<c>0xC1023A</c>
<c>[0].3.A</c>
<c>Dump information for given custom report MIDs.</c>
<c>ListOps</c>
<c>0x81023B</c>
<c>[0].3.B</c>
<c>List known operator IDs.</c>
<c>DescOps</c>
<c>0xC1023C</c>
<c>[0].3.C</c>
<c>Dump information for given operator MIDs.</c>
<c>ListCtrls</c>
<c>0x81023D</c>
<c>[0].3.D</c>
<c>List known custom control MIDs.</c>
<c>DescCtrls</c>
<c>0xC1023E</c>
<c>[0].3.E</c>
<c>Dump information for given controls MIDs.</c>
<c>AddMacroDef</c>
<c>0xC1023F</c>
<c>[0].3.F</c>
<c>Define a custom macro.</c>
<c>DelMacroDef</c>
<c>0xC103310</c>
<c>[0].3.10</c>
<c>Forget a custom macro.</c>
<c>ListMacros</c>
<c>0x8103311</c>
<c>[0].3.11</c>
<c>List known custom macro MIDs.</c>
<c>DescMacros</c>
<c>0xC103312</c>
<c>[0].3.12</c>
<c>Dump information for given custom macro MIDs.</c>
<c>AddTimeRule</c>
<c>0xC103313</c>
<c>[0].3.13</c>
<c>Define a time-based prod rule.</c>
<c>DelTimeRule</c>
<c>0xC103314</c>
<c>[0].3.14</c>
<c>Forget a time-based prod rule.</c>
<c>ListTimeRules</c>
<c>0x8103315</c>
<c>[0].3.15</c>
<c>List known time-based rules.</c>
<c>DescTimeRules</c>
<c>0xC103316</c>
<c>[0].3.16</c>
<c>Dump information for given time-based rules.</c>
<c>AddStateRule</c>
<c>0xC103317</c>
<c>[0].3.17</c>
<c>Define a state-based prod rule.</c>
<c>DelStateRule</c>
<c>0xC103318</c>
<c>[0].3.18</c>
<c>Forget a state-based prod rule.</c>
<c>ListStateRules</c>
<c>0x8103319</c>
<c>[0].3.19</c>
<c>List known state-based rules.</c>
<c>DescStateRules</c>
<c>0xC10331A</c>
<c>[0].3.1A</c>
<c>Dump information for given state-based rules.</c>
</texttable>
</section>
<section title="Control Specification">
<section title="ListADMs" toc="default">
<t> This control causes the agent to produce a report detailing the list of all ADMs
configured on the agent and available for use.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_adm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListADMs Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+ +------------+
| # ADMs | ADM 1 Name | ... | ADM N Name |
| [SDNV] | [STR] | | [STR] |
+--------+------------+ +------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# ADMs">
<vspace blankLines="0" /> The number of ADMs known to the agent.
</t>
<t hangText="ADM [x] Name">
<vspace blankLines="0" /> For each ADM, it's human readable name.
</t>
</list>
</t>
</section>
<section title="ListAtomicIDs" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
atomic data item understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_atomic_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListAtomicIDs Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Atomic IDs |
| [MC] |
+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Atomic IDs">
<vspace blankLines="0" /> A MID Collection of the MIDs of each atomic data definition known to the agent.
</t>
</list>
</t>
</section>
<section title="DescAtomicData" toc="default">
<t> This control causes the agent to produce a detailed description of the requested atomic data definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_atomic_data_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescAtomicData Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Atomic IDs |
| [MC] |
+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Atomic IDs">
<vspace blankLines="0" /> The list of MIDs identifying the atomic IDs to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_atomic_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescAtomicData Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+----------+----------+ +----------+----------+
| # IDs | ID1 Name | ID1 Type |... | IDn Name | IDn Type |
| [SDNV] | [STR] | [SDNV] | | [STR] | [SDNV] |
+--------+----------+----------+ +----------+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# IDs">
<vspace blankLines="0" /> The number of atomic data descriptions returned.
</t>
<t hangText="ID[n] Name">
<vspace blankLines="0" /> The name of the nth returned atomic data item.
</t>
<t hangText="ID[n] Type">
<vspace blankLines="0" /> Type enumeration for the nth atomic data item.
</t>
</list>
</t>
</section>
<section title="AddCompData" toc="default">
<t> This control configures a new computed data definition on the agent. A computed data item uses an expression to assign a data value.
</t>
<t> This control takes 3 parameters in the following format. </t>
<figure align="center" anchor="add_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>AddCompData Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+--------+--------+
| Def ID | Def | Type |
| [MID] | [EXPR] | [SDNV] |
+--------+--------+--------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Def ID">
<vspace blankLines="0" /> The MID value identifying the new computed data definition.
</t>
<t hangText="Def">
<vspace blankLines="0" /> The expression used to calculate the value for the new computed data item.
</t>
<t hangText="Type">
<vspace blankLines="0" /> The data type for the resultant computed data value.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="DelCompData" toc="default">
<t> This control removes a computed data definition from the agent.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="del_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DelCompData Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------------+
| IDs To Remove |
| [MC] |
+---------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="IDs To Remove">
<vspace blankLines="0" /> The list of computed data items to be removed from the agent.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="ListCompData" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
computed data definition understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_cust_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListCompData Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Custom IDs |
| [MC] |
+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Custom IDs">
<vspace blankLines="0" /> The collection of identifiers for those computed data definitions known to the agent.
</t>
</list>
</t>
</section>
<section title="DescCompData" toc="default">
<t> This control causes the agent to produce a detailed description of the requested computed data definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescCompData Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Comp IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Comp IDs">
<vspace blankLines="0" /> The MID collection identifying the computed data items to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_comp_data_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescCompData Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------+-------+--------+---------+ +-------+--------+--------+
|# IDs | C1 ID | C1 Def | C1 Type |... | Cn ID | Cn Def | Cn Type|
|[SDNV]| [MID] | [EXPR] | [SDNV] | | [MID] | [EXPR] | [SDNV] |
+------+-------+--------+---------+ +-------+--------+--------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# IDs">
<vspace blankLines="0" /> The number of computed data definitions in the report.
</t>
<t hangText="C[n] ID">
<vspace blankLines="0" /> The MID of the nth computed data definition.
</t>
<t hangText="C[n] Def">
<vspace blankLines="0" /> The expression used to calculate the value of the Nth computed data item.
</t>
<t hangText="C[n] Type">
<vspace blankLines="0" /> The data type of the value of the Nth computed data item.
</t>
</list>
</t>
</section>
<section title="AddRptDef" toc="default">
<t> This control configures a new custom report definition on the agent. 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.
</t>
<t> This control takes 2 parameters in the following format. </t>
<figure align="center" anchor="add_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>AddRptDef Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+
| RPT ID | Definition |
| [MID] | [MC] |
+--------+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rpt ID">
<vspace blankLines="0" /> The MID for the new report.
</t>
<t hangText="Definition">
<vspace blankLines="0" /> The ordered set of MIDs representing the contents of the report.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="DelRptDef" toc="default">
<t> This control removes a custom report definition from the agent.
</t>
<t> This control takes 1 parameters in the following format. </t>
<figure align="center" anchor="del_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DelRptDef Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------------+
| IDs To Remove |
| [MC] |
+---------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="IDs to Remove">
<vspace blankLines="0" /> The collection of MIDs identifying the report definitions to remove from the agent.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="ListRpts" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
report definition understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListRpts Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------+
| Reports |
| [MC] |
+---------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Reports">
<vspace blankLines="0" /> The collection of MIDs representing custom report IDs known to the agent.
</t>
</list>
</t>
</section>
<section title="DescRpts" toc="default">
<t> This control causes the agent to produce a detailed description of the requested report definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_rpt_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescRpts Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Report IDs |
| [MC] |
+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Report IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the report definitions to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescRpts Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+----------+-----------+ +----------+-----------+
| # IDs | RPT 1 ID | RPT 1 Def | ... | RPT N ID | RPT N Def |
| [SDNV] | [MID] | [MC] | | [MID] | [MC] |
+--------+----------+-----------+ +----------+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# IDs">
<vspace blankLines="0" /> The number of report definitions in this report.
</t>
<t hangText="RPT[n] ID">
<vspace blankLines="0" /> The MID of the nth report definition.
</t>
<t hangText="RPT[n] Def">
<vspace blankLines="0" /> The ordered collection of IDs comprising the Nth report definition.
</t>
</list>
</t>
</section>
<section title="ListOps" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
operator understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_ops_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListOps Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------+
| OPS |
| [MC] |
+------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="OPS">
<vspace blankLines="0" /> The collection of MIDs for every op known by the agent.
</t>
</list>
</t>
</section>
<section title="DescOps" toc="default">
<t> This control causes the agent to produce a detailed listing of the requested operator definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_op_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescOps Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+
| OP IDs |
| [MC] |
+--------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="OP IDs">
<vspace blankLines="0" /> The set of operators to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_op_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescOps Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+---------+-----------+ +---------+-----------+
| # OPs | OP 1 ID | OP 1 Desc | ... | OP N ID | OP N Desc |
| [SDNV] | [MID] | [STR] | | [MID] | [STR] |
+--------+---------+-----------+ +---------+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# OPs">
<vspace blankLines="0" /> The number of operator definitions in the report.
</t>
<t hangText="OP[n] ID">
<vspace blankLines="0" /> The MID of the nth operator definition.
</t>
<t hangText="OP[n] Def">
<vspace blankLines="0" /> The description of the nth operator.
</t>
</list>
</t>
</section>
<section title="ListCtrls" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
control understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_ctrls_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListCtrls Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-------+
| CTRLs |
| [MC] |
+-------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="CTRLs">
<vspace blankLines="0" /> The collection of MIDs of controls known to the agent.
</t>
</list>
</t>
</section>
<section title="DescCtrls" toc="default">
<t> This control causes the agent to produce a detailed listing of the requested control definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_ctrl_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescCtrls Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| CTRL IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="CTRL IDs">
<vspace blankLines="0" /> The set of controls to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_ctrl_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescCtrls Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------+----------+------------+ +----------+------------+
| # CTRLs | CTRL1 ID | CTRL1 Desc | ... | CTRLN ID | CTRLN Desc |
| [SDNV] | [MID] | [STR] | | [MID] | [STR] |
+---------+----------+------------+ +----------+------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# CTRLs">
<vspace blankLines="0" /> The number of control definitions in the report.
</t>
<t hangText="CTRL[n] ID">
<vspace blankLines="0" /> The MID of the nth control definition.
</t>
<t hangText="CTRL[n] Desc">
<vspace blankLines="0" /> The description of the Nth control definition, to include information on parameters.
</t>
</list>
</t>
</section>
<section title="AddMacroDef" toc="default">
<t> This control configures a new custom macro definition on the agent. A macro is a
series of controls that should be run in sequence.
</t>
<t> This control takes 3 parameters in the following format. </t>
<figure align="center" anchor="add_macro_def_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>AddMacroDef Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+----------+------+
| Macro Name | Macro ID | Def |
| [STR] | [MID] | [MC] |
+------------+----------+------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Macro Name">
<vspace blankLines="0" /> The descriptive name for the macro.
</t>
<t hangText="Macro ID">
<vspace blankLines="0" /> The MID value identifying the new macro.
</t>
<t hangText="Def">
<vspace blankLines="0" /> The ordered set of controls/macros that are run sequentially during macro execution.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="DelMacroDef" toc="default">
<t> This control removes a custom macro definition from the agent.
</t>
<t> This control takes 1 parameters in the following format. </t>
<figure align="center" anchor="del_macro_def_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DelMacroDef Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------------+
| IDs To Remove |
| [MC] |
+---------------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="IDs To Remove">
<vspace blankLines="0" /> The collection of MIDs identifying the macros to be removed from the agent.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="ListMacros" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
custom macro definition understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_macro_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListMacros Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-----------+
| Macro IDs |
| [MC] |
+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Macro IDs">
<vspace blankLines="0" /> The list of macro definitions known to the agent.
</t>
</list>
</t>
</section>
<section title="DescMacros" toc="default">
<t> This control causes the agent to produce a detailed listing of the requested macro definitions.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_macro_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescMacros Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-----------+
| Macro IDs |
| [MC] |
+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Macro IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the macros to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_macro_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescMacros Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+-----+------+ +-------+-----+------+
|# Macros|M1 Name|M1 ID|M1 Def| ... |Mn Name|Mn ID|Mn Def|
| [SDNV] | [STR] |[MID]| [MC] | | [STR] |[MID]| [MC] |
+--------+-------+-----+------+ +-------+-----+------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# Macros">
<vspace blankLines="0" /> The number of macro definitions in the report.
</t>
<t hangText="M[n] Name">
<vspace blankLines="0" /> The name of the nth macro definition.
</t>
<t hangText="M[n] ID">
<vspace blankLines="0" /> The MID of the nth macro definition.
v </t>
<t hangText="M[n] Def">
<vspace blankLines="0" /> The expression used to calculate the value of the Nth computed data item.
</t>
</list>
</t>
</section>
<section title="AddTimeRule" toc="default">
<t> This control configures a new time-based production rule on the agent.
A time-based production rule instructs the agent to produce a report comprising
a fixed set of component values periodically over time. The component values may
represent any type of data value, including atomic data, computed data, or reports.
</t>
<t> This control takes 4 parameters in the following format. </t>
<figure align="center" anchor="add_time_rule_parm" title="" suppress-title="false" alt="" width="" height="">
<preamble>AddTimeRule Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+--------+---------+
| Start | Period (s) | Count | Results |
| [TS] | [SDNV] | [SDNV] | [MC] |
+--------+------------+--------+---------+ </artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Start">
<vspace blankLines="0" /> The time at which the production should commence.
</t>
<t hangText="Period">
<vspace blankLines="0" /> The number of seconds to wait between report message generation.
</t>
<t hangText="Count">
<vspace blankLines="0" /> The number of reports to be generated
by this configuration. The special value of 0 indicates
production should continue indefinitely.
</t>
<t hangText="Results">
<vspace blankLines="0" /> The collection of MIDs to be included in the report.
</t>
</list>
</t>
<t> No report is produced in response to this individual command. THe configured reports
will be produced in accordance to the configured time period. </t>
</section>
<section title="DelTimeRule" toc="default">
<t> This control removes a time-based production rule from the agent.
</t>
<t> This control takes 1 parameters in the following format. </t>
<figure align="center" anchor="del_time_rule_parm" title="" suppress-title="false" alt="" width="" height="">
<preamble>DelTimeRule Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the rules to be removed from the agent.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="ListTimeRules" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
time-based production rule understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_time_rules_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListTimeRules Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the time-based rules known to the agent.
</t>
</list>
</t>
</section>
<section title="DescTimeRules" toc="default">
<t> This control causes the agent to produce a detailed listing of the requested time-based production rules.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_time_rule_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescTimeRules Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the time-based rules to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_time_rule_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescTimeRules Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+----------+-----------+----------+-----------+
|# Rules | R1 ID | R1 START | R1 PERIOD | R1 Count | R1 Result | ...
| [SDNV] | [MID] | [TS] | [SDNV] | [SDNV] | [MC] |
+--------+-------+----------+-----------+----------+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# Rules">
<vspace blankLines="0" /> The number of time-based rule definitions in the report.
</t>
<t hangText="R[n] ID">
<vspace blankLines="0" /> The MID identifier for the nth time-based rule definition.
</t>
<t hangText="R[n] Start">
<vspace blankLines="0" /> The time at which the nth time-based rule production should commence.
</t>
<t hangText="R[n] Period">
<vspace blankLines="0" /> The number of seconds to wait between running the nth time-based rule.
</t>
<t hangText="R[n] Count">
<vspace blankLines="0" /> The number of reports to be generated
by the nth time-based report. The special value of 0 indicates
production should continue indefinitely.
</t>
<t hangText="R[n] Results">
<vspace blankLines="0" /> The collection of MIDs to be included in the report generated by the nth time-based rule.
</t>
</list>
</t>
</section>
<section title="AddStateRule" toc="default">
<t> This control configures a new state-based production rule on the agent.
A state-based production rule instructs the agent to produce a report comprising
a fixed set of component values periodically whenever the expression evaluates to true.
The component values may represent any type of data value, including atomic data,
computed data, or reports.
</t>
<t> This control takes 4 parameters in the following format. </t>
<figure align="center" anchor="add_state_rule_parm" title="" suppress-title="false" alt="" width="" height="">
<preamble>AddStateRule Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+--------+--------+---------+
| Start | State | Count | Results |
| [TS] | [PRED] | [SDNV] | [MC] |
+--------+--------+--------+---------+ </artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Start">
<vspace blankLines="0" /> The time at which the production should commence.
</t>
<t hangText="State">
<vspace blankLines="0" /> The expression which, when non-zero, causes the report to be generated.
</t>
<t hangText="Count">
<vspace blankLines="0" /> The number of reports to be generated
by this configuration. The special value of 0 indicates
production should continue indefinitely.
</t>
<t hangText="Results">
<vspace blankLines="0" /> The collection of MIDs to be included in the report.
</t>
</list>
</t>
<t> No report is produced in response to this individual command. </t>
</section>
<section title="DelStateRule" toc="default">
<t> This control removes a state-based production rule from the agent.
</t>
<t> This control takes 1 parameters in the following format. </t>
<figure align="center" anchor="del_state_rule_parm" title="" suppress-title="false" alt="" width="" height="">
<preamble>DelStateRule Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the rules to be removed from the agent.
</t>
</list>
</t>
<t> This control causes no report to be produced.</t>
</section>
<section title="ListStateRules" toc="default">
<t> This control causes the agent to produce a list containing the MID of every
state-based production rule understood by the agent.
</t>
<t> This control takes no parameters. </t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="list_state_rules_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>ListStateRules Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the state-based rules known to the agent.
</t>
</list>
</t>
</section>
<section title="DescStateRules" toc="default">
<t> This control causes the agent to produce a detailed listing of the requested state-based production rules.
</t>
<t> This control takes 1 parameter in the following format. </t>
<figure align="center" anchor="desc_state_rule_parm_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescStateRules Parameters</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
| [MC] |
+----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="Rule IDs">
<vspace blankLines="0" /> The collection of MIDs identifying the state-based rules to be described.
</t>
</list>
</t>
<t> This control causes a report to be generated with the following format.</t>
<figure align="center" anchor="desc_state_rule_fig" title="" suppress-title="false" alt="" width="" height="">
<preamble>DescStateRules Report Format</preamble>
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+----------+-----------+----------+-----------+
|# Rules | R1 ID | R1 START | R1 PERIOD | R1 Count | R1 Result | ...
| [SDNV] | [MID] | [TS] | [SDNV] | [SDNV] | [MC] |
+--------+-------+----------+-----------+----------+-----------+
</artwork>
</figure>
<t>
<list hangIndent="8" style="hanging">
<t hangText="# Rules">
<vspace blankLines="0" /> The number of state-based rule definitions in the report.
</t>
<t hangText="R[n] ID">
<vspace blankLines="0" /> The MID identifier for the nth state-based rule definition.
</t>
<t hangText="R[n] Start">
<vspace blankLines="0" /> The time at which the nth state-based rule production should commence.
</t>
<t hangText="R[n] Period">
<vspace blankLines="0" /> The number of seconds to wait between running the nth state-based rule.
</t>
<t hangText="R[n] Count">
<vspace blankLines="0" /> The number of reports to be generated
by the nth state-based report. The special value of 0 indicates
production should continue indefinitely.
</t>
<t hangText="R[n] Results">
<vspace blankLines="0" /> The collection of MIDs to be included in the report generated by the nth state-based rule.
</t>
</list>
</t>
</section>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations" toc="default">
<t>
At this time, this protocol has no fields registered by IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>Transport security is handled by the transport layer, for example the
<xref target="RFC6257" pageno="false" format="default">Bundle Security Protocol</xref> when using the
<xref target="RFC5050" pageno="false" format="default">Bundle Protocol</xref>.</t>
<t>Finer grain application security is done via ACLs which are defined
via configuration messages and implementation specific.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="RFC4838">
<front>
<title>Delay-Tolerant Networking Architecture</title>
<author initials="V." surname="Cerf" fullname="V. Cerf">
<organization />
</author>
<author initials="S." surname="Burleigh" fullname="S. Burleigh">
<organization />
</author>
<author initials="A." surname="Hooke" fullname="A. Hooke">
<organization />
</author>
<author initials="L." surname="Torgerson" fullname="L. Torgerson">
<organization />
</author>
<author initials="R." surname="Durst" fullname="R. Durst">
<organization />
</author>
<author initials="K." surname="Scott" fullname="K. Scott">
<organization />
</author>
<author initials="K." surname="Fall" fullname="K. Fall">
<organization />
</author>
<author initials="H." surname="Weiss" fullname="H. Weiss">
<organization />
</author>
<date year="2007" month="April" />
<abstract>
<t>This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4838" />
<format type="TXT" octets="89265" target="http://www.rfc-editor.org/rfc/rfc4838.txt" />
</reference>
<reference anchor="RFC6256">
<front>
<title>Using Self-Delimiting Numeric Values in Protocols</title>
<author initials="W." surname="Eddy" fullname="W. Eddy">
<organization />
</author>
<author initials="E." surname="Davies" fullname="E. Davies">
<organization />
</author>
<date year="2011" month="May" />
<abstract>
<t>Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6256" />
<format type="TXT" octets="40765" target="http://www.rfc-editor.org/rfc/rfc6256.txt" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list><t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" />
<format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html" />
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" />
</reference>
<reference anchor="RFC5050">
<front>
<title>Bundle Protocol Specification</title>
<author initials="K." surname="Scott" fullname="K. Scott">
<organization />
</author>
<author initials="S." surname="Burleigh" fullname="S. Burleigh">
<organization />
</author>
<date year="2007" month="November" />
<abstract>
<t>This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).</t><t> This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5050" />
<format type="TXT" octets="120435" target="http://www.rfc-editor.org/rfc/rfc5050.txt" />
</reference>
<reference anchor="RFC6257">
<front>
<title>Bundle Security Protocol Specification</title>
<author initials="S." surname="Symington" fullname="S. Symington">
<organization />
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization />
</author>
<author initials="H." surname="Weiss" fullname="H. Weiss">
<organization />
</author>
<author initials="P." surname="Lovell" fullname="P. Lovell">
<organization />
</author>
<date year="2011" month="May" />
<abstract>
<t>This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.</t><t> This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6257" />
<format type="TXT" octets="142509" target="http://www.rfc-editor.org/rfc/rfc6257.txt" />
</reference>
<reference anchor="tolerance">
<front>
<title>Defining Tolerance: Impacts of Delay and Didruption when
Managing Challenged Networks</title>
<author initials="E.B." surname="Birrane">
<organization />
</author>
<author initials="S.B." surname="Burleigh">
<organization />
</author>
<author initials="V.C." surname="Cerf">
<organization />
</author>
<date year="2001" />
</front>
</reference>
<reference anchor="DTNM">
<front>
<title>DTN Network management: The Definition and Exchange of
Infrastructure Information in High Delay Environments</title>
<author initials="E.B." surname="Birrane">
<organization />
</author>
<author initials="H.K." surname="Kruse">
<organization />
</author>
<date month="" year="" />
</front>
</reference>
</references>
<!--
<references title="Informative References">
&RFC5050;
</references>
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:44:54 |