idnits 2.17.1 draft-irtf-nmrg-autonomic-network-definitions-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2013) is 3770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: June 23, 2014 A. Clemm 6 Cisco Systems 7 B. Carpenter 8 Univ. of Auckland 9 S. Jiang 10 Huawei Technologies Co., Ltd 11 L. Ciavaglia 12 Alcatel-Lucent 13 December 20, 2013 15 Autonomic Networking - Definitions and Design Goals 16 draft-irtf-nmrg-autonomic-network-definitions-00.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 goal is a network where nodes have minimal 27 dependencies on human administrators or centralized management 28 systems. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 23, 2014. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction to Autonomic Networking . . . . . . . . . . . . 2 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Self-Management . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. By Default Secure . . . . . . . . . . . . . . . . . . . . 5 69 3.3. Decentralisation and Distribution . . . . . . . . . . . . 5 70 3.4. Simplification of the Northbound Interfaces . . . . . . . 5 71 3.5. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.6. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 6 73 3.7. Modularity . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.8. Independence of Function and Layer . . . . . . . . . . . 7 75 3.9. Full Life Cycle Support . . . . . . . . . . . . . . . . . 7 76 4. Non Design Goals . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Eliminate human operators . . . . . . . . . . . . . . . . 8 78 4.2. Eliminate emergency fixes . . . . . . . . . . . . . . . . 8 79 4.3. Eliminate management control and central policy . . . . . 8 80 4.4. Eliminate existing configuration tools . . . . . . . . . 8 81 4.5. Eliminate existing network management systems . . . . . . 8 82 5. Guidelines for Case Studies . . . . . . . . . . . . . . . . . 9 83 6. An Autonomic Reference Model . . . . . . . . . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 86 9. Informative References . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 autonomic 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. A routing protocol such as OSPF 101 or ISIS exhibits 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 element was often not put into protocols to follow this 106 paradigm, but into configuration. This configuration made network 107 elements highly dependent on some process that manages them, either a 108 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. 113 Some information an autonomic node requires however cannot be 114 discovered; where input from some central intelligence is required, 115 it is provided in a highly abstract, network wide form. 117 This document provides the definitions and gesign goals for Autonomic 118 Networking. 120 2. Definitions 122 Autonomic: Self-managing (self-configuring, self-protecting, self- 123 healing and self-optimizing); however, allowing high-level guidance 124 by a central entity, through intent. 126 Intent: An abstract, high level policy used to operate the network 127 autonomically. Its scope is an autonomic domain, such as an 128 enterprise network. It does not contain configuration or information 129 for a specific node. It may contain information pertaining to nodes 130 with a specific role. 132 Autonomic Domain: A collection of autonomic nodes that instantiate 133 the same intent. 135 Autonomic Function: A function which requires no configuration, and 136 can derive all required information either through self-knowledge, 137 discovery or through intent. 139 Autonomic Service Agent: An agent implemented on an autonomic node 140 which implements an autonomic function, either in part (in the case 141 of a distributed function) or whole. 143 Autonomic Node: A node which employs autonomic functions. It may 144 operate on any layer of the networking stack. Examples are routers, 145 switches, personal computers, call managers, etc. 147 Fully Autonomic Node: A node which employs exclusively autonomic 148 functions. It requires no configuration. 150 Autonomic Network: A network containing autonomic nodes. 152 Fully Autonomic Network: A network consisting of exclusively fully 153 autonomic nodes. 155 3. Design Goals 157 This section explains the high level goals of Autonomic Networking, 158 independent of any specific solutions. 160 3.1. Self-Management 162 The original design goals of autonomic systems as described in 163 [Kephart] also apply to Autonomic Networks. The over-arching goal is 164 self-management, which is comprised of several self-* properties. 165 The most commonly cited are: 167 o Self-configuration: The nodes do not require to be configured, but 168 they configure themselves, based on self-knowledge, discovery, and 169 intent. Discovery is the default way for a node to receive the 170 information it needs to operate. 172 o Self-healing: The nodes adapt on their own to changes in the 173 environment, and heal problems automatically. 175 o Self-optimising: The nodes automatically determine ways to 176 optimise their behaviour. 178 o Self-protection: The nodes automatically secure themselves against 179 potential attacks. 181 Almost any network can be described as "self-managing", as long as 182 the definition of "self" is large enough. For example, to a 183 residential user, the service provider network she connects to could 184 be considered "autonomic", because the user only specifies a very 185 high level policy such as "Internet access" and is not exposed to any 186 internals of the network. 188 For the work in the IETF and IRTF we define the "self" properties on 189 the node level. It is the design goal to make network nodes self- 190 managing, in other words, minimally dependent on management systems 191 or controllers, as well as human operators. Self-managing nodes 192 might need to exchange information with other nodes in order to 193 achieve the required goals. 195 3.2. By Default Secure 197 All autonomic interactions should be by default secure. This 198 requires that any member of an autonomic domain can assert its 199 membership using a domain identity, for example a certificate issued 200 by a domain certification authority. This domain identity is used 201 for nodes to learn about their neighbouring nodes, to determine the 202 boundaries of the domain, and to cryptographically secure 203 interactions within the domain. Nodes from different domains can 204 also mutually verify their identity and secure interactions as long 205 as they have a common trust anchor. 207 A strong, cryptographically verifiable domain identity is a 208 fundamental cornerstone in autonomic networking. It can be leveraged 209 to secure all communications, and allows thus automatic security 210 without traditional configuration, for example pre-shared keys. 212 Autonomic nodes must be able to adapt their behaviour depending on 213 the domain of the node they are interacting with. 215 3.3. Decentralisation and Distribution 217 The goal of Autonomic Networking is to minimise dependencies on 218 central elements; therefore, de-centralisation and distribution are 219 fundamental to the concept. If a problem can be solved in a 220 distributed manner, it should not be centralised. 222 In certain cases it is today operationally preferable to keep a 223 central repository of information, for example a user database on a 224 AAA server. An autonomic network must also be able to use such 225 central systems, in order to be deployable. However, it is possible 226 to distribute such databases as well, and such efforts should be at 227 least considered. 229 3.4. Simplification of the Northbound Interfaces 231 Even in a decentralised solution, certain information flows with 232 central entities are required. Examples are the definition of intent 233 or high level service definitions, as well as network status requests 234 and aggregated reporting. 236 Therefore, also elements in an autonomic network require a northbound 237 interface. However, the design goal is to maintain this interface as 238 simple and high level as possible. 240 3.5. Abstraction 242 An administrator or autonomic management system interacts with an 243 autonomic network on a high level of abstraction. Intent is defined 244 at a level of abstraction that is much higher than that of typical 245 configuration parameters, for example, "optimize my network for 246 energy efficiency". Intent must not be used to convey low-level 247 commands or concepts, since those are on a different abstraction 248 level. The administrator should not even be exposed to the version 249 of the IP protocol running in the network. 251 Also on the reporting and feedback side an autonomic network 252 abstracts information and provides high-level messages such as "the 253 link between node X and Y is down". 255 3.6. Autonomic Reporting 257 An autonomic network, while minimizing the need for user 258 intervention, still needs to provide users with visibility like in 259 traditional networks. However, in an autonomic network reporting 260 should happen on a network wide basis. Information about the network 261 should be collected and aggregated by the network itself, presented 262 in consolidated fashion to the administrator. 264 The layers of abstraction that are provided via intent need to be 265 supported for reporting functions as well, in order to give users an 266 indication about the effectiveness of their intent. For example, in 267 order to assess how effective the network performs with regards to 268 the intent "optimize my network for energy efficiency", the network 269 should provide aggregate information about the number of ports that 270 were able to be shut down while validating current service levels are 271 on aggregate still met. 273 Autonomic network events should concern the autonomic network as a 274 whole, not individual systems in isolation. For example, the same 275 failure symptom should not be reported from every system that 276 observes it, but only once for the autonomic network as a whole. 277 Ultimately, the autonomic network should support exception based 278 management, in which only events that truly require user attention 279 are actually notified. This requires capabilities that allow systems 280 within the network to compare information and apply special 281 algorithms to determine what should be reported. 283 3.7. Modularity 285 It is unrealistic to expect a fully autonomic network in complex 286 environments for many years to come. While simple networks may 287 become autonomic in one single step, a phased approach is required 288 for most of today's networks. 290 Autonomic functions can be implemented in a modular way. For 291 example, the internal routing algorithm in many networks today is 292 already mostly autonomic. Other modules can be made autonomic step 293 by step. 295 3.8. Independence of Function and Layer 297 Today's autonomic functions may reside on any layer in the networking 298 stack. For example, layer 2 switching today is already relatively 299 autonomic in many environments; routing functions can be autonomic. 300 "Autonomic" in the context of this framework is a property of a node. 301 This node can be a switch, router, server, or call manager. 302 Autonomic functionality is independent of the function of a node. 303 Even application layer functionality such as unified communications 304 can be autonomic. 306 An Autonomic Network requires an overall control plane for autonomic 307 nodes to communicate. As in general IP networking, IP is the layer 308 that binds all those elements together; autonomic functions in the 309 context of this framework should therefore operate at the IP layer. 310 This concerns neighbour discovery protocols and other autonomic 311 control plane functions. 313 3.9. Full Life Cycle Support 315 An autonomic node does not depend on external input to operate; it 316 needs to understand its current situation and surrounding, and 317 operate according to its current state. Therefore, an autonomic node 318 must understand its full life cycle, from first manufacturing testing 319 through deployment, testing, troubleshooting, up to decommissioning. 321 The state of the life-cycle of an autonomic node is reflected in a 322 state model. The behaviour of an autonomic node may be different for 323 different deployment states. 325 4. Non Design Goals 327 This section identifies various items which are explicitly not design 328 goals for autonomic networks, which are mentioned to avoid 329 misunderstandings of the general intention. 331 4.1. Eliminate human operators 333 The problem targeted by autonomic networking is the error-prone and 334 hard to scale model of individual configuration of network elements, 335 traditionally by manual commands but today mainly by scripting and/or 336 configuration management databases. This does not, however, imply 337 the elimination of skilled human operators, who will still be needed 338 for oversight, policy management, diagnosis, reaction to help desk 339 tickets, etc. etc. The main impact on operators should be less 340 tedious detailed work and more high-level work. (They should become 341 more like doctors and nurses than hospital orderlies.) 343 4.2. Eliminate emergency fixes 345 However good the autonomous mechanisms, sometimes there will be fault 346 conditions etc. that they cannot deal with correctly. At this point 347 skilled operator interventions will be needed to correct or work 348 around the problem. Hopefully this can be done by high-level 349 mechanisms (adapting the policy database in some way) but in some 350 cases direct intervention at device level may be unavoidable. This 351 is obviously the case for hardware failures, even if the autonomic 352 network has bypassed the fault for the time being. Truck rolls will 353 not be eliminated when faulty equipment needs to be replaced. 354 However, this may be less urgent if the autonomic system 355 automatically reconfigures to minimise the operational impact. 357 4.3. Eliminate management control and central policy 359 Senior management might fear loss of control of an autonomic network. 360 In fact this is no more likely than with a traditional network; the 361 emphasis on automatically applying general policy and security rules 362 might even provide more management control. 364 4.4. Eliminate existing configuration tools 366 While autonomic networks will rarely need manual intervention, there 367 is no expectation that traditional top-down configuration tools will 368 vanish immediately. Autonomic techniques will have to co-exist with 369 them, and they will survive for as long as they are useful. 370 Initially they will certainly play a part in confidence-building in 371 the autonomic method, and they will be held in reserve for emergency 372 use for a long time. 374 4.5. Eliminate existing network management systems 376 Existing monitoring and reporting systems will continue to be needed, 377 and as just noted existing configuration mechanisms will not vanish. 378 Therefore, it is to be expected that the existing NMS will be 379 retained in parallel with autonomic mechanisms, and will be adapted 380 as necessary. Some aspects of the autonomic mechanism (e.g. 381 aggregated reporting, exception reporting) should indeed be 382 integrated with the existing NMS as far as possible. 384 5. Guidelines for Case Studies 386 [This section is work in progress.] 388 6. An Autonomic Reference Model 390 An Autonomic Network consists of Autonomic Nodes. Those nodes 391 communicate with each other through an Autonomic Control Plane which 392 provides a robust and secure communications overlay. The Autonomic 393 Control Plane is self-organizing and autonomic itself. 395 An Autonomic Node contains various elements, such as autonomic 396 service agents. Figure 1 shows a reference model of an autonomic 397 node. The elements and their interaction are: 399 o Autonomic Service Agents, which implement the autonomic behaviour 400 of a specific service or function. 402 o Self-knowledge: An autonomic node knows its own properties and 403 capabilities 405 o Network Knowledge (Discovery): An autonomic service agent may 406 require various discovery functions in the network, such as 407 service discovery. 409 o Intent: Network wide high level policy. Autonomic Service Agents 410 use an intent interpretation engine to locally instantiate the 411 global intent. This may involve coordination with other Autonomic 412 Nodes. 414 o Feedback Loops: Control elements outside the node may interact 415 with autonomic nodes through feedback loops. 417 o An Autonomic User Agent, providing a front-end to external users 418 (administrators and management applications) through which they 419 can communicate intent, receive reports, and monitor the Autonomic 420 Network. 422 o Autonomic Control Plane: Allows the node to communicate with other 423 autonomic nodes. Autonomic functions such as intent distribution, 424 feedback loops, discovery mechanisms, etc, use the autonomic 425 control plane. 427 +------------------------------------------------------------+ 428 | +----------+ +--------------+ | 429 | | | | Feedback | | 430 | | Intent | | Loops | | 431 | +----------+ +--------------+ | 432 | ^ ^ | 433 | Autonomic User Agent | 434 | V V | 435 | +-----------+ +------------+ +------------+ | 436 | | Self- | | Autonomic | | Network | | 437 | | knowledge |<------>| Service |<------>| Knowledge | | 438 | | | | Agents | | (Discovery)| | 439 | +-----------+ +------------+ +------------+ | 440 | ^ ^ | 441 | | | | 442 | V V | 443 |------------------------------------------------------------| 444 | Autonomic Control Plane | 445 |------------------------------------------------------------| 446 | Standard Operating System Functions | 447 +------------------------------------------------------------+ 449 Figure 1 451 7. Security Considerations 453 This document specifies a framework. Security is an integral part of 454 this framework. 456 8. Acknowledgements 458 The work on Autonomic Networking is the result of a large team 459 project at Cisco Systems. In alphabetical order: Ignas Bagdonas, 460 Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno 461 Klauser. 463 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 464 similar framework for autonomic networking in the "General Autonomic 465 Network Architecture" [GANA]. Many concepts explained in this 466 document can be mapped to the GANA framework. The mapping is outside 467 the scope of this document. Special thanks to Ranganai Chaparadza 468 for his comments and help on this document. 470 9. Informative References 472 [GANA] ETSI GS AFI 002, , "Autonomic network engineering for the 473 self-managing Future Internet (AFI): GANA Architectural 474 Reference Model for Autonomic Networking, Cognitive 475 Networking and Self-Management.", April 2013, 476 . 479 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 480 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 481 January 2003. 483 Authors' Addresses 485 Michael Behringer 486 Cisco Systems 487 Building D, 45 Allee des Ormes 488 Mougins 06250 489 France 491 Email: mbehring@cisco.com 493 Max Pritikin 494 Cisco Systems 496 Email: pritikin@cisco.com 498 Steinthor Bjarnason 499 Cisco Systems 501 Email: sbjarnas@cisco.com 503 Alex Clemm 504 Cisco Systems 506 Email: alex@cisco.com 508 Brian Carpenter 509 Department of Computer Science 510 University of Auckland 511 PB 92019 512 Auckland 1142 513 New Zealand 515 Email: brian.e.carpenter@gmail.com 516 Sheng Jiang 517 Huawei Technologies Co., Ltd 518 Q14, Huawei Campus 519 No.156 Beiqing Road 520 Hai-Dian District, Beijing 100095 521 P.R. China 523 Email: jiangsheng@huawei.com 525 Laurent Ciavaglia 526 Alcatel-Lucent 528 Email: Laurent.Ciavaglia@alcatel-lucent.com