<?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">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc tocdep"4"?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>


   
 <rfc category="std" ipr="trust200902" docName="draft-birrane-dtn-amp-08" submissionType="IETF" xml:lang="en">

   <!-- ***** 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="AMP">Asynchronous 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>
      
      <date month="April" year="2020" />

      <!-- Meta-data Declarations -->
      <area>General</area>
      <workgroup>Delay-Tolerant Networking</workgroup>
      <keyword>DTN</keyword>
      <keyword>Network Management</keyword>
      <keyword>Delay-Tolerant 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 document describes a binary encoding of the Asynchronous 
            Management Model (AMM) and a protocol for the exchange of these 
            encoded items over a network. This Asynchronous Management Protocol 
            (AMP) does not require transport-layer sessions, operates over
            unidirectional links, and seeks to reduce the energy and compute
            power necessary for performing network management on resource
            constrained devices.
         </t>
      </abstract>
   </front>
  
   <middle>
      <section title="Introduction" toc="default">
         <t>
            Network management in challenged and resource constrained networks 
            must be accomplished differently than the network management methods 
            in high-rate, high-availability networks. The Asynchronous 
            Management Architecture (AMA) <xref target="I-D.birrane-dtn-ama"/> 
            provides an overview and justification of an alternative to 
            "synchronous" management services such as those provided by NETCONF. 
            In particular, the AMA defines the need for a flexible, robust, and 
            efficient autonomy engine to handle decisions when operators cannot
            be active in the network. The logical description of that autonomous 
            model and its major components is given in the AMA Data Model 
            (ADM) <xref target="I-D.birrane-dtn-adm"/>.
         </t>
         <t>
            The ADM presents an efficient and expressive autonomy model for the 
            asynchronous management of a network node, but does not specify any 
            particular encoding. This document, the Asynchronous Management 
            Protocol (AMP), provides a binary encoding of AMM objects and 
            specifies a protocol for the exchange of these encoded objects. 
         </t>
      </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"/>.
         </t>
      </section>

      <section title="Scope" toc="default">
         <section title="Protocol Scope" toc="default">
            <t> 
               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.
            </t>
            <t>
               It is assumed that the protocols used to carry AMP messages 
               provide addressing, confidentiality, integrity, security, 
               fragmentation/reassembly, and other network functions. 
               Therefore, these items are outside of the scope of 
               this document. 
            </t>
         </section>

         <section title="Specification Scope" toc="default">
            <t>
               This document describes the format of messages used to exchange 
               data models between managing and managed devices in a network. 
               The rationale for this type of exchange is outside of the scope 
               of this document and is covered in  <xref target="I-D.birrane-dtn-ama"/>.
               The description and explanation of the data models exchanged is also
               outside of the scope of this document and is covered in 
               <xref target="I-D.birrane-dtn-adm"/>.
             </t>
             <t>
               This document does not address specific configurations of
               AMP-enabled devices, nor does it discuss the interface between AMP
               and other management protocols. 
            </t>
         </section>
      </section>      
  
   
   <section title="Terminology" toc="default">
      <t>
         Note: The terms "Actor", "Agent", "Application Data Model", 
         "Externally Defined Data", "Variable", "Control", "Literal", "Macro", 
         "Manager", "Report Template", "Report", "Table", "Constant", 
         "Operator", "Time-Based Rule" and "State-Based Rule" are used without 
         modification from the definitions provided in 
         <xref target="I-D.birrane-dtn-ama"/>. 
      </t>
      
   </section>

   <section title="Constraints and Assumptions">
      <t>
         The desirable properties of an asynchronous management protocol, as 
         specified in the AMA, are summarized here to represent design constraints 
         on the AMP specification. 

         <list hangIndent="8" style="symbols">
            <t> 
               Intelligent Push of Information - Nodes in a challenged network 
               cannot guarantee concurrent, bi-directional communications. Some 
               links between nodes may be strictly unidirectional. AMP Agents
               "push" data to Managers rather than Managers "pulling" data from 
               Agents. 
            </t>
            <t>
               Small Message Sizes - Smaller messages require smaller 
               periods of viable transmission for communication,
               incur less retransmission cost, and consume fewer resources when
               persistently stored en route in the network. AMP minimizes
               message size wherever practical, to include binary data 
               representations and predefined data definitions and templates.
            </t>
            <t>
               Absolute and Custom Data Identification - All data in the 
               system must be uniquely addressable, to include operator-specified
               information. AMP provides a compact encoding for identifiers.
            </t>
            <t> 
               Autonomous, Stateless Operation - There is no reliable concept of 
               session establishment or round-trip data exchange in asynchronous
               networks. AMP is designed to be stateless. Where helpful, AMP 
               provides mechanisms for transactional ordering of commands within 
               a single AMP protocol data unit, but otherwise degrades 
               gracefully when nodes in the network diver in their
               configuration.
            </t>
         </list>
      </t>
   </section>

   <section title="Technical Notes" toc="default" anchor="tech_notes">
      <t>
         <list style="symbols">
            <t>
               Unless otherwise specified, multi-byte values in this 
               specification are expected to be transmitted in network byte order 
               (Big Endian).
            </t>
            <t>
               Character encodings for all text-based data types will use UTF-8
               encodings. 
            </t>
            <t>
               All AMP encodings are self-terminating. This means that, given 
               an indefinite-length octet stream, each encoding can be 
               unambiguously decoded from the stream without requiring 
               additional information such as a length field separate from the 
               data type definition.
            </t>
            <t>
               This specification uses the term OCTETS to refer to a sequence
               of one or more related 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. 
            </t>
            <t>
               If an OCTETS sequence is included as an element of a CBOR array
               then the sequence MUST be considered as a single array element
               when determining the size of the array.
            </t>
            <t>
               Bit-fields in this document are specified with bit position 0 
               holding the least-significant bit (LSB). When illustrated in this
               document, the LSB appears on the right.
            </t>
            <t>
               In order to describe the encoding of data models specified
               in <xref target="I-D.birrane-dtn-adm"/>, this specification 
               must refer to both the data object being encoded and to
               the encoding of that data object. When discussing the encoded 
               version of a data object, this specification uses
               the notation "E(data_object)" where E() refers to a 
               conceptual encoding function. This notation is only provided 
               as a means of clarifying the text and imposes no changes to the
               actual wire coding. For example, this specification will refer to
               the "macro" data object as "Macro" and to the encoding of a 
               Macro as "E(Macro)". 
            </t>
            <t>
               Illustrations of fields in this specification consist of the name 
               of the field, the type of the field between []'s, and if the 
               field is optional, the text "(opt)". 
               <vspace blankLines="0"/>
               Field order is deterministic and, therefore, fields MUST be 
               transmitted in the order in which they are specified. In cases 
               where an optional field is not present, then the next field will
               be considered for transmission. 
               <vspace blankLines="0"/>
               An example is shown in <xref target="ex_fig"/> below.
               In this illustration two fields (Field 1 and Field 2) are shown,
               with Field 1 of Type 1 and Field 2 of Type 2.  Field 2 is also
               listed as being optional. Byte fields are shown in order of 
               receipt, from left-to-right. Therefore, when transmitted on 
               the wire, Field 1 will be received first, followed by Field 2 (if
               present). 
               
               <figure anchor="ex_fig" title="Byte Field Formatting Example">
                  <artwork align="center"> &#xA;<!-- 
                     -->+----------+----------+&#xA;<!-- 
                     -->| Field 1  | Field 2  |&#xA;<!-- 
                     -->| [TYPE 1] | [TYPE 2] |&#xA;<!-- 
                     -->|          |  (opt)   |&#xA;<!--               
                     -->+----------+----------+                  
                  </artwork>
               </figure>   

               When types are documented in this way, the type always refers to 
               the encoding of that type. The E() notation is not used as it is
               to be inferred from the context of the illustration.
            </t>
         </list>
      </t>
   </section>

   <section title="AMP-Specific Concepts">
      <t>
         The AMP specification provides an encoding of objects comprising the
         AMM. As such, AMP defines very few structures of its own. This section 
         identifies those data structures that are unique to the AMP and 
         required for it to perform appropriate and efficient encodings of 
         AMM objects. 
      </t>

      <section title="Nicknames (NN)" anchor="nn_chp">
         <t>
            In the AMP, a "Nickname" (NN) is used to reduce the overall size of
            the encoding of ARIs that are defined in the context of an ADM. A
            NN is calculated as a function of an ADM Moderated Namespace and
            the type of object being identified.            
         </t>

         <section title="Motivation for Compression" anchor="ari_comp">
            <t>
               As identifiers, ARIs are used heavily in AMM object definitions,
               particularly in those that define collections of objects. This
               makes encoding ARIs an important consideration when trying to
               optimize the size of AMP message. 
            </t>
            <t>
               Additionally, the majority of ARIs are defined in the context
               of an ADM. Certain AMM objects types (EDDs, OPs, CTRLs, TBLTs) 
               can only be defined in the context of an ADM. Other object types
               (VARs, CONSTs, RPTTs) may have common, useful objects defined
               in an ADM as well. The structure of an ADM, to include its
               use of a Moderated Namespace and collections by object type, 
               provide a regular structure that can be exploited for 
               creating a compact representation.
            </t>
            <t>
               In particular, as specified in <xref target="I-D.birrane-dtn-adm"/>, 
               ARIs can be grouped by (1) their namespace and (2) the type of 
               AMM object being identified. For example, consider the following 
               ARIs of type EDD defined in ADM1 with a Moderated Namespace of
               "/DTN/ADM1/".
            </t>
            <t>
               ari:/DTN/ADM1/Edd.item_1
               ari:/DTN/ADM1/Edd.item_2
               ...
               ari:/DTN/ADM1/Edd.item_1974
            </t>
            <t>
               In this case, the namespace (/DTN/ADM1/) and the object type (Edd)
               are good candidates for enumeration because their string
               encoding is very verbose and their information follows a 
               regular structure shared across multiple ARIs. Separately, 
               the string representation of object names (item_1, item_2, etc...) 
               may be very verbose and they are also candidates for enumeration
               as they occupy a particular ADM object type in a particular
               order as published in the ADM. 
            </t>
         </section>

         <section title="ADM Enumeration" anchor="adm_enum">
            <t>
               Any ARI defined in an ADM exists in the context of a Moderated
               Namespace. These namespaces provide a unique string name for
               the ADM. However, ADMs can also be assigned a unique enumeration
               by the same moderating entities that ensure namespace uniqueness.
            </t>
            <t>
               An ADM enumeration is an unsigned integer in the range of 0 to 
               (2^64)/20. This range provides effective support for thousands 
               of trillions of ADMs.
            </t>
            <t>
               The formal set of ADMs, similar to SNMP MIBs and NETCONF YANG 
               models, will be moderated and published. Additionally, a set of 
               informal ADMs may be developed on a network-by-network or on an 
               organization-by-organization bases. 
            </t>
            <t>
               Since informal ADMs exist within a predefined context (a network, 
               an organization, or some other entity) they do not have individual 
               ADM enumerations and are assigned the special enumeration "0".
               ARIs that are not defined in formal ADMs rely on other context
               information to help with their encoding (see <xref target="e_ari_chp"/>).
            </t>
         </section>

         <section title="ADM Template Collection Enumeration">
            <t>
               The ADM template presented in <xref target="I-D.birrane-dtn-adm"/>
               defines a series of object collections for the specification of 
               various AMM objects. Enumerating these collections in a standard
               way allows for their compressed representation in the context
               of nicknames for objects stored in these collections.
            </t>
            <t>
               The enumeration of ADM Template collections is provided in 
               <xref target="nntype_enums"/> below.
            </t>
            <texttable anchor="nntype_enums" title="ADM Type Enumerations">
               <ttcol align="center">AMM Object Type</ttcol>
               <ttcol align="center">Enumeration</ttcol>
                              
               <c>CONST</c>
               <c>0</c>

               <c>CTRL</c>
               <c>1</c>

               <c>EDD</c>
               <c>2</c>

               <c>MAC</c>
               <c>3</c>

               <c>OPER</c>
               <c>4</c>

               <c>RPTT</c>
               <c>5</c>

               <c>SBR</c>
               <c>6</c>

               <c>TBLT</c>
               <c>7</c>

               <c>TBR</c>
               <c>8</c>

               <c>VAR</c>
               <c>9</c>

               <c>metadata</c>
               <c>10</c>

               <c>reserved</c>
               <c>11-19</c>
            </texttable>

            <t>
               NOTE: Collection enumerations are different from AMM object types.
               For example, the enumeration for the VAR collection (9) in an ADM is
               different from the VAR object type (12). 
            </t>
         </section>

         <section title="Nickname Definition">
            <t>
               As an enumeration, a Nickname is captured as a 64-bit unsigned 
               integer (UVAST) calculated as a function of the ADM enumeration
               and the ADM type enumeration, as follows.
            </t>
            <figure>
               <artwork align="center" xml:space="preserve">&#xA;<!-- 
                 -->NN = ((ADM Enumeration) * 20) + (ADM Object Type Enumeration)
               </artwork>
            </figure>

            <t>
               Considering the example set of ARIs from <xref target="ari_comp"/>,
               assuming that ADM1 has ADM enumeration 9 and given that objects
               in the example were of type EDD, the NN for each of the 1974 
               items would be: (9 * 20) + 2 = 182. In this particular example, 
               the ARI "/DTN/ADM1/Edd.item_1974" can be encoded in 5 bytes: two 
               bytes to CBOR encode the nickname (182) and 3 bytes to CBOR encode 
               the item's offset in the Edd collection (1974). 
            </t>
         </section>

         <section title="ADM Enumeration Considerations">
            <t>
               The assignment of formal ADM enumerations SHOULD take into 
               consideration the nature of the applications and protocols to 
               which the ADM applies. Those ADMs that are likely to be used in 
               challenged networks SHOULD be allocated low enumeration numbers 
               (e.g. those that will fit into 1-2 bytes) while ADMs that are 
               likely to only be used in well resourced networks SHOULD be 
               allocated higher enumeration numbers. It SHOULD NOT be the 
               case that ADM enumerations are allocated on a first-come, 
               first-served basis. It is recommended that ADM enumerations 
               should be labeled based on the number of bytes of the Nickname 
               as a function of the size of the ADM enumeration. These labels 
               are shown in <xref target="nn_label"/>.
            </t>

             <texttable anchor="nn_label" title="ADM Enumerations Labels">
               <ttcol align="center">ADM Enum</ttcol>
               <ttcol align="center">NN Size</ttcol>
               <ttcol align="center">Label</ttcol>
               <ttcol align="center">Comment</ttcol>
                                          
               <c>0x1 - 0xCCC</c>
               <c>1-2 Bytes</c>
               <c>Challenged Networks</c>
               <c>Constraints imposed by physical layer and power.</c>

               <c>0xCCD - 0xCCCCCCC</c>
               <c>3-4 Bytes</c>
               <c>Congested Networks</c>
               <c>Constraints imposed by network traffic.</c>

               <c>&gt;=0xCCCCCCD</c>
               <c>5-8 Bytes</c>
               <c>Resourced Networks</c>
               <c>Generally unconstrained networks.</c>
            </texttable>
         </section>
      </section>
   </section>

   <section title="Encodings">
      <t>
         This section describes the binary encoding of logical data constructs
         using the Concise Binary Object Representation (CBOR) defined in
         <xref target="RFC7049"/>.
      </t>

      <section title="CBOR Considerations">
         <t>
            The following considerations act as guidance for CBOR encoders and
            decoders implementing the AMP. 
         </t>
         <t>
            <list hangIndent="8" style="symbols">
               <t>
                  All AMP encodings are of definite length and, therefore, 
                  indefinite encodings MUST NOT be used.
               </t>
               <t>
                  AMP encodings MUST NOT use CBOR tags. Identification 
                  mechanisms in the AMP capture structure and other information 
                  such that tags are not necessary.
               </t>
               <t>
                  Canonical CBOR MUST be used for all encoding. All AMP CBOR 
                  decoders MUST run in strict mode. 
               </t>
               <t>
                  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. 
               </t>
               <t>
                  Encodings MUST result in smallest data representations. There 
                  are several cases where the AMM defines types with less 
                  granularity than CBOR. For example, AMM defines the UINT type 
                  to represent unsigned integers up to 32 bits in length. CBOR 
                  supports separate 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 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.
               </t>
            </list>
         </t>
      </section>    

      <section title="AMM Type Encodings">
         <section title="Primitive Types" anchor="prim_enc">
            <t>
               The AMP encodes AMM primitive types as outlined in 
               <xref target="std_types"/>.
            </t>
            
            <texttable anchor="std_types" title="Standard Numeric Types">
               <ttcol align="center">AMM Type</ttcol>
               <ttcol align="center">CBOR Major Type</ttcol>               
               <ttcol align="center">Comments</ttcol>
                              
               <c>BYTE</c>
               <c>unsigned int or byte string</c>
               <c>BYTEs are individually encoded as unsigned integers unless the
               are defined as part of a byte string, in which case they are 
               encoded as a single byte in the byte string.</c>
            
               <c>INT</c>
               <c>unsigned integer or negative integer</c>
               <c>INTs are encoded as positive or negative integers from (u)int8_t up to (u)int32_t.</c>

               <c>UINT</c>
               <c>unsigned integer</c>
               <c>UINTs are unsigned integers from uint8_t up to uint32_t.</c>

               <c>VAST</c>
               <c>unsigned integer or negative integer</c>
               <c>VASTs are encoding as positive or negative integers up to (u)int64_t.</c>

               <c>UVAST</c>
               <c>unsigned integer</c>
               <c>VASTs are unsigned integers up to uint64_t.</c>

               <c>REAL32</c>
               <c>floating point</c>
               <c>Up to an IEEE-754 Single Precision Float.</c>

               <c>REAL64</c>
               <c>floating point</c>
               <c>Up to an IEEE-754 Double Precision Float.</c>

               <c>STRING</c>
               <c>text string</c>
               <c>Uses CBOR encoding unmodified.</c>

               <c>BOOL</c>
               <c>Simple Value</c>
               <c>0 is considered FALSE. Any other value is considered TRUE.</c>
            </texttable>            
         </section>

         <section title="Derived Types">
            <t>
               This section provides the CBOR encodings for AMM derived types.
            </t>

            <section title="Byte String Encoding">
               <t>
                  The AMM derived type Byte String (BYTESTR) is encoded as a
                  CBOR byte string.
               </t>
            </section>

            <section title="Time Values (TV) and Timestamps (TS)">
               <t>
                  An TV is encoded as a UVAST. Similarly, a TS is also encoded
                  as a UVAST since a TS is simply an absolute TV.
               </t>
               <t>                  
                  Rather than define two separate encodings for TVs (one for
                  absolute TVs and one for relative TVs) a single, 
                  unambiguous encoding can be generated by defining a 
                  Relative Time Epoch (RTE) and interpreting the type of TV
                  in relation to that epoch. Time values less than the RTE
                  MUST be interpreted as relative times. Time values greater
                  than or equal to the RTE MUST be interpreted as absolute
                  time values. 
               </t>
               <t>
                  A relative TV is encoded as the number of seconds after
                  an initiating event. An absolute TV (and TS) is encoded as the 
                  number of seconds that have elapsed since 1 Jan 2000 00:00:00 
                  (Unix Time 946684800).
               </t>

               <t>
                  The RTE is defined as the timestamp value for September 9th, 
                  2017 (Unix time 1504915200). Since TS values are the number
                  of seconds since 1 Jan 2000 00:00:00, the RTE as a TS value is
                  1504915200 - 946684800 = 558230400.
               </t>

               <t>
                  The potential values of TV, and how they should be
                  interpreted as relative or absolute is illustrated below. 
               
                  <figure>
                     <artwork align="center">&#xA;<!--
                      -->                        Potential Time values                            &#xA;<!--
                      -->          ________________________/\________________________             &#xA;<!--
                      -->         /                                                  \            &#xA;<!--
                      -->               Relative Times            Absolute Times                  &#xA;<!--
                      -->         &lt;------------------------&gt;&lt;------------------------&gt;&#xA;<!--
                      -->              0 - 558,230,400          558,230,401 - 2^64                &#xA;<!--
                      -->                                                                         &#xA;<!--
                      -->         |------------------------|-------------------------|            &#xA;<!--
                      -->         |                        |                                      &#xA;<!--
                      -->00:00:00 1 Jan 2000      00:00:00 9 Sep 2017                             &#xA;<!--
                      -->Unix Time 946684800      Unix Time 1504915200
                     </artwork>
                  </figure>
               </t>

               <t>
                  For example, a time value of "10" is a relative time
                  representing 10 seconds after an initiating event. A time 
                  value of "600,000,000" refers to Saturday, 5 Jan, 2019 
                  10:40:00.
               </t>

               <t>
                  NOTE: Absolute and relative times are interchangeable. An 
                  absolute time can be converted into a relative time by 
                  subtracting the current time from the absolute time. A relative 
                  time can be converted into an absolute time by adding to the 
                  relative time the timestamp of its relative event. A 
                  pseudo-code example of converting a relative time to an 
                  absolute time is as follows, assuming that current-time is 
                  expressed in Unix Epoch time.

                  <figure>
                     <artwork>&#xA;<!--
                        -->IF (time_value &lt;= 558230400) THEN &#xA;<!--
                        -->  absolute_time = (event_time - 946684800) + time_value&#xA;<!--
                        -->ELSE &#xA;<!--
                        -->  absolute_time = time_value
                     </artwork>
                  </figure>
               </t>                 
            </section>

            <section title="Type-Name-Value (TNV)" anchor="etnv_chp">
               <t>
                  TNV values are encoded as a CBOR array that comprises four 
                  distinct pieces of information: a set of flags, a type, an 
                  optional name, and an optional value. In the E(TNV) the flag and 
                  type information are compressed into a single value. The CBOR 
                  array MUST have length 1, 2, or 3 depending on the number of 
                  optional fields appearing in the encoding. The E(TNV) format is
                  illustrated in <xref target="tnv_fig"/>.

                  <figure align="center" anchor="tnv_fig" title="E(TNV) Format">
                     <artwork align="center" xml:space="preserve">&#xA;<!--
                        -->            +---------+                     &#xA;<!--
                        -->            |   TNV   |                     &#xA;<!--
                        -->            | [ARRAY] |                     &#xA;<!--
                        -->            +----++---+                     &#xA;<!--                     
                        -->                 ||                         &#xA;<!--
                        -->                 ||                         &#xA;<!--
                        --> _______________/  \________________  &#xA;<!--
                        -->/                                   \&#xA;<!--
                        -->+------------+-----------+----------+&#xA;<!--
                        -->| Flags/Type |    Name   |   Value  |&#xA;<!--
                        -->|   [BYTE]   | [TXT STR] | [Varies] |&#xA;<!--
                        -->|            |   (opt)   |   (opt)  |&#xA;<!--
                        -->+------------+-----------+----------+
                     </artwork>
                  </figure>
               </t>

               <t>
                  The E(TNV) fields are defined as follows.
                  
                  <list hangIndent="8" style="hanging">
                     <t hangText="Flags/Type"><vspace blankLines="0" /> 
                        The first byte of the E(TNV) describes the type associated
                        with the TNV and which optional components are present.
                        The layout of this byte is illustrated in 
                        <xref target="etnv_flag"/>.
                    
                        <figure align="center" anchor="etnv_flag">
                           <preamble>E(TNV) Flag/Type Byte Format</preamble>
                           <artwork align="center" xml:space="preserve">&#xA;<!--
                              -->+------+---------------+&#xA;<!--
                              -->| Name |    Struct     |&#xA;<!--
                              -->| Flag |     Type      |&#xA;<!--
                              -->+------+---------------+&#xA;<!--
                              -->|  7   | 6 5 4 3 2 1 0 |&#xA;<!--
                              -->+------+---------------+&#xA;<!--
                               -->MSB                     LSB
                           </artwork>
                        </figure>
                        
                        <list hangIndent="8" style="hanging">
                           <t hangText="Name Flag"><vspace blankLines="0"/>
                              This flag indicates that the TNV contains a name field.
                              When set to 1 the Name field MUST be present in the
                              E(TNV). When set to 0 the Name field MUST NOT be present
                              in the E(TNV).
                           </t>

                           <t hangText="Struct Type"><vspace blankLines="0" /> 
                              This field lists the type associated with this TNV and
                              MUST contain one of the types defined in 
                              <xref target="I-D.birrane-dtn-adm"/> with the exception
                              that the type of a TNV MUST NOT be a TNV. 
                           </t>
                        </list>
                     </t>
                     
                     <t hangText="Name"> <vspace blankLines="0"/>
                        This optional field captures the human-readable name for
                        the TNV encoded as a CBOR text string. If there are 3
                        elements in the TNV array OR there are 2 elements in the 
                        array and the Name Flag is set, then this field MUST be
                        present. Otherwise, this field MUST NOT be present.
                     </t>

                     <t hangText="Value"> <vspace blankLines="0"/>
                        This optional field captures the encoded value associated
                        with this TNV. The value is encoded in accordance with
                        AMP rules for encoding of items of the type of this TNV.
                        If there are 3 elements in the TNV array OR there are 2
                        elements in the array and the Name Flag is not set, then
                        this field MUST be present. Otherwise, this field MUST NOT
                        be present.
                     </t>
                  </list>
               </t>
            </section>
         </section>

         <section title="Collections">

            <section title="Type-Name-Value Collection (TNVC)" anchor="tnvc_chp">
               <t>
                  A TNV Collection (TNVC) is an ordered set of TNVs with special
                  semantics for more efficiently encoding sets of TNVs with
                  identical attributes. 
               </t>
               <t>
                  A TNV, defined in <xref target="etnv_chp"/>, consists of three 
                  distinct components: a type, a name, and a value. When all of 
                  the TNVs in the TNVC have the same format (such 
                  as they all include type information) then the encoding of the
                  TNVC can use this information to save encoding space and
                  make processing more efficient. In cases when all TNVs have 
                  the same format, the types (if present), names (if present), 
                  and values (if present) are separated into their own arrays 
                  for individual processing with type information (if present) 
                  always appearing first.
               </t>

               <t>
                  Extracting type information to the "front" of the collection
                  optimizes the performance of type validators.  A validator can
                  inspect the first array to ensure that element values match type
                  expectations.  If type information were distributed throughout the
                  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
                  collection. 
               </t>

               <t>
                  A TNVC is encoded as a sequence of at least 1 octet, where the
                  single required octet includes the flag BYTE representing the 
                  optional portions of the collection that are present. If the 
                  flag BYTE indicates an empty collection there will be no 
                  following octets.The
                  format of a TNVC is illustrated in <xref target="tnvc_fig"/>.

                  <figure align="center" anchor="tnvc_fig" title="E(TNVC) Format">
                     <artwork align="center" xml:space="preserve">&#xA;<!--
                        -->                        +----------+     &#xA;<!--
                        -->                        |   TNVC   |     &#xA;<!--
                        -->                        | [OCTETS] |     &#xA;<!--
                        -->                        +----++----+     &#xA;<!--                     
                        -->                             ||          &#xA;<!--
                        -->                             ||          &#xA;<!--
                        --> ____________________________/  \_____________________________ &#xA;<!--
                        -->/                                                             \&#xA;<!--
                        -->+--------+---------+----------+----------+----------+----------+&#xA;<!--
                        -->| Flags  | # Items |  Types   |  Names   |  Values  |  Mixed   |&#xA;<!--
                        -->| [BYTE] |  [UINT] | [OCTETS] | [OCTETS] | [OCTETS] | [OCTETS] |&#xA;<!--
                        -->|        |  (Opt)  |  (Opt)   |  (Opt)   |  (Opt)   |  (Opt)   |&#xA;<!--
                        -->+--------+---------+----------+----------+----------+----------+
                     </artwork>
                  </figure>               
               </t>
 
               <t>
                  The E(TNVC) fields are defined as follows.
                     
                  <list hangIndent="8" style="hanging">
                     <t hangText="Flags"><vspace blankLines="0" /> 
                        The first byte of the E(TNVC) describes which optional
                        portions of a TNV will be present for each TNV in the
                        collection. 
                        <vspace blankLines="0" />
                        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).
                        <vspace blankLines="0" />
                        The layout of this byte is illustrated in 
                        <xref target="etnvc_flag"/>.
                    
                        <figure align="center" anchor="etnvc_flag">
                           <preamble>E(TNV) Flag Byte Format</preamble>
                           <artwork align="center" xml:space="preserve">&#xA;<!--
                              -->+----------+------+------+------+------+&#xA;<!--
                              -->| Reserved | Mix  | Type | Name | Val  |&#xA;<!--
                              -->|  Flags   | Flag | Flag | Flag | Flag |&#xA;<!--
                              -->+----------+------+------+------+------+&#xA;<!--
                              -->|    7-4   |   3  |   2  |   1  |   0  |&#xA;<!--
                              -->+----------+------+------+------+------+&#xA;<!--
                               -->MSB                              LSB
                           </artwork>
                        </figure>

                        <list hangIndent="8" style="hanging">
                           <t hangText="Mixed Flag"><vspace blankLines="0"/>
                              This flag indicates that the set of TNVs in the
                              collection do not all share the same properties
                              and, therefore, the collection is a mix of
                              different types of TNV. When set to 1 the
                              E(TNVC) MUST contain the Mixed Values field and
                              all other flags in this byte MUST be set to 0.
                              When set to 0 the E(TNVC) MUST NOT contain the
                              Mixed Values field.
                           </t>

                           <t hangText="Type Flag"><vspace blankLines="0"/>
                              This flag indicates whether each TNV in the 
                              collection has type information associated with 
                              it. When set to 1 the E(TNVC) MUST contain type
                              information for each TNV.  When set to 0, type
                              information MUST NOT be present.
                           </t>

                           <t hangText="Name Flag"><vspace blankLines="0"/>
                              This flag indicates whether each TNV in the 
                              collection has name information associated with 
                              it. When set to 1 the E(TNVC) MUST contain name
                              information for each TNV.  When set to 0, name
                              information MUST NOT be present.
                           </t>

                           <t hangText="Value Flag"><vspace blankLines="0"/>
                              This flag indicates whether each TNV in the 
                              collection has value information associated with 
                              it. When set to 1 the E(TNVC) MUST contain value
                              information for each TNV.  When set to 0, value
                              information MUST NOT be present.
                           </t>
                        </list>
                     </t>

                     <t hangText="# Items"><vspace blankLines="0" /> 
                        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.
                     </t>

                     <t hangText="Types"><vspace blankLines="0" /> 
                        The types field is encoded as an OCTETS sequence where
                        the Nth byte in the sequence represents the type for
                        the Nth TNV in the collection. This field MUST be 
                        present in the E(TNVC) when the Type Flag is set to 1
                        and MUST NOT be present otherwise. If present, this
                        field MUST contain exactly the same number of types
                        as number of items in the TNVC.
                     </t>

                     <t hangText="Names"><vspace blankLines="0" /> 
                        The names field is encoded as an OCTETS sequence 
                        containing the names of the TNVs in the collection.
                        Each name is encoded as a CBOR string, with the
                        Nth CBOR string representing the name of the Nth 
                        TNV in the collection. This field MUST be present in
                        the E(TNVC) when the Names Flag is set to 1 and
                        MUST NOT be present otherwise. If present, this 
                        field MUST contain exactly the same number of
                        CBOR strings as number of items in the TNVC.
                     </t>
                     <t hangText="Values"><vspace blankLines="0" /> 
                        The values field is encoded as an OCTETS sequence 
                        containing the values of TNVs in the collection.
                        <vspace blankLines="0" />
                        If the Type Flag is set to 1 then each entry will be 
                        encoded in accordance with the corresponding index 
                        in the type field. For example, the 1st value will be 
                        encoded using the encoding rules for the first byte
                        in the type OCTETS sequence. 
                        <vspace blankLines="0" />
                        If the Type Flag is set to 0 then the values will be
                        encoded as native CBOR types. CBOR types do not have
                        a one-to-one mapping with AMP types and it is the
                        responsibility of the transmitting AMP actor and the
                        receiving AMP actor to determine how to map these to 
                        AMP types. This field MUST be present in the E(TNVC) 
                        when the Value Flag is set to 1 and MUST NOT be present 
                        otherwise. If present, this field MUST contain exactly
                        the same number of values as number of items in the
                        TNVC.
                     </t>
                     <t hangText="Mixed"><vspace blankLines="0" /> 
                        The mixed field is encoded as an OCTETS sequence
                        containing a series of E(TNV) objects. This field
                        MUST be present when the Mixed Flag is set to 1 and
                        MUST NOT be present otherwise. If present, this field
                        MUST contain exactly the same number of E(TNV) objects
                        as numnber of items in the TNVC.  
                     </t>
                  </list>
               </t>
            </section>

            <section title="ARI Collections (AC)" anchor="ac_chp">
               <t>
                  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 illustrated in <xref target="e_ac"/>. 
                  
                  <figure align="center" anchor="e_ac">
                     <preamble>E(AC) Format</preamble>
                     <artwork align="center" xml:space="preserve">&#xA;<!--
                        -->     +---------+        &#xA;<!--
                        -->     |    AC   |        &#xA;<!--
                        -->     | [ARRAY] |        &#xA;<!--
                        -->     +----++---+        &#xA;<!--                     
                        -->          ||            &#xA;<!--
                        -->          ||            &#xA;<!--
                        --> ________/  \_________  &#xA;<!--
                        -->/                     \ &#xA;<!--
                        -->+-------+     +-------+ &#xA;<!--
                        -->| ARI 1 | ... | ARI N | &#xA;<!--
                        -->| [ARI] |     | [ARI] | &#xA;<!--
                        -->+-------+     +-------+
                     </artwork>
                  </figure>
               </t>
            </section>
         
            <section title="Expressions (EXPR)" anchor="expr_chp" toc="default">
               <t>
                  The Expression object encapsulates a typed postfix expression in
                  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.
               </t>
               <t>
                  The Expression object is encoded as an OCTETS sequence whose 
                  format is illustrated in <xref target="e_expr_fmt"/>. 
                  
                  <figure align="center" anchor="e_expr_fmt">  
                     <preamble>E(EXPR) Format</preamble>             
                     <artwork align="center" xml:space="preserve"> &#xA;<!--
                        -->     +----------+        &#xA;<!--
                        -->     |   EXPR   |        &#xA;<!--
                        -->     | [OCTETS] |        &#xA;<!--
                        -->     +-----++---+        &#xA;<!--                     
                        -->           ||            &#xA;<!--
                        -->           ||            &#xA;<!--
                        --> _________/  \_________  &#xA;<!--
                        -->/                      \ &#xA;<!--
                        -->+---------+------------+&#xA;<!--
                        -->|   Type  | Expression |&#xA;<!--
                        -->|  [BYTE] |    [AC]    |&#xA;<!--
                        -->+---------+------------+
                     </artwork>
                  </figure>
                  
                  <list hangIndent="8" style="hanging">
                     <t hangText="Type"><vspace blankLines="0" />
                        The enumeration representing the type of the result of the 
                        evaluated expression. This type MUST be defined in 
                        <xref target="I-D.birrane-dtn-adm"/> as a "Primitive Type". 
                     </t>
                     
                     <t hangText="Expression"><vspace blankLines="0" />
                        An expression is represented in the AMP as an ARI collection,
                        where each ARI in the ordered collection represents either an
                        operand or operator in postfix form. 
                     </t>
                  </list>
               </t>
            </section>
         </section>
      </section>

      <section title="AMM Resource Identifier (ARI)" anchor="e_ari_chp">
         <t>
            The ARI, as defined in <xref target="I-D.birrane-dtn-adm"/>, 
            identifies an AMM object. There are two kinds of objects that 
            can be identified in this scheme: literal objects (of type 
            LIT) and all other objects. 
         </t>

         <section title="Encoding ARIs of Type LITERAL">
            <t>
               A literal identifier is one that is literally defined by 
               its value, such as numbers (0, 3.14) and strings ("example"). 
               ARIs of type LITERAL do not have issuers or nicknames or 
               parameters. They are simply typed basic values. 
            </t>

            <t>
               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.
            </t>
            <t>
               The E(ARI) structure for LIT types is illustrated in 
               <xref target="e_ari_lit_fig"/>.              
            
               <figure align="center" anchor="e_ari_lit_fig">
                  <preamble>E(ARI) Literal Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+--------+----------+   &#xA;<!--
                     -->| Flags  |  Value   |   &#xA;<!--
                     -->| [BYTE] | [VARIES] |   &#xA;<!--
                     -->+--------+----------+
                  </artwork>
               </figure>
            </t>          

            <t>
               These fields are defined as follows.
            
               <list hangIndent="8" style="hanging">
                  <t hangText="Flags"><vspace blankLines="0" /> 
                     The Flags byte identifies the object as being of type
                     LIT and also captures the primitive type of the 
                     following value. The layout of this byte is illustrated 
                     in <xref target="e_ari_lit_flag"/>.
                 
                     <figure align="center" anchor="e_ari_lit_flag">
                        <preamble>E(ARI) Literal Flag Byte Format</preamble>
                        <artwork align="center" xml:space="preserve"> &#xA;<!--
                           -->+-------------------+-------------+&#xA;<!--
                           -->| VALUE TYPE OFFSET | STRUCT TYPE |&#xA;<!--
                           -->+-------------------+-------------|&#xA;<!--
                           -->|   7   6   5   4   | 3  2  1  0  |&#xA;<!--
                           -->+-------------------+-------------+&#xA;<!--
                           --> MSB                           LSB
                        </artwork>
                     </figure>
                  
                     <list hangIndent="8" style="hanging">
                        <t hangText="Value Type Offset"><vspace blankLines="0"/>
                           The high nibble of the flag byte contains the offset
                           into the Primitive Types enumeration defined in
                           <xref target="I-D.birrane-dtn-adm"/>. An offset of 0 
                           represents the 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 the type value fits into a nibble.
                        </t>

                        <t hangText="Structure Type"><vspace blankLines="0" /> 
                           The lower nibble of the flag byte identifies the 
                           type of AMM Object being identified by the ARI. 
                           In this instance, this value MUST be 
                           LIT, as defined in <xref target="I-D.birrane-dtn-adm"/>.
                        </t>
                     </list>
                  </t>

                  <t hangText="Value"> <vspace blankLines="0"/>
                     This field captures the CBOR encoding of the value. 
                     Values are encoded according to their Value Type as 
                     specified in the flag byte in accordance with the encoding 
                     rules provided in <xref target="prim_enc"/>.
                  </t>
               </list>
            </t>
         </section>


         <section title="Encoding Non-Literal ARIs">
            <t>
               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-machine binary encoding of this information removes 
               human-readable information such as Name and Description 
               from the E(ARI). Additionally, this encoding adds other 
               information to improve the efficiency of the encoding,
               such as the concept of Nicknames, defined in <xref target="nn_chp"/>.
            </t>

            <t>
               The E(ARI) is encoded as an OCTETS sequence and consists of a 
               mandatory flag byte, an encoded object name, and optional 
               annotations to assist with filtering, access control, and 
               parameterization. The E(ARI) structure is illustrated in 
               <xref target="e_ari_fig"/>.              
              
               <figure align="center" anchor="e_ari_fig">
                  <preamble>E(ARI) General Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+--------+---------+-----------+---------+-----------+-----------+&#xA;<!--
                     -->| Flags  |   NN    |   Name    |  Parms  |   Issuer  |    Tag    |&#xA;<!--
                     -->| [BYTE] | [UVAST] | [BYTESTR] | [TNVC]  | [BYTESTR] | [BYTESTR] |&#xA;<!--
                     -->|        |  (opt)  |           |  (opt)  |   (opt)   |    opt)   |&#xA;<!--
                     -->+--------+---------+-----------+---------+-----------+-----------+
                  </artwork>
               </figure>
            </t>

            <t>
               These fields are defined as follows.
               
               <list hangIndent="8" style="hanging">
                  <t hangText="Flags"><vspace blankLines="0" /> 
                     Flags describe the type of structure and which
                     optional fields are present in the encoding. 
                     The layout of the flag byte is illustrated in 
                     <xref target="e_ari_flag"/>.
                 
                     <figure align="center" anchor="e_ari_flag">
                        <preamble>E(ARI) General Flag Byte Format</preamble>
                        <artwork align="center" xml:space="preserve">&#xA;<!--
                           -->+----+------+-----+-----+-------------+&#xA;<!--
                           -->| NN | PARM | ISS | TAG | STRUCT TYPE |&#xA;<!--
                           -->+----+------+-----+-----+-------------+&#xA;<!--
                           -->| 7  |  6   |  5  |  4  | 3  2  1  0  |&#xA;<!--
                           -->+----+------+-----+-----+-------------+&#xA;<!--
                            -->MSB                               LSB
                        </artwork>
                     </figure>

                     <list hangIndent="8" style="hanging">
                        
                        <t hangText="Nickname (NN)"><vspace blankLines="0"/>
                           This flag indicates that ADM compression is used for this
                           E(ARI). When set to 1 the Nickname field MUST be present in
                           the E(ARI). When set to 0 the Nickname field MUST NOT be
                           present in the E(ARI). When an ARI is user-defined, there 
                           are no semantics for Nicknames and, therefore, this field
                           MUST be 0 when the Issuer flag is set to 1. Implementations SHOULD
                           use Nicknames whenever possible to reduce the size of the E(ARI).
                        </t>

                        <t hangText="Parameters Present (PARM)"><vspace blankLines="0"/>
                           This flag indicates that this ARI can be parameterized
                           and that parameter information is included in the E(ARI).
                           When set to 1 the Parms field MUST be present in the E(ARI).
                           When set to 0 the Parms field MUST NOT be present in the
                           E(ARI).  
                        </t>

                        <t hangText="Issuer Present (ISS)"><vspace blankLines="0" /> 
                           This flag indicates that this ARI is defined in the context
                           of a specific issuing entity. When set to 1 the Issuer field
                           MUST be present in the E(ARI). When set to 0 the Issuer field
                           MUST NOT be present in the E(ARI).
                        </t>

                        <t hangText="Tag Present (TAG)"><vspace blankLines="0" /> 
                           This flag indicates that the ARI is defined in the context 
                           of a specific issuing entity and that issuing entity adds
                           additional information in the form of a tag. When set to 1
                           the Tag field MUST be present in the E(ARI). When set to 0
                           the Tag field MUST NOT be present in the E(ARI). This flag
                           MUST be set to 0 if the Issuer Present flag is set to 0.
                        </t>

                        <t hangText="Structure Type (STRUCT TYPE)"><vspace blankLines="0" /> 
                           The lower nibble of the E(ARI) flag byte identifies 
                           the kind of structure being identified.  This 
                           field MUST contain one of the AMM object types 
                           defined in <xref target="I-D.birrane-dtn-adm"/>.
                        </t>
                     </list>
                  </t>

                  <t hangText="Nickname (NN)"> <vspace blankLines="0"/>
                     This optional field contains the Nickname as calculated 
                     according to <xref target="nn_chp"/>. 
                  </t>

                  <t hangText="Object Name"> <vspace blankLines="0"/>
                     This mandatory field contains an encoding of the ADM
                     object. For elements defined in an ADM Template (e.g., 
                     where the Issuer Flag is set to 0) this is the 0-based 
                     index into the ADM collection holding this element. For 
                     all user-defined ADM objects, (e.g., where the Issuer 
                     Flag is set to 1) this value is as defined
                     by the Issuing organization.
                  </t>
                  
                  <t hangText="Parameters"><vspace blankLines="0" /> 
                     The parameters field is represented as a Type Name Value Collection
                     (TNVC) as defined in <xref target="tnvc_chp"/>. The overall number
                     of items in the collection represents the number of parameters. The
                     types of the TNVC represent the types of each parameter, with the first
                     listed type associated with the first parameter, and so on. The values, if present,
                     represent the values of the parameters, with the first listed value being
                     the value of the first parameter, and so on.
                  </t>

                  <t hangText="Issuer"><vspace blankLines="0" /> 
                     This is a binary identifier representing a predetermined 
                     issuer name. The AMP protocol does not parse or validate this 
                     identifier, using it only as a distinguishing bit pattern to 
                     ensure uniqueness. This value, for example, may come from 
                     a global registry of organizations, an issuing node address, 
                     or some other network-unique marking. The issuer field MUST NOT
                     be present for any ARI defined in an ADM.
                  </t>

                  <t hangText="Tag"><vspace blankLines="0"/>
                     A value used to disambiguate multiple ARIs with the same 
                     Issuer. The definition of the tag is left to the discretion 
                     of the Issuer. The Tag field MUST be present if the Tag Flag
                     is set in the flag byte and MUST NOT be present otherwise.
                  </t>
               </list>
            </t>
         </section>
      </section>
                                    
      <section title="ADM Object Encodings">

         <t>
            The autonomy model codified in <xref target="I-D.birrane-dtn-adm"/>
            comprises multiple individual objects. This section describes the
            CBOR encoding of these objects.
         </t>
         <t>
            Note: The encoding of an object refers to the way in which the 
            complete object can be encoded such that the object as it exists
            on a Manager may be re-created on an Agent, and vice-versa. In cases
            where both a Manager and an Agent already have the definition of an
            object, then only the encoded ARI of the object needs to be communicated.
            This is the case for all objects defined in a published ADM and any
            user-defined object that has been synchronized between an Agent and
            Manager.
         </t>

         <section title="Externally Defined Data (EDD)" anchor="e_edd_chp">
      
            <t>
               Externally defined data (EDD) are solely defined in the ADMs 
               for various applications and protocols. EDDs represent values 
               that are calculated external to an AMA Agent, such as values
               measured by firmware. 
            </t>
         
            <t>
               The representation of these data is simply their identifying 
               ARIs. The representation of an EDD is illustrated in 
               <xref target="e_edd_fmt"/>.
                   
               <figure align="center" anchor="e_edd_fmt">   
               <preamble>E(EDD) Format</preamble>            
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+-------+&#xA;<!--
                     -->|  ID   |&#xA;<!--
                     -->| [ARI] |&#xA;<!--
                     -->+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the EDD. Since
                     EDDs are always defined solely in the context 
                     of an ADM, this ARI MUST NOT have an ISSUER field 
                     and MUST NOT have a TAG field. This ARI may be defined 
                     with parameters.
                  </t>
               </list>  
            </t>
         </section>

         <section title="Constants (CONST)" anchor="e_const_chp">
            <t>
               Unlike Literals, a Constant is an immutable, typed, named
               value. Examples of constants include PI to some number of
               digits or the UNIX Epoch. 
            </t>
            <t>
               Since ADM definitions are preconfigured on Agents and Managers 
               in an AMA, the type information for a given Constant is known by 
               all actors in the system and the encoding of the Constant needs 
               to only be the name of the constant as the Manager
               and Agent can derive the type and value from the unique Constant name.
            </t>

            <t>
               The format of a Constant is illustrated in <xref target="e_const_fmt"/>.
                   
               <figure align="center" anchor="e_const_fmt" suppress-title="false">
                  <preamble>E(CONST) Format</preamble>               
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+-------+&#xA;<!--
                     -->|  ID   |&#xA;<!--
                     -->| [ARI] |&#xA;<!--
                     -->+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the Constant. Since Constant 
                     definitions are always provided in an ADM, this ARI MUST 
                     NOT have an ISSUER field and MUST NOT have a TAG field.  
                     The ARI MUST NOT have parameters.
                  </t>
               </list>               
            </t>
         </section>

         <section title="Controls (CTRL)" anchor="e_ctrl_chp">
            <t>
               A Control represents a pre-defined and optionally parameterized opcode
               that can be run on an Agent. Controls in the AMP are always defined 
               in the context of an AMA; there is no concept of an operator-defined 
               Control. Since Controls are pre-configured in Agents and 
               Managers as part of ADM support, their representation is the ARI
               that identifies them, similar to EDDs. 
            </t>
            <t>
               The format of a Control is illustrated in <xref target="e_ctrl_fmt"/>.
                   
               <figure align="center" anchor="e_ctrl_fmt">
                  <preamble>E(CTRL) Format</preamble>          
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+-------+&#xA;<!--
                     -->|  ID   |&#xA;<!--
                     -->| [ARI] |&#xA;<!--
                     -->+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the Control. This ARI 
                     MUST NOT have an ISSUER field and MUST NOT have a TAG field. 
                     This ARI may have parameters.
                  </t>
               </list>               
            </t>
         </section>

         <section title="Macros (MAC)" anchor="e_mac_chp">
            <t>
               Macros in the AMP are ordered collections of ARIs (an AC) that
               contain Controls or other Macros. When run by an Agent, each
               ARI in the AC MUST be run in order. 
            </t>
            <t>
               Any AMP implementation MUST allow at least 4 levels of Macro nesting.
               Implementations MUST prevent recursive nesting of Macros. 
            </t>
            <t>
               The ARI associated with a Macro MAY contain parameters. Each parameter
               present in a Macro ARI MUST contain type, name, and value information. 
               Any Control or Macro encapsulated within a parameterized Macro MAY also
               contain parameters. If an encapsulated object parameter contains only
               name information, then the parameter value MUST be taken from the named
               parameter provided by the encapsulating Macro. Otherwise, the value provided
               to the object MUST be used instead.
            </t>

            <t>
               The format of a Macro is illustrated in <xref target="e_macro_fmt"/>.
                   
               <figure align="center" anchor="e_macro_fmt">             
                  <preamble>E(MAC) Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                      -->+-------+------------+&#xA;<!--
                      -->|  ID   | Definition |&#xA;<!--
                      -->| [ARI] |    [AC]    |&#xA;<!--
                      -->+-------+------------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the Macro. When a 
                     Macro is defined in an ADM this ARI MUST NOT 
                     have an ISSUER field and MUST NOT have a TAG field. When the 
                     Macro is defined outside of an ADM, the ARI MUST have an
                     ISSUER field and MAY have a TAG field.
                  </t>
                  <t hangText="Definition"><vspace blankLines="0" />
                     This is the ordered collection of ARIs that identify the
                     Controls and other Macros that should be run as part of
                     running this Macro.
                  </t>               
               </list>               
            </t>
         </section>

         <section title="Operators (OPER)" anchor="e_op_chp">
            <t>
               Operators 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 preconfigured in Agents and Managers as 
               part of ADM support, their representation is simply the ARI
               that identifies them. 
            </t>
            <t>
               The ADM definition of an Operator MUST specify how many parameters
               are expected and the expected type of each parameter. 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 should accept 10 parameters.                                
            </t>                  
            <t>
               Operators are always evaluated in the context of an Expression.
               The encoding of an Operator is illustrated in <xref target="e_op_fmt"/>.
                   
               <figure align="center" anchor="e_op_fmt">          
                  <preamble>E(OP) Format</preamble>     
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+-------+&#xA;<!--
                     -->|  ID   |&#xA;<!--
                     -->| [ARI] |&#xA;<!--
                     -->+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the Operator. Since
                     Operators are always defined solely in the context 
                     of an ADM, this ARI MUST NOT have an ISSUER field and 
                     MUST NOT have a TAG field. 
                  </t>
               </list>               
            </t>
         </section>

         <section title="Report Templates (RPTT)" anchor="e_rptt_chp">
            <t>
               A Report Template is an ordered collection of identifiers that
               describe the order and format of data in any Report built
               in compliance with the template. A template is a schema for a
               class of reports. It contains no actual values and
               may be defined in a formal ADM or configured by users in the
               context of a network deployment. 
            </t>
            <t>
               The encoding of a RPTT is illustrated in <xref target="e_rptt_fmt"/>.

               <figure align="center" anchor="e_rptt_fmt">
                  <preamble>E(RPTT) Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->+-------+----------+ &#xA;<!--
                     -->|  ID   | Contents | &#xA;<!--
                     -->| [ARI] |   [AC]   | &#xA;<!--
                     -->+-------+----------+ 
                  </artwork>
               </figure>

               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the report template. 
                  </t>
                  <t hangText="Contents"><vspace blankLines="0" /> 
                     This is the ordered collection of ARIs that define the
                     template. 
                  </t>
               </list>               

            </t>
         </section>

         <section title="Report (RPT)" anchor="e_rpt_chp">
            <t>
               A Report is a set of data values populated using a given Report 
               Template. While Reports do not contain name information, they MAY
               contain type information in cases where recipients wish to perform
               type validation prior to interpreting the Report contents in the 
               context of a Report Template. Reports are "anonymous" in the sense that
               any individual Report does not contain a unique identifier. Reports can
               be differentiated by examining the combination of (1) the Report Template
               being populated, (2) the time at which the Report was populated, and
               (3) the Agent producing the report.
            </t>
            <t>
               A Report object is comprised of the identifier of the 
               template used to populate the report, an optional timestamp, 
               and the contents of the report. A Report is encoded as a 
               CBOR array with either 2 or 3 elements. If the array has 2 
               elements then the optional Timestamp MUST NOT be in the Report encoding.
               If the array has 3 elements then the optional timestamp MUST be included
               in the Report encoding. The Report encoding is 
               illustrated in <xref target="e_rpt_fmt"/>.
                  
               <figure align="center" anchor="e_rpt_fmt">
                  <preamble>E(RPT) Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->            +---------+&#xA;<!--
                     -->            |   RPT   |&#xA;<!--
                     -->            | [ARRAY] |&#xA;<!--
                     -->            +---++----+&#xA;<!--
                     -->                ||&#xA;<!--
                     -->                ||&#xA;<!--
                     -->  _____________/  \______________&#xA;<!--
                     --> /                               \&#xA;<!--
                     -->+----------+-----------+----------+&#xA;<!--
                     -->| Template | Timestamp | Entries  |&#xA;<!--
                     -->| [OCTETS: |   [TS]    | [OCTETS: |&#xA;<!--
                     -->|   ARI]   |   (opt)   |  TNVC]   |&#xA;<!--
                     -->+----------+-----------+----------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="Template"><vspace blankLines="0" /> 
                     This is the ARI identifying the template used to interpret the
                     data in this report.
                     <vspace blankLines="1"/>
                     This ARI may be parameterized and, if so, the parameters MUST 
                     include a name field and have been passed-by-name to the 
                     template contents when constructing the report.
                  </t>
                  <t hangText="Timestamp"><vspace blankLines="0"/>
                     The timestamp marks the time at which the report was created.
                     This timestamp may be omitted in cases where the time of
                     the report generation can be inferred from other information.
                     For example, if a report is included in a message group such
                     that the timestamp of the message group is equivalent to the
                     timestamp of the report, the report timestamp may be omitted
                     and the timestamp of the included message group used instead.
                  </t>
                  <t hangText="Entries"><vspace blankLines="0" />
                     This is the collection of data values that comprise the 
                     report contents in accordance with the associated Report Template.
                  </t>
               </list>  
            </t>
         </section>

         <section title="State-Based Rules (SBR)" anchor="e_SBR_chp">
            <t>
               A State-Based Rule (SBR) specifies that a particular action 
               should be taken by an Agent based on some evaluation of the
               internal state of the Agent. A SBR specifies that starting 
               at a particular START time an ACTION should be run by the
               Agent if some CONDITION evaluates to true, until the ACTION has 
               been run COUNT times. When the SBR is no longer valid it may 
               be discarded by the agent.                         
            </t>
            <t>
               Examples of SBRs include:
               <list>
                  <t>
                     Starting 2 hours from receipt, whenever V1 > 10, produce
                     a Report for Report Template R1 no more than 20 times.                                    
                  </t>
                  <t>
                     Starting at some future absolute time, whenever V2 != V4, 
                     run Macro M1 no more than 36 times.
                  </t>
               </list> 
            </t>
         
            <t>   
               An SBR object is encoded as an OCTETS sequence as 
               illustrated in <xref target="e_SBR_fmt"/>.
                   
               <figure align="center" anchor="e_SBR_fmt">    
                  <preamble>E(SBR) Format</preamble>     
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->                   +----------+&#xA;<!--
                     -->                   |    SBR   |&#xA;<!--
                     -->                   | [OCTETS] |&#xA;<!--
                     -->                   +----++----+&#xA;<!--
                     -->                        ||&#xA;<!--
                     -->                        ||&#xA;<!--
                     -->_______________________/  \_______________________&#xA;<!--
                     -->/                                                  \&#xA;<!--
                     -->+-------+-------+--------+--------+--------+--------+&#xA;<!--
                     -->|  ID   | START |  COND  | EVALS  | FIRES  | ACTION |&#xA;<!--
                     -->| [ARI] | [TV]  | [EXPR] | [UINT] | [UINT] |  [AC]  |&#xA;<!--
                     -->+-------+-------+--------+--------+--------+--------+           
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the SBR. If this ARI contains
                     parameters they MUST include a name in support of pass-by-name
                     to each element of the Action AC.
                  </t>
                  <t hangText="START"><vspace blankLines="0" />
                     The time at which the SBR condition should start to be evaluated. This
                     will mark the first evaluation of the condition associated with
                     the SBR.  
                  </t>
                  <t hangText="CONDITION"><vspace blankLines="0" />
                     The Expression which, if true, results in the SBR running 
                     the associated action. An EXPR is considered true if it
                     evaluates to a non-zero value.
                  </t>
                  <t hangText="EVALS"><vspace blankLines="0" />
                     The number of times the SBR condition can be evaluated.  
                     The special value of 0 indicates there is no limit
                     on how many times the condition can be evaluated.
                  </t>
                  <t hangText="FIRES"><vspace blankLines="0" />
                     The number of times the SBR action can be run.  
                     The special value of 0 indicates there is no limit
                     on how many times the action can be run.
                  </t>
                  <t hangText="ACTION"><vspace blankLines="0" />
                     The collection of Controls and/or Macros to
                     run as part of the action.  This is encoded as an AC 
                     in accordance with <xref target="ac_chp"/> with
                     the stipulation that every ARI in this collection MUST
                     be of type CTRL or MAC.
                  </t>
               </list>               
            </t>
         </section>

         <section title="Table Templates (TBLT)" anchor="e_tblt_chp">
            <t>
               A Table Template (TBLT) describes the types, and optionally
               names, of the columns that define a Table. 
            </t>
            <t>
               Because TBLTs are only defined in the context of an ADM, their
               definition cannot change operationally.  Therefore, a TBLT is
               encoded simply as the ARI for the template. The format
               of the TBLT Object Array is illustrated in <xref target="e_tblt_fig"/>.
               
               <figure align="center" anchor="e_tblt_fig">
                  <preamble>E(TBLT) Format</preamble>
                  <artwork align="center" xml:space="preserve">  &#xA;<!--
                     -->+-------+&#xA;<!--
                     -->|  ID   |&#xA;<!--
                     -->| [ARI] |&#xA;<!--
                     -->+-------+&#xA;
                  </artwork>
               </figure>              
            </t>
            <t>
               The elements of the TBLT array are defined as follows.
            
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI of the table template encoded in accordance with
                     <xref target="e_ari_chp"/>.
                  </t>
               </list>
            </t>
         </section>         
         
         <section title="Tables (TBL)" anchor="e_tbl_chp">
            <t>
               A Table object describes the series of values associated with a
               Table Template. 
            </t>
            <t>
               A Table object is encoded as a CBOR array, with the first element of 
               the array identifying the Table Template and each subsequent element
               identifying a row in the table. The format
               of the TBL Object Array is illustrated in <xref target="e_tbl_fig"/>.
               
               <figure align="center" anchor="e_tbl_fig">
                  <preamble>E(TBL) Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->            +---------+&#xA;<!--
                     -->            |   TBL   |&#xA;<!--
                     -->            | [ARRAY] |&#xA;<!--
                     -->            +---++----+&#xA;<!--
                     -->                ||&#xA;<!--
                     -->                ||&#xA;<!--
                      -->______________/  \_______________&#xA;<!--
                     -->/                                 \&#xA;<!--
                     -->+---------+--------+     +--------+&#xA;<!--
                     -->| TBLT ID |  Row 1 |     |  Row N |&#xA;<!--
                     -->|  [ARI]  | [TNVC] | ... | [TNVC] |&#xA;<!--
                     -->+---------+--------+     +--------+                                
                  </artwork>
               </figure>              
            </t>
        
            <t>
               The TBL fields are defined as follows.
            
               <list hangIndent="8" style="hanging">
                  <t hangText="Template ID (TBLT ID)"><vspace blankLines="0" /> 
                     This is the ARI of the table template describing the format of
                     the table and is encoded in accordance with
                     <xref target="e_ari_chp"/>.
                  </t>
                  <t hangText="Row"><vspace blankLines="0" /> 
                     Each row of the table is represented as a series of values with optional
                     type information to aid in type checking table contents to column types.
                     Each row is encoded as a TNVC and MAY include type information. AMP
                     implementations should consider the impact of including type information
                     for every row on the overall size of the encoded table.
                     <vspace blankLines="0" /> 
                     Each TNVC representing a row MUST contain the same number of elements
                     as there are columns in the referenced Table Template. 
                  </t>
               </list>                                    
            </t>
         </section>

         <section title="Time-Based Rules (TBR)" anchor="e_TBR_chp">

            <t>
               A Time-Based Rule (TBR) specifies that a particular action 
               should be taken by an Agent based on some time interval. A TBR
               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
               TBR is no longer valid it MAY BE discarded by the Agent. 
            </t>
            <t>
               Examples of TBRs include:
               <list>
                  <t>
                     Starting 2 hours from receipt, produce
                     a Report for Report Template R1 every 10 hours ending after 20 times.                                    
                  </t>
                  <t>
                     Starting at the given absolute time, run Macro M1 every
                     24 hours ending after 365 times.
                  </t>
               </list> 
            </t>
                  
            <t>   
               The TBR object is encoded as an OCTETS sequence as illustrated
               in <xref target="e_TBR_fmt"/>.
                   
               <figure align="center" anchor="e_TBR_fmt">
                  <preamble>E(TBR) Format</preamble>
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->                +----------+&#xA;<!--
                     -->                |    TBR   |&#xA;<!--
                     -->                | [OCTETS] |&#xA;<!--
                     -->                +----++----+&#xA;<!--
                     -->                     ||&#xA;<!--
                     -->                     ||&#xA;<!--
                     --> ___________________/  \___________________&#xA;<!--
                     -->/                                          \&#xA;<!--
                     -->+-------+-------+--------+--------+--------+&#xA;<!--
                     -->|  ID   | START | PERIOD | COUNT  | ACTION |&#xA;<!--
                     -->| [ARI] | [TV]  | [UINT] | [UINT] |  [AC]  |&#xA;<!--
                     -->+-------+-------+--------+--------+--------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">

                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the TBR and is encoded in accordance with
                     <xref target="e_ari_chp"/>. If this ARI contains
                     parameters they MUST include a name in support of pass-by-name
                     to each element of the Action AC.
                  </t>

                  <t hangText="START"><vspace blankLines="0" />
                     The time at which the TBR condition should start to be evaluated. 
                  </t>

                  <t hangText="PERIOD"><vspace blankLines="0" />
                     The number of seconds to wait between running the action
                     associated with the TBR.
                  </t>

                  <t hangText="COUNT"><vspace blankLines="0" />
                     The number of times the TBR action can be run.  
                     The special value of 0 indicates there is no limit
                     on how many times the action can be run.
                  </t>

                  <t hangText="ACTION"><vspace blankLines="0" />
                     The collection of Controls and/or Macros to
                     run as part of the action.  This is encoded as an ARI 
                     Collection in accordance with <xref target="ac_chp"/> with
                     the stipulation that every ARI in this collection MUST
                     represent either a Control or a Macro. 
                  </t>

               </list>               
            </t>
         </section>
         
         <section title="Variables (VAR)" anchor="e_var_chp">
            <t>
               Variable objects are transmitted in the AMP without the human-readable
               description. 
            </t>
            <t>
               Variable objects are encoded as an OCTETS sequence whose
               format is illustrated in <xref target="e_var_fmt"/>. 

               <figure align="center" anchor="e_var_fmt">            
                  <preamble>E(VAR) Format</preamble>   
                  <artwork align="center" xml:space="preserve">&#xA;<!--
                     -->  +-----------+ &#xA;<!--
                     -->  |  Variable | &#xA;<!--
                     -->  |  [OCTETS] | &#xA;<!--
                     -->  +-----++----+ &#xA;<!--                                                      
                     -->        ||       &#xA;<!--
                     -->        ||       &#xA;<!--
                     --> ______/  \_____ &#xA;<!--
                     -->/               \&#xA;<!--
                     -->+-------+-------+&#xA;<!--
                     -->|  ID   | Value |&#xA;<!--
                     -->| [ARI] | [TNV] |&#xA;<!--
                     -->+-------+-------+
                  </artwork>
               </figure>
               
               <list hangIndent="8" style="hanging">
                  <t hangText="ID"><vspace blankLines="0" /> 
                     This is the ARI identifying the VAR and is encoded in accordance with
                     <xref target="e_ari_chp"/>. This ARI MUST NOT include
                     parameters.
                  </t>
                  <t hangText="Value"><vspace blankLines="0" />
                     This field captures the value (and optionally the type
                     and name) of the variable, encoded as a TNV.
                  </t>
               </list>  
            </t>
         </section>
      </section>
   </section>

   
   <section title="Functional Specification" anchor="func_spec">
      <t>
         This section describes the format of the messages that comprise the
         AMP protocol.        
      </t>

      <section title="AMP Message Summary">
         <t>
            The AMP message specification is limited to three basic communications:     
         </t>

         <texttable anchor="msg_enums" title="ADM Message Type Enumerations">
               <ttcol>Message</ttcol>
               <ttcol>Enumeration</ttcol>
               <ttcol>Description</ttcol>
                              
               <c>Register Agent</c>
               <c>0</c>
               <c>Add Agents to the list of managed devices known to a Manager.</c>

               <c>Report Set</c>
               <c>1</c>
               <c>Receiving a Report of one or more Report Entries from an Agent.</c>

               <c>Perform Control</c>
               <c>2</c>
               <c>Sending a Macro of one or more Controls to an Agent.</c>

               <c>Table Set</c>
               <c>3</c>
               <c>Receiving one or more tables from an Agent.</c>

            </texttable>

         <t>
            The entire management of a network can be performed using these three
            messages and the configurations from associated ADMs.  
         </t>
      </section>

      <section title="Message Group Format" toc="default">
         <t>
            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 <xref target="msg_grp"/>. 
        
            These message groups are
            assumed communicated amongst Agents and Managers as the payloads of
            encapsulating protocols which should provide additional security and 
            data integrity features as needed.
         </t>

         <t>
            A message group is encoded as a CBOR array with at least 2 elements,
            the first being the time the group was created followed by 1 or more
            messages that comprise the group. The format of the message group is
            illustrated in <xref target="msg_grp"/>.

            <figure align="center" anchor="msg_grp">
               <preamble>AMP Message Group Format</preamble>
               <artwork align="center" xml:space="preserve">
              +---------------+
              | Message Group |
              |    [ARRAY]    |
              +------++-------+
                     ||
 ____________________||___________________
/                                         \
+-----------+-----------+     +-----------+
| Timestamp | Message 1 | ... | Message N |
|    [TS]   | [BYTESTR] |     | [BYTESTR] |
+-----------+-----------+     +-----------+
               </artwork>
            </figure>
            
            <list hangIndent="8" style="hanging">
               <t hangText="Timestamp"><vspace blankLines="0" />
                  The creation time for this messaging group. 
                  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. This is encoded in accordance with <xref target="std_types"/>. 
               </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 AMP specification adheres to a
            common message format, illustrated in <xref target="msg_fmt"/>, 
            consisting of a message header, a message body, and an optional trailer.
         </t>
         <t>
            Each message in the AMP is encode as an OCTETS sequence formatted in
            accordance with <xref target="msg_fmt"/>.
         
            <figure align="center" anchor="msg_fmt">
               <preamble>AMP Message Format</preamble>
               <artwork align="center" xml:space="preserve">
+--------+----------+----------+
| Header |   Body   | Trailer  |
| [BYTE] | [VARIES] | [VARIES] |
|        |          |  (opt.)  |
+--------+----------+----------+
               </artwork>
            </figure>

            <list hangIndent="8" style="hanging">
               <t hangText="Header"><vspace blankLines="0" /> 
                  The message header BYTE is shown in <xref target="cmn_hdr"/>. 
                  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">
                     <preamble>AMP Common Message Header</preamble>
                     <artwork align="center" xml:space="preserve">                     
+----------+-----+------+-----+----------+
| Reserved | ACL | Nack | Ack |  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 which AMP message is being represented.
                     </t>
                     <t hangText="ACK Flag"><vspace blankLines="0" /> 
                        The ACK flag describes whether successful application 
                        of the message must generate an acknowledgment 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 
                        AMP 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 AMP Actor in the network, pursuant to other security protocol
                  implementations.
               </t>
            </list>
         </t>
      </section>
      
      <section title="Register Agent" anchor="reg_agent_msg_chp">
         <t>
            The Register Agent message is used to inform an AMP Manager of
            the presence of another Agent in the network. 
         </t>
         <t>
            The body of this message is the name of the new agent,
            encoded as illustrated in <xref target="register_agent_msg"/>.

            <figure align="center" anchor="register_agent_msg">
               <preamble>Register Agent Message Body</preamble>
               <artwork align="center" xml:space="preserve">
+-----------+
|  Agent ID | 
| [BYTESTR] |
+-----------+
               </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. 
               </t>
            </list>
         </t>
      </section>
        
        
      <section title="Report Set" anchor="rpt_set_def">
         <t>
            The Report Set message contains a set of 1 or more Reports produced by
            an AMP Agent and sent to an AMP Manager. 
         </t> 
      	<t>
            The body of this message contains information on the recipient of the
            reports followed by one or more Reports. The body is encoded as 
            illustrated in <xref target="rpt_set_msg"/>.
             
            <figure align="center" anchor="rpt_set_msg">
               <preamble>Report Set Message Body</preamble>
               <artwork align="center" xml:space="preserve">
+----------+----------+
| RX Names |  Reports |
|  [ARRAY] |  [ARRAY] |
+----------+----------+
              </artwork>
             </figure>

            <list hangIndent="8" style="hanging">
              <t hangText="RX Names"><vspace blankLines="0" /> 
                 This field captures the set of Managers that have been sent this
                 report set. This is encoded as a CBOR array that MUST have at least
                 one entry. Each entry in this array is encoded as a CBOR text string.
              </t>
              <t hangText="Reports"> <vspace blankLines="0" /> 
                 This field captures the set of reports being sent. This is encoded
                 as a CBOR array that MUST have at least one entry. Each entry in this
                 array is encoded as a RPT in accordance with <xref target="e_rpt_chp"/>.
              </t>
            </list>
         </t>
      </section>

        
      <section title="Perform Control" toc="default">
         <t>
            The perform control message causes the receiving AMP Actor to
            run one or more preconfigured Controls provided in the message.
         </t>
         <t>
            The body of this message is the start time for the controls followed
            by the controls themselves, as illustrated in <xref target="perf_ctrl_msg"/>.

            <figure align="center" anchor="perf_ctrl_msg">
               <preamble>Perform Control Message Body</preamble>
               <artwork align="center" xml:space="preserve">
+-------+-----------+
| Start |  Controls |
|  [TV] |    [AC]   |
+-------+-----------+
               </artwork>
            </figure>
          
            <list hangIndent="8" style="hanging">
               <t hangText="Start"> <vspace blankLines="0" /> 
                  The time at which the Controls/Macros should be run.
               </t>
               <t hangText="Controls"> <vspace blankLines="0" /> 
                  The collection of ARIs that represent the Controls and/or Macros 
                  to be run by the AMP Actor. Every ARI in this collection MUST
                  be either a Control or a Macro. 
               </t>
            </list>
         </t>
      </section>    

      <section title="Table Set" anchor="tbl_set_def">
         <t>
            The Table Set message contains a set of 1 or more TBLs produced by
            an AMP Agent and sent to an AMP Manager. 
         </t> 
         <t>
            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 <xref target="tbl_set_msg"/>.
             
            <figure align="center" anchor="tbl_set_msg">
               <preamble>Table Set Message Body</preamble>
               <artwork align="center" xml:space="preserve">
+----------+----------+
| RX Names |  Tables  |
|  [ARRAY] |  [ARRAY] |
+----------+----------+
              </artwork>
             </figure>

            <list hangIndent="8" style="hanging">
              <t hangText="RX Names"><vspace blankLines="0" /> 
                 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 encoded as a CBOR text string.
              </t>

              <t hangText="Tables"> <vspace blankLines="0" /> 
                 This field captures the set of tables being sent. This is encoded
                 as a CBOR array that MUST have at least one entry. Each entry in this
                 array is encoded as a TBL in accordance with <xref target="e_tbl_chp"/>.
              </t>

            </list>
         </t>
      </section>
   </section>
    

    
   <section anchor="IANA" title="IANA Considerations" toc="default">
      <t>
         A Nickname registry needs to be established.
      </t>
   </section>
   
   <section anchor="Security" title="Security Considerations" toc="default">
      <t>
         Security within the AMP exists in two layers: transport layer
         security and access control.
      </t>
      
      <t>
         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.
      </t>
      
      <t>
         Finer grain application security is done via ACLs provided in the
         AMP message headers.
      </t>
   </section>

   <section title="Implementation Notes">
      <t>
         A reference implementation of this version of the AMP specification is
         available in the 3.6.2 release of the ION open source code base 
         available from sourceforge at https://sourceforge.net/projects/ion-dtn/.
      </t>
   </section>
   
</middle>

  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Informative References">
    
      <?rfc include="reference.I-D.draft-birrane-dtn-ama-07"?>
              
    </references>
    
    <references title="Normative References">
&RFC2119;
&RFC7049;
    
      <?rfc include="reference.I-D.draft-birrane-dtn-adm-02"?>

    </references>
    
    <section anchor="contr" title="Acknowledgements" toc="default">
      <t>
         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. 
         David Linko and Evana DiPietro of the Johns Hopkins University
         Applied Physics Laboratory contributed appreciated review and type
         checking of various elements of this specification.
      </t>
    </section>
    
  </back>
</rfc>
