idnits 2.17.1 draft-irtf-nmrg-autonomic-network-definitions-06.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 (March 9, 2015) is 3334 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-04 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: September 10, 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 March 9, 2015 15 Autonomic Networking - Definitions and Design Goals 16 draft-irtf-nmrg-autonomic-network-definitions-06.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 September 10, 2015. 49 Copyright Notice 51 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 9 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 Its scope is an autonomic domain, such as an enterprise network. It 184 does not contain configuration or information for a specific node 185 (see Section 3.2 on how intent co-exists with alternative management 186 paradigms). It may contain information pertaining to nodes with a 187 specific role, for example an edge switch, or a node running a 188 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 off 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 be able to use such central 343 systems, in order to be deployable. It is possible to distribute 344 such databases as well, and such efforts should be at least 345 considered. Depending on the case, distribution may not be simple 346 replication, but involve more complex interactions and organisation. 348 3.5. Simplification of Autonomic Node Northbound Interfaces 350 Even in a decentralised solution, certain information flows with 351 central entities are required. Examples are the distribution of 352 intent or high level service definitions, as well as network status 353 requests, audit information, logging and aggregated reporting. 355 Therefore, also nodes in an autonomic network require a northbound 356 interface. However, the design goal is to maintain this interface as 357 simple and high level as possible. 359 3.6. Abstraction 361 An administrator or autonomic management system interacts with an 362 autonomic network on a high level of abstraction. Intent is defined 363 at a level of abstraction that is much higher than that of typical 364 configuration parameters, for example, "optimize my network for 365 energy efficiency". Intent must not be used to convey low-level 366 commands or concepts, since those are on a different abstraction 367 level. 369 For example, the administrator should not be exposed to the version 370 of the IP protocol running in the network. 372 Also on the reporting and feedback side an autonomic network 373 abstracts information and provides high-level messages such as "the 374 link between node x and y is down" (possibly with an identifier for 375 the specific link, in case of multiple links). 377 3.7. Autonomic Reporting 379 An autonomic network, while minimizing the need for user 380 intervention, still needs to provide users with visibility like in 381 traditional networks. However, in an autonomic network reporting 382 should happen on a network wide basis. Information about the network 383 should be collected and aggregated by the network itself, presented 384 in consolidated fashion to the administrator. 386 The layers of abstraction that are provided via intent need to be 387 supported for reporting functions as well, in order to give users an 388 indication about the effectiveness of their intent. For example, in 389 order to assess how effective the network performs with regards to 390 the intent "optimize my network for energy efficiency", the network 391 should provide aggregate information about the number of ports that 392 were able to be shut down, and the corresponding energy savings, 393 while validating current service levels are on aggregate still met. 395 Autonomic network events should concern the autonomic network as a 396 whole, not individual systems in isolation. For example, the same 397 failure symptom should not be reported from every system that 398 observes it, but only once for the autonomic network as a whole. 399 Ultimately, the autonomic network should support exception based 400 management, in which only events that truly require user attention 401 are actually notified. This requires capabilities that allow systems 402 within the network to compare information and apply specific 403 algorithms to determine what should be reported. 405 3.8. Common Autonomic Networking Infrastructure 407 [I-D.irtf-nmrg-an-gap-analysis] points out that there are already a 408 number of fully or partially autonomic functions available today. 409 However, these are largely independent, and each has its own methods 410 and protocols to communicate, discover, define and distribute policy, 411 etc. 413 The goal of the work on autonomic networking in the IETF is therefore 414 not just to create autonomic functions, but to define a common 415 infrastructure that autonomic functions can use. This autonomic 416 networking infrastructure may contain common control and management 417 functions such as messaging, service discovery, negotiation, intent 418 distribution, self-monitoring and diagnostics, etc. A common 419 approach to define and manage intent is also required. 421 Refer to the reference model below: All the components around the 422 "autonomic service agents" should be common components, such that the 423 autonomic service agents do not have to replicate common tasks 424 individually. 426 3.9. Independence of Function and Layer 428 Autonomic functions may reside on any layer in the networking stack. 429 For example, layer 2 switching today is already relatively autonomic 430 in many environments, since most switches can be plugged together in 431 many ways and will automatically build a simple layer 2 topology. 432 Routing functions run on a higher layer and can be autonomic on layer 433 3. Even application layer functionality such as unified 434 communications can be autonomic. 436 "Autonomic" in the context of this framework is a property of a 437 function which is implemented on a node. Autonomic functions can be 438 implemented on any node type, for example a switch, router, server, 439 or call manager. 441 An Autonomic Network requires an overall control plane for autonomic 442 nodes to communicate. As in general IP networking, IP is the 443 spanning layer that binds all those elements together; autonomic 444 functions in the context of this framework should therefore operate 445 at the IP layer. This concerns neighbour discovery protocols and 446 other autonomic control plane functions. 448 3.10. Full Life Cycle Support 450 An autonomic function does not depend on external input to operate; 451 it needs to understand its current situation and surrounding, and 452 operate according to its current state. Therefore, an autonomic 453 function must understand the full life cycle of the device it runs 454 on, from first manufacturing testing through deployment, testing, 455 troubleshooting, up to decommissioning. 457 The state of the life-cycle of an autonomic node is reflected in a 458 state model. The behaviour of an autonomic function may be different 459 for different deployment states. 461 4. Non Design Goals 463 This section identifies various items that are explicitly not design 464 goals in the IETF/IRTF for autonomic networks, which are mentioned to 465 avoid misunderstandings of the general intention. They address some 466 commonly expressed concerns from network administrators and 467 architects. 469 4.1. Eliminate human operators 471 Section 3.1 states that "It is the design goal to [...] minimally 472 dependent on [...] human operators". It is however not a design goal 473 to completely eliminate them. The problem targeted by autonomic 474 networking is the error-prone and hard to scale model of individual 475 configuration of network elements, traditionally by manual commands 476 but today mainly by scripting and/or configuration management 477 databases. This does not, however, imply the elimination of skilled 478 human operators, who will still be needed for oversight, policy 479 management, diagnosis, reaction to help desk tickets, etc. etc. The 480 main impact on administrators should be less tedious detailed work 481 and more high-level work. (They should become more like doctors than 482 hospital orderlies.) 484 4.2. Eliminate emergency fixes 486 However good the autonomous mechanisms, sometimes there will be fault 487 conditions etc. that they cannot deal with correctly. At this point 488 skilled operator interventions will be needed to correct or work 489 around the problem. Hopefully this can be done by high-level 490 mechanisms (adapting the policy database in some way) but in some 491 cases direct intervention at device level may be unavoidable. This 492 is obviously the case for hardware failures, even if the autonomic 493 network has bypassed the fault for the time being. Truck rolls will 494 not be eliminated when faulty equipment needs to be replaced. 495 However, this may be less urgent if the autonomic system 496 automatically reconfigures to minimise the operational impact. 498 4.3. Eliminate central control 500 While it is a goal to simplify northbound interfaces (Section 3.5), 501 it is not a goal to eliminate central control, but to allow it on a 502 higher abstraction level. Senior management might fear loss of 503 control of an autonomic network. In fact this is no more likely than 504 with a traditional network; the emphasis on automatically applying 505 general policy and security rules might even provide more central 506 control. 508 5. An Autonomic Reference Model 510 An Autonomic Network consists of Autonomic Nodes. Those nodes 511 communicate with each other through an Autonomic Control Plane which 512 provides a robust and secure communications overlay. The Autonomic 513 Control Plane is self-organizing and autonomic itself. 515 An Autonomic Node contains various elements, such as autonomic 516 service agents which implement autonomic functions. Figure 1 shows a 517 reference model of an autonomic node. The elements and their 518 interaction are: 520 o Autonomic Service Agents, which implement the autonomic behaviour 521 of a specific service or function. 523 o Self-knowledge: An autonomic node knows its own properties and 524 capabilities 526 o Network Knowledge (Discovery): An autonomic service agent may 527 require various discovery functions in the network, such as 528 service discovery. 530 o Intent: Network wide high level policy. Autonomic Service Agents 531 use an intent interpretation engine to locally instantiate the 532 global intent. This may involve coordination with other Autonomic 533 Nodes. 535 o Feedback Loops: Control elements outside the node may interact 536 with autonomic nodes through feedback loops. 538 o An Autonomic User Agent, providing a front-end to external users 539 (administrators and management applications) through which they 540 can communicate intent, receive reports, and monitor the Autonomic 541 Network. 543 o Autonomic Control Plane: Allows the node to communicate with other 544 autonomic nodes. Autonomic functions such as intent distribution, 545 feedback loops, discovery mechanisms, etc, use the autonomic 546 control plane. The autonomic control plane can run inband, over a 547 configured VPN, over a self-managing overlay network, as described 548 in [I-D.behringer-autonomic-control-plane], or over a traditional 549 out of band network. Security is a requirement for the Autonomic 550 Control Plane, which can be bootstrapped by a mechanism as 551 described in [I-D.pritikin-bootstrapping-keyinfrastructures]. 553 +------------------------------------------------------------+ 554 | +----------+ +--------------+ | 555 | | | | Feedback | | 556 | | Intent | | Loops | | 557 | +----------+ +--------------+ | 558 | ^ ^ | 559 | Autonomic User Agent | 560 | V V | 561 | +-----------+ +------------+ +------------+ | 562 | | Self- | | Autonomic | | Network | | 563 | | knowledge |<------>| Service |<------>| Knowledge | | 564 | | | | Agents | | (Discovery)| | 565 | +-----------+ +------------+ +------------+ | 566 | ^ ^ | 567 | | | | 568 | V V | 569 |------------------------------------------------------------| 570 | Autonomic Control Plane | 571 |------------------------------------------------------------| 572 | Standard Operating System Functions | 573 +------------------------------------------------------------+ 575 Figure 1 577 6. IANA Considerations 579 This draft does not request any IANA action. 581 7. Security Considerations 583 This document provides definitions and design goals for autonomic 584 networking. A full threat analysis will be required as part of the 585 development of solutions, taking account of potential attacks from 586 within the network as well as from outside. 588 8. Acknowledgements 590 Many parts of this work on Autonomic Networking are the result of a 591 large team project at Cisco Systems. In alphabetical order: Ignas 592 Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, 593 Bruno Klauser. 595 We thank the following people for their input to this document: 596 Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, 597 and Diego Lopez Garcia. 599 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 600 similar framework for autonomic networking in the "General Autonomic 601 Network Architecture" [GANA]. Many concepts explained in this 602 document can be mapped to the GANA framework. The mapping is outside 603 the scope of this document. Special thanks to Ranganai Chaparadza 604 for his comments and help on this document. 606 9. Informative References 608 [Dobson] Dobson et al., S., "A survey of autonomic communications", 609 ACM Transactions on Autonomous and Adaptive Systems (TAAS) 610 Volume 1 Issue 2, Pages 223-259 , December 2006. 612 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 613 self-managing Future Internet (AFI): GANA Architectural 614 Reference Model for Autonomic Networking, Cognitive 615 Networking and Self-Management.", April 2013, 616 . 619 [I-D.behringer-autonomic-control-plane] 620 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 621 Autonomic Control Plane", draft-behringer-autonomic- 622 control-plane-00 (work in progress), June 2014. 624 [I-D.irtf-nmrg-an-gap-analysis] 625 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 626 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 627 gap-analysis-04 (work in progress), March 2015. 629 [I-D.pritikin-bootstrapping-keyinfrastructures] 630 Pritikin, M., Behringer, M., and S. Bjarnason, 631 "Bootstrapping Key Infrastructures", draft-pritikin- 632 bootstrapping-keyinfrastructures-01 (work in progress), 633 September 2014. 635 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 636 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 637 January 2003, . 640 [Movahedi] 641 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 642 Survey of Autonomic Network Architectures and Evaluation 643 Criteria", IEEE Communications Surveys & Tutorials Volume: 644 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 645 Page(s): 464 - 490, 2012. 647 [Samaan] Samaan, N. and A. Karmouch, "Towards Autonomic Network 648 Management: an Analysis of Current and Future Research 649 Directions", IEEE Communications Surveys and Tutorials 650 Volume: 11 , Issue: 3; DOI: 10.1109/SURV.2009.090303; 651 Page(s): 22 - 36, 2009. 653 Authors' Addresses 655 Michael Behringer 656 Cisco Systems 657 Building D, 45 Allee des Ormes 658 Mougins 06250 659 France 661 Email: mbehring@cisco.com 663 Max Pritikin 664 Cisco Systems 665 5330 Airport Blvd 666 Boulder, CO 80301 667 USA 669 Email: pritikin@cisco.com 671 Steinthor Bjarnason 672 Cisco Systems 673 Mail Stop LYS01/5 674 Philip Pedersens vei 1 675 LYSAKER, AKERSHUS 1366 676 Norway 678 Email: sbjarnas@cisco.com 680 Alexander Clemm 681 Cisco Systems 682 170 West Tasman Drive 683 San Jose , California 95134-1706 684 USA 686 Email: alex@cisco.com 687 Brian Carpenter 688 Department of Computer Science 689 University of Auckland 690 PB 92019 691 Auckland 1142 692 New Zealand 694 Email: brian.e.carpenter@gmail.com 696 Sheng Jiang 697 Huawei Technologies Co., Ltd 698 Q14, Huawei Campus 699 No.156 Beiqing Road 700 Hai-Dian District, Beijing 100095 701 P.R. China 703 Email: jiangsheng@huawei.com 705 Laurent Ciavaglia 706 Alcatel Lucent 707 Route de Villejust 708 Nozay 91620 709 France 711 Email: laurent.ciavaglia@alcatel-lucent.com