< draft-birrane-dtn-amp-06.txt   draft-birrane-dtn-amp-07.txt >
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft Johns Hopkins Applied Physics Laboratory Internet-Draft Johns Hopkins Applied Physics Laboratory
Intended status: Standards Track March 11, 2019 Intended status: Standards Track July 7, 2019
Expires: September 12, 2019 Expires: January 8, 2020
Asynchronous Management Protocol Asynchronous Management Protocol
draft-birrane-dtn-amp-06 draft-birrane-dtn-amp-07
Abstract Abstract
This document describes a binary encoding of the Asynchronous This document describes a binary encoding of the Asynchronous
Management Model (AMM) and a protocol for the exchange of these Management Model (AMM) and a protocol for the exchange of these
encoded items over a network. This Asynchronous Management Protocol encoded items over a network. This Asynchronous Management Protocol
(AMP) does not require transport-layer sessions, operates over (AMP) does not require transport-layer sessions, operates over
unidirectional links, and seeks to reduce the energy and compute unidirectional links, and seeks to reduce the energy and compute
power necessary for performing network management on resource power necessary for performing network management on resource
constrained devices. constrained devices.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
7.1.5. ADM Enumeration Considerations . . . . . . . . . . . 9 7.1.5. ADM Enumeration Considerations . . . . . . . . . . . 9
8. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. CBOR Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. CBOR Considerations . . . . . . . . . . . . . . . . . . . 9
8.2. AMM Type Encodings . . . . . . . . . . . . . . . . . . . 10 8.2. AMM Type Encodings . . . . . . . . . . . . . . . . . . . 10
8.2.1. Primitive Types . . . . . . . . . . . . . . . . . . . 10 8.2.1. Primitive Types . . . . . . . . . . . . . . . . . . . 10
8.2.2. Derived Types . . . . . . . . . . . . . . . . . . . . 11 8.2.2. Derived Types . . . . . . . . . . . . . . . . . . . . 11
8.2.3. Collections . . . . . . . . . . . . . . . . . . . . . 14 8.2.3. Collections . . . . . . . . . . . . . . . . . . . . . 14
8.3. AMM Resource Identifier (ARI) . . . . . . . . . . . . . . 19 8.3. AMM Resource Identifier (ARI) . . . . . . . . . . . . . . 19
8.3.1. Encoding ARIs of Type LITERAL . . . . . . . . . . . . 19 8.3.1. Encoding ARIs of Type LITERAL . . . . . . . . . . . . 19
8.3.2. Encoding Non-Literal ARIs . . . . . . . . . . . . . . 20 8.3.2. Encoding Non-Literal ARIs . . . . . . . . . . . . . . 20
8.4. ADM Object Encodings . . . . . . . . . . . . . . . . . . 22 8.4. ADM Object Encodings . . . . . . . . . . . . . . . . . . 23
8.4.1. Externally Defined Data (EDD) . . . . . . . . . . . . 23 8.4.1. Externally Defined Data (EDD) . . . . . . . . . . . . 23
8.4.2. Constants (CONST) . . . . . . . . . . . . . . . . . . 23 8.4.2. Constants (CONST) . . . . . . . . . . . . . . . . . . 24
8.4.3. Controls (CTRL) . . . . . . . . . . . . . . . . . . . 24 8.4.3. Controls (CTRL) . . . . . . . . . . . . . . . . . . . 24
8.4.4. Macros (MAC) . . . . . . . . . . . . . . . . . . . . 24 8.4.4. Macros (MAC) . . . . . . . . . . . . . . . . . . . . 25
8.4.5. Operators (OPER) . . . . . . . . . . . . . . . . . . 25 8.4.5. Operators (OPER) . . . . . . . . . . . . . . . . . . 26
8.4.6. Report Templates (RPTT) . . . . . . . . . . . . . . . 26 8.4.6. Report Templates (RPTT) . . . . . . . . . . . . . . . 26
8.4.7. Report (RPT) . . . . . . . . . . . . . . . . . . . . 26 8.4.7. Report (RPT) . . . . . . . . . . . . . . . . . . . . 27
8.4.8. State-Based Rules (SBR) . . . . . . . . . . . . . . . 28 8.4.8. State-Based Rules (SBR) . . . . . . . . . . . . . . . 28
8.4.9. Table Templates (TBLT) . . . . . . . . . . . . . . . 29 8.4.9. Table Templates (TBLT) . . . . . . . . . . . . . . . 30
8.4.10. Tables (TBL) . . . . . . . . . . . . . . . . . . . . 30 8.4.10. Tables (TBL) . . . . . . . . . . . . . . . . . . . . 30
8.4.11. Time-Based Rules (TBR) . . . . . . . . . . . . . . . 31 8.4.11. Time-Based Rules (TBR) . . . . . . . . . . . . . . . 31
8.4.12. Variables (VAR) . . . . . . . . . . . . . . . . . . . 32 8.4.12. Variables (VAR) . . . . . . . . . . . . . . . . . . . 33
9. Functional Specification . . . . . . . . . . . . . . . . . . 33 9. Functional Specification . . . . . . . . . . . . . . . . . . 33
9.1. AMP Message Summary . . . . . . . . . . . . . . . . . . . 33 9.1. AMP Message Summary . . . . . . . . . . . . . . . . . . . 33
9.2. Message Group Format . . . . . . . . . . . . . . . . . . 34 9.2. Message Group Format . . . . . . . . . . . . . . . . . . 34
9.3. Message Format . . . . . . . . . . . . . . . . . . . . . 35 9.3. Message Format . . . . . . . . . . . . . . . . . . . . . 35
9.4. Register Agent . . . . . . . . . . . . . . . . . . . . . 36 9.4. Register Agent . . . . . . . . . . . . . . . . . . . . . 37
9.5. Report Set . . . . . . . . . . . . . . . . . . . . . . . 37 9.5. Report Set . . . . . . . . . . . . . . . . . . . . . . . 37
9.6. Perform Control . . . . . . . . . . . . . . . . . . . . . 37 9.6. Perform Control . . . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9.7. Table Set . . . . . . . . . . . . . . . . . . . . . . . . 38
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
12. Implementation Notes . . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 12. Implementation Notes . . . . . . . . . . . . . . . . . . . . 39
13.1. Informative References . . . . . . . . . . . . . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.2. Normative References . . . . . . . . . . . . . . . . . . 39 13.1. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 13.2. Normative References . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Network management in challenged and resource constrained networks Network management in challenged and resource constrained networks
must be accomplished differently than the network management methods must be accomplished differently than the network management methods
in high-rate, high-availability networks. The Asynchronous in high-rate, high-availability networks. The Asynchronous
Management Architecture (AMA) [I-D.birrane-dtn-ama] provides an Management Architecture (AMA) [I-D.birrane-dtn-ama] provides an
overview and justification of an alternative to "synchronous" overview and justification of an alternative to "synchronous"
management services such as those provided by NETCONF. In management services such as those provided by NETCONF. In
particular, the AMA defines the need for a flexible, robust, and particular, the AMA defines the need for a flexible, robust, and
skipping to change at page 5, line 26 skipping to change at page 5, line 26
(Big Endian). (Big Endian).
o Character encodings for all text-based data types will use UTF-8 o Character encodings for all text-based data types will use UTF-8
encodings. encodings.
o All AMP encodings are self-terminating. This means that, given an o All AMP encodings are self-terminating. This means that, given an
indefinite-length octet stream, each encoding can be unambiguously indefinite-length octet stream, each encoding can be unambiguously
decoded from the stream without requiring additional information decoded from the stream without requiring additional information
such as a length field separate from the data type definition. such as a length field separate from the data type definition.
o This specification uses the term OCTETS to refer to a sequence of
one or more BYTE values. There is no implied structure associated
with OCTETS, meaning they do not encode a length value or utilize
a terminator character. While OCTETS may contain CBOR-encoded
values, the OCTETS sequence itself is not encoded as a CBOR
structure.
o Bit-fields in this document are specified with bit position 0 o Bit-fields in this document are specified with bit position 0
holding the least-significant bit (LSB). When illustrated in this holding the least-significant bit (LSB). When illustrated in this
document, the LSB appears on the right. document, the LSB appears on the right.
o In order to describe the encoding of data models specified in o In order to describe the encoding of data models specified in
[I-D.birrane-dtn-adm], this specification must refer to both the [I-D.birrane-dtn-adm], this specification must refer to both the
data object being encoded and to the encoding of that data object. data object being encoded and to the encoding of that data object.
When discussing the encoded version of a data object, this When discussing the encoded version of a data object, this
specification uses the notation "E(data_object)" where E() refers specification uses the notation "E(data_object)" where E() refers
to a conceptual encoding function. This notation is only provided to a conceptual encoding function. This notation is only provided
skipping to change at page 10, line 8 skipping to change at page 10, line 8
o All AMP encodings are of definite length and, therefore, o All AMP encodings are of definite length and, therefore,
indefinite encodings MUST NOT be used. indefinite encodings MUST NOT be used.
o AMP encodings MUST NOT use CBOR tags. Identification mechanisms o AMP encodings MUST NOT use CBOR tags. Identification mechanisms
in the AMP capture structure and other information such that tags in the AMP capture structure and other information such that tags
are not necessary. are not necessary.
o Canonical CBOR MUST be used for all encoding. All AMP CBOR o Canonical CBOR MUST be used for all encoding. All AMP CBOR
decoders MUST run in strict mode. decoders MUST run in strict mode.
o Because AMA objects are self-delineating they can be serialized
into, or deserialized from, OCTETS. CBOR containers such as
BYTESTR and TXTSTR that encode length fields are only useful for
data that is not self-delineating, such as name fields. Encoding
self-delineating objects into CBOR containers reduced efficiency
as length fields would then be added to data that does not reqire
a length field for processing.
o Encodings MUST result in smallest data representations. There are o Encodings MUST result in smallest data representations. There are
several cases where the AMM defines types with less granularity several cases where the AMM defines types with less granularity
than CBOR. For example, AMM defines the UINT type to represent than CBOR. For example, AMM defines the UINT type to represent
unsigned integers up to 32 bits in length. CBOR supports separate unsigned integers up to 32 bits in length. CBOR supports separate
definitions of unsigned integers of 8, 16, or 32 bits in length. definitions of unsigned integers of 8, 16, or 32 bits in length.
In cases where an AMM type MAY be encoded in multiple ways in In cases where an AMM type MAY be encoded in multiple ways in
CBOR, the smallest data representation MUST be used. For example, CBOR, the smallest data representation MUST be used. For example,
UINT values of 0-255 MUST be encoded as a uint8_t, and so on. UINT values of 0-255 MUST be encoded as a uint8_t, and so on.
8.2. AMM Type Encodings 8.2. AMM Type Encodings
skipping to change at page 15, line 23 skipping to change at page 15, line 23
appearing first. appearing first.
Extracting type information to the "front" of the collection Extracting type information to the "front" of the collection
optimizes the performance of type validators. A validator can optimizes the performance of type validators. A validator can
inspect the first array to ensure that element values match type inspect the first array to ensure that element values match type
expectations. If type information were distributed throughout the expectations. If type information were distributed throughout the
collection, as in the case with the TNVC, a type validator would need collection, as in the case with the TNVC, a type validator would need
to scan through the entire set of data to validate each type in the to scan through the entire set of data to validate each type in the
collection. collection.
A TNVC is encoded as a CBOR array with at least one element, the A TNVC is encoded as a sequence of at least 1 octet, where the single
flags which represent the optional portions of the collection that required octet includes the flag BYTE representing the optional
are present. If the TNVC represents an empty set, there will be no portions of the collection that are present. If the flag BYTE
additional entries. The format of a TNVC is illustrated in Figure 4. indicates an empty collection there will be no following octets.The
format of a TNVC is illustrated in Figure 4.
+----------+ +----------+
| TNVC | | TNVC |
| [ARRAY] | | [OCTETS] |
+----++----+ +----++----+
|| ||
|| ||
______________________/ \_______________________ ____________________________/ \_____________________________
/ \ / \
+--------+-----------+---------+---------+---------+ +--------+---------+----------+----------+----------+----------+
| Flags | Types | Names | Values | Mixed | | Flags | # Items | Types | Names | Values | Mixed |
| [BYTE] | [BYTESTR] | [ARRAY] | [ARRAY] | [ARRAY] | | [BYTE] | [UINT] | [OCTETS] | [OCTETS] | [OCTETS] | [OCTETS] |
| | (Opt) | (Opt) | (Opt) | (Opt) | | | (Opt) | (Opt) | (Opt) | (Opt) | (Opt) |
+--------+-----------+---------+---------+---------+ +--------+---------+----------+----------+----------+----------+
Figure 4: E(TNVC) Format Figure 4: E(TNVC) Format
The E(TNVC) fields are defined as follows. The E(TNVC) fields are defined as follows.
Flags Flags
The first byte of the E(TNVC) describes which optional The first byte of the E(TNVC) describes which optional
portions of a TNV will be present for each TNV in the portions of a TNV will be present for each TNV in the
collection. The layout of this byte is illustrated in collection.
Figure 5.
If all non-reserved flags have the value 0 then the TNVC
represents an empty collection, in which case no other
information is provided for the E(TNVC).
The layout of this byte is illustrated in Figure 5.
E(TNV) Flag Byte Format E(TNV) Flag Byte Format
+----------+------+------+------+------+ +----------+------+------+------+------+
| Reserved | Mix | Type | Name | Val | | Reserved | Mix | Type | Name | Val |
| Flags | Flag | Flag | Flag | Flag | | Flags | Flag | Flag | Flag | Flag |
+----------+------+------+------+------+ +----------+------+------+------+------+
| 7-4 | 3 | 2 | 1 | 0 | | 7-4 | 3 | 2 | 1 | 0 |
+----------+------+------+------+------+ +----------+------+------+------+------+
MSB LSB MSB LSB
Figure 5 Figure 5
Type Flag Mixed Flag
This flag indicates that the set of TNVs in the This flag indicates that the set of TNVs in the
collection do not all share the same properties and, collection do not all share the same properties and,
therefore, the collection is a mix of different types therefore, the collection is a mix of different types
of TNV. When set to 1 the E(TNVC) MUST contain the of TNV. When set to 1 the E(TNVC) MUST contain the
Mixed Values field and all other flags in this byte Mixed Values field and all other flags in this byte
MUST be set to 0. When set to 0 the E(TNVC) MUST NOT MUST be set to 0. When set to 0 the E(TNVC) MUST NOT
contain the Mixed Values field. contain the Mixed Values field.
Type Flag Type Flag
This flag indicates whether each TNV in the This flag indicates whether each TNV in the
skipping to change at page 16, line 47 skipping to change at page 16, line 52
information for each TNV. When set to 0, name information for each TNV. When set to 0, name
information MUST NOT be present. information MUST NOT be present.
Value Flag Value Flag
This flag indicates whether each TNV in the This flag indicates whether each TNV in the
collection has value information associated with it. collection has value information associated with it.
When set to 1 the E(TNVC) MUST contain value When set to 1 the E(TNVC) MUST contain value
information for each TNV. When set to 0, value information for each TNV. When set to 0, value
information MUST NOT be present. information MUST NOT be present.
# Items
The number of items field lists the number of items that are
contained in the TNVC. Each of the types, names, and values
sequences (if present) MUST have exactly this number of
entries in them. This field MUST be present in the E(TNVC)
when any one of the non-reserved bits of the Flag Byte are
set to 1.
Types Types
The types field is encoded as a CBOR byte string with length The types field is encoded as an OCTETS sequence where the
equal to the number of items in the collection. The Nth byte Nth byte in the sequence represents the type for the Nth TNV
in the byte string represents the type for the Nth TNV in the in the collection. This field MUST be present in the E(TNVC)
collection. This field MUST be present in the E(TNVC) when when the Type Flag is set to 1 and MUST NOT be present
the Type Flag is set to 1 and MUST NOT be present otherwise. otherwise. If present, this field MUST contain exactly the
same number of types as number of items in the TNVX.
Names Names
The names field is encoded as a CBOR array with one entry for The names field is encoded as an OCTETS sequence containing
each item in the collection. Each entry in the array is the names of the TNVs in the collection. Each name is
encoded as a CBOR string and represents the name of a TNV in encoded as a CBOR string, with the Nth CBOR string
the collection. The Nth string in the array represents the representing the name of the Nth TNV in the collection. This
name for the Nth TNV in the collection. This field MUST be field MUST be present in the E(TNVC) when the Names Flag is
present in the E(TNVC) when the Name Flag is set to 1 and set to 1 and MUST NOT be present otherwise. If present, this
MUST NOT be present otherwise. field MUST contain exactly the same number of CBOR strings as
number of items in the TNVC.
Values Values
The values field is encoded as a CBOR array with one entry The values field is encoded as an OCTETS sequence containing
for each item in the collection. Each entry in the array is the values of TNVs in the collection.
encoded as follows. If the Type Flag is set to 1 then each If the Type Flag is set to 1 then each entry will be encoded
entry will be encoded in accordance with the corresponding in accordance with the corresponding index in the type field.
index in the type field. For example, the 1st entry in the For example, the 1st value will be encoded using the encoding
value array will be encoded as the first entry in the type rules for the first byte in the type OCTETS sequence.
bytestring. If the Type Flag is set to 0 then the entries in If the Type Flag is set to 0 then the values will be encoded
the value array will be encoded as a native CBOR type. CBOR as native CBOR types. CBOR types do not have a one-to-one
types do not have a one-to-one mapping with AMP types and it mapping with AMP types and it is the responsibility of the
is the responsibility of the transmitting AMP actor and the transmitting AMP actor and the receiving AMP actor to
receiving AMP actor to determine how to map these to AMP determine how to map these to AMP types. This field MUST be
types. This field MUST be present in the E(TNVC) when the present in the E(TNVC) when the Value Flag is set to 1 and
Value Flag is set to 1 and MUST NOT be present otherwise. MUST NOT be present otherwise. If present, this field MUST
contain exactly the same number of values as number of items
in the TNVC.
Mixed Mixed
The mixed field is encoded as a CBOR array with one entry for The mixed field is encoded as an OCTETS sequence containing a
each item in the collection. Each entry in the array series of E(TNV) objects. This field MUST be present when
contains a E(TNV). This field MUST be present in the E(TNVC) the Mixed Flag is set to 1 and MUST NOT be present otherwise.
when the Mix Flag is set to 1 and MUST NOT be present If present, this field MUST contain exactly the same number
otherwise. of E(TNV) objects as numnber of items in the TNVC.
8.2.3.2. ARI Collections (AC) 8.2.3.2. ARI Collections (AC)
An ARI collection is an ordered collection of ARI values. It is An ARI collection is an ordered collection of ARI values. It is
encoded as a CBOR array with each element being an encoded ARI, as encoded as a CBOR array with each element being an encoded ARI, as
illustrated in Figure 6. illustrated in Figure 6.
E(AC) Format E(AC) Format
+---------+ +---------+
skipping to change at page 18, line 28 skipping to change at page 18, line 34
+-------+ +-------+ +-------+ +-------+
Figure 6 Figure 6
8.2.3.3. Expressions (EXPR) 8.2.3.3. Expressions (EXPR)
The Expression object encapsulates a typed postfix expression in The Expression object encapsulates a typed postfix expression in
which each operator MUST be of type OPER and each operand MUST be the which each operator MUST be of type OPER and each operand MUST be the
typed result of an operator or one of EDD, VAR, LIT, or CONST. typed result of an operator or one of EDD, VAR, LIT, or CONST.
The Expression object is encoded as a CBOR byte string whose format The Expression object is encoded as an OCTETS sequence whose format
is illustrated in Figure 7. is illustrated in Figure 7.
E(EXPR) Format E(EXPR) Format
+--------+------------+ +----------+
| Type | Expression | | EXPR |
| [BYTE] | [AC] | | [OCTETS] |
+--------+------------+ +-----++---+
||
||
_________/ \_________
/ \
+---------+------------+
| Type | Expression |
| [BYTE] | [AC] |
+---------+------------+
Figure 7 Figure 7
Type Type
The enumeration representing the type of the result of the The enumeration representing the type of the result of the
evaluated expression. This type MUST be defined in evaluated expression. This type MUST be defined in
[I-D.birrane-dtn-adm] as a "Primitive Type". [I-D.birrane-dtn-adm] as a "Primitive Type".
Expression Expression
An expression is represented in the AMP as an ARI collection, An expression is represented in the AMP as an ARI collection,
skipping to change at page 19, line 18 skipping to change at page 19, line 28
object. There are two kinds of objects that can be identified in object. There are two kinds of objects that can be identified in
this scheme: literal objects (of type LIT) and all other objects. this scheme: literal objects (of type LIT) and all other objects.
8.3.1. Encoding ARIs of Type LITERAL 8.3.1. Encoding ARIs of Type LITERAL
A literal identifier is one that is literally defined by its value, A literal identifier is one that is literally defined by its value,
such as numbers (0, 3.14) and strings ("example"). ARIs of type such as numbers (0, 3.14) and strings ("example"). ARIs of type
LITERAL do not have issuers or nicknames or parameters. They are LITERAL do not have issuers or nicknames or parameters. They are
simply typed basic values. simply typed basic values.
The E(ARI) of a LIT object is encoded as a CBOR byte string and The E(ARI) of a LIT object is encoded as an OCTETS sequence and
consists of a mandatory flag BYTE and the value of the LIT. consists of a mandatory flag BYTE and the value of the LIT.
The E(ARI) structure for LIT types is illustrated in Figure 8. The E(ARI) structure for LIT types is illustrated in Figure 8.
E(ARI) Literal Format E(ARI) Literal Format
+--------+----------+ +--------+----------+
| Flags | Value | | Flags | Value |
| [BYTE] | [VARIES] | | [BYTE] | [VARIES] |
+--------+----------+ +--------+----------+
skipping to change at page 19, line 41 skipping to change at page 20, line 7
These fields are defined as follows. These fields are defined as follows.
Flags Flags
The Flags byte identifies the object as being of type LIT and The Flags byte identifies the object as being of type LIT and
also captures the primitive type of the following value. The also captures the primitive type of the following value. The
layout of this byte is illustrated in Figure 9. layout of this byte is illustrated in Figure 9.
E(ARI) Literal Flag Byte Format E(ARI) Literal Flag Byte Format
+------------+-------------+ +-------------------+-------------+
| VALUE TYPE | STRUCT TYPE | | VALUE TYPE OFFSET | STRUCT TYPE |
+------------+-------------| +-------------------+-------------|
| 7 6 5 4 | 3 2 1 0 | | 7 6 5 4 | 3 2 1 0 |
+------------+-------------+ +-------------------+-------------+
MSB LSB MSB LSB
Figure 9 Figure 9
Value Type Value Type Offset
The high nibble of the flag byte describes the type The high nibble of the flag byte contains the offset
of the value of the ARI being encoded. This type into the Primitive Types enumeration defined in
MUST be one of the AMM data types defined in [I-D.birrane-dtn-adm]. An offset of 0 represents the
[I-D.birrane-dtn-adm] as a "Primitive Type". first defined Primitive Type. An offset of 1
represents the second defined Primitive Type, and so
on. An offset into the data types field is used to
ensure that they type value fits into a nibble.
Structure Type Structure Type
The lower nibble of the flag byte identifies the type The lower nibble of the flag byte identifies the type
of AMM Object being identified by the ARI. In this of AMM Object being identified by the ARI. In this
instance, this value MUST be LIT, as defined in instance, this value MUST be LIT, as defined in
[I-D.birrane-dtn-adm]. [I-D.birrane-dtn-adm].
Value Value
This field captures the CBOR encoding of the value. Values This field captures the CBOR encoding of the value. Values
are encoded according to their Value Type as specified in the are encoded according to their Value Type as specified in the
skipping to change at page 20, line 29 skipping to change at page 20, line 47
8.3.2. Encoding Non-Literal ARIs 8.3.2. Encoding Non-Literal ARIs
All other ARIs are defined in the context of AMM objects and may All other ARIs are defined in the context of AMM objects and may
contain parameters and other meta-data. The AMP, as a machine-to- contain parameters and other meta-data. The AMP, as a machine-to-
machine binary encoding of this information removes human-readable machine binary encoding of this information removes human-readable
information such as Name and Description from the E(ARI). information such as Name and Description from the E(ARI).
Additionally, this encoding adds other information to improve the Additionally, this encoding adds other information to improve the
efficiency of the encoding, such as the concept of Nicknames, defined efficiency of the encoding, such as the concept of Nicknames, defined
in Section 7.1. in Section 7.1.
The E(ARI) is encoded as a CBOR byte string and consists of a The E(ARI) is encoded as an OCTETS sequence and consists of a
mandatory flag byte, an encoded object name, and optional annotations mandatory flag byte, an encoded object name, and optional annotations
to assist with filtering, access control, and parameterization. The to assist with filtering, access control, and parameterization. The
E(ARI) structure is illustrated in Figure 10. E(ARI) structure is illustrated in Figure 10.
E(ARI) General Format E(ARI) General Format
+--------+---------+-----------+---------+---------+-----------+ +--------+---------+-----------+---------+---------+-----------+
| Flags | NN | Name | Parms | Issuer | Tag | | Flags | NN | Name | Parms | Issuer | Tag |
| [BYTE] | [UVAST] | [BYTESTR] | [TNVC] | [UVAST] | [BYTESTR] | | [BYTE] | [UVAST] | [BYTESTR] | [TNVC] | [UVAST] | [BYTESTR] |
| | (opt) | | (opt) | (opt) | opt) | | | (opt) | | (opt) | (opt) | opt) |
skipping to change at page 28, line 29 skipping to change at page 29, line 13
longer valid it may be discarded by the agent. longer valid it may be discarded by the agent.
Examples of SBRs include: Examples of SBRs include:
Starting 2 hours from receipt, whenever V1 > 10, produce a Report Starting 2 hours from receipt, whenever V1 > 10, produce a Report
for Report Template R1 no more than 20 times. for Report Template R1 no more than 20 times.
Starting at some future absolute time, whenever V2 != V4, run Starting at some future absolute time, whenever V2 != V4, run
Macro M1 no more than 36 times. Macro M1 no more than 36 times.
An SBR object is encoded as a CBOR array with 5 elements as An SBR object is encoded as an OCTETS sequence as illustrated in
illustrated in Figure 19. Figure 19.
E(SBR) Format E(SBR) Format
+---------+ +----------+
| SBR | | SBR |
| [ARRAY] | | [OCTETS] |
+---++----+ +----++----+
|| ||
|| ||
_______________________/ \_______________________ _______________________/ \_______________________
/ \ / \
+-------+-------+--------+--------+--------+--------+ +-------+-------+--------+--------+--------+--------+
| ID | START | COND | EVALS | FIRES | ACTION | | ID | START | COND | EVALS | FIRES | ACTION |
| [ARI] | [TV] | [EXPR] | [UINT] | [UINT] | [AC] | | [ARI] | [TV] | [EXPR] | [UINT] | [UINT] | [AC] |
+-------+-------+--------+--------+--------+--------+ +-------+-------+--------+--------+--------+--------+
Figure 19 Figure 19
skipping to change at page 31, line 33 skipping to change at page 32, line 8
discarded by the Agent. discarded by the Agent.
Examples of TBRs include: Examples of TBRs include:
Starting 2 hours from receipt, produce a Report for Report Starting 2 hours from receipt, produce a Report for Report
Template R1 every 10 hours ending after 20 times. Template R1 every 10 hours ending after 20 times.
Starting at the given absolute time, run Macro M1 every 24 hours Starting at the given absolute time, run Macro M1 every 24 hours
ending after 365 times. ending after 365 times.
The TBR object is encoded as a CBOR array with 5 elements as The TBR object is encoded as an OCTETS sequence as illustrated in
illustrated in Figure 22. Figure 22.
E(TBR) Format E(TBR) Format
+---------+ +----------+
| TBR | | TBR |
| [ARRAY] | | [OCTETS] |
+---++----+ +----++----+
|| ||
|| ||
___________________/ \___________________ ___________________/ \___________________
/ \ / \
+-------+-------+--------+--------+--------+ +-------+-------+--------+--------+--------+
| ID | START | PERIOD | COUNT | ACTION | | ID | START | PERIOD | COUNT | ACTION |
| [ARI] | [TV] | [UINT] | [UINT] | [AC] | | [ARI] | [TV] | [UINT] | [UINT] | [AC] |
+-------+-------+--------+--------+--------+ +-------+-------+--------+--------+--------+
Figure 22 Figure 22
skipping to change at page 32, line 36 skipping to change at page 33, line 10
the action. This is encoded as an ARI Collection in the action. This is encoded as an ARI Collection in
accordance with Section 8.2.3.2 with the stipulation that accordance with Section 8.2.3.2 with the stipulation that
every ARI in this collection MUST represent either a Control every ARI in this collection MUST represent either a Control
or a Macro. or a Macro.
8.4.12. Variables (VAR) 8.4.12. Variables (VAR)
Variable objects are transmitted in the AMP without the human- Variable objects are transmitted in the AMP without the human-
readable description. readable description.
Variable objects are encoded as a CBOR byte string whose format is Variable objects are encoded as an OCTETS sequence whose format is
illustrated in Figure 23. illustrated in Figure 23.
E(VAR) Format E(VAR) Format
+------------+ +-----------+
| Variable | | Variable |
| [BYTESTR] | | [OCTETS] |
+-----++-----+ +-----++----+
|| ||
|| ||
______/ \_____ ______/ \_____
/ \ / \
+-------+-------+ +-------+-------+
| ID | Value | | ID | Value |
| [ARI] | [TNV] | | [ARI] | [TNV] |
+-------+-------+ +-------+-------+
Figure 23 Figure 23
skipping to change at page 34, line 16 skipping to change at page 34, line 16
| Message | Enumeration | Description | | Message | Enumeration | Description |
+------------+-------------+----------------------------------------+ +------------+-------------+----------------------------------------+
| Register | 0 | Add Agents to the list of managed | | Register | 0 | Add Agents to the list of managed |
| Agent | | devices known to a Manager. | | Agent | | devices known to a Manager. |
| | | | | | | |
| Report Set | 1 | Receiving a Report of one or more | | Report Set | 1 | Receiving a Report of one or more |
| | | Report Entries from an Agent. | | | | Report Entries from an Agent. |
| | | | | | | |
| Perform | 2 | Sending a Macro of one or more | | Perform | 2 | Sending a Macro of one or more |
| Control | | Controls to an Agent. | | Control | | Controls to an Agent. |
| | | |
| Table Set | 3 | Receiving one or more tables from an |
| | | Agent. |
+------------+-------------+----------------------------------------+ +------------+-------------+----------------------------------------+
Table 4: ADM Message Type Enumerations Table 4: ADM Message Type Enumerations
The entire management of a network can be performed using these three The entire management of a network can be performed using these three
messages and the configurations from associated ADMs. messages and the configurations from associated ADMs.
9.2. Message Group Format 9.2. Message Group Format
Individual messages within the AMP are combined into a single group Individual messages within the AMP are combined into a single group
skipping to change at page 34, line 49 skipping to change at page 35, line 16
+---------------+ +---------------+
| Message Group | | Message Group |
| [ARRAY] | | [ARRAY] |
+------++-------+ +------++-------+
|| ||
____________________||___________________ ____________________||___________________
/ \ / \
+-----------+-----------+ +-----------+ +-----------+-----------+ +-----------+
| Timestamp | Message 1 | ... | Message N | | Timestamp | Message 1 | ... | Message N |
| [TS] | [BYTESTR] | | [BYTESTR] | | [TS] | [OCTETS] | | [OCTETS] |
+-----------+-----------+ +-----------+ +-----------+-----------+ +-----------+
Figure 24 Figure 24
Timestamp Timestamp
The creation time for this messaging group. Individual The creation time for this messaging group. Individual
messages may have their own creation timestamps based on messages may have their own creation timestamps based on
their type, but the group timestamp also serves as the their type, but the group timestamp also serves as the
default creation timestamp for every message in the group. default creation timestamp for every message in the group.
This is encoded in accordance with Table 3. This is encoded in accordance with Table 3.
Message N Message N
The Nth message in the group. The Nth message in the group.
9.3. Message Format 9.3. Message Format
Each message identified in the AMP specification adheres to a common Each message identified in the AMP specification adheres to a common
message format, illustrated in Figure 25, consisting of a message message format, illustrated in Figure 25, consisting of a message
header, a message body, and an optional trailer. header, a message body, and an optional trailer.
Each message in the AMP is encode as a CBOR byte string formatted in Each message in the AMP is encode as an OCTETS sequence formatted in
accordance with Figure 25. accordance with Figure 25.
AMP Message Format AMP Message Format
+--------+----------+----------+ +--------+----------+----------+
| Header | Body | Trailer | | Header | Body | Trailer |
| [BYTE] | [VARIES] | [VARIES] | | [BYTE] | [VARIES] | [VARIES] |
| | | (opt.) | | | | (opt.) |
+--------+----------+----------+ +--------+----------+----------+
skipping to change at page 38, line 22 skipping to change at page 38, line 39
Figure 29 Figure 29
Start Start
The time at which the Controls/Macros should be run. The time at which the Controls/Macros should be run.
Controls Controls
The collection of ARIs that represent the Controls and/or The collection of ARIs that represent the Controls and/or
Macros to be run by the AMP Actor. Every ARI in this Macros to be run by the AMP Actor. Every ARI in this
collection MUST be either a Control or a Macro. collection MUST be either a Control or a Macro.
9.7. Table Set
The Table Set message contains a set of 1 or more TBLs produced by an
AMP Agent and sent to an AMP Manager.
The body of this message contains information on the recipient of the
tables followed by one or more TBLs. The body is encoded as
illustrated in Figure 30.
Table Set Message Body
+----------+--------+ +--------+
| RX Names | TBL 1 | | TBL N |
| [ARRAY] | [TBL] | ... | [TBL] |
+----------+--------+ +--------+
Figure 30
RX Names
This field captures the set of Managers that have been sent
this table set. This is encoded as a CBOR array that MUST
have at least one entry. Each entry in this array is
encdoded as a CBOR text string.
TBL N
The Nth Table encoded in accordance with Section 8.4.10.
10. IANA Considerations 10. IANA Considerations
A Nickname registry needs to be established. A Nickname registry needs to be established.
11. Security Considerations 11. Security Considerations
Security within the AMP exists in two layers: transport layer Security within the AMP exists in two layers: transport layer
security and access control. security and access control.
Transport-layer security addresses the questions of authentication, Transport-layer security addresses the questions of authentication,
 End of changes. 38 change blocks. 
108 lines changed or deleted 182 lines changed or added

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