idnits 2.17.1 draft-irtf-nmrg-autonomic-network-definitions-05.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 (December 16, 2014) is 3412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: June 19, 2015 A. Clemm 6 Cisco Systems 7 B. Carpenter 8 Univ. of Auckland 9 S. Jiang 10 Huawei Technologies Co., Ltd 11 L. Ciavaglia 12 Alcatel Lucent 13 December 16, 2014 15 Autonomic Networking - Definitions and Design Goals 16 draft-irtf-nmrg-autonomic-network-definitions-05.txt 18 Abstract 20 Autonomic systems were first described in 2001. The fundamental goal 21 is self-management, including self-configuration, self-optimization, 22 self-healing and self-protection. This is achieved by an autonomic 23 function having minimal dependencies on human administrators or 24 centralized management systems. It usually implies distribution 25 across network elements. 27 This document defines common language, and outlines design goals and 28 non-design goals for autonomic functions. A high level reference 29 model illustrates how functional elements in an autonomic network 30 interact. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 19, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction to Autonomic Networking . . . . . . . . . . . . 2 67 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Self-Management . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Co-Existence with Traditional Management . . . . . . . . 6 71 3.3. By Default Secure . . . . . . . . . . . . . . . . . . . . 7 72 3.4. Decentralisation and Distribution . . . . . . . . . . . . 8 73 3.5. Simplification of Autonomic Node Northbound Interfaces . 8 74 3.6. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.7. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 8 76 3.8. Common Autonomic Networking Infrastructure . . . . . . . 9 77 3.9. Independence of Function and Layer . . . . . . . . . . . 10 78 3.10. Full Life Cycle Support . . . . . . . . . . . . . . . . . 10 79 4. Non Design Goals . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1. Eliminate human operators . . . . . . . . . . . . . . . . 10 81 4.2. Eliminate emergency fixes . . . . . . . . . . . . . . . . 11 82 4.3. Eliminate central control . . . . . . . . . . . . . . . . 11 83 5. An Autonomic Reference Model . . . . . . . . . . . . . . . . 11 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 9. Informative References . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction to Autonomic Networking 92 Autonomic systems were first described in a manifesto by IBM in 2001 93 [Kephart]. The fundamental concept involves eliminating external 94 systems from a system's control loops and closing of control loops 95 within the autonomic system itself, with the goal of providing the 96 system with self-management capabilities, including self- 97 configuration, self-optimization, self-healing and self-protection. 99 IP networking was initially designed with similar properties in mind. 100 An IP network should be distributed and redundant to withstand 101 outages in any part of the network. Routing protocols such as OSPF 102 or ISIS exhibit properties of self-management, and can thus be 103 considered autonomic in the definition of this document. 105 However, as IP networking evolved, the ever increasing intelligence 106 of network elements was often not put into protocols to follow this 107 paradigm, but external configuration systems. This configuration 108 made network elements dependent on some process that manages them, 109 either a human, or a network management system. 111 Autonomic functions can be defined in two ways: 113 o On a node level: Nodes interact with each other to form feedback 114 loops. 116 o On a system level: Feedback loops include central elements as 117 well. 119 System level autonomy is implicitly or explicitly the subject in many 120 IETF working groups, where interactions with controllers or network 121 management systems are discussed. 123 This work specifically focuses on node level autonomic functions. It 124 focuses on intelligence of algorithms at the node level, to minimize 125 dependency on human administrators and central management systems. 127 Some network deployments benefit from a fully autonomic approach, for 128 example networks with a large number of relatively simple devices. 129 Most of currently deployed networks however will require a mixed 130 approach, where some functions are autonomic and others are centrally 131 managed. Central management of networking functions clearly has 132 advantages and will be chosen for many networking functions. This 133 document does not discuss which functions should be centralised or 134 follow an autonomic approach. Instead, it should help make the 135 decision which is the best approach for a given situation. 137 Autonomic function cannot always discover all required information; 138 for example, policy related information requires human input, because 139 policy is by its nature derived and specified by humans. Where input 140 from some central intelligence is required, it is provided in a 141 highly abstract, network wide form. 143 Autonomic Computing in general and Autonomic Networking in particular 144 have been the subject of academic study for many years. There is a 145 large literature, including several useful overview papers (e.g., 146 [Samaan], [Movahedi], and [Dobson]). In the present document we 147 focus on concepts and definitions that seem sufficiently mature to 148 become the basis for interoperable specifications in the near future. 149 In particular, such specifications will need to co-exist with 150 traditional methods of network configuration and management, rather 151 than realising an exclusively autonomic system with all the 152 properties that it would require. 154 There is an important difference between "automatic" and "autonomic". 155 "Automatic" refers to a pre-defined process, such as a script. 156 "Autonomic" is used in the context of self-management. It includes 157 feedback loops between elements as well as northbound to central 158 elements. See also the definitions in the next section. Generally, 159 an automatic process works in a given environment, but has to be 160 adapted if the environment changes. An autonomic process can adapt 161 to changing environments. 163 This document provides the definitions and design goals for Autonomic 164 Networking in the IETF and IRTF. 166 2. Definitions 168 We make the following definitions: 170 Autonomic: Self-managing (self-configuring, self-protecting, self- 171 healing, self-optimizing); however, allowing high-level guidance by a 172 central entity, through intent. An autonomic function adapts on its 173 own to a changing environment. 175 Automatic: A process that occurs without human intervention, with 176 step-by-step execution of rules. However it relies on humans 177 defining the sequence of rules, so is not Autonomic in the full 178 sense. For example, a start-up script is automatic but not 179 autonomic. An automatic function may need manual adjustments if the 180 environment changes. 182 Intent: An abstract, high level policy used to operate the network 183 autonomically. Its scope is an autonomic domain, such as an 184 enterprise network. It does not contain configuration or information 185 for a specific node (see Section 3.2 on how intent co-exists with 186 alternative management paradigms). It may contain information 187 pertaining to nodes with a specific role, for example an edge switch, 188 or a node running a specific function. 190 Autonomic Domain: A collection of autonomic nodes that instantiate 191 the same intent. 193 Autonomic Function: A feature or function which requires no 194 configuration, and can derive all required information either through 195 self-knowledge, discovery or through intent. 197 Autonomic Service Agent: An agent implemented on an autonomic node 198 which implements an autonomic function, either in part (in the case 199 of a distributed function) or whole. 201 Autonomic Node: A node which employs exclusively autonomic functions. 202 It requires (!) no configuration. (Note that configuration can be 203 used to override an autonomic function. See Section 3.2 for more 204 details.) An Autonomic Node may operate on any layer of the 205 networking stack. Examples are routers, switches, personal 206 computers, call managers, etc. 208 Autonomic Network: A network containing exclusively autonomic nodes. 209 It may contain one or several autonomic domains. 211 3. Design Goals 213 This section explains the high level goals of Autonomic Networking, 214 independent of any specific solutions. 216 3.1. Self-Management 218 The original design goals of autonomic systems as described in 219 [Kephart] also apply to Autonomic Networks. The over-arching goal is 220 self-management, which is comprised of several self-* properties. 221 The most commonly cited are: 223 o Self-configuration: Functions do not require to be configured, 224 neither by an administrator nor a management system. They 225 configure themselves, based on self-knowledge, discovery, and 226 intent. Discovery is the default way for an autonomic function to 227 receive the information it needs to operate. 229 o Self-healing: Autonomic functions adapt on their own to changes in 230 the environment, and heal problems automatically. 232 o Self-optimising: Autonomic functions automatically determine ways 233 to optimise their behaviour against a set of well-defined goals. 235 o Self-protection: Autonomic functions automatically secure 236 themselves against potential attacks. 238 Almost any network can be described as "self-managing", as long as 239 the definition of "self" is large enough. For example, a well- 240 defined SDN system, including the controller elements, can be 241 described over all as "autonomic", if the controller provides an 242 interface to the administrator which has the same properties as 243 mentioned above (high level, network-wide, etc). 245 For the work in the IETF and IRTF we define the "self" properties on 246 the node level. It is the design goal to make functions on network 247 nodes self- managing, in other words, minimally dependent on 248 management systems or controllers, as well as human operators. Self- 249 managing functions on a node might need to exchange information with 250 other nodes in order to achieve the required goals. 252 As mentioned in the Introduction, closed-loop control is an important 253 aspect of self-managing systems. This implies peer-to-peer dialogues 254 between the parties that make up the closed loop. Such dialogues 255 require two-way "discussion" or "negotiation" between each pair or 256 groups of peers involved in the loop, so they cannot readily use 257 typical top-down command-response protocols. Also, a discovery phase 258 is unavoidable before such closed-loop control can take place. 259 Multi-party protocols are also possible but can be significantly more 260 complex. 262 3.2. Co-Existence with Traditional Management 264 For the foreseeable future, fully autonomic nodes and networks will 265 be the exception; autonomic behaviour will initially be defined 266 function by function. Therefore, co-existence with other network 267 management paradigms has to be considered. Examples are management 268 by command line, SNMP, SDN (with related APIs), netconf, etc. 270 Conflict resolution between autonomic default behaviour and intent on 271 one side, and other methods on the other is therefore required. This 272 is achieved through prioritisation. Generally, autonomic mechanisms 273 define a network wide behaviour, whereas the alternative methods are 274 typically on a node by node basis. Node based management concepts 275 take a higher priority over autonomic methods. This is in line with 276 current examples of autonomic functions, for example routing: A 277 (statically configured) route has priority over the routing 278 algorithm. In short: 280 o lowest priority: autonomic default behaviour 282 o medium priority: autonomic intent 284 o highest priority: node specific network management concepts, such 285 as command line, SNMP, SDN, netconf, etc. How these concepts are 286 prioritised between themselves is outside the scope of this 287 document. 289 The above priorisation essentially results in the actions of the 290 human administrator always being able to over-rule autonomic 291 behaviour. This is generally the expectation of network operators 292 today, and remains therefore a design principle here. In critical 293 systems, such as atomic power plants, sometimes the opposite 294 philosophy is used: The expectation is that a well defined algorithm 295 is more reliable than a human operator, especially in rare exception 296 cases. Networking generally does not follow this philosophy yet. 297 Warnings however should be issued if node specific overrides may 298 conflict with autonomic behaviour. 300 In other fields, autonomic mechanisms disengage automatically if 301 certain conditions occur: The auto-pilot in a plane switches off if 302 the plane is outside a pre-defined envelope of flight parameters. 303 The assumption is that the algorithms only work correctly if the 304 input values are in expected ranges. Some opinions however suggest 305 that exactly in exceptional conditions is the worst moment to switch 306 of autonomic behaviour, since the pilots have no full understanding 307 of the situation at this point, and may be under high levels of 308 stress. For this reason we suggest here to NOT generally disable 309 autonomic functions if they encounter unexpected conditions, because 310 it is expected that this adds another level of unpredictability in 311 networks, when the situation may already be hard to understand. 313 3.3. By Default Secure 315 All autonomic interactions should be by default secure. This 316 requires that any member of an autonomic domain can assert its 317 membership using a domain identity, for example a certificate issued 318 by a domain certification authority. This domain identity is used 319 for nodes to learn about their neighbouring nodes, to determine the 320 boundaries of the domain, and to cryptographically secure 321 interactions within the domain. Nodes from different domains can 322 also mutually verify their identity and secure interactions as long 323 as they have a mutually respected trust anchor. 325 A strong, cryptographically verifiable domain identity is a 326 fundamental cornerstone in autonomic networking. It can be leveraged 327 to secure all communications, and allows thus automatic security 328 without traditional configuration, for example pre-shared keys. 330 Autonomic functions must be able to adapt their behaviour depending 331 on the domain of the node they are interacting with. 333 3.4. Decentralisation and Distribution 335 The goal of Autonomic Networking is to minimise dependencies on 336 central elements; therefore, de-centralisation and distribution are 337 fundamental to the concept. If a problem can be solved in a 338 distributed manner, it should not be centralised. 340 In certain cases it is today operationally preferable to keep a 341 central repository of information, for example a user database on a 342 AAA server. An autonomic network should also be able to use such 343 central systems, in order to be deployable. However, it is possible 344 to distribute such databases as well, and such efforts should be at 345 least considered. 347 3.5. Simplification of Autonomic Node Northbound Interfaces 349 Even in a decentralised solution, certain information flows with 350 central entities are required. Examples are the distribution of 351 intent or high level service definitions, as well as network status 352 requests, audit information, logging and aggregated reporting. 354 Therefore, also nodes in an autonomic network require a northbound 355 interface. However, the design goal is to maintain this interface as 356 simple and high level as possible. 358 3.6. Abstraction 360 An administrator or autonomic management system interacts with an 361 autonomic network on a high level of abstraction. Intent is defined 362 at a level of abstraction that is much higher than that of typical 363 configuration parameters, for example, "optimize my network for 364 energy efficiency". Intent must not be used to convey low-level 365 commands or concepts, since those are on a different abstraction 366 level. 368 For example, the administrator should not be exposed to the version 369 of the IP protocol running in the network. 371 Also on the reporting and feedback side an autonomic network 372 abstracts information and provides high-level messages such as "the 373 link between node x and y is down" (possibly with an identifier for 374 the specific link, in case of multiple links). 376 3.7. Autonomic Reporting 378 An autonomic network, while minimizing the need for user 379 intervention, still needs to provide users with visibility like in 380 traditional networks. However, in an autonomic network reporting 381 should happen on a network wide basis. Information about the network 382 should be collected and aggregated by the network itself, presented 383 in consolidated fashion to the administrator. 385 The layers of abstraction that are provided via intent need to be 386 supported for reporting functions as well, in order to give users an 387 indication about the effectiveness of their intent. For example, in 388 order to assess how effective the network performs with regards to 389 the intent "optimize my network for energy efficiency", the network 390 should provide aggregate information about the number of ports that 391 were able to be shut down, and the corresponding energy savings, 392 while validating current service levels are on aggregate still met. 394 Autonomic network events should concern the autonomic network as a 395 whole, not individual systems in isolation. For example, the same 396 failure symptom should not be reported from every system that 397 observes it, but only once for the autonomic network as a whole. 398 Ultimately, the autonomic network should support exception based 399 management, in which only events that truly require user attention 400 are actually notified. This requires capabilities that allow systems 401 within the network to compare information and apply specific 402 algorithms to determine what should be reported. 404 3.8. Common Autonomic Networking Infrastructure 406 [I-D.irtf-nmrg-an-gap-analysis] points out that there are already a 407 number of fully or partially autonomic functions available today. 408 However, these are largely independent, and each has its own methods 409 and protocols to communicate, discover, define and distribute policy, 410 etc. 412 The goal of the work on autonomic networking in the IETF is therefore 413 not just to create autonomic functions, but to define a common 414 infrastructure that autonomic functions can use. This autonomic 415 networking infrastructure may contain common control and management 416 functions such as messaging, service discovery, negotiation, intent 417 distribution, self-monitoring and diagnostics, etc. A common 418 approach to define and manage intent is also required. 420 Refer to the reference model below: All the components around the 421 "autonomic service agents" should be common components, such that the 422 autonomic service agents do not have to replicate common tasks 423 individually. 425 3.9. Independence of Function and Layer 427 Autonomic functions may reside on any layer in the networking stack. 428 For example, layer 2 switching today is already relatively autonomic 429 in many environments, since most switches can be plugged together in 430 many ways and will automatically build a simple layer 2 topology. 431 Routing functions run on a higher layer and can be autonomic on layer 432 3. Even application layer functionality such as unified 433 communications can be autonomic. 435 "Autonomic" in the context of this framework is a property of a 436 function which is implemented on a node. Autonomic functions can be 437 implemented on any node type, for example a switch, router, server, 438 or call manager. 440 An Autonomic Network requires an overall control plane for autonomic 441 nodes to communicate. As in general IP networking, IP is the 442 spanning layer that binds all those elements together; autonomic 443 functions in the context of this framework should therefore operate 444 at the IP layer. This concerns neighbour discovery protocols and 445 other autonomic control plane functions. 447 3.10. Full Life Cycle Support 449 An autonomic function does not depend on external input to operate; 450 it needs to understand its current situation and surrounding, and 451 operate according to its current state. Therefore, an autonomic 452 function must understand the full life cycle of the device it runs 453 on, from first manufacturing testing through deployment, testing, 454 troubleshooting, up to decommissioning. 456 The state of the life-cycle of an autonomic node is reflected in a 457 state model. The behaviour of an autonomic function may be different 458 for different deployment states. 460 4. Non Design Goals 462 This section identifies various items that are explicitly not design 463 goals in the IETF/IRTF for autonomic networks, which are mentioned to 464 avoid misunderstandings of the general intention. They address some 465 commonly expressed concerns from network administrators and 466 architects. 468 4.1. Eliminate human operators 470 Section 3.1 states that "It is the design goal to [...] minimally 471 dependent on [...] human operators". It is however not a design goal 472 to completely eliminate them. The problem targeted by autonomic 473 networking is the error-prone and hard to scale model of individual 474 configuration of network elements, traditionally by manual commands 475 but today mainly by scripting and/or configuration management 476 databases. This does not, however, imply the elimination of skilled 477 human operators, who will still be needed for oversight, policy 478 management, diagnosis, reaction to help desk tickets, etc. etc. The 479 main impact on administrators should be less tedious detailed work 480 and more high-level work. (They should become more like doctors than 481 hospital orderlies.) 483 4.2. Eliminate emergency fixes 485 However good the autonomous mechanisms, sometimes there will be fault 486 conditions etc. that they cannot deal with correctly. At this point 487 skilled operator interventions will be needed to correct or work 488 around the problem. Hopefully this can be done by high-level 489 mechanisms (adapting the policy database in some way) but in some 490 cases direct intervention at device level may be unavoidable. This 491 is obviously the case for hardware failures, even if the autonomic 492 network has bypassed the fault for the time being. Truck rolls will 493 not be eliminated when faulty equipment needs to be replaced. 494 However, this may be less urgent if the autonomic system 495 automatically reconfigures to minimise the operational impact. 497 4.3. Eliminate central control 499 While it is a goal to simplify northbound interfaces (Section 3.5), 500 it is not a goal to eliminate central control, but to allow it on a 501 higher abstraction level. Senior management might fear loss of 502 control of an autonomic network. In fact this is no more likely than 503 with a traditional network; the emphasis on automatically applying 504 general policy and security rules might even provide more central 505 control. 507 5. An Autonomic Reference Model 509 An Autonomic Network consists of Autonomic Nodes. Those nodes 510 communicate with each other through an Autonomic Control Plane which 511 provides a robust and secure communications overlay. The Autonomic 512 Control Plane is self-organizing and autonomic itself. 514 An Autonomic Node contains various elements, such as autonomic 515 service agents which implement autonomic functions. Figure 1 shows a 516 reference model of an autonomic node. The elements and their 517 interaction are: 519 o Autonomic Service Agents, which implement the autonomic behaviour 520 of a specific service or function. 522 o Self-knowledge: An autonomic node knows its own properties and 523 capabilities 525 o Network Knowledge (Discovery): An autonomic service agent may 526 require various discovery functions in the network, such as 527 service discovery. 529 o Intent: Network wide high level policy. Autonomic Service Agents 530 use an intent interpretation engine to locally instantiate the 531 global intent. This may involve coordination with other Autonomic 532 Nodes. 534 o Feedback Loops: Control elements outside the node may interact 535 with autonomic nodes through feedback loops. 537 o An Autonomic User Agent, providing a front-end to external users 538 (administrators and management applications) through which they 539 can communicate intent, receive reports, and monitor the Autonomic 540 Network. 542 o Autonomic Control Plane: Allows the node to communicate with other 543 autonomic nodes. Autonomic functions such as intent distribution, 544 feedback loops, discovery mechanisms, etc, use the autonomic 545 control plane. The autonomic control plane can run inband, over a 546 configured VPN, over a self-managing overlay network, as described 547 in [I-D.behringer-autonomic-control-plane], or over a traditional 548 out of band network. Security is a requirement for the Autonomic 549 Control Plane, which can be bootstrapped by a mechanism as 550 described in [I-D.pritikin-bootstrapping-keyinfrastructures]. 552 +------------------------------------------------------------+ 553 | +----------+ +--------------+ | 554 | | | | Feedback | | 555 | | Intent | | Loops | | 556 | +----------+ +--------------+ | 557 | ^ ^ | 558 | Autonomic User Agent | 559 | V V | 560 | +-----------+ +------------+ +------------+ | 561 | | Self- | | Autonomic | | Network | | 562 | | knowledge |<------>| Service |<------>| Knowledge | | 563 | | | | Agents | | (Discovery)| | 564 | +-----------+ +------------+ +------------+ | 565 | ^ ^ | 566 | | | | 567 | V V | 568 |------------------------------------------------------------| 569 | Autonomic Control Plane | 570 |------------------------------------------------------------| 571 | Standard Operating System Functions | 572 +------------------------------------------------------------+ 574 Figure 1 576 6. IANA Considerations 578 This draft does not request any IANA action. 580 7. Security Considerations 582 This document provides definitions and design goals for autonomic 583 networking. A full threat analysis will be required as part of the 584 development of solutions, taking account of potential attacks from 585 within the network as well as from outside. 587 8. Acknowledgements 589 Many parts of this work on Autonomic Networking are the result of a 590 large team project at Cisco Systems. In alphabetical order: Ignas 591 Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, 592 Bruno Klauser. 594 We thank the following people for their input to this document: 595 Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran. 597 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 598 similar framework for autonomic networking in the "General Autonomic 599 Network Architecture" [GANA]. Many concepts explained in this 600 document can be mapped to the GANA framework. The mapping is outside 601 the scope of this document. Special thanks to Ranganai Chaparadza 602 for his comments and help on this document. 604 9. Informative References 606 [Dobson] Dobson et al., S., "A survey of autonomic communications", 607 ACM Transactions on Autonomous and Adaptive Systems (TAAS) 608 Volume 1 Issue 2, Pages 223-259 , December 2006. 610 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 611 self-managing Future Internet (AFI): GANA Architectural 612 Reference Model for Autonomic Networking, Cognitive 613 Networking and Self-Management.", April 2013, 614 . 617 [I-D.behringer-autonomic-control-plane] 618 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 619 Autonomic Control Plane", draft-behringer-autonomic- 620 control-plane-00 (work in progress), June 2014. 622 [I-D.irtf-nmrg-an-gap-analysis] 623 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 624 for Autonomic Networking", draft-irtf-nmrg-an-gap- 625 analysis-03 (work in progress), December 2014. 627 [I-D.pritikin-bootstrapping-keyinfrastructures] 628 Pritikin, M., Behringer, M., and S. Bjarnason, 629 "Bootstrapping Key Infrastructures", draft-pritikin- 630 bootstrapping-keyinfrastructures-01 (work in progress), 631 September 2014. 633 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 634 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 635 January 2003, . 638 [Movahedi] 639 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 640 Survey of Autonomic Network Architectures and Evaluation 641 Criteria", IEEE Communications Surveys & Tutorials Volume: 642 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 643 Page(s): 464 - 490, 2012. 645 [Samaan] Samaan, N. and A. Karmouch, "Towards Autonomic Network 646 Management: an Analysis of Current and Future Research 647 Directions", IEEE Communications Surveys and Tutorials 648 Volume: 11 , Issue: 3; DOI: 10.1109/SURV.2009.090303; 649 Page(s): 22 - 36, 2009. 651 Authors' Addresses 653 Michael Behringer 654 Cisco Systems 655 Building D, 45 Allee des Ormes 656 Mougins 06250 657 France 659 Email: mbehring@cisco.com 661 Max Pritikin 662 Cisco Systems 663 5330 Airport Blvd 664 Boulder, CO 80301 665 USA 667 Email: pritikin@cisco.com 669 Steinthor Bjarnason 670 Cisco Systems 671 Mail Stop LYS01/5 672 Philip Pedersens vei 1 673 LYSAKER, AKERSHUS 1366 674 Norway 676 Email: sbjarnas@cisco.com 678 Alexander Clemm 679 Cisco Systems 680 170 West Tasman Drive 681 San Jose , California 95134-1706 682 USA 684 Email: alex@cisco.com 685 Brian Carpenter 686 Department of Computer Science 687 University of Auckland 688 PB 92019 689 Auckland 1142 690 New Zealand 692 Email: brian.e.carpenter@gmail.com 694 Sheng Jiang 695 Huawei Technologies Co., Ltd 696 Q14, Huawei Campus 697 No.156 Beiqing Road 698 Hai-Dian District, Beijing 100095 699 P.R. China 701 Email: jiangsheng@huawei.com 703 Laurent Ciavaglia 704 Alcatel Lucent 705 Route de Villejust 706 Nozay 91620 707 France 709 Email: laurent.ciavaglia@alcatel-lucent.com