idnits 2.17.1 draft-carpenter-anima-asa-guidelines-02.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 (July 1, 2017) is 2484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-06 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-06 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-13 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-03 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: January 2, 2018 Huawei Technologies Co., Ltd 6 July 1, 2017 8 Guidelines for Autonomic Service Agents 9 draft-carpenter-anima-asa-guidelines-02 11 Abstract 13 This document proposes guidelines for the design of Autonomic Service 14 Agents for autonomic networks. It is based on the Autonomic Network 15 Infrastructure outlined in the ANIMA reference model, making use of 16 the Autonomic Control Plane and the Generic Autonomic Signaling 17 Protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 2, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Logical Structure of an Autonomic Service Agent . . . . . . . 3 55 3. Interaction with the Autonomic Networking Infrastructure . . 4 56 3.1. Interaction with the security mechanisms . . . . . . . . 4 57 3.2. Interaction with the Autonomic Control Plane . . . . . . 5 58 3.3. Interaction with GRASP and its API . . . . . . . . . . . 5 59 3.4. Interaction with Intent mechanism . . . . . . . . . . . . 6 60 4. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 6 61 5. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Coordination . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 10.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document proposes guidelines for the design of Autonomic Service 75 Agents (ASAs) in the context of an Autonomic Network (AN) based on 76 the Autonomic Network Infrastructure (ANI) outlined in the ANIMA 77 reference model [I-D.ietf-anima-reference-model]. This 78 infrastructure makes use of the Autonomic Control Plane (ACP) 79 [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic 80 Signaling Protocol (GRASP) [I-D.ietf-anima-grasp]. 82 There is a considerable literature about autonomic agents with a 83 variety of proposals about how they should be characterized. Some 84 examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. 85 However, for the present document, the basic definitions and goals 86 for autonomic networking given in [RFC7575] apply . According to RFC 87 7575, an Autonomic Service Agent is "An agent implemented on an 88 autonomic node that implements an autonomic function, either in part 89 (in the case of a distributed function) or whole." 91 The reference model [I-D.ietf-anima-reference-model] expands this by 92 adding that an ASA is "a process that makes use of the features 93 provided by the ANI to achieve its own goals, usually including 94 interaction with other ASAs via the GRASP protocol 95 [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts 96 with the specific targets of its function, using any suitable 97 mechanism. Unless its function is very simple, the ASA will need to 98 be multi-threaded so that it can handle overlapping asynchronous 99 operations. It may therefore be a quite complex piece of software in 100 its own right, forming part of the application layer above the ANI." 102 A basic property of an ASA is that it is a relatively complex 103 software component that will in many cases control and monitor 104 simpler entities in the same host or elsewhere. For example, a 105 device controller that manages tens or hundreds of simple devices 106 might contain a single ASA. 108 The remainder of this document offers guidance on the design of ASAs. 110 2. Logical Structure of an Autonomic Service Agent 112 As mentioned above, all but the simplest ASAs will be multi-threaded 113 programs. 115 A typical ASA will have a main thread that performs various initial 116 housekeeping actions such as: 118 o Obtain authorization credentials. 120 o Register the ASA with GRASP. 122 o Acquire relevant policy Intent. 124 o Define data structures for relevant GRASP objectives. 126 o Register with GRASP those objectives that it will actively manage. 128 o Launch a self-monitoring thread. 130 o Enter its main loop. 132 The logic of the main loop will depend on the details of the 133 autonomic function concerned. Whenever asynchronous operations are 134 required, extra threads will be launched. Examples of such threads 135 include: 137 o A background thread to repeatedly flood an objective to the AN, so 138 that any ASA can receive the objective's latest value. 140 o A thread to accept incoming synchronization requests for an 141 objective managed by this ASA. 143 o A thread to accept incoming negotiation requests for an objective 144 managed by this ASA, and then to conduct the resulting negotiation 145 with the counterpart ASA. 147 o A thread to manage subsidiary non-autonomic devices directly. 149 These threads should all either exit after their job is done, or 150 enter a wait state for new work, to avoid blocking other threads 151 unnecessarily. 153 Note: If the programming environment does not support multi- 154 threading, an 'event loop' style of implementation could be adopted, 155 in which case each of the above threads would be implemented as an 156 event handler called in turn by the main loop. In this case, the 157 GRASP API (Section 3.3) must provide non-blocking calls. If 158 necessary, the GRASP session identifier will be used to distinguish 159 simultaneous negotiations. 161 According to the degree of parallelism needed by the application, 162 some of these threads might be launched in multiple instances. In 163 particular, if negotiation sessions with other ASAs are expected to 164 be long or to involve wait states, the ASA designer might allow for 165 multiple simultaneous negotiating threads, with appropriate use of 166 queues and locks to maintain consistency. 168 The main loop itself could act as the initiator of synchronization 169 requests or negotiation requests, when the ASA needs data or 170 resources from other ASAs. In particular, the main loop should watch 171 for changes in policy Intent that affect its operation. It should 172 also do whatever is required to avoid unnecessary resource 173 consumption, such as including an arbitrary wait time in each cycle 174 of the main loop. 176 The self-monitoring thread is of considerable importance. Autonomic 177 service agents must never fail. To a large extent this depends on 178 careful coding and testing, with no unhandled error returns or 179 exceptions, but if there is nevertheless some sort of failure, the 180 self-monitoring thread should detect it, fix it if possible, and in 181 the worst case restart the entire ASA. 183 3. Interaction with the Autonomic Networking Infrastructure 185 3.1. Interaction with the security mechanisms 187 An ASA by definition runs in an autonomic node. Before any normal 188 ASAs are started, such nodes must be bootstrapped into the autonomic 189 network's secure key infrastructure in accordance with 190 [I-D.ietf-anima-bootstrapping-keyinfra]. This key infrastructure 191 will be used to secure the ACP (next section) and may be used by ASAs 192 to set up additional secure interactions with their peers, if needed. 194 Note that the secure bootstrap process itself may include special- 195 purpose ASAs that run in a constrained insecure mode. 197 3.2. Interaction with the Autonomic Control Plane 199 In a normal autonomic network, ASAs will run as clients of the ACP. 200 It will provide a fully secured network environment for all 201 communication with other ASAs, in most cases mediated by GRASP (next 202 section). 204 Note that the ACP formation process itself may include special- 205 purpose ASAs that run in a constrained insecure mode. 207 3.3. Interaction with GRASP and its API 209 GRASP [I-D.ietf-anima-grasp] is expected to run as a separate process 210 with its API [I-D.liu-anima-grasp-api] available in user space. Thus 211 ASAs may operate without special privilege, unless they need it for 212 other reasons. The ASA's view of GRASP is built around GRASP 213 objectives (Section 4), defined as data structures containing 214 administrative information such as the objective's unique name, and 215 its current value. The format and size of the value is not 216 restricted by the protocol, except that it must be possible to 217 serialise it for transmission in CBOR [RFC7049], which is no 218 restriction at all in practice. 220 The GRASP API offers the following features: 222 o Registration functions, so that an ASA can register itself and the 223 objectives that it manages. 225 o A discovery function, by which an ASA can discover other ASAs 226 supporting a given objective. 228 o A negotiation request function, by which an ASA can start 229 negotiation of an objective with a counterpart ASA. With this, 230 there is a corresponding listening function for an ASA that wishes 231 to respond to negotiation requests, and a set of functions to 232 support negotiating steps. 234 o A synchronization function, by which an ASA can request the 235 current value of an objective from a counterpart ASA. With this, 236 there is a corresponding listening function for an ASA that wishes 237 to respond to synchronization requests. 239 o A flood function, by which an ASA can cause the current value of 240 an objective to be flooded throughout the AN so that any ASA can 241 receive it. 243 For further details and some additional housekeeping functions, see 244 [I-D.liu-anima-grasp-api]. 246 This API is intended to support the various interactions expected 247 between most ASAs, such as the interactions outlined in Section 2. 248 However, if ASAs require additional communication between themselves, 249 they can do so using any desired protocol. One option is to use 250 GRASP discovery and synchronization as a rendez-vous mechanism 251 between two ASAs, passing communication parameters such as a TCP port 252 number as the value of a GRASP objective. As noted above, either the 253 ACP or in special cases the autonomic key infrastructure will be used 254 to secure such communications. 256 3.4. Interaction with Intent mechanism 258 At the time of writing, the Intent mechanism for the ANI is 259 undefined. It is expected to operate by an information distribution 260 mechanism that can reach all autonomic nodes, and therefore every 261 ASA. However, each ASA must be capable of operating "out of the box" 262 in the absence of locally defined Intent, so every ASA implementation 263 must include carefully chosen default values and settings for all 264 parameters and choices that might depend on Intent. 266 4. Design of GRASP Objectives 268 The general rules for the format of GRASP Objective options, their 269 names, and IANA registration are given in [I-D.ietf-anima-grasp]. 270 Additionally that document discusses various general considerations 271 for the design of objectives, which are not repeated here. However, 272 we emphasize that the GRASP protocol does not provide transactional 273 integrity. In other words, if an ASA is capable of overlapping 274 several negotiations for a given objective, then the ASA itself must 275 use suitable locking techniques to avoid interference between these 276 negotiations. For example, if an ASA is allocating part of a shared 277 resource to other ASAs, it needs to ensure that the same part of the 278 resource is not allocated twice. This might impact the design of the 279 objective as well as the logic flow of the ASA. 281 In particular, if 'dry run' mode is defined for the objective, its 282 specification, and every implementation, must consider what state 283 needs to be saved following a dry run negotiation, such that a 284 subsequent live negotiation can be expected to succeed. It must be 285 clear how long this state is kept, and what happens if the live 286 negotiation occurs after this state is deleted. An ASA that requests 287 a dry run negotiation must take account of the possibility that a 288 successful dry run is followed by a failed live negotiation. Because 289 of these complexities, the dry run mechanism should only be supported 290 by objectives and ASAs where there is a significant benefit from it. 292 The actual value field of an objective is limited by the GRASP 293 protocol definition to any data structure that can be expressed in 294 Concise Binary Object Representation (CBOR) [RFC7049]. For some 295 objectives, a single data item will suffice; for example an integer, 296 a floating point number or a UTF-8 string. For more complex cases, a 297 simple tuple structure such as [item1, item2, item3] could be used. 298 Nothing prevents using other formats such as JSON, but this requires 299 the ASA to be capable of parsing and generating JSON. The formats 300 acceptable by the GRASP API will limit the options in practice. A 301 fallback solution is for the API to accept and deliver the value 302 field in raw CBOR, with the ASA itself encoding and decoding it via a 303 CBOR library. 305 5. Life Cycle 307 Autonomic functions could be permanent, in the sense that ASAs are 308 shipped as part of a product and persist throughout the product's 309 life. However, a more likely situation is that ASAs need to be 310 installed or updated dynamically, because of new requirements or 311 bugs. Because continuity of service is fundamental to autonomic 312 networking, the process of seamlessly replacing a running instance of 313 an ASA with a new version needs to be part of the ASA's design. This 314 topic is discussed in detail in "A Day in the Life of an Autonomic 315 Function" [I-D.peloso-anima-autonomic-function]. 317 6. Coordination 319 Some autonomic functions will be completely independent of each 320 other. However, others are at risk of interfering with each other - 321 for example, two different optimization functions might both attempt 322 to modify the same underlying parameter in different ways. In a 323 complete system, a method is needed of identifying ASAs that might 324 interfere with each other and coordinating their actions when 325 necessary. This issue is considered in "Autonomic Functions 326 Coordination" [I-D.ciavaglia-anima-coordination]. 328 7. Security Considerations 330 ASAs are intended to run in an environment that is protected by the 331 Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], 332 admission to which depends on an initial secure bootstrap process 333 [I-D.ietf-anima-bootstrapping-keyinfra]. However, this does not 334 relieve ASAs of responsibility for security. In particular, when 335 ASAs configure or manage network elements outside the ACP, they must 336 use secure techniques and carefully validate any incoming 337 information. As appropriate to their specific functions, ASAs should 338 take account of relevant privacy considerations [RFC6973]. 340 Authorization of ASAs is a subject for future study. At present, 341 ASAs are trusted by virtue of being installed on a node that has 342 successfully joined the ACP. 344 8. IANA Considerations 346 This document makes no request of the IANA. 348 9. Acknowledgements 350 TBD. 352 10. References 354 10.1. Normative References 356 [I-D.ietf-anima-autonomic-control-plane] 357 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 358 Control Plane", draft-ietf-anima-autonomic-control- 359 plane-06 (work in progress), March 2017. 361 [I-D.ietf-anima-bootstrapping-keyinfra] 362 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 363 S., and K. Watsen, "Bootstrapping Remote Secure Key 364 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 365 keyinfra-06 (work in progress), May 2017. 367 [I-D.ietf-anima-grasp] 368 Bormann, C., Carpenter, B., and B. Liu, "A Generic 369 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 370 grasp-13 (work in progress), June 2017. 372 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 373 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 374 October 2013, . 376 10.2. Informative References 378 [DeMola06] 379 De Mola, F. and R. Quitadamo, "An Agent Model for Future 380 Autonomic Communications", Proceedings of the 7th WOA 2006 381 Workshop From Objects to Agents 51-59, September 2006. 383 [GANA13] ETSI GS AFI 002, "Autonomic network engineering for the 384 self-managing Future Internet (AFI): GANA Architectural 385 Reference Model for Autonomic Networking, Cognitive 386 Networking and Self-Management.", April 2013, 387 . 390 [Huebscher08] 391 Huebscher, M. and J. McCann, "A survey of autonomic 392 computing--degrees, models, and applications", ACM 393 Computing Surveys (CSUR) Volume 40 Issue 3 DOI: 394 10.1145/1380584.1380585, August 2008. 396 [I-D.ciavaglia-anima-coordination] 397 Ciavaglia, L. and P. Peloso, "Autonomic Functions 398 Coordination", draft-ciavaglia-anima-coordination-01 (work 399 in progress), March 2016. 401 [I-D.ietf-anima-reference-model] 402 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 403 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 404 Reference Model for Autonomic Networking", draft-ietf- 405 anima-reference-model-03 (work in progress), March 2017. 407 [I-D.liu-anima-grasp-api] 408 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 409 Autonomic Signaling Protocol Application Program Interface 410 (GRASP API)", draft-liu-anima-grasp-api-04 (work in 411 progress), June 2017. 413 [I-D.peloso-anima-autonomic-function] 414 Pierre, P. and L. Ciavaglia, "A Day in the Life of an 415 Autonomic Function", draft-peloso-anima-autonomic- 416 function-01 (work in progress), March 2016. 418 [Movahedi12] 419 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 420 Survey of Autonomic Network Architectures and Evaluation 421 Criteria", IEEE Communications Surveys & Tutorials Volume: 422 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 423 Page(s): 464 - 490, 2012. 425 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 426 Morris, J., Hansen, M., and R. Smith, "Privacy 427 Considerations for Internet Protocols", RFC 6973, 428 DOI 10.17487/RFC6973, July 2013, 429 . 431 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 432 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 433 Networking: Definitions and Design Goals", RFC 7575, 434 DOI 10.17487/RFC7575, June 2015, 435 . 437 Appendix A. Change log [RFC Editor: Please remove] 439 draft-carpenter-anima-asa-guidelines-02, 2017-07-01: 441 Expanded description of event-loop case. 443 Added note about 'dry run' mode. 445 draft-carpenter-anima-asa-guidelines-01, 2017-01-06: 447 More sections filled in 449 draft-carpenter-anima-asa-guidelines-00, 2016-09-30: 451 Initial version 453 Authors' Addresses 455 Brian Carpenter 456 Department of Computer Science 457 University of Auckland 458 PB 92019 459 Auckland 1142 460 New Zealand 462 Email: brian.e.carpenter@gmail.com 464 Sheng Jiang 465 Huawei Technologies Co., Ltd 466 Q14, Huawei Campus, No.156 Beiqing Road 467 Hai-Dian District, Beijing, 100095 468 P.R. China 470 Email: jiangsheng@huawei.com