idnits 2.17.1 draft-birrane-dtn-ama-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ACL' is mentioned on line 1029, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E. Birrane 3 Internet-Draft Johns Hopkins Applied Physics Laboratory 4 Intended status: Informational June 23, 2018 5 Expires: December 25, 2018 7 Asynchronous Management Architecture 8 draft-birrane-dtn-ama-07 10 Abstract 12 This document describes an asynchronous management architecture (AMA) 13 suitable for providing application-level network management services 14 in a challenged networking environment. Challenged networks are 15 those that require fault protection, configuration, and performance 16 reporting while unable to provide humans-in-the-loop with synchronous 17 feedback or otherwise preserve transport-layer sessions. In such a 18 context, networks must exhibit behavior that is both determinable and 19 autonomous while maintaining compatibility with existing network 20 management protocols and operational concepts. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 25, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 1.3. Organization . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Challenged Networks . . . . . . . . . . . . . . . . . . . 7 63 3.2. Current Approaches and Their Limitations . . . . . . . . 8 64 4. Service Definitions . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3. Autonomous Parameterized Procedure Calls . . . . . . . . 10 68 4.4. Administration . . . . . . . . . . . . . . . . . . . . . 11 69 5. Desirable Properties . . . . . . . . . . . . . . . . . . . . 12 70 5.1. Intelligent Push of Information . . . . . . . . . . . . . 12 71 5.2. Minimize Message Size Not Node Processing . . . . . . . . 12 72 5.3. Absolute Data Identification . . . . . . . . . . . . . . 13 73 5.4. Custom Data Definition . . . . . . . . . . . . . . . . . 13 74 5.5. Autonomous Operation . . . . . . . . . . . . . . . . . . 13 75 6. Roles and Responsibilities . . . . . . . . . . . . . . . . . 14 76 6.1. Agent Responsibilities . . . . . . . . . . . . . . . . . 14 77 6.2. Manager Responsibilities . . . . . . . . . . . . . . . . 15 78 7. Logical Data Model . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. Data Representations: Constants, Externally Defined Data, 80 and Variables . . . . . . . . . . . . . . . . . . . . . . 16 81 7.2. Data Collections: Reports and Tables . . . . . . . . . . 17 82 7.2.1. Report Templates and Reports . . . . . . . . . . . . 17 83 7.2.2. Table Templates and Tables . . . . . . . . . . . . . 18 84 7.3. Command Execution: Controls and Macros . . . . . . . . . 18 85 7.4. Autonomy: Time and State-Based Rules . . . . . . . . . . 19 86 7.4.1. State-Based Rule (SBR) . . . . . . . . . . . . . . . 19 87 7.4.2. Time-Based Rule (TBR) . . . . . . . . . . . . . . . . 20 88 7.5. Calculations: Expressions, Literals, and Operators . . . 20 89 8. System Model . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8.1. Control and Data Flows . . . . . . . . . . . . . . . . . 21 91 8.2. Control Flow by Role . . . . . . . . . . . . . . . . . . 22 92 8.2.1. Notation . . . . . . . . . . . . . . . . . . . . . . 22 93 8.2.2. Serialized Management . . . . . . . . . . . . . . . . 22 94 8.2.3. Multiplexed Management . . . . . . . . . . . . . . . 23 95 8.2.4. Data Fusion . . . . . . . . . . . . . . . . . . . . . 25 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 11. Informative References . . . . . . . . . . . . . . . . . . . 26 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 The Asynchronous Management Architecture (AMA) provides application- 104 layer network management services over links where delivery delays 105 prevent timely communications between a network operator and a 106 managed device. These delays may be caused by long signal 107 propagations or frequent link disruptions (such as described in 108 [RFC4838]) or by non-environmental factors such as unavailability of 109 network operators, administrative delays, or delays caused by 110 quality-of-service prioritizations and service-level agreements. 112 An AMA is necessary as the assumptions inherent to the architecture 113 and design of synchronous management tools and techniques are not 114 valid in challenged network scenarios. In these scenarios, 115 synchronous approaches either patiently wait for periods of bi- 116 directional connectivity or require the investment of significant 117 time and resources to evolve a challenged network into a well- 118 connected, low-latency network. In some cases such evolution is 119 merely a costly way to over-resource a network. In other cases, such 120 evolution is impossible given physical limitations imposed by signal 121 propagation delays, power, transmission technologies, and other 122 phenomena. Asynchronous management of asynchronous networks enables 123 large-scale deployments, distributed technical capabilities, and 124 reduced deployment and operations costs. 126 The rationale and motivation for asynchronous management is captured 127 in [BIRRANE1], [BIRRANE2],[BIRRANE3]. The properties and feasibility 128 of such a system are taken from prototyping work done in accordance 129 with [I-D.irtf-dtnrg-dtnmp]. 131 1.1. Scope 133 This document describes the motivation, service definitions, 134 desirable properties, roles/responsibilities, system model, and 135 logical data model that form the AMA. These descriptions should be 136 of sufficient specificity that implementations conformant to this 137 architecture will operate successfully in a challenged networking 138 environment. 140 This document is not a prescriptive standardization of a physical 141 data model or protocol. Instead, it serves as informative guidance 142 to authors of such models and protocols. 144 It is assumed that any challenged network where network management 145 would be usefully applied supports basic services (where necessary) 146 such as naming, addressing, integrity, confidentiality, 147 authentication, fragmentation, and traditional network/session layer 148 functions. Therefore, these items are outside of the scope of the 149 AMA and not covered in this document. 151 While possible that a challenged network may interface with an 152 unchallenged network, this document does not address the concept of 153 network management compatibility with synchronous approaches. 155 1.2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 1.3. Organization 163 The remainder of this document is organized into seven sections that, 164 together, describe an AMA suitable for enterprise management of 165 asynchronous networks: terminology, motivation, service definitions, 166 desirable properties, roles/responsibilities, logical data model, and 167 system model. The description of each section is as follows. 169 o Terminology - This section identifies those terms critical to 170 understanding the proper operation of the AMA. Whenever possible, 171 these terms align in both word selection and meaning with their 172 analogs from other management protocols. 174 o Motivation - This section provides an overall motivation for this 175 work as providing a novel and useful alternative to current 176 network management approaches. Specifically, this section 177 describes common network functions and how synchronous mechanisms 178 fail to provide these functions in an asynchronous environment. 180 o Service Definitions - This section defines asynchronous network 181 management services in terms of terminology, scope, and impact. 183 o Desirable Properties - This section identifies the properties to 184 which an asynchronous management system should adhere to 185 effectively implement service definitions in an asynchronous 186 environment. These properties guide the subsequent definition of 187 the system and logical models that comprise the AMA. 189 o Roles and Responsibilities - This section identifies the roles in 190 the AMA and their associated responsibilities. It provides the 191 terminology and context for discussing how network management 192 services interact. 194 o Logical Data Model - This section describes the kinds of data that 195 should be represented in deployment asynchronous management 196 system. 198 o System Model - This section describes data flows amongst various 199 defined Actor roles. These flows capture how the AMA system works 200 to provide asynchronous network management services in accordance 201 with defined desirable properties. 203 2. Terminology 205 o Actor - A software service running on either managed or managing 206 devices for the purpose of implementing management protocols 207 between such devices. Actors may implement the "Manager" role, 208 "Agent" role, or both. 210 o Agent Role (or Agent) - The role associated with a managed device, 211 responsible for reporting performance data, enforcing 212 administrative policies, and accepting/performing actions. Agents 213 exchange information with Managers operating either on the same 214 device or on a remote managing device. 216 o Externally Defined Data (EDD) - Information made available to an 217 Agent by a managed device, but not computed directly by the Agent. 219 o Variables (VARs) - Information that is computed by an Agent, 220 typically as a function of EDD values and/or other Variables. 222 o Constants (CONST) - A constant represents a typed, immutable value 223 that is referred to by a semantic name. Constants are used in 224 situations where substituting a name for a fixed value provides 225 useful semantic information. For example, using the named 226 constant PI rather than the literal value 3.14. 228 o Controls (CTRLs) - Operations that may be undertaken by an Actor 229 to change the behavior, configuration, or state of an application 230 or protocol managed by an AMP. 232 o Literals (LITs) - A literal represents a value without a semantic 233 name. Literals are used in cases where adding a semantic name to 234 a fixed value provides no useful semantic information. For 235 example, the number 4 is a literal value. 237 o Macros (MACs) - A named, ordered collection of Controls. 239 o Manager - A role associated with a managing device responsible for 240 configuring the behavior of, and receiving information from, 241 Agents. Managers interact with one or more Agents located on the 242 same device and/or on remote devices in the network. 244 o Operator (OP) - The enumeration and specification of a 245 mathematical function used to calculate variable values and 246 construct expressions to evaluate Agent state. 248 o Report (RPT) - A typed, ordered collection of data values gathered 249 by one or more Agents and provided to one or more Managers. 250 Reports only contain typed data values and the identity of the 251 Report Template (RPTT) to which they conform. 253 o Report Template (RPTT) - A named, typed, ordered collection of 254 data types that represent the structure of a Report (RPT). This 255 is the schema for a Report, generated by a Manager and 256 communicated to one or more Agents. 258 o Rule - A unit of autonomous specification that provides a 259 stimulus-response relationship between time or state on an Agent 260 and the Controls to be run as a result of that time or state. 262 o State-Based Rule (SBR) - A state-based rule is any rule in which 263 the rule stimulus is triggered by the calculable internal state of 264 the Agent. 266 o Table (TBL) - A typed collection of data values organized in a 267 tabular way in which columns represent homogeneous types of data 268 and rows represent unique sets of data values conforming to column 269 types. Reports only contain typed data values and the identity of 270 the Table Template (TBLT) to which they confirm. 272 o Table Template (TBLT) - A named, typed, ordered collection of 273 columns that comprise the structure for representing tabular data 274 values. This template forms the structure of a Table (TBL). 276 o Time-Based Rule (TBR) - A time-based rule is a specialization, and 277 simplification, of a state-based rule in which the rule stimulus 278 only considers relative time as it is known on the Agent. 280 3. Motivation 282 Challenged networks, to include networks challenged by administrative 283 or policy delays, cannot guarantee capabilities required to enable 284 synchronous management techniques. These capabilities include high- 285 rate, highly-available data, round-trip data exchange, and operators 286 "in-the-loop". The inability of current approaches to provide 287 network management services in a challenged network motivates the 288 need for a new network management architecture focused on 289 asynchronous, open-loop, autonomous control of network components. 291 3.1. Challenged Networks 293 A growing variety of link-challenged networks support packetization 294 to increase data communications reliability without otherwise 295 guaranteeing a simultaneous end-to-end path. Examples of such 296 networks include Mobile Ad-Hoc Networks (MANets), Vehicular Ad-Hoc 297 Networks (VANets), Space-Terrestrial Internetworks (STINTs), and 298 heterogeneous networking overlays. Links in such networks are often 299 unavailable due to attenuations, propagation delays, occultation, and 300 other limitations imposed by energy and mass considerations. Data 301 communications in such networks rely on store-and-forward and other 302 queuing strategies to wait for the connectivity necessary to usefully 303 advance a packet along its route. 305 Similarly, there also exist well-resourced networks that incur high 306 message delivery delays due to hardware, software, or human 307 limitations. Some examples of these networks are networks with 308 understaffed operations centers and where data volume and management 309 requirements exceed the real-time cognitive load of operators and/or 310 their associated operations console software support. Also, networks 311 that restrict user access to existing bandwidth due to policy create 312 functionally similar situations to that of link disruption and delay. 314 Independent of the reason, when a node experiences an inability to 315 communicate it must rely on autonomous mechanisms to ensure its safe 316 operation and ability to usefully re-join the network at a later 317 time. Additionally, nodes in a sparsely populated network may often 318 be disconnected, making the concepts of "connected network" and 319 "instantaneous connectivity" either impractical or impossible. 321 Specifically, challenged networks exhibit the following properties 322 that may violate assumptions built into current approaches to 323 synchronous network management. 325 o Links may be uni-directional. 327 o Bi-directional links may have asymmetric data rates. 329 o No end-to-end path is guaranteed to exist at any given time 330 between any two nodes. 332 o Round-trip communications between any two nodes within any given 333 time window may be impossible. 335 3.2. Current Approaches and Their Limitations 337 Network management tools in unchallenged networks provide mechanisms 338 for communicating locally-collected data from Agents to Managers, 339 typically using a "pull" mechanism where data must be explicitly 340 requested by a Manager in order to be transmitted by an Agent. 342 Management approaches that rely on timely data exchange, such as 343 those that rely on negotiated sessions or other synchronized 344 acknowledgment, do not function in challenged network environments. 345 Familiar examples of TCP/IP based management via closed-loop, 346 synchronous messaging do not work when network disruptions increase 347 in frequency and severity. While no protocol delivers data in the 348 absence of a networking link, protocols that eliminate or drastically 349 reduce overhead and end-point coordination require smaller 350 transmission windows and continue to function when confronted with 351 scaling delays and disruptions in the network. 353 A legacy method for management in unchallenged networks today is the 354 Simple Network Management Protocol (SNMP) [RFC3416]. SNMP utilizes a 355 request/response model to set and retrieve data values such as host 356 identifiers, link utilizations, error rates, and counters between 357 application software on Agents and Managers. Data may be directly 358 sampled or consolidated into representative statistics. 359 Additionally, SNMP supports a model for asynchronous notification 360 messages, called traps, based on predefined triggering events. Thus, 361 Managers can query Agents for status information, send new 362 configurations, and be informed when specific events have occurred. 363 Traps and queryable data are defined in one or more Managed 364 Information Bases (MIBs) which define the information for a 365 particular data standard, protocol, device, or application. 367 While there is a large installation base for SNMP there are several 368 aspects of the protocol that make in inappropriate for use in a 369 challenged networking environment. SNMP relies on sessions with low 370 round-trip latency to support its "pull" model. The SNMP trap model 371 provides some Agent-side processing, however because the processing 372 has very low fidelity and traps are typically "fire and forget," the 373 underlying transport protocol that supports reliable, in-order 374 message delivery is required. Adaptive modifications to SNMP to 375 support challenged networks would alter the basic function of the 376 protocol (data models, control flows, and syntax) so as to be 377 functionally incompatible with existing SNMP installations. 378 Therefore, this approach is not suitable for an asynchronous network 379 management system. 381 The Network Configuration Protocol (NETCONF) provides device-level 382 configuration capabilities [RFC6241] to replace vendor-specific 383 command line interface configuration software. The XML-based 384 protocol provides a remote procedure call (RPC) syntax such that any 385 exposed functionality on an Agent can be exercised via a software 386 application interface. NETCONF places no specific functional 387 requirements or constraints on the capabilities of the Agent, which 388 makes it a very flexible tool for configuring a homogeneous network 389 of devices. 391 NETCONF places specific constraints on any underlying transport 392 protocol: a long-lived, reliable, low-latency sequenced data delivery 393 session. This is a fundamental requirement given the RPC-nature of 394 the operating concept, and it is unsustainable in a challenged 395 network. Aspects of the data modeling associated with NETCONF may 396 apply to an asynchronous network management system, such that some 397 modeling tools may be used, even if the network control plane cannot. 399 Just as the concept of a loosely-confederated set of nodes changes 400 the definition of a network, it also changes the operational concept 401 of what it means to manage a network. When a network stops being a 402 single entity exhibiting a single behavior, "network management" 403 becomes large-scale "node management". Individual nodes must share 404 the burden of implementing desirable behavior without reliance on a 405 single oracle of configuration or other coordinating function such as 406 an operator-in-the-loop. 408 4. Service Definitions 410 This section identifies the services that must exist between Managers 411 and Agents within an AMA. These services include configuration, 412 reporting, parameterized control, and administration. 414 4.1. Configuration 416 Configuration services update Agent data associated with managed 417 applications and protocols. Some configuration data might be defined 418 in the context of an application or protocol, such that any network 419 using that application or protocol would understand that data. Other 420 configuration data may be defined tactically for use in a specific 421 network deployment and not available to other networks even if they 422 use the same applications or protocols. 424 New configurations received by an Agent must be validated to ensure 425 that they do not conflict with other configurations or would 426 otherwise prevent the Agent from effectively working with other 427 Actors in its region. With no guarantee of round-trip data exchange, 428 Agents cannot rely on remote Managers to correct erroneous or stale 429 configurations from harming the flow of data through a challenged 430 network. 432 Examples of configuration service behavior include the following. 434 o Creating a new datum as a function of other well-known data: 435 C = A + B. 437 o Creating a new report as a unique, ordered collection of known 438 data: 439 RPT = {A, B, C}. 441 o Storing predefined, parameterized responses to potential future 442 conditions: 443 IF (X > 3) THEN RUN CMD(PARM). 445 4.2. Reporting 447 Reporting services populate report templates with values collected or 448 computed by an Agent. The resultant reports are sent to one or more 449 Managers by the Agent. The term "reporting" is used in place of the 450 term "monitoring", as monitoring implies a timeliness and regularity 451 that cannot be guaranteed by a challenged network. Reports sent by 452 an Agent provide best-effort information to receiving Managers. 454 Since a Manager is not actively "monitoring" an Agent, the Agent must 455 make its own determination on when to send what Reports based on its 456 own local time and state information. Agents should produce Reports 457 of varying fidelity and with varying frequency based on thresholds 458 and other information set as part of configuration services. 460 Examples of reporting service behavior include the following. 462 o Generate Report R1 every hour (time-based production). 464 o Generate Report R2 when X > 3 (state-based production). 466 4.3. Autonomous Parameterized Procedure Calls 468 Similar to an RPC call, some mechanism MUST exist which allows a 469 procedure to be run on an Agent in order to effect its behavior or 470 otherwise change its internal state. Since there is no guarantee 471 that a Manager will be in contact with an Agent at any given time, 472 the decisions of whether and when a procedure should be run MUST be 473 made locally and autonomously by the Agent. Two types of automation 474 triggers are identified in the AMA: triggers based on the general 475 state of the Agent and triggers based on an Agent's notion of time. 476 As such, the autonomous execution of procedures can be viewed as a 477 stimulus-response system, where the stimulus is the positive 478 evaluation of a state or time based predicate and the response is the 479 function to be executed. 481 The autonomous nature of procedure execution by an Agent implies that 482 the full suite of information necessary to run a procedure may not be 483 known by a Manager in advance. To address this situation, a 484 parameterization mechanism MUST be available so that required data 485 can be provided at the time of execution on the Agent rather than at 486 the time of definition/configuration by the Manager. 488 Autonomous, parameterized procedure calls provide a powerful 489 mechanism for Managers to "manage" an Agent asynchronously during 490 periods of no communication by pre-configuring responses to events 491 that may be encountered by the Agent at a future time. 493 Examples of potential behavior include the following. 495 o Updating local routing information based on instantaneous link 496 analysis. 498 o Managing storage on the device to enforce quotas. 500 o Applying or modifying local security policy. 502 4.4. Administration 504 Administration services enforce the potentially complex mapping of 505 configuration, reporting, and control services amongst Agents and 506 Managers in the network. Fine-grained access controls that specify 507 which Managers may apply which services to which Agents may be 508 necessary in networks that either deal with multiple administrative 509 entities or overlay networks that cross administrative boundaries. 510 Whitelists, blacklists, key-based infrastructures, or other schemes 511 may be used for this purpose. 513 Examples of administration service behavior include the following. 515 o Agent A1 only Sends reports for Protocol P1 to Manager M1. 517 o Agent A2 only accepts a configurations for Application Y from 518 Managers M2 and M3. 520 o Agent A3 accepts services from any Manager providing the proper 521 authentication token. 523 Note that the administrative enforcement of access control is 524 different from security services provided by the networking stack 525 carrying AMP messages. 527 5. Desirable Properties 529 This section describes those design properties that are desirable 530 when defining an architecture that must operate across challenged 531 links in a network. These properties ensure that network management 532 capabilities are retained even as delays and disruptions in the 533 network scale. Ultimately, these properties are the driving design 534 principles for the AMA. 536 5.1. Intelligent Push of Information 538 Pull management mechanisms require that a Manager send a query to an 539 Agent and then wait for the response to that query. This practice 540 implies a control-session between entities and increases the overall 541 message traffic in the network. Challenged networks cannot guarantee 542 that the roundtrip data-exchange will occur in a timely fashion. In 543 extreme cases, networks may be comprised of solely uni-directional 544 links which drastically increases the amount of time needed for a 545 roundtrip data exchange. Therefore, pull mechanisms must be avoided 546 in favor of push mechanisms. 548 Push mechanisms, in this context, refer to the ability of Agents to 549 make their own determinations in relation to the information that 550 should be sent to Managers. Such mechanisms do not require round- 551 trip communications as Managers do not request each reporting 552 instance; Managers need only request once, in advance, that 553 information be produced in accordance with a predetermined schedule 554 or in response to a predefined state on the Agent. In this way 555 information is "pushed" from Agents to Managers and the push is 556 "intelligent" because it is based on some internal evaluation 557 performed by the Agent. 559 5.2. Minimize Message Size Not Node Processing 561 Protocol designers must balance message size versus message 562 processing time at sending and receiving nodes. Verbose 563 representations of data simplify node processing whereas compact 564 representations require additional activities to generate/parse the 565 compacted message. There is no asynchronous management advantage to 566 minimizing node processing time in a challenged network. However, 567 there is a significant advantage to smaller message sizes in such 568 networks. Compact messages require smaller periods of viable 569 transmission for communication, incur less re-transmission cost, and 570 consume less resources when persistently stored en-route in the 571 network. AMPs should minimize PDUs whenever practical, to include 572 packing and unpacking binary data, variable-length fields, and pre- 573 configured data definitions. 575 5.3. Absolute Data Identification 577 Elements within the management system must be uniquely identifiable 578 so that they can be individually manipulated. Identification schemes 579 that are relative to system configuration make data exchange between 580 Agents and Managers difficult as system configurations may change 581 faster than nodes can communicate. 583 Consider the following common technique for approximating an 584 associative array lookup. A manager wishing to do an associative 585 lookup for some key K1 will (1) query a list of array keys from the 586 agent, (2) find the key that matches K1 and infer the index of K1 587 from the returned key list, and (3) query the discovered index on the 588 agent to retrieve the desired data. 590 Ignoring the inefficiency of two pull requests, this mechanism fails 591 when the Agent changes its key-index mapping between the first and 592 second query. Rather than constructing an artificial mapping from K1 593 to an index, an AMP must provide an absolute mechanism to lookup the 594 value K1 without an abstraction between the Agent and Manager. 596 5.4. Custom Data Definition 598 Custom definition of new data from existing data (such as through 599 data fusion, averaging, sampling, or other mechanisms) provides the 600 ability to communicate desired information in as compact a form as 601 possible. Specifically, an Agent should not be required to transmit 602 a large data set for a Manager that only wishes to calculate a 603 smaller, inferred data set. The Agent should calculate the smaller 604 data set on its own and transmit that instead. Since the 605 identification of custom data sets is likely to occur in the context 606 of a specific network deployment, AMPs must provide a mechanism for 607 their definition. 609 5.5. Autonomous Operation 611 AMA network functions must be achievable using only knowledge local 612 to the Agent. Rather than directly controlling an Agent, a Manager 613 configures an engine of the Agent to take its own action under the 614 appropriate conditions in accordance with the Agent's notion of local 615 state and time. 617 Such an engine may be used for simple automation of predefined tasks 618 or to support semi-autonomous behavior in determining when to run 619 tasks and how to configure or parameterize tasks when they are run. 620 Wholly autonomous operations MAY be supported where required. 621 Generally, autonomous operations should provide the following 622 benefits. 624 o Distributed Operation - The concept of pre-configuration allows 625 the Agent to operate without regular contact with Managers in the 626 system. The initial configuration (and periodic update) of the 627 system remains difficult in a challenged network, but an initial 628 synchronization on stimuli and responses drastically reduces needs 629 for centralized operations. 631 o Deterministic Behavior - Such behavior is necessary in critical 632 operational systems where the actions of a platform must be well 633 understood even in the absence of an operator in the loop. 634 Depending on the types of stimuli and responses, these systems may 635 be considered to be maintaining simple automation or semi- 636 autonomous behavior. In either case, this preserves the ability 637 of a frequently-out-of-contact Manager to predict the state of an 638 Agent with more reliability than cases where Agents implement 639 independent and fully autonomous systems. 641 o Engine-Based Behavior - Several operational systems are unable to 642 deploy "mobile code" based solutions due to network bandwidth, 643 memory or processor loading, or security concerns. Engine-based 644 approaches are preferred as they can be flexible without incurring 645 a set of problematic requirements or concerns. 647 6. Roles and Responsibilities 649 By definition, Agents reside on managed devices and Managers reside 650 on managing devices. This section describes how these roles 651 participate in the network management functions outlined in the prior 652 section. 654 6.1. Agent Responsibilities 656 Application Support 657 Agents MUST collect all data, execute all procedures, 658 populate all reports and run operations required by each 659 application which the Agent claims to manage. Agents MUST 660 report supported applications so that Managers in a network 661 understands what information is understood by what Agent. 663 Local Data Collection 664 Agents MUST collect from local firmware (or other on-board 665 mechanisms) and report all data defined for the management of 666 applications for which they have been configured. 668 Autonomous Control 669 Agents MUST determine, without Manager intervention, whether 670 a procedure should be invoked. Agents MAY also invoke 671 procedures on other devices for which they act as proxy. 673 User Data Definition 674 Agents MUST provide mechanisms for operators in the network 675 to use configuration services to create customized data 676 definitions in the context of a specific network or network 677 use-case. Agents MUST allow for the creation, listing, and 678 removal of such definitions in accordance with whatever 679 security models are deployed within the particular network. 681 Where applicable, Agents MUST verify the validity of these 682 definitions when they are configured and respond in a way 683 consistent with the logging/error-handling policies of the 684 Agent and the network. 686 Autonomous Reporting 687 Agents MUST determine, without real-time Manager 688 intervention, whether and when to populate and transmit a 689 given report targeted to one or more Managers in the network. 691 Consolidate Messages 692 Agents SHOULD produce as few messages as possible when 693 sending information. For example, rather than sending 694 multiple messages, each with one report to a Manager, an 695 Agent SHOULD prefer to send a single message containing 696 multiple reports. 698 Regional Proxy 699 Agents MAY perform any of their responsibilities on behalf of 700 other network nodes that, themselves, do not have an Agent. 701 In such a configuration, the Agent acts as a proxy for these 702 other network nodes. 704 6.2. Manager Responsibilities 706 Agent Capabilities Mapping 707 Managers MUST understand what applications are managed by the 708 various Agents with which they communicate. Managers should 709 not attempt to request, invoke, or refer to application 710 information for applications not managed by an Agent. 712 Data Collection 713 Managers MUST receive information from Agents by 714 asynchronously configuring the production of reports and then 715 waiting for, and collecting, responses from Agents over time. 716 Managers MAY try to detect conditions where Agent information 717 has not been received within operationally relevant time 718 spans and react in accordance with network policy. 720 Custom Definitions 721 Managers should provide the ability to define custom data 722 definitions. Any custom definitions MUST be transmitted to 723 appropriate Agents and these definitions MUST be remembered 724 to interpret the reporting of these custom values from Agents 725 in the future. 727 Data Translation 728 Managers should provide some interface to other network 729 management protocols. Managers MAY accomplish this by 730 accumulating a repository of push-data from high-latency 731 parts of the network from which data may be pulled by low- 732 latency parts of the network. 734 Data Fusion 735 Managers MAY support the fusion of data from multiple Agents 736 with the purpose of transmitting fused data results to other 737 Managers within the network. Managers MAY receive fused 738 reports from other Managers pursuant to appropriate security 739 and administrative configurations. 741 7. Logical Data Model 743 The AMA logical data model captures the types of information that 744 should be collected and exchanged to implement necessary roles and 745 responsibilities. The data model presented in this section does not 746 presuppose a specific mapping to a physical data model or encoding 747 technique; it is included to provide a way to logically reason about 748 the types of data that should be exchanged in an asynchronously 749 managed network. 751 The elements of the AMA logical data model are described as follows. 753 7.1. Data Representations: Constants, Externally Defined Data, and 754 Variables 756 There are three fundamental representations of data in the AMA: (1) 757 data whose values do not change as a function of time or state, (2) 758 data whose values change as determined by sampling/calculation 759 external to the network management system, and (3) data whose values 760 are calculated internal to the network management system. 762 Data whose values do not change as a function of time or state are 763 defined as Constants (CONST). CONST values are strongly types, named 764 values that cannot be modified once they have been defined. 766 Data that are sampled/calculated external to the network management 767 system are defined as Externally Defined Data" (EDD). EDD values 768 represent the most useful information in the management system as 769 they are provided by the applications or protocols being managed on 770 the Agent. It is RECOMMENDED that EDD values be strongly typed to 771 avoid issues with interpreting the data value. It is also 772 RECOMMENDED that the timeliness/staleness of the data value be 773 considered when using the data in the context of autonomous action on 774 the Agent. 776 Data that is calculated internal to the network management system is 777 defined as a Variable (VAR). VARs allow the creation of new data 778 values for use in the network management system. New value 779 definitions are useful for storing user-defined information, storing 780 the results of complex calculations for easier re-use, and providing 781 a mechanism for combining information from multiple external sources. 782 It is RECOMMENDED that VARs be strongly typed to avoid issues with 783 interpreting the data value. In cases where a VAR definition relies 784 on other VAR definitions, mechanisms to prevent circular references 785 MUST be included in any actual data model or implementation. 787 7.2. Data Collections: Reports and Tables 789 Individual data values may be exchanged amongst Agents and Managers 790 in the AMA. However, data are typically most useful to a Manager 791 when received as part of a set of information. Ordered collections 792 of data values can be produced by Agents and sent to Managers as a 793 way of efficiently communicating Agent status. Within the AMA, the 794 structure of the ordered collection is treated separately from the 795 values that populate such a structure. 797 The AMA provides two ways of defining collections of data: reports 798 and tables. Reports are ordered sets of data values, whereas Tables 799 are special types of reports whose entries have a regular, tabular 800 structure. 802 7.2.1. Report Templates and Reports 804 The typed, ordered structure of a data collection is defined as a 805 Report Template (RPTT). A particular set of data values provided in 806 compliance with such a template is called a Report (RPT). 808 Separating the structure and content of a report reduces the overall 809 size of RPTs in cases where reporting structures are well known and 810 unchanging. RPTTs can be synchronized between an Agent and a Manager 811 so that RPTs themselves do not incur the overhead of carrying self- 812 describing data. RPTTs may include EDD values, VARs, and also other 813 RPTTs. In cases where a RPTT includes another RPTTs, mechanisms to 814 prevent circular references MUST be included in any actual data model 815 or implementation. 817 Protocols and applications managed in the AMA may define common 818 RPTTs. Additionally, users within a network may define their own 819 RPTTs that are useful in the context of a particular deployment. 821 7.2.2. Table Templates and Tables 823 Tables optimize the communication of multiple sets of data in 824 situations where each data set has the same syntactical structure and 825 with the same semantic meaning. Unlike reports, the regularity of 826 tabular data representations allow for the addition of new rows 827 without changing the structure of the table. Attempting to add a new 828 data set at the end of a report would require alterations to the 829 report template. 831 The typed, ordered structure of a table is defined as a 832 Table Template (TBLT). A particular instance of values populating 833 the table template is called a Table (TBL). 835 TBLTs describes the "columns" that define the table schema. A TBL 836 represents the instance of a specific TBLT that holds actual data 837 values. These data values represent the "rows" of the table. 839 The prescriptive nature of the TBLT allows for the possibility of 840 advanced filtering which may reduce traffic between Agents and 841 Managers. However, the unique structure of each TBLT may make them 842 difficult or impossible to change dynamically in a network. 844 7.3. Command Execution: Controls and Macros 846 Low-latency, high-availability approaches to network management use 847 mechanisms such as (or similar to) RPCs to cause some action to be 848 performed on an Agent. The AMA enables similar capabilities without 849 requiring that the Manager be in the processing loop of the Agent. 850 Command execution in the AMA happens through the use of controls and 851 macros. 853 A Control (CTRL) represents a parameterized, predefined procedure 854 that can be run on an Agent. CTRLs do not have a return code as 855 there is not the same concept of sequential execution in an 856 asynchronous model. Parameters can be provided when running a 857 command from a Manager, pre-configured as part of an autonomy 858 response on the Agent, or auto-generated as needed on the Agent. The 859 success or failure of a control MAY be inferred by reports generated 860 for that purpose. 862 NOTE: The AMA term control is derived in part from the concept of 863 Command and Control (C2) where control implies the operational 864 instructions that must be undertaken to implement (or maintain) a 865 commanded objective. An asynchronous management function controls an 866 Agent to allow it to fulfill its commanded purpose in a variety of 867 operational scenarios. For example, attempting to maintain a safe 868 internal thermal environment for a spacecraft is considered "thermal 869 control" (not "thermal commanding") even though thermal control 870 involves "commanding" heaters, louvers, radiators, and other 871 temperature-effecting components. 873 Often, a series of controls must be executed in concert to achieve a 874 particular outcome. A Macro (MACRO) represents an ordered collection 875 of controls (or other macros). In cases where a MACRO includes 876 another MACRO, mechanisms to prevent circular references and maximum 877 nesting levels MUST be included in any actual data model or 878 implementation. 880 7.4. Autonomy: Time and State-Based Rules 882 The AMA data model contains EDDs and VARs that capture the state of 883 applications on an Agent. The model also contains controls and 884 macros to perform actions on an Agent. A mechanism is needed to 885 relate these two capabilities: to perform an action on the Agent in 886 response to the state of the Agent. This mechanism in the AMA is the 887 "rule" and can key activated based on Agent state (state-based rule) 888 or based on the Agent's notion of relative time (time-based rule). 890 7.4.1. State-Based Rule (SBR) 892 State-Based Rules (SBRs) perform actions based on the Agent's 893 internal state, as identified by EDD and VAR values. An SBR 894 represents a stimulus-response pairing in the following form: 896 IF predicate THEN response 898 The predicate is a logical expression that evaluates to true if the 899 rule stimulus is present and evaluates to false otherwise. The 900 response may be any control or macro known to the Agent. 902 An example of an SBR could be to turn off a heater if some internal 903 temperature is greater than a threshold: 905 IF (current_temp > maximum_temp) THEN turn_heater_off 906 Rules should be allowed to construct their stimuli from the full set 907 of EDD values and VARs available to the network management system. 908 Similarly, macro responses should be allowed to include controls from 909 all applications known by the Agent. This enables an expressive 910 capability to have multiple applications monitored and managed by the 911 Agent. 913 7.4.2. Time-Based Rule (TBR) 915 Time-Based Rules (TBR) perform actions based on the Agent's notion of 916 the passage of time. A possible TBR construct would be to perform 917 some action at 1Hz on the Agent. 919 A TBR is a specialization of an SBR as the Agent's notion of time is 920 a type of Agent state. For example, a TBR to perform an action every 921 24 hours could be expressed using some type of predicate of the form: 923 (((current_time - base_time) % 24_hours) == 0) 925 However, time-based events are popular enough that special semantics 926 for expressing them would likely significantly reduce the 927 computations necessary to represent time functions in a SBR. 929 7.5. Calculations: Expressions, Literals, and Operators 931 Actions such as computing a VAR value or describing a rule predicate 932 require some mechanism for calculating the value of mathematical 933 expressions. In addition the the aforementioned AMA logical data 934 objects, Literals, Operators, and Expressions are used to perform 935 these calculations. 937 A Literal (LIT) represents a strongly typed datum whose identity is 938 equivalent to its value. An example of a LIT value is "4" - it's 939 identifier (4) is the same as its value (4). Literals differ from 940 constants in that constants have an identifier separate from their 941 value. For example, the constant PI may refer to a value of 3.14. 942 However the literal 3.14159 always refers to the value 3.14159. 944 An Operator (OP) represents a mathematical operation in an 945 expression. OPs should support multiple operands based on the 946 operation supported. A common set of OPs SHOULD be defined for any 947 Agent and systems MAY choose to allow individual applications to 948 define new OPs to assist in the generation of new VAR values and 949 predicates for managing that application. OPs may be simple binary 950 operations such as "A + B" or more complex functions such as sin(A) 951 or avg(A,B,C,D). Additionally, OPs may be typed. For example, 952 addition of integers may be defined separately from addition of real 953 numbers. 955 An Expression (EXPR) is a combination of operators and operands used 956 to construct a numerical value from a series of other elements of the 957 AMA logical model. Operands include any AMA logical data model 958 object that can be interpreted as a value, such as EDD, VAR, CONST, 959 and LIT values. Operators perform some function on operands to 960 generate new values. 962 8. System Model 964 This section describes the notional data flows and control flows that 965 illustrate how Managers and Agents within an AMA cooperate to perform 966 network management services. 968 8.1. Control and Data Flows 970 The AMA identifies three significant data flows: control flows from 971 Managers to Agents, reports flows from Agents to Managers, and fusion 972 reports from Managers to other Managers. These data flows are 973 illustrated in Figure 1. 975 AMA Control and Data Flows 977 +---------+ +------------------------+ +---------+ 978 | Node A | | Node B | | Node C | 979 | | | | | | 980 |+-------+| |+-------+ +-------+| |+-------+| 981 || ||=====>>||Manager|====>>| ||====>>|| || 982 || ||<<=====|| B |<<====|Agent B||<<====|| || 983 || || |+--++---+ +-------+| ||Manager|| 984 || Agent || +---||-------------------+ || C || 985 || A || || || || 986 || ||<<=========||==========================|| || 987 || ||===========++========================>>|| || 988 |+-------+| |+-------+| 989 +---------+ +---------+ 991 Figure 1 993 In this data flow, the Agent on node A receives Controls from 994 Managers on nodes B and C, and replies with Report Entries back to 995 these Managers. Similarly, the Agent on node B interacts with the 996 local Manager on node B and the remote Manager on node C. Finally, 997 the Manager on node B may fuse Report Entries received from Agents at 998 nodes A and B and send these fused Report Entries back to the Manager 999 on node C. 1001 From this figure it is clear that there exist many-to-many 1002 relationships amongst Managers, amongst Agents, and between Agents 1003 and Managers. Note that Agents and Managers are roles, not 1004 necessarily differing software applications. Node A may represent a 1005 single software application fulfilling only the Agent role, whereas 1006 node B may have a single software application fulfilling both the 1007 Agent and Manager roles. The specifics of how these roles are 1008 realized is an implementation matter. 1010 8.2. Control Flow by Role 1012 This section describes three common configurations of Agents and 1013 Managers and the flow of messages between them. These configurations 1014 involve local and remote management and data fusion. 1016 8.2.1. Notation 1018 The notation outlined in Table 1 describes the types of control 1019 messages exchanged between Agents and Managers. 1021 +-------------+--------------------------------------+--------------+ 1022 | Term | Definition | Example | 1023 +-------------+--------------------------------------+--------------+ 1024 | EDD# | EDD definition. | EDD1 | 1025 | | | | 1026 | V# | Variable definition. | V1 = EDD1 + | 1027 | | | V0. | 1028 | | | | 1029 | DEF([ACL], | Define id from expression. Allow | DEF([*], V1, | 1030 | ID,EXPR) | managers in access control list | EDD1 + EDD2) | 1031 | | (ACL) to request this id. | | 1032 | | | | 1033 | PROD(P,ID) | Produce ID according to predicate P. | PROD(1s, | 1034 | | P may be a time period (1s) or an | EDD1) | 1035 | | expression (EDD1 > 10). | | 1036 | | | | 1037 | RPT(ID) | A report identified by ID. | RPT(EDD1) | 1038 +-------------+--------------------------------------+--------------+ 1040 Table 1: Terminology 1042 8.2.2. Serialized Management 1044 This is a nominal configuration of network management where a Manager 1045 interacts with a set of Agents. The control flows for this are 1046 outlined in Figure 2. 1048 Serialized Management Control Flow 1050 +----------+ +---------+ +---------+ 1051 | Manager | | Agent A | | Agent B | 1052 +----+-----+ +----+----+ +----+----+ 1053 | | | 1054 |-----PROD(1s, EDD1)--->| | (1) 1055 |----------------------------PROD(1s, EDD1)-->| 1056 | | | 1057 | | | 1058 |<-------RPT(EDD1)------| | (2) 1059 |<----------------------------RPT(EDD1)-------| 1060 | | | 1061 | | | 1062 |<-------RPT(EDD1)------| | 1063 |<----------------------------RPT(EDD1)-------| 1064 | | | 1065 | | | 1066 |<-------RPT(EDD1)------| | 1067 |<----------------------------RPT(EDD1)-------| 1068 | | | 1070 In a simple network, a Manager interacts with multiple Agents. 1072 Figure 2 1074 In this figure, the Manager configures Agents A and B to produce EDD1 1075 every second in (1). At some point in the future, upon receiving and 1076 configuring this message, Agents A and B then build a Report Entry 1077 containing EDD1 and send those reports back to the Manager in (2). 1079 8.2.3. Multiplexed Management 1081 Networks spanning multiple administrative domains may require 1082 multiple Managers (for example, one per domain). When a Manager 1083 defines custom Reports/Variables to an Agent, that definition may be 1084 tagged with an Access Control List (ACL) to limit what other Managers 1085 will be privy to this information. Managers in such networks should 1086 synchronize with those other Managers granted access to their custom 1087 data definitions. When Agents generate messages, they MUST only send 1088 messages to Managers according to these ACLs, if present. The 1089 control flows in this scenario are outlined in Figure 3. 1091 Multiplexed Management Control Flow 1093 +-----------+ +-------+ +-----------+ 1094 | Manager A | | Agent | | Manager B | 1095 +-----+-----+ +---+---+ +-----+-----+ 1096 | | | 1097 |---DEF(A,V1,EDD1*2)-->|<-DEF(B, V2, EDD2*2)--| (1) 1098 | | | 1099 |---PROD(1s, V1)------>|<---PROD(1s, V2)------| (2) 1100 | | | 1101 |<--------RPT(V1)------| | (3) 1102 | |--------RPT(V2)------>| 1103 |<--------RPT(V1)------| | 1104 | |--------RPT(V2)------>| 1105 | | | 1106 | |<---PROD(1s, V1)------| (4) 1107 | | | 1108 | |---ERR(V1 no perm.)-->| 1109 | | | 1110 |--DEF(*,V3,EDD3*3)--->| | (5) 1111 | | | 1112 |---PROD(1s, V3)------>| | (6) 1113 | | | 1114 | |<----PROD(1s, V3)-----| 1115 | | | 1116 |<--------RPT(V3)------|--------RPT(V3)------>| (7) 1117 |<--------RPT(V1)------| | 1118 | |--------RPT(V2)------>| 1119 |<-------RPT(V3)-------|--------RPT(V3)------>| 1120 |<-------RPT(V1)-------| | 1121 | |--------RPT(V2)------>| 1123 Complex networks require multiple Managers interfacing with Agents. 1125 Figure 3 1127 In more complex networks, any Manager may choose to define custom 1128 Reports and Variables, and Agents may need to accept such definitions 1129 from multiple Managers. Variable definitions may include an ACL that 1130 describes who may query and otherwise understand these definitions. 1131 In (1), Manager A defines V1 only for A while Manager B defines V2 1132 only for B. Managers may, then, request the production of Report 1133 Entries containing these definitions, as shown in (2). Agents 1134 produce different data for different Managers in accordance with 1135 configured production rules, as shown in (3). If a Manager requests 1136 the production of a custom definition for which the Manager has no 1137 permissions, a response consistent with the configured logging policy 1138 on the Agent should be implemented, as shown in (4). Alternatively, 1139 as shown in (5), a Manager may define custom data with no 1140 restrictions allowing all other Managers to request and use this 1141 definition. This allows all Managers to request the production of 1142 Report Entries containing this definition, shown in (6) and have all 1143 Managers receive this and other data going forward, as shown in (7). 1145 8.2.4. Data Fusion 1147 In some networks, Agents do not individually transmit their data to a 1148 Manager, preferring instead to fuse reporting data with local nodes 1149 prior to transmission. This approach reduces the number and size of 1150 messages in the network and reduces overall transmission energy 1151 expenditure. The AMA supports fusion of NM reports by co-locating 1152 Agents and Managers on nodes and offloading fusion activities to the 1153 Manager. This process is illustrated in Figure 4. 1155 Data Fusion Control Flow 1157 +-----------+ +-----------+ +---------+ +---------+ 1158 | Manager A | | Manager B | | Agent B | | Agent C | 1159 +---+-------+ +-----+-----+ +----+----+ +----+----+ 1160 | | | | 1161 |--DEF(A,V0,EDD1+AD2)->| | | (1) 1162 |--PROD(EDD1&AD2,V0)-->| | | 1163 | | | | 1164 | |--PROD(1s,EDD1)->| | (2) 1165 | |------------------PROD(1s, EDD2)->| 1166 | | | | 1167 | |<---RPT(EDD1)----| | (3) 1168 | |<------------------RPT(EDD2)------| 1169 | | | | 1170 |<-----RPT(A,V0)-------| | | (4) 1171 | | | | 1173 Data fusion occurs amongst Managers in the network. 1175 Figure 4 1177 In this example, Manager A requires the production of a Variable V0, 1178 from node B, as shown in (1). The Manager role understands what data 1179 is available from what agents in the subnetwork local to B, 1180 understanding that EDD1 is available locally and EDD2 is available 1181 remotely. Production messages are produced in (2) and data collected 1182 in (3). This allows the Manager at node B to fuse the collected 1183 Report Entries into V0 and return it in (4). While a trivial 1184 example, the mechanism of associating fusion with the Manager 1185 function rather than the Agent function scales with fusion 1186 complexity, though it is important to reiterate that Agent and 1187 Manager designations are roles, not individual software components. 1188 There may be a single software application running on node B 1189 implementing both Manager B and Agent B roles. 1191 9. IANA Considerations 1193 This protocol has no fields registered by IANA. 1195 10. Security Considerations 1197 Security within an AMA MUST exist in two layers: transport layer 1198 security and access control. 1200 Transport-layer security addresses the questions of authentication, 1201 integrity, and confidentiality associated with the transport of 1202 messages between and amongst Managers and Agents in the AMA. This 1203 security is applied before any particular Actor in the system 1204 receives data and, therefore, is outside of the scope of this 1205 document. 1207 Finer grain application security is done via ACLs which are defined 1208 via configuration messages and implementation specific. 1210 11. Informative References 1212 [BIRRANE1] 1213 Birrane, E. and R. Cole, "Management of Disruption- 1214 Tolerant Networks: A Systems Engineering Approach", 2010. 1216 [BIRRANE2] 1217 Birrane, E., Burleigh, S., and V. Cerf, "Defining 1218 Tolerance: Impacts of Delay and Disruption when Managing 1219 Challenged Networks", 2011. 1221 [BIRRANE3] 1222 Birrane, E. and H. Kruse, "Delay-Tolerant Network 1223 Management: The Definition and Exchange of Infrastructure 1224 Information in High Delay Environments", 2011. 1226 [I-D.irtf-dtnrg-dtnmp] 1227 Birrane, E. and V. Ramachandran, "Delay Tolerant Network 1228 Management Protocol", draft-irtf-dtnrg-dtnmp-01 (work in 1229 progress), December 2014. 1231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1232 Requirement Levels", BCP 14, RFC 2119, 1233 DOI 10.17487/RFC2119, March 1997, 1234 . 1236 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 1237 for the Simple Network Management Protocol (SNMP)", 1238 STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, 1239 . 1241 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1242 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1243 Networking Architecture", RFC 4838, April 2007. 1245 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1246 and A. Bierman, Ed., "Network Configuration Protocol 1247 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1248 . 1250 Author's Address 1252 Edward J. Birrane 1253 Johns Hopkins Applied Physics Laboratory 1255 Email: Edward.Birrane@jhuapl.edu