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