| Delay-Tolerant Networking | E. Birrane |
| Internet-Draft | Johns Hopkins Applied Physics Laboratory |
| Intended status: Experimental | J. Mayer |
| Expires: September 21, 2016 | INSYEN AG |
| March 20, 2016 |
Asynchronous Management Protocol
draft-birrane-dtn-amp-02
This document describes an Asynchronous Management Protocol (AMP) conformant with an Asynchronous Management Architecture (AMA). The AMP provides monitoring and configuration services between managing devices (Managers) and managed devices (Agents), some of which may operate on the far side of high-delay or high-disruption links. The AMP minimizes the number of transmitted bytes, operates without sessions or (concurrent) two-way links, and functions autonomously when there is no timely contact with a network operator. The AMP accomplishes this without requiring mobile code and generally reduces the processor, memory, and storage requirements of implementing Managers and Agents.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 21, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies an Asynchronous Management Protocol (AMP) that provides application-layer network management services over links where propagation delays or link disruptions prevent timely communications between a network operator and a managed device. The AMP is conformant to the Asynchronous Management Architecture [AMA].
Network management protocols define the messages that implement management functions amongst managed and managing devices in a network. These functions include the definition, production, and reporting of performance data, the application of administrative policy, and the configuration of behavior based on local time and state measurements.
Networks whose communication links are frequently challenged by physical or administrative effects may not provide the guarantee of low-latency, duplex data communications necessary to support sessions and other synchronous communication. For such networks, an asynchronous management protocol is required which provides familiar network management services in the absence of sessions and operator-in-the-loop control.
AMP 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 several desirable properties outlined in [AMA] and briefly listed below.
+----------+----------+
| Field 1 | Field 2 |
| [TYPE 1] | [TYPE 2] |
| | (opt) |
+----------+----------+
Figure 1: Byte Field Formatting Example
The AMP provides data monitoring, administration, and configuration for applications operating above the data link layer of the OSI networking model. While the AMP may be configured to support the management of network layer protocols, it also uses these protocol stacks to encapsulate and communicate its own messages.
It is assumed that the protocols used to carry AMP 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.
This document describes the format of the AMP messages exchanged amongst managing and managed devices in a challenged network. This document further describes the rationale behind key design decisions to the extent that such a description informs the operational deployment and configuration of an AMP implementation. This document does not address specific data configurations of AMP-enabled devices, nor does it discuss the interface between AMP and other management protocols, such as SNMP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Note: The terms "Actor", "Agent", "Application Data Model", "Atomic Data", "Computed Data", "Controls", "Macros", "Managers", and "Reports" are exactly conformant with those definitions as provided in [AMA]. Brief versions of these definitions are provided in this document as an aid to the reader, but the AMA specification should be read for a complete understanding of these concepts.
This section identifies those terms critical to understanding the proper operation of the AMP. Whenever possible, these terms align in both word selection and meaning with their analogs from other management protocols and with the AMA.
This section identifies the data types used to capture information within the AMP. The data model consists of the description of basic type definitions, compound type definitions, naming schemes, and type enumerations.
Basic types are those that are not comprised of any other set of types known to the AMP.
The AMP supports types for unsigned bytes, 32/64-bit signed and unsigned integers, and 32/64-bit floating point values, as outlined in Table 1.
| AMP ID | BitWidth | Description |
|---|---|---|
| BYTE | 8 | unsigned byte value |
| INT | 32 | Signed integer in 2's complement |
| UINT | 32 | Unsigned integer in 2's complement |
| VAST | 64 | Signed integer in 2's complement |
| UVAST | 64 | Unsigned integer in 2's complement |
| REAL32 | 32 | Single-precision, 32-bit floating point value in IEEE-754 format. |
| REAL64 | 64 | Double-precision, 64-bit floating point value in IEEE-754 format. |
The data type "SDNV" refers to a Self-Delimiting Numerical Value (SDNV) described in [RFC6256]. SDNVs are used in the AMP to capture any data items that are expected to be 8 bytes or less in total length. AMP Actors MAY reject any value encoded in an SDNV that is greater than 8 bytes in length.
One popular use of ADNVs in the AMP is to compress the representation of 32/64-bit integer values. This simplifies the AMP by not having to additionally support 8/16-bit versions of integers without incurring significant transmission waste when encoding small numbers into 32/64-bit representations.
Unless otherwise noted, all basic data types are encoded in the SDNV format within the AMP specification.
Timestamps represent time within the AMP. For compatibility with a variety of protocols, the use of UTC time is selected to represent all time values in the AMP. However, timestamps in AMP may represent either absolute or relative time based on the associated AMP Epoch.
AMP uses September 9th, 2012 as the timestamp epoch (UTC time 1348025776). Times 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 AMP timestamp is encoded as an SDNV to avoid the 32-bit 2038 UTC rollover problem.
IF (timestamp < 1348025776) THEN
absolute_time = current_time + timestamp
ELSE
absolute_time = timestamp
The absolute time associated with a timestamp can be calculated by an AMP Actor with the following pseudocode.
The AMP supports the string type as an ordered collection of byte values assumed terminated by a special NULL-terminator value of 0. Within the AMP, the String type is almost always deprecated in favor of the BLOB type (which asserts the data value first).
A Binary Large Object (BLOB) is an ordered collection of bytes prefaced by the number of bytes making up the BLOB. The format of a BLOB is illustrated in Figure 2. BLOBs are used in the AMP to capture variable data sets that are too large to efficiently store in an SDNV.
Binary Large Object Format
+---------+--------+--------+ +--------+
| # Bytes | BYTE 1 | BYTE 2 | ... | BYTE N |
| [SDNV] | [BYTE] | [BYTE] | | [BYTE] |
+---------+--------+--------+ +--------+
Figure 2: Binary Large Object Format
Often, multiple BLOBs must be communicated in the AMP. A Data Collection (DC) is an ordered set of BLOBs, prefaced by the number of BLOBs making up the collection. The format of a DC is illustrated in Figure 3.
Data Collection
+---------+--------+--------+ +--------+
| # BLOBs | BLOB 1 | BLOB 2 | ... | BLOB N |
| [SDNV] | [BLOB] | [BLOB] | | [BLOB] |
+---------+--------+--------+ +--------+
Figure 3: Data Collection Format
When Data Collections are used to convey parameters for AMP controls, or otherwise used to capture the "return" values of controls, the data SHOULD be annotated with the associated type for each data in the collection. The Typed Data Collection (TDC) provides this augmentation. A TDC is a regular DC with one additional BLOB added to the collection to capture type information. This "Type BLOB" stores the type of each other entry in the DC in a byte.
The TDC format is illustrated in Figure 4
Typed Data Collection
+---------+-----------+-------------+ +-------------+
| # BLOBs | TYPE BLOB | DATA BLOB 1 | ... | DATA BLOB N |
| [SDNV] | [BLOB] | [BLOB] | | [BLOB] |
+---------+-----------+-------------+ +-------------+
Figure 4: Typed Data Collection Format
For example, consider a Data Collection of 3 BLOBs, with BLOB 1 having type UINT, BLOB 2 having type VAST, and BLOB 3 having type SDNV. The DC structure has no way of capturing this type information. The corresponding TDC would have 4 BLOBs. BLOB 1 would have length 3 and contain the enumerations for UINT, VAST, and SDNV - each encoded in one byte. BLOBs 2, 3, and 4 would be the original data. This example is illustrated in Figure 5.
Typed Data Collection Example
DC TDC
+---------------------+ +--------------------------------+
| # BLOBs = {3} | | # BLOBs = {4} |
+---------------------+ +--------------------------------+
| BLOB 1 = {DATA1,...}|--------+ | TYPE BLOB = {UINT, VAST, SNDV} |
+---------------------+ | +--------------------------------+
| BLOB 2 = {DATA2,...}|-----+ +->| DATA BLOB 1 = {DATA1,...} |
+---------------------+ | +--------------------------------+
| BLOB 3 = {DATA3,...}|--+ +---->| DATA BLOB 2 = {DATA2,...} |
+---------------------+ | +--------------------------------+
+------->| DATA BLOB 3 = {DATA3,...} |
+--------------------------------+
Figure 5: Typed Data Collection Example
Data structures defined and exchanged within the AMP must be uniquely identifiable both within a network and (when AMP is used in an overlay) across networks. This section describes the "Managed Identifier" (MID) which is the single data structure used to provide unique naming for the AMP data structures defined in Section 4. The MID is a variable-length structure with optional fields that encapsulates all of the information and annotation necessary to identify an AMP structure.
The MID consists of a mandatory flag byte, a mandoatory unique identifier, and optional annotations to assist with filtering, access control, and parameterization. The unique identifier at the core of a MID is based on the Object Identifier (OID) and its Basic Encoding Rules (BER) as identified in the ITU-T X.690 standard. The specifics of the OID encoding are provided below.
The use of OIDs in the MID structure allows Agents and Managers to interface with other management schemes (such as SNMP) at management boundaries between challenged and un-challenged networks.
The MID structure is comprised of up to four fields, as illustrated in Figure 6.
MID format
+--------+--------+--------+--------+
| Flags | Issuer | OID | Tag |
| [BYTE] | [SDNV] |[VARIED]| [SDNV] |
| | (opt) | | (opt) |
+--------+--------+--------+--------+
Figure 6: Managed Identifier Format
The MID fields are defined as follows.
MID Flag Format
+-----+---+---+------------+
| OID |TAG|ISS| STRUCT ID |
+-----+---+---+------------+
| 7 6 | 5 | 4 | 3 2 1 0 |
+-----+---+---+------------+
MSB LSB
Figure 7
+----------+
| Full OID |
| [BLOB] |
+----++----+
||
||
_____________________/ \_________________________
/ \
+------------+---------+---------+ +---------+
| OID Length | Octet 1 | Octet 2 | ... | Octet N |
| [SDNV] | [BYTE] | [BYTE] | | [BYTE] |
+------------+---------+---------+ +---------+
Figure 8: Full OID Format
+----------+------------+
| FULL OID | Parameters |
| [BLOB] | [TDC] |
+----------+-----++-----+
||
||
__________________/ \____________________________________
/ \
+----------+------------+--------+--------+ +--------+
| # Params | Parm Types | Parm 1 | Parm 2 | | Parm N |
| [SDNV] | [BLOB] | [BLOB] | [BLOB] | ... | [BLOB] |
+----------+------------+--------+--------+ +--------+
Figure 9: Parameterized OID Format
+----------+--------------+
| Nickname | Relative OID |
| [SDNV] | [BLOB] |
+----------+--------------+
Figure 10: Compressed OID Format
Compressed Parameterized OID Format
+----------+--------------+------------+
| Nickname | Relative OID | Parameters |
| [SDNV] | [BLOB] | [TDC] |
+----------+--------------+------------+
Figure 11: Compressed Parameterized OID Format
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 0x91 indicates a computed data value with an issuer field, but no tag field encapsulating a compressed OID.
Parameterized OIDs provide a powerful mechanism for customizing the behavior of the AMP Agent both through expressive operator-constructed controls and (where appropriate) auto-generated values based on autonomous processing. As discussed above, parameters are represented as a TDC appended to an OID as part of the definition of a parameterized OID structure. The parameters specified within the TDC may be represented in one of two ways: the parameter itself (parameter as value), or a computed value that holds the parameter (parameter as reference).
NOTE: parameterized values (such as those for controls and literal definitions) are formally defined in ADMs with a well-known, static typing. The type value associated with the TDC in a parameter list is used to provide type-checking safety to ensure that the given parameters match expected parameter types. It is important to understand that the types in the parameter TDC DO NOT define the parameterized interface to a control or literal - only the ADM defining the control or literal defines the typed interface.
When specifying a parameter using a value, the BYTE representing the parameter type MUST be set to the expected parameter type and the BLOB representing the parameter contents MUST be set to the parameter value.
For example, consider a parameterized OID that takes 1 parameter, which it expects to be an unsigned integer (UINT). When populating this parameter by value, the type of the populated parameter field MUST be set to UINT and the parameter value MUST set to the hard-coded unsigned integer, say "4".
The specifying of parameter values by asserting their value directly in the parameterized OID is the default case for most parameters and it is recommended that this approach be taken when specifying any parameter value if the value is both unlikely to change and is known at the time of generating the parameterized OID.
When the value of a parameter is likely to change, then a computed value (CD) definition may be substituted for the parameter value. When it comes time to interpret the parameter value, the current value of the computed value may be substituted. The details of the CD structure are given in Section 4.3.
A parameter provided as a reference MUST be of type Computed Data (CD). When evaluating a parameter within a parameterized OID, if the parameter type is of type CD then the type of the CD MUST match the expected type of the parameter. If the type of the CD does not match the expected parameter type then the Agent MUST consider this a type mismatch.
NOTE: If the expected type of the parameter is already CD, and a parameter of type CD is provided, then the system MUST interpret the CD as if it were a parameter as value. The AMP specification DOES NOT support a CD which references another CD as doing so leads to significant confusion in implementations and the possibility of circular reference.
The determination of whether a parameter has been provided as a value or as a reference is made by comparing the given type of the parameter to the expected type of the parameter (as specified in some ADM).
If the parameter type and the expected type match, then the parameter MUST be considered as a value itself.
If the parameter type is a CD whose type matches the expected type, then the CD in the parameter MUST be considered a reference to the actual parameter and the value of the CD MUST be used on each evaluation of the parameter.
In any other case, the parameter MUST be considered invalid as being from a type mismatch.
In addition to the data types already mentioned, the following special data types are also defined.
+--------+-------+ +-------+
| # MIDs | MID 1 | ... | MID N |
| [SDNV] | [MID] | | [MID] |
+--------+-------+ +-------+
Figure 12: MID Collection
A MID collection is comprised of a value identifying the number of MIDs in the collection, followed by each MID, as illustrated in Figure 12.
+------------+
| Expression |
| [MC] |
+------------+
Figure 13
Expressions apply operations to data and literal values to generate new data values. The expression type in AMP is a collection of MIDs that represent a postfix notation stack of Data, Literal, and Operation types. For example, the infix expression A * (B * C) is represented as the sequence A B C * *. The format of an expression is illustrated in Figure 13.
Predicates are expressions whose values are interpreted 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 (MC).
Several data structured within the AMP are defined as a named collection of other named entities. For example, a Macro is a named collection of Controls; a Report is a named collection of other data items; a computed data definition is a named expression which, from above, is a collection of MIDs representing the postfix notation of the calculating function.
+--------+----------+------------+
| Def ID | Def Type | Definition |
| [MID] | [BYTE] | [MC] |
+--------+----------+------------+
Figure 14: Definition Format
The Definition (DEF) type captures instances where the AMP refers to a named, typed collection of information. The format of a DEF is illustrated in Figure 14.
This section identifies the basic structures that comprise the data items exchanged in the AMP, including the definition of these structures based on the aforementioned data model and the behavior of AMP Actors when interacting with these structures.
The AMA defines a series of logical components that should be included as part of an asynchronous management protocol. These components are summarized from the AMA in the following table.
| Component | Summary Description |
|---|---|
| Primitive Data | A typed, measured value whose definition does not change. |
| Computed Data | A value computed from primitive data and other computed data. |
| Report | Collection of primitive and/or computed data and/or other reports. |
| Control | Parameterized opcode for an action that can be taken by an Agent. |
| Rule | A pre-configured response to a pre-defined state on an Agent. |
| Macro | An ordered collection of controls. |
| Literal | A constant used when evaluated rules or computing data. |
| Operator | An opcode representing a mathematical function known to an Agent. |
The AMP implements these logical components in largely a one-to-one fashion with the exception that the AMP defines two types of autonomous rules: time-based and state-based. This section describes the format of these data structures in the context of the aforementioned AMP data types. NOTE: The expression of these structures is only to describe how these structures appear in messages exchanged between and amongst Agents and Managers in a challenged network. Individual software applications may choose their own most efficient internal representation of these structures.
Primitive Data are pre-defined as part of ADMs for various applications and protocols. These represent values that are directly measured by firmware on Agents rather than computed as a function of other data in the system.
+-------+
| ID |
| [MID] |
+-------+
Figure 15: Primitive Data Format
The representation of these data is simply their identifying MIDs. The representation of a primitive data item is illustrated in Figure 15.
Managers
Agents
Computed data are either as defined in an ADM or tactically by operators in a particular network. Computed data differ from Primitive Data in that they are completely described by other known data in the system (either other Computed Data, or other Primitive Data). For example, letting P# be a Primitive Data item and C# be a Computed Data item, the following are examples of Computed Data definitions.
C1 = P1 * P2
C2 = C1 + P3
+---------------+--------+
| Computed Data | Flags |
| [DEF] | [BYTE] |
+-------++------+--------+
||
||
____________/ \_______________
/ \
+-------+--------+------------+
| ID | TYPE | Definition |
| [MID] | [BYTE] | [EXPR] |
+-------+--------+------------+
Figure 16: Computed Data Format
Computed data are defined by the DEF triplet (ID, TYPE, EXPR) and a set of processing flags, as illustrated in Figure 16.
CD Processing Flags Format
+-----------+-----+-----+-----+
| RESERVED | ERR | ENA | STK |
+-----------+-----+-----+-----+
| 7 - 3 | 2 | 1 | 0 |
+-----------+-----+-----+-----+
MSB LSB
Figure 17
Managers
Agents
Reports capture information generated by Agents and transmitted to Managers in the AMP. Since the AMP is an asynchronous protocol there is no explicit association between the contents of a report and a generating action by either a Manager or an Agent.
Note that reports in the AMP are NOT key-value pairs. The definition of the report is assumed known by the Agent producing the report and the Manager receiving the report. Similarly, when a report captured the return of a control, the format of the return value is assumed known to the Agent and Manager. This approach results in a significant space saving when communicating reports in the network.
A report is a named, typed data collection. Each BLOB within the typed data collection is referred to as a report entry. Reports are generated in one of three scenarios: (1) when a report is explicitly requested, (2) when a rule determines that a report should be generated, and (3) when a control runs and generates a return value that is sent as a report.
When a report is generated by command or by rule, then the report is given a unique identifier either by the ADM defining the report, or by an operator defining a report as part of network configuration. When a report is generated ad-hoc to capture the return value of a control, the report identifier is the same as the identifier of the control whose return value it captures.
+-------+---------+
| ID | Entries |
| [MID] | [TDC] |
+-------+---++----+
||
||
___________________________/ \__________________________________
/ \
+-----------+-------------+---------+---------+ +---------+
| # Entries | Entry Types | Entry 1 | Entry 2 | | Entry N |
| [SDNV] | [BLOB] | [BLOB] | [BLOB] | ... | [BLOB] |
+-----------+-------------+---------+---------+ +---------+
Figure 18: Report Format
The definition of a report is illustrated in Figure 18.
Managers
Agents
A Control represents a pre-defined (possibly parameterized) opcode that can be run on an Agent. Controls in the AMP are always defined in the context of an ADM. There is no concept of an operator-defined control, as controls represent the opcodes of actions taken directly by the firmware. Since Controls are pre-configured in Agents and Managers as part of ADM support, their representation is simply the MID that identifies them, similar to Primitive Data.
One difference between the definition of Controls and Primitive Data is that Controls may accept parameters. This is accomplished by using a parameterized OID in the MID identifying the Control.
+-------+
| ID |
| [MID] |
+-------+
Figure 19: Control Format
The format of a Control is illustrated in Figure 19.
Managers
Agents
A Time-Based Rule (TRL) specifies that a particular action should be taken by an Agent based on some time interval. A TRL specifies that starting at a particular START time, and for every PERIOD seconds thereafter, an ACTION should be run by the Agent until the ACTION has been run for COUNT times. When the TRL is no longer valid it MAY BE discarded by the Agent.
Examples of TRLs include:
+-------+-------+--------+--------+--------+-------+
| ID | START | PERIOD | COUNT | ACTION | FLAGS |
| [MID] | [TS] | [SDNV] | [SDNV] | [MC] |[BYTE] |
+-------+-------+--------+--------+--------+-------+
Figure 20: Time-Based Rule Format
The format of a TRL is illustrated in Figure 20.
CD Processing Flags Format
+------------+-----+-----+
| RESERVED | ERR | ENA |
+------------+-----+-----+
| 7 - 2 | 1 | 0 |
+------------+-----+-----+
MSB LSB
Figure 21
Managers
Agents
A State-Based Rule (SRL) specifies that a particular action should be taken by an Agent based on some evaluation of the internal state of the Agent. A SRL specifies that starting at a particular START time, and for every PERIOD seconds thereafter, an ACTION should be run by the Agent if some CONDITION evaluates to true, until the CONDITION has been evaluated COUNT times. When the SRL is no longer valid it MAY BE discarded by the Agent.
Examples of SRLs include:
+-------+-------+--------+--------+--------+-------+-------+--------+
| ID | START | COND | COUNT | ACTION | FLAGS | HIST | THR |
| | | | | | | (opt) | (opt) |
| [MID] | [TS] | [PRED] | [SDNV] | [MC] |[BYTE] |[SDNV] | [SDNV] |
+-------+-------+--------+--------+--------+-------+-------+--------+
Figure 22: State-Based Rule Format
The format of a SRL is illustrated in Figure 22.
CD Processing Flags Format
+-----------+-----+-----+-----+
| RESERVED | THR | ERR | ENA |
+-----------+-----+-----+-----+
| 7 - 3 | 2 | 1 | 0 |
+-----------+-----+-----+-----+
MSB LSB
Figure 23
Managers
Agents
Macros in the AMP are simply ordered collections of MIDs (an MC) that describe Controls or other Macros. When run by an Agent, each MID in the MC is run in order. Similar to a Computed Data definition, a Macro is a named collection of MIDs and is represented by a DEF structure.
While the MIDs representing any given control may be parameterized, the MID associated with a Macro MAY NOT be parameterized.
+-------+
| Macro |
| [DEF] |
+---++--+
||
||
____________/ \_______________
/ \
+-------+--------+------------+
| ID | TYPE | Definition |
| [MID] | [BYTE] | [MC] |
+-------+--------+------------+
Figure 24: Macro Format
The format of a Macro is illustrated in Figure 24.
Managers
Agents
Literals in the AMP represent constants either as defined in an ADM or as specified by a user. Examples of constants that could be defined in an ADM include common mathematical values such as PI or well-known Epochs such as the UNIX Epoch. Examples of constants that could be user-defined as part of expressions include simple numerical values, such as 5 in the expression (A > 5). In both cases, Literals MUST ALWAYS be defined in an ADM, with user-definable Literal values being provided through the MID parameterization mechanism as follows.
The ADM definition of a Literal MUST include the type of the Literal value. Since ADM definitions are preconfigured on Agents and Managers in an AMA the type information for a given Literal is therefore known by all Actors in the system.
If the MID identifying the Literal encapsulates a non-parameterized OID, then the value is given in the ADM and Agents and Managers can lookup this value in their set of pre-configured data.
If the MID identifying the Literal encapsulates a parameterized OID, then the parameters to the OID define the value of the Literal. Users wishing to create a new Literal will create a MID with whatever parameters are necessary to create the value. The documentation of the ADM defining the Literal MUST describe how parameters result in the calculation of the Literal value.
+-------+
| ID |
| [MID] |
+-------+
Figure 25: Control Format
The format of a Literal is illustrated in Figure 25.
Managers
Agents
Operators in the AMP are always defined in the context of an ADM. There is no concept of a user-defined operator, as operators represent mathematical functions implemented by the firmware on an Agent. Since Operators are pre-configured in Agents and Managers as part of ADM support, their representation is simply the MID that identifies them, similar to Primitive Data and Controls.
The ADM definition of an Operator MUST specify how many parameters are expected. For example, the unary NOT Operator ("!") would accept one parameter. The binary PLUS Operator ("+") would accept two parameters. A custom function to calculate the average of the last 10 samples of a data item would accept 10 parameters.
+-------+
| ID |
| [MID] |
+-------+
Figure 26: Operator Format
Operators are always evaluated in the context of an Expression. The format of an Operator is illustrated in Figure 26.
Managers
Agents
This section lists the data type IDs and enumerations for the data types outlined in this section. IDs are the text abbreviations used in this specification and in ADMs to identify data types. Enumerations associate data types with an unsigned integer value. These enumerations MUST be used whenever a data type is represented as a numerical representation, such as the case with the TYPE BLOB of a TDC.
NOTE: Type enumerations are always represented as a BYTE in the AMP.
IDs and enumerations are grouped by the kind of data they represent, as follows. AMP structure identifiers occupy enumerations 0 - 9 and represent AMP data structures that are formally identified by a MID. Basic data types occupy enumerations 10-19 and represent primitive data types in the AMP specification. Compound and special types occupy enumerations 20-30 and represent other data types known to the AMP specification.
| AMP Structure | ID | Enumeration | Numeric |
|---|---|---|---|
| Atomic Data | AD | 0 | No |
| Computed Data | CD | 1 | No |
| Report | RPT | 2 | No |
| Control | CTRL | 4 | No |
| State-Based Rule | SRL | 5 | No |
| Time-Based Rule | TRL | 6 | No |
| Macro | MACRO | 7 | No |
| Literal | LIT | 8 | No |
| Operator | OP | 9 | No |
| Basic Data Type | ID | Enumeration | Numeric |
|---|---|---|---|
| BYTE | BYTE | 10 | No |
| Signed 32-bit Integer | INT | 11 | Yes |
| Unsigned 32-bit Integer | UINT | 12 | Yes |
| Signed 64-bit Integer | VAST | 13 | Yes |
| Unsigned 64-bit Integer | UVAST | 14 | Yes |
| Single-Precision Floating Point | REAL32 | 15 | Yes |
| Double-Precision Floating Point | REAL64 | 16 | Yes |
| Self-Delineating Numerical Value | SDNV | 17 | No |
| Timestamp | TS | 18 | No |
| Compound/Special Data Type | ID | Enumeration | Numeric |
|---|---|---|---|
| Character String | STR | 20 | No |
| Binary Large Object | BLOB | 21 | No |
| Managed Identifier | MID | 22 | No |
| MID Collection | MC | 23 | No |
| Expression | EXPR | 24 | No |
| Definition | DEF | 25 | No |
| Data Collection | DC | 26 | No |
| Typed Data Collection | TDC | 27 | No |
An application data model (ADM) specifies the set of AMP 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 AMP 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.
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.
Each ADM specifies the globally unique identifiers and descriptions for all data, controls, literals, and operators associated with the application or protocol managed 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.
ADM definitions specify the metadata, data, controls, literals, and operators associated with a managed application or protocol.
ADM metadata consist of the items necessary to uniquely identify the ADM itself. The required metadata items include the following.
| Item | Type | Description | Req. |
|---|---|---|---|
| Name | STR | The human-readable name of the ADM. | Y |
| Version | STR | Version of the ADM encoded as a string. | Y |
| OID Nickname N | OID | 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 arbitrary number of nicknames defined for an ADM. | N |
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.
The full set of Primitive Data, Computed Data, Reports, Controls, Rules, Macros, Literals, and Operators that can be understood by an AMP Agent have been separated into an AMP Agent ADM. Just as the AMP uses ADMs to manage applications and protocols, the ADM model is also used to implement the functionality of the Agent. As such, the AMP message specification is limited to three basic communications: Section 8.
as outlined in
The entire management of a network can be performed using these three messages and the configurations from associated ADMs.
This section describes the format of the messages that comprise the AMP protocol. When discussing the format/types of data that comprise message fields, the following conventions are used.
+--------+-----------+-----------+ +-----------+
| # Msgs | Timestamp | Message 1 | ... | Message N |
| [SDNV] | [TS] | [VAR] | | [VAR] |
+--------+-----------+-----------+ +-----------+
Figure 27: AMP Message Group Format
Individual messages within the AMP are combined into a single group for communication with another AMP Actor. Messages within a group MUST be received and applied as an atomic unit. The format of a message group is illustrated in Figure 27. These message groups are assumed communicated amongst Agents and Managers as the payloads of encapsulating protocols which MAY provide additional security and data integrity features.
+--------+-------+---------+
| Header | Body | Trailer |
| [BYTE] | [VAR] | [VAR] |
| | | (opt.) |
+--------+-------+---------+
Figure 28: AMP Message Format
+--------+----+---+---------+-------+
|ACL Used|Nack|Ack| Context |Opcode |
+--------+----+---+---------+-------+
| 7 | 6 | 5 | 4 3 | 2 1 0 |
+--------+----+---+---------+-------+
MSB LSB
Figure 29: AMP Common Message Header
Each message identified in the AMP specification adheres to a common message format, illustrated in Figure 28, consisting of a message header, a message body, and an optional trailer.
+----------+
| Agent ID |
| [SDNV] |
+----------+
Figure 30: Register Agent Message Body
The Register Agent message is used to inform a AMP manager of the presence of another agent in the network.
+------+----------+-------+-------+ +-------+
| Time | Num Rpts | RPT 1 | RPT 2 | | RPT N |
| [TS] | [SDNV] | [RPT] | [RPT] | ... | [RPT] |
+------+----------+-------+-------+ +-------+
Figure 31: Data Report Message Body
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.
+-------+-----------+
| Start | Controls |
| [TS] | [MC] |
+-------+-----------+
Figure 32: Perform Control Message Body
The perform control method causes the receiving AMP Actor to apply one or more pre-configured controls provided in the form of a Macro.
At this time, this protocol has no fields registered by IANA. However, such a registry MUST be established to capture certain data elements provided in ADMs, such as nicknames and root OIDs.
Security within the AMP exists in two layers: transport layer security and access control.
Transport-layer security addresses the questions of authentication, integrity, and confidentiality associated with the transport of messages between and amongst Managers and Agents. This security is applied before any particular Actor in the system receives data and, therefore, is outside of the scope of this document.
Finer grain application security is done via ACLs provided in the AMP message headers.
| [AMA] | Birrane, E., "Asynchronous Management Architecture", Internet-Draft draft-birrane-dtn-ama-00, August 2015. |
| [I-D.irtf-dtnrg-dtnmp] | Birrane, E. and V. Ramachandran, "Delay Tolerant Network Management Protocol", Internet-Draft draft-irtf-dtnrg-dtnmp-01, December 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6256] | Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 2011. |
The following participants contributed technical material, use cases, and useful thoughts on the overall approach to this protocol specification: Jeremy Pierce-Mayer of INSYEN AG contributed the concept of the typed data collection and early type checking in the protocol and has agreed to document the access control list and error reporting portion of the specification.