idnits 2.17.1 draft-behringer-autonomic-network-framework-01.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 (October 16, 2013) is 3835 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 Network Working Group M. Behringer 3 Internet-Draft M. Pritikin 4 Intended status: Informational S. Bjarnason 5 Expires: April 19, 2014 A. Clemm 6 Cisco Systems 7 October 16, 2013 9 A Framework for Autonomic Networking 10 draft-behringer-autonomic-network-framework-01.txt 12 Abstract 14 Autonomic systems were first described in 2001. The fundamental goal 15 is self-management, including self-configuration, self-optimization, 16 self-healing and self-protection. 18 This document applies the concepts of autonomic systems to a network, 19 and describes a framework for Autonomic Networking. The goal is a 20 network where nodes have minimal dependencies on human administrators 21 or centralized management systems. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 19, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction to Autonomic Networking . . . . . . . . . . . . 2 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Fundamental Concepts . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Domain Identity . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.5. Autonomic Reporting . . . . . . . . . . . . . . . . . . . 5 65 3.6. Decentralisation and Distribution . . . . . . . . . . . . 5 66 3.7. Modularity . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.8. Independence of Function and Layer . . . . . . . . . . . 6 68 3.9. Full Life Cycle Support . . . . . . . . . . . . . . . . . 6 69 4. An Autonomic Framework . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Informative References . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction to Autonomic Networking 77 Autonomic systems were first described in a manifesto by IBM in 2001 78 [Kephart]. The fundamental concept involves eliminating external 79 systems from a system's control loops and closing of control loops 80 within the autonomic system itself, with the goal of providing the 81 autonomic system with self-management capabilities, including self- 82 configuration, self-optimization, self-healing and self-protection. 84 IP networking was initially designed with similar properties in mind. 85 An IP network should be distributed and redundant to withstand 86 outages in any part of the network. A routing protocol such as OSPF 87 or ISIS exhibits properties of self-management, and can thus be 88 considered autonomic in the definition of this framework. 90 However, as IP networking evolved, the ever increasing intelligence 91 of network element was often not put into protocols to follow this 92 paradigm, but into configuration. This configuration made network 93 elements highly dependent on some process that manages them, either a 94 human, or a network management system. 96 Autonomic Networking aims at putting the intelligence of today's 97 operations back into algorithms at the node level, to minimize 98 dependency on human administrators and central management systems. 99 Some information an autonomic node requires however cannot be 100 discovered; where input from some central intelligence is required, 101 it is provided in a highly abstract, network wide form. 103 This document provides a framework for achieving this goal. 105 2. Definitions 107 Autonomic: Self-managing (self-configuring, self-protecting, self- 108 healing and self-optimizing); however, allowing high-level guidance 109 by a central entity, through intent. 111 Intent: An abstract, high level policy used to operate the network 112 autonomically. Its scope is an autonomic domain, such as an 113 enterprise network. It does not contain configuration or information 114 for a specific node. It may contain information pertaining to nodes 115 with a specific role. 117 Autonomic Domain: A collection of autonomic nodes that instantiate 118 the same intent. 120 Autonomic Function: A function which requires no configuration, and 121 can derive all required information either through self-knowledge, 122 discovery or through intent. 124 Autonomic Node: A node which employs autonomic functions. It may 125 operate on any layer of the networking stack. Examples are routers, 126 switches, personal computers, call managers, etc. 128 Fully Autonomic Node: A node which employs exclusively autonomic 129 functions. It requires no configuration. 131 Autonomic Network: A network containing autonomic nodes. 133 Fully Autonomic Network: A network consisting of exclusively fully 134 autonomic nodes. 136 3. Fundamental Concepts 138 3.1. Domain Identity 140 Any member of the domain can assert its membership using a domain 141 identity, for example a certificate issued by a domain certification 142 authority. This domain identity is used for nodes to learn about 143 their neighbouring nodes, to determine the boundaries of the domain, 144 and to cryptographically secure interactions within the domain. 145 Nodes from different domains can also mutually verify their identity 146 and secure interactions as long as they have a common trust anchor. 148 A strong, cryptographically verifiable domain identity is a 149 fundamental cornerstone in autonomic networking. It can be leveraged 150 to secure all communications, and allows thus automatic security 151 without traditional configuration, for example pre-shared keys. 153 Autonomic nodes must be able to adapt their behaviour depending on 154 the domain of the node they are interacting with. 156 3.2. Discovery 158 In traditional networks, significant amounts of the information that 159 a node needs to operate are provided through northbound interfaces, 160 for example configuration. An autonomic node has a minimal 161 northbound interface, limited to receiving intent and providing 162 feedback loops. 164 Discovery is the default way for a node to receive the information it 165 needs to operate. 167 There are certain pieces of information that a node cannot discover, 168 because they derive from non-technical business objectives. For 169 example a routing policy cannot be discovered through intelligence in 170 the network. This type of information is an exception to the rule of 171 "default discover", and is propagated in intent. 173 3.3. Intent 175 An autonomic network has to allow for input from the outside to guide 176 the network's behaviour. The administrator's desired behaviour of 177 the network is expressed as "intent". It contains certain 178 information which is derived from business level objectives. Intent 179 should only include information which the network cannot infer or 180 discover. 182 Intent has a network wide scope and must be communicated to all nodes 183 of the network, independent of their function. A node may 184 instantiate only the portions of intent that are relevant to its 185 function. Intent must not be used to address specific nodes or 186 locations in the network. 188 3.4. Abstraction 190 An administrator or autonomic management system interacts with an 191 autonomic network on a high level of abstraction. Intent is defined 192 at a level of abstraction that is much higher than that of typical 193 configuration parameters, for example, "optimize my network for 194 energy efficiency". Intent must not be used to convey low-level 195 commands or concepts, since those are on a different abstraction 196 level. The administrator should not even be exposed to the version 197 of the IP protocol running in the network. 199 Also on the reporting and feedback side an autonomic network 200 abstracts information and provides high-level messages such as "the 201 link between node X and Y is down". 203 3.5. Autonomic Reporting 205 An autonomic network, while minimizing the need for user 206 intervention, still needs to provide users with visibility like in 207 traditional networks. However, in an autonomic network reporting 208 should happen on a network wide basis. Information about the network 209 should be collected and aggregated by the network itself, presented 210 in consolidated fashion to the administrator. 212 The layers of abstraction that are provided via intent need to be 213 supported for reporting functions as well, in order to give users an 214 indication about the effectiveness of their intent. For example, in 215 order to assess how effective the network performs with regards to 216 the intent "optimize my network for energy efficiency", the network 217 should provide aggregate information about the number of ports that 218 were able to be shut down while validating current service levels are 219 on aggregate still met. 221 Autonomic network events should concern the autonomic network as a 222 whole, not individual systems in isolation. For example, the same 223 failure symptom should not be reported from every system that 224 observes it, but only once for the autonomic network as a whole. 225 Ultimately, the autonomic network should support exception based 226 management, in which only events that truly require user attention 227 are actually notified. This requires capabilities that allow systems 228 within the network to compare information and apply special 229 algorithms to determine what should be reported. 231 3.6. Decentralisation and Distribution 233 The goal of Autonomic Networking is to minimise dependencies on 234 central elements; therefore, de-centralisation and distribution are 235 fundamental to the concept. If a problem can be solved in a 236 distributed manner, it should not be centralised. 238 In certain cases it is today operationally preferable to keep a 239 central repository of information, for example a user database on a 240 AAA server. An autonomic network must also be able to use such 241 central systems, in order to be deployable. However, it is possible 242 to distribute such databases as well, and such efforts should be at 243 least considered. 245 3.7. Modularity 247 It is unrealistic to expect a fully autonomic network in complex 248 environments for many years to come. While simple networks may 249 become autonomic in one single step, a phased approach is required 250 for most of today's networks. 252 Autonomic functions can be implemented in a modular way. For 253 example, the internal routing algorithm in many networks today is 254 already mostly autonomic. Other modules can be made autonomic step 255 by step. 257 3.8. Independence of Function and Layer 259 Today's autonomic functions may reside on any layer in the networking 260 stack. For example, layer 2 switching today is already relatively 261 autonomic in many environments; routing functions can be autonomic. 262 "Autonomic" in the context of this framework is a property of a node. 263 This node can be a switch, router, server, or call manager. 264 Autonomic functionality is independent of the function of a node. 265 Even application layer functionality such as unified communications 266 can be autonomic. 268 An Autonomic Network requires an overall control plane for autonomic 269 nodes to communicate. As in general IP networking, IP is the layer 270 that binds all those elements together; autonomic functions in the 271 context of this framework should therefore operate at the IP layer. 272 This concerns neighbour discovery protocols and other autonomic 273 control plane functions. 275 3.9. Full Life Cycle Support 277 An autonomic node does not depend on external input to operate; it 278 needs to understand its current situation and surrounding, and 279 operate according to its current state. Therefore, an autonomic node 280 must understand its full life cycle, from first manufacturing testing 281 through deployment, testing, troubleshooting, up to decommissioning. 283 The state of the life-cycle of an autonomic node is reflected in a 284 state model. The behaviour of an autonomic node may be different for 285 different deployment states. 287 4. An Autonomic Framework 289 An Autonomic Network consists of Autonomic Nodes. Those nodes 290 communicate with each other through an Autonomic Control Plane which 291 provides a robust and secure communications overlay. The Autonomic 292 Control Plane is self-organizing and autonomic itself. 294 An Autonomic Node contains various elements, such as autonomic 295 service agents. Figure 1 shows a reference model of an autonomic 296 node. The elements and their interaction are: 298 o Autonomic Service Agents, which implement the autonomic behaviour 299 of a specific service or function. 301 o Self-knowledge: An autonomic node knows its own properties and 302 capabilities 304 o Network Knowledge (Discovery): An autonomic service agent may 305 require various discovery functions in the network, such as 306 service discovery. 308 o Intent: Network wide high level policy. Autonomic Service Agents 309 use an intent interpretation engine to locally instantiate the 310 global intent. This may involve coordination with other Autonomic 311 Nodes. 313 o Feedback Loops: Control elements outside the node may interact 314 with autonomic nodes through feedback loops. 316 o An Autonomic User Agent, providing a front-end to external users 317 (administrators and management applications) through which they 318 can communicate intent, receive reports, and monitor the Autonomic 319 Network. 321 o Autonomic Control Plane: Allows the node to communicate with other 322 autonomic nodes. Autonomic functions such as intent distribution, 323 feedback loops, discovery mechanisms, etc, use the autonomic 324 control plane. 326 +------------------------------------------------------------+ 327 | +----------+ +--------------+ | 328 | | | | Feedback | | 329 | | Intent | | Loops | | 330 | +----------+ +--------------+ | 331 | ^ ^ | 332 | Autonomic User Agent | 333 | V V | 334 | +-----------+ +------------+ +------------+ | 335 | | Self- | | Autonomic | | Network | | 336 | | knowledge |<------>| Service |<------>| Knowledge | | 337 | | | | Agents | | (Discovery)| | 338 | +-----------+ +------------+ +------------+ | 339 | ^ ^ | 340 | | | | 341 | V V | 342 |------------------------------------------------------------| 343 | Autonomic Control Plane | 344 |------------------------------------------------------------| 345 | Standard Operating System Functions | 346 +------------------------------------------------------------+ 348 Figure 1 350 5. Security Considerations 352 This document specifies a framework. Security is an integral part of 353 this framework. 355 6. Acknowledgements 357 The work on Autonomic Networking is the result of a large team 358 project at Cisco Systems. In alphabetical order: Ignas Bagdonas, 359 Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno 360 Klauser. 362 The ETSI working group AFI (http://portal.etsi.org/afi) defines a 363 similar framework for autonomic networking in the "General Autonomic 364 Network Architecture" [GANA]. Many concepts explained in this 365 document can be mapped to the GANA framework. The mapping is outside 366 the scope of this document. Special thanks to Ranganai Chaparadza 367 for his comments and help on this document. 369 7. Informative References 371 [GANA] ETSI GS AFI 002, ., "Autonomic network engineering for the 372 self-managing Future Internet (AFI): GANA Architectural 373 Reference Model for Autonomic Networking, Cognitive 374 Networking and Self-Management. ", April 2013, . 378 [Kephart] Kephart, J. and D. Chess, "The Vision of Autonomic 379 Computing", IEEE Computer vol. 36, no. 1, pp. 41-50, 380 January 2003. 382 Authors' Addresses 384 Michael H. Behringer 385 Cisco Systems 387 Email: mbehring@cisco.com 389 Max Pritikin 390 Cisco Systems 392 Email: pritikin@cisco.com 394 Steinthor Bjarnason 395 Cisco Systems 397 Email: sbjarnas@cisco.com 399 Alex Clemm 400 Cisco Systems 402 Email: alex@cisco.com