idnits 2.17.1 draft-irtf-nmrg-autonomic-network-definitions-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2015) is 3315 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 24, 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 23, 2015 15 Autonomic Networking - Definitions and Design Goals 16 draft-irtf-nmrg-autonomic-network-definitions-07.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 24, 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 (see below). An autonomic function 173 adapts on its 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. Intent is typically defined and provided by a 189 central entity. 191 Autonomic Domain: A collection of autonomic nodes that instantiate 192 the same Intent. 194 Autonomic Function: A feature or function which requires no 195 configuration, and can derive all required information either through 196 self-knowledge, discovery or through Intent. 198 Autonomic Service Agent: An agent implemented on an autonomic node 199 which implements an autonomic function, either in part (in the case 200 of a distributed function) or whole. 202 Autonomic Node: A node which employs exclusively autonomic functions. 203 It requires (!) no configuration. (Note that configuration can be 204 used to override an autonomic function. See Section 3.2 for more 205 details.) An Autonomic Node may operate on any layer of the 206 networking stack. Examples are routers, switches, personal 207 computers, call managers, etc. 209 Autonomic Network: A network containing exclusively autonomic nodes. 210 It may contain one or several autonomic domains. 212 3. Design Goals 214 This section explains the high level goals of Autonomic Networking, 215 independent of any specific solutions. 217 3.1. Self-Management 219 The original design goals of autonomic systems as described in 220 [Kephart] also apply to Autonomic Networks. The over-arching goal is 221 self-management, which is comprised of several self-* properties. 222 The most commonly cited are: 224 o Self-configuration: Functions do not require to be configured, 225 neither by an administrator nor a management system. They 226 configure themselves, based on self-knowledge, discovery, and 227 Intent. Discovery is the default way for an autonomic function to 228 receive the information it needs to operate. 230 o Self-healing: Autonomic functions adapt on their own to changes in 231 the environment, and heal problems automatically. 233 o Self-optimising: Autonomic functions automatically determine ways 234 to optimise their behaviour against a set of well-defined goals. 236 o Self-protection: Autonomic functions automatically secure 237 themselves against potential attacks. 239 Almost any network can be described as "self-managing", as long as 240 the definition of "self" is large enough. For example, a well- 241 defined SDN system, including the controller elements, can be 242 described over all as "autonomic", if the controller provides an 243 interface to the administrator which has the same properties as 244 mentioned above (high level, network-wide, etc). 246 For the work in the IETF and IRTF we define the "self" properties on 247 the node level. It is the design goal to make functions on network 248 nodes self- managing, in other words, minimally dependent on 249 management systems or controllers, as well as human operators. Self- 250 managing functions on a node might need to exchange information with 251 other nodes in order to achieve this design goal. 253 As mentioned in the Introduction, closed-loop control is an important 254 aspect of self-managing systems. This implies peer-to-peer dialogues 255 between the parties that make up the closed loop. Such dialogues 256 require two-way "discussion" or "negotiation" between each pair or 257 groups of peers involved in the loop, so they cannot readily use 258 typical top-down command-response protocols. Also, a discovery phase 259 is unavoidable before such closed-loop control can take place. 260 Multi-party protocols are also possible but can be significantly more 261 complex. 263 3.2. Co-Existence with Traditional Management 265 For the foreseeable future, autonomic nodes and networks will be the 266 exception; autonomic behaviour will initially be defined function by 267 function. Therefore, co-existence with other network management 268 paradigms has to be considered. Examples are management by command 269 line, SNMP, SDN (with related APIs), NETCONF, etc. 271 Conflict resolution between autonomic default behaviour and Intent on 272 one side, and other methods on the other is therefore required. This 273 is achieved through prioritisation. Generally, autonomic mechanisms 274 define a network wide behaviour, whereas the alternative methods are 275 typically on a node by node basis. Node based management concepts 276 take a higher priority over autonomic methods. This is in line with 277 current examples of autonomic functions, for example routing: A 278 (statically configured) route has priority over the routing 279 algorithm. In short: 281 o lowest priority: autonomic default behaviour 283 o medium priority: autonomic Intent 285 o highest priority: node specific network management concepts, such 286 as command line, SNMP, SDN, NETCONF, etc. How these concepts are 287 prioritised between themselves is outside the scope of this 288 document. 290 The above priorisation essentially results in the actions of the 291 human administrator always being able to over-rule autonomic 292 behaviour. This is generally the expectation of network operators 293 today, and remains therefore a design principle here. In critical 294 systems, such as atomic power plants, sometimes the opposite 295 philosophy is used: The expectation is that a well defined algorithm 296 is more reliable than a human operator, especially in rare exception 297 cases. Networking generally does not follow this philosophy yet. 298 Warnings however should be issued if node specific overrides may 299 conflict with autonomic behaviour. 301 In other fields, autonomic mechanisms disengage automatically if 302 certain conditions occur: The auto-pilot in a plane switches off if 303 the plane is outside a pre-defined envelope of flight parameters. 304 The assumption is that the algorithms only work correctly if the 305 input values are in expected ranges. Some opinions however suggest 306 that exactly in exceptional conditions is the worst moment to switch 307 off autonomic behaviour, since the pilots have no full understanding 308 of the situation at this point, and may be under high levels of 309 stress. For this reason we suggest here to NOT generally disable 310 autonomic functions if they encounter unexpected conditions, because 311 it is expected that this adds another level of unpredictability in 312 networks, when the situation may already be hard to understand. 314 3.3. By Default Secure 316 All autonomic interactions should be by default secure. This 317 requires that any member of an autonomic domain can assert its 318 membership using a domain identity, for example a certificate issued 319 by a domain certification authority. This domain identity is used 320 for nodes to learn about their neighbouring nodes, to determine the 321 boundaries of the domain, and to cryptographically secure 322 interactions within the domain. Nodes from different domains can 323 also mutually verify their identity and secure interactions as long 324 as they have a mutually respected trust anchor. 326 A strong, cryptographically verifiable domain identity is a 327 fundamental cornerstone in Autonomic Networking. It can be leveraged 328 to secure all communications, and allows thus automatic security 329 without traditional configuration, for example pre-shared keys. 331 Autonomic functions must be able to adapt their behaviour depending 332 on the domain of the node they are interacting with. 334 3.4. Decentralisation and Distribution 336 The goal of Autonomic Networking is to minimise dependencies on 337 central elements; therefore, de-centralisation and distribution are 338 fundamental to the concept. If a problem can be solved in a 339 distributed manner, it should not be centralised. 341 In certain cases it is today operationally preferable to keep a 342 central repository of information, for example a user database on a 343 AAA server. An autonomic network should be able to use such central 344 systems, in order to be deployable. It is possible to distribute 345 such databases as well, and such efforts should be at least 346 considered. Depending on the case, distribution may not be simple 347 replication, but involve more complex interactions and organisation. 349 3.5. Simplification of Autonomic Node Northbound Interfaces 351 Even in a decentralised solution, certain information flows with 352 central entities are required. Examples are high level service 353 definitions, as well as network status requests, audit information, 354 logging and aggregated reporting. 356 Therefore, also nodes in an autonomic network require a northbound 357 interface. However, the design goal is to maintain this interface as 358 simple and high level as possible. 360 3.6. Abstraction 362 An administrator or autonomic management system interacts with an 363 autonomic network on a high level of abstraction. Intent is defined 364 at a level of abstraction that is much higher than that of typical 365 configuration parameters, for example, "optimize my network for 366 energy efficiency". Intent must not be used to convey low-level 367 commands or concepts, since those are on a different abstraction 368 level. 370 For example, the administrator should not be exposed to the version 371 of the IP protocol running in the network. 373 Also on the reporting and feedback side an autonomic network 374 abstracts information and provides high-level messages such as "the 375 link between node x and y is down" (possibly with an identifier for 376 the specific link, in case of multiple links). 378 3.7. Autonomic Reporting 380 An autonomic network, while minimizing the need for user 381 intervention, still needs to provide users with visibility like in 382 traditional networks. However, in an autonomic network, reporting 383 should happen on a network wide basis. Information about the network 384 should be collected and aggregated by the network itself, presented 385 in consolidated fashion to the administrator. 387 The layers of abstraction that are provided via Intent need to be 388 supported for reporting functions as well, in order to give users an 389 indication about the effectiveness of their intent. For example, in 390 order to assess how effective the network performs with regards to 391 the Intent "optimize my network for energy efficiency", the network 392 should provide aggregate information about the number of ports that 393 were able to be shut down, and the corresponding energy savings, 394 while validating current service levels are on aggregate still met. 396 Autonomic network events should concern the autonomic network as a 397 whole, not individual systems in isolation. For example, the same 398 failure symptom should not be reported from every system that 399 observes it, but only once for the autonomic network as a whole. 400 Ultimately, the autonomic network should support exception based 401 management, in which only events that truly require user attention 402 are actually notified. This requires capabilities that allow systems 403 within the network to compare information and apply specific 404 algorithms to determine what should be reported. 406 3.8. Common Autonomic Networking Infrastructure 408 [I-D.irtf-nmrg-an-gap-analysis] points out that there are already a 409 number of autonomic functions available today. However, these are 410 largely independent, and each has its own methods and protocols to 411 communicate, discover, define and distribute policy, 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. The main 480 impact on administrators should be less tedious detailed work and 481 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 receive reports, and monitor the Autonomic 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 | | Loops | | 556 | +------------+ | 557 | ^ | 558 | Autonomic User Agent | 559 | 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: Reference Model for an Autonomic Node 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, 596 and Diego Lopez Garcia. 598 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 599 similar framework for Autonomic Networking in the "General Autonomic 600 Network Architecture" [GANA]. Many concepts explained in this 601 document can be mapped to the GANA framework. The mapping is outside 602 the scope of this document. Special thanks to Ranganai Chaparadza 603 for his comments and help on this document. 605 9. Informative References 607 [Dobson] Dobson et al., S., "A survey of autonomic communications", 608 ACM Transactions on Autonomous and Adaptive Systems (TAAS) 609 Volume 1 Issue 2, Pages 223-259 , December 2006. 611 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 612 self-managing Future Internet (AFI): GANA Architectural 613 Reference Model for Autonomic Networking, Cognitive 614 Networking and Self-Management.", April 2013, 615 . 618 [I-D.behringer-autonomic-control-plane] 619 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 620 Autonomic Control Plane", draft-behringer-autonomic- 621 control-plane-00 (work in progress), June 2014. 623 [I-D.irtf-nmrg-an-gap-analysis] 624 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 625 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 626 gap-analysis-04 (work in progress), March 2015. 628 [I-D.pritikin-bootstrapping-keyinfrastructures] 629 Pritikin, M., Behringer, M., and S. Bjarnason, 630 "Bootstrapping Key Infrastructures", draft-pritikin- 631 bootstrapping-keyinfrastructures-01 (work in progress), 632 September 2014. 634 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 635 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 636 January 2003, . 639 [Movahedi] 640 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 641 Survey of Autonomic Network Architectures and Evaluation 642 Criteria", IEEE Communications Surveys & Tutorials Volume: 643 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 644 Page(s): 464 - 490, 2012. 646 [Samaan] Samaan, N. and A. Karmouch, "Towards Autonomic Network 647 Management: an Analysis of Current and Future Research 648 Directions", IEEE Communications Surveys and Tutorials 649 Volume: 11 , Issue: 3; DOI: 10.1109/SURV.2009.090303; 650 Page(s): 22 - 36, 2009. 652 Authors' Addresses 654 Michael Behringer 655 Cisco Systems 656 Building D, 45 Allee des Ormes 657 Mougins 06250 658 France 660 Email: mbehring@cisco.com 662 Max Pritikin 663 Cisco Systems 664 5330 Airport Blvd 665 Boulder, CO 80301 666 USA 668 Email: pritikin@cisco.com 670 Steinthor Bjarnason 671 Cisco Systems 672 Mail Stop LYS01/5 673 Philip Pedersens vei 1 674 LYSAKER, AKERSHUS 1366 675 Norway 677 Email: sbjarnas@cisco.com 679 Alexander Clemm 680 Cisco Systems 681 170 West Tasman Drive 682 San Jose , California 95134-1706 683 USA 685 Email: alex@cisco.com 686 Brian Carpenter 687 Department of Computer Science 688 University of Auckland 689 PB 92019 690 Auckland 1142 691 New Zealand 693 Email: brian.e.carpenter@gmail.com 695 Sheng Jiang 696 Huawei Technologies Co., Ltd 697 Q14, Huawei Campus 698 No.156 Beiqing Road 699 Hai-Dian District, Beijing 100095 700 P.R. China 702 Email: jiangsheng@huawei.com 704 Laurent Ciavaglia 705 Alcatel Lucent 706 Route de Villejust 707 Nozay 91620 708 France 710 Email: laurent.ciavaglia@alcatel-lucent.com