idnits 2.17.1 draft-behringer-anima-reference-model-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 16, 2015) is 3115 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 736, but not defined == Missing Reference: 'Meyer97' is mentioned on line 838, but not defined == Unused Reference: 'RFC2119' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'RFC7404' is defined on line 1053, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-addressing-02 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Carpenter 5 Expires: April 18, 2016 Univ. of Auckland 6 T. Eckert 7 Cisco 8 L. Ciavaglia 9 Alcatel Lucent 10 B. Liu 11 Huawei Technologies 12 J. Nobre 13 Federal University of Rio Grande do Sul 14 J. Strassner 15 Huawei Technologies 16 October 16, 2015 18 A Reference Model for Autonomic Networking 19 draft-behringer-anima-reference-model-04 21 Abstract 23 This document describes a reference model for Autonomic Networking. 24 The goal is to define how the various elements in an autonomic 25 context work together, to describe their interfaces and relations. 26 While the document is written as generally as possible, the initial 27 solutions are limited to the chartered scope of the WG. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 18, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 65 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 66 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 67 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 68 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Naming requirements . . . . . . . . . . . . . . . . . 6 70 4.1.2. Proposed Mechanisms . . . . . . . . . . . . . . . . . 7 71 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 9 74 4.5. Intent Distribution . . . . . . . . . . . . . . . . . . . 10 75 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 10 77 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security and Trust Infrastructure . . . . . . . . . . . . . . 13 79 6.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 13 80 6.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 13 81 6.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 13 83 6.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 13 84 7. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 14 85 7.1. General Description of an ASA . . . . . . . . . . . . . . 14 86 7.2. Specific ASAs for the Enrolment Process . . . . . . . . . 14 87 7.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 14 88 7.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 14 89 7.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 14 90 8. Management and Programmability . . . . . . . . . . . . . . . 14 91 8.1. How an AN Network Is Managed . . . . . . . . . . . . . . 14 92 8.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 15 93 8.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 16 94 8.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 17 95 8.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 17 96 8.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 18 97 8.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 18 98 9. Coordination Between Autonomic Functions (*) . . . . . . . . 19 99 9.1. The Coordination Problem (*) . . . . . . . . . . . . . . 19 100 9.2. A Coordination Functional Block (*) . . . . . . . . . . . 20 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 10.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 21 103 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 The document "Autonomic Networking - Definitions and Design Goals" 111 [RFC7575] explains the fundamental concepts behind Autonomic 112 Networking, and defines the relevant terms in this space. In section 113 5 it describes a high level reference model. This document defines 114 this reference model with more detail, to allow for functional and 115 protocol specifications to be developed in an architecturally 116 consistent, non-overlapping manner. While the document is written as 117 generally as possible, the initial solutions are limited to the 118 chartered scope of the WG. 120 As discussed in [RFC7575], the goal of this work is not to focus 121 exclusively on fully autonomic nodes or networks. In reality, most 122 networks will run with some autonomic functions, while the rest of 123 the network is traditionally managed. This reference model allows 124 for this hybrid approach. 126 This is a living document and will evolve with the technical 127 solutions developed in the ANIMA WG. Sections marked with (*) do not 128 represent current charter items. While this document must give a 129 long term architectural view, not all functions will be standardized 130 at the same time. 132 2. The Network View 134 This section describes the various elements in a network with 135 autonomic functions, and how these entities work together, on a high 136 level. Subsequent sections explain the detailed inside view for each 137 of the autonomic network elements, as well as the network functions 138 (or interfaces) between those elements. 140 Figure 1 shows the high level view of an Autonomic Network. It 141 consists of a number of autonomic nodes, which interact directly with 142 each other. Those autonomic nodes provide a common set of 143 capabilities across the network, called the "Autonomic Networking 144 Infrastructure" (ANI). The ANI provides functions like naming, 145 addressing, negotiation, synchronization, discovery and messaging. 147 Autonomic functions typically span several, possibly all nodes in the 148 network. The atomic entities of an autonomic function are called the 149 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 151 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 152 : : Autonomic Function 1 : : 153 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 154 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 155 : : : 156 : +- - - - - - - - - - - - - - + : 157 : : Autonomic Function 2 : : 158 : : ASA 2 : ASA 2 : : 159 : +- - - - - - - - - - - - - - + : 160 : : : 161 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 162 : Autonomic Networking Infrastructure : 163 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 164 +--------+ : +--------+ : +--------+ : +--------+ 165 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 166 +--------+ : +--------+ : +--------+ : +--------+ 168 Figure 1: High level view of an Autonomic Network 170 In a horizontal view, autonomic functions span across the network, as 171 well as the Autonomic Networking Infrastructure. In a vertical view, 172 a node always implements the ANI, plus it may have one or several 173 Autonomic Service Agents. 175 The Autonomic Networking Infrastructure (ANI) therefore is the 176 foundation for autonomic functions. The current charter of the ANIMA 177 WG is to specify the ANI, using a few autonomic functions as use 178 cases. 180 3. The Autonomic Network Element 182 3.1. Architecture 184 This section describes an autonomic network element and its internal 185 architecture. The reference model explained in the document 186 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 187 the sources of information that an autonomic service agent can 188 leverage: Self-knowledge, network knowledge (through discovery), 189 Intent, and feedback loops. Fundamentally, there are two levels 190 inside an autonomic node: the level of Autonomic Service Agents, and 191 the level of the Autonomic Networking Infrastructure, with the former 192 using the services of the latter. Figure 2 illustrates this concept. 194 +------------------------------------------------------------+ 195 | | 196 | +-----------+ +------------+ +------------+ | 197 | | Autonomic | | Autonomic | | Autonomic | | 198 | | Service | | Service | | Service | | 199 | | Agent 1 | | Agent 2 | | Agent 3 | | 200 | +-----------+ +------------+ +------------+ | 201 | ^ ^ ^ | 202 | - - | - - API level - -| - - - - - - - |- - - | 203 | V V V | 204 |------------------------------------------------------------| 205 | Autonomic Networking Infrastructure | 206 | - Data structures (ex: certificates, peer information) | 207 | - Autonomic Control Plane | 208 | - Autonomic Node Addressing | 209 | - Discovery, negotiation and synchronisation functions | 210 | - Intent distribution | 211 | - Aggregated reporting and feedback loops | 212 | - Routing | 213 |------------------------------------------------------------| 214 | Basic Operating System Functions | 215 +------------------------------------------------------------+ 217 Figure 2: Model of an autonomic node 219 The Autonomic Networking Infrastructure (lower part of Figure 2) 220 contains node specific data structures, for example trust information 221 about itself and its peers, as well as a generic set of functions, 222 independent of a particular usage. This infrastructure should be 223 generic, and support a variety of Autonomic Service Agents (upper 224 part of Figure 2). The Autonomic Control Plane is the summary of all 225 interactions of the Autonomic Networking Infrastructure with other 226 nodes and services. 228 The use cases of "Autonomics" such as self-management, self- 229 optimisation, etc, are implemented as Autonomic Service Agents. They 230 use the services and data structures of the underlying autonomic 231 networking infrastructure. The underlying Autonomic Networking 232 Infrastructure should itself be self-managing. 234 The "Basic Operating System Functions" include the "normal OS", 235 including the network stack, security functions, etc. 237 Full AN nodes have the full Autonomic Networking Infrastructure, with 238 the full functionality described in this document. At a later stage 239 ANIMA may define a scope for constrained nodes with a reduced ANI and 240 well-defined minimal functionality. They are currently out of scope. 242 4. The Autonomic Networking Infrastructure 244 The Autonomic Networking Infrastructure provides a layer of common 245 functionality across an Autonomic Network. It comprises "must 246 implement" functions and services, as well as extensions. 248 An Autonomic Function, comprising of Autonomic Service Agents on 249 nodes, can rely on the fact that all nodes in the network implement 250 at least the "must implement" functions. 252 4.1. Naming 254 4.1.1. Naming requirements 256 o Representing each device 258 Inside a domain, each autonomic device needs a domain specific 259 identifier. 261 [Open Questions] Are there devices that don't need names? Do 262 ASAs need names? 264 o Uniqueness 266 The names MUST NOT collide within one autonomic domain. 268 It is acceptable that the names in different domains collide, 269 since they could be distinguished by domains. 271 o Semantic Encoding 273 It is RECOMMENDED that the names encode some semantics rather 274 than meaningless strings. The semantics might be: 276 + Location 278 + Device type 280 + Functional role 282 + Ownership 284 + etc. 286 This is for ease of management consideration that network 287 administrators could easily recognize the device directly 288 through the names. 290 o Consistency 292 The devices' naming SHOULD follow the same pattern within a 293 domain. 295 4.1.2. Proposed Mechanisms 297 __ 299 o Structured Naming Pattern 301 The whole name string could be divided into several fields, 302 each of which representing a specific semantic as described 303 above. For example: Location-DeviceType-FunctionalRole- 304 DistinguisherNumber@NameofDomain. 306 The structure should be flexible that some fields are optional. 307 When these optional fields are added, the name could still be 308 recognized as the previous one. In above example, the 309 "DistinguisherNumber" and "NameofDomain" are mandatory whereas 310 others are optional. At initial stage, the devices might be 311 only capable of self-generating the mandatory fields and the 312 "DeviceType" because of the lack of knowledge. Later, they 313 might have learned the "Location" and "FunctionalRole" and 314 added the fields into current name. However, the other devices 315 could still recognize it according to the same 316 "DistinguisherNumber". 318 o Advertised Common Fields 320 Some fields in the structured name might be common among the 321 domain (e.g. "Location" "NameofDomain"). Thus, these part of 322 the names could be advertised through Intent 323 DistributionSection 4.5. 325 o Self-generated Fields 327 The mandatory fields SHOULD be self-generated so that one 328 device could name itself sufficiently without any advertised 329 knowledges. 331 There should various methods for a device to extract/generate a 332 proper word for each mandatory semantic fields (e.g. 333 "DeviceType", "DistinguisherNum") from its self-knowledge. 335 Detailed design of specific naming patterns and methods are out of 336 scope of this document. 338 4.2. Addressing 340 Autonomic Service Agents (ASAs) need to communicate with each other, 341 using the autonomic addressing of the node they reside on. This 342 section describes the addressing approach of the Autonomic Networking 343 Infrastructure, used by ASAs. It does NOT describe addressing 344 approaches for the data plane of the network, which may be configured 345 and managed in the traditional way, or negotiated as a service of an 346 ASA. One use case for such an autonomic function is described in 347 [I-D.jiang-auto-addr-management]. The addressing of the Autonomic 348 Networking Infrastructure is in scope for this section, the address 349 space they negotiate for the data plane is not. 351 Autonomic addressing is a function of the Autonomic Networking 352 Infrastructure (lower part of Figure 2), specifically the Autonomic 353 Control Plane. ASAs do not have their own addresses. They may use 354 either API calls, or the autonomic addressing scheme of the Autonomic 355 Networking Infrastructure. 357 An autonomic addressing scheme has the following requirements: 359 o Zero-touch for simple networks: Simple networks should have 360 complete self-management of addressing, and not require any 361 central address management, tools, or address planning. 363 o Low-touch for complex networks: If complex networks require 364 operator input for autonomic address management, it should be 365 limited to high level guidance only, expressed in Intent. 367 o Flexibility: The addressing scheme must be flexible enough for 368 nodes to be able to move around, for the network to grow, split 369 and merge. 371 o Robustness: It should be as hard as possible for an administrator 372 to negatively affect addressing (and thus connectivity) in the 373 autonomic context. 375 o Support for virtualization: Autonomic Nodes may support Autonomic 376 Service Agents in different virtual machines or containers. The 377 addressing scheme should support this architecture. 379 o Simplicity: To make engineering simpler, and to give the human 380 administrator an easy way to trouble-shoot autonomic functions. 382 o Scale: The proposed scheme should work in any network of any size. 384 o Upgradability: The scheme must be able to support different 385 addressing concepts in the future. 387 The primary use for the autonomically managed addressing described 388 here is for the Autonomic Control Plane 389 ([I-D.ietf-anima-autonomic-control-plane]). The fundamental 390 concepts, as well as the proposed addressing scheme for the ACP is 391 discussed in [I-D.behringer-anima-autonomic-addressing]. 393 4.3. Discovery 395 Traditionally, most of the information a node requires is provided 396 through configuration or northbound interfaces. An autonomic 397 function should rely on such northbound interfaces minimally or not 398 at all, and therefore it needs to discover peers and other resources 399 in the network. This section describes various discovery functions 400 in an autonomic network. 402 Discovering nodes and their properties and capabilities: A core 403 function to establish an autonomic domain is the mutual discovery of 404 autonomic nodes, primarily adjacent nodes and secondarily off-link 405 peers. This may in principle either leverage existing discovery 406 mechanisms, or use new mechanisms tailored to the autonomic context. 407 An important point is that discovery must work in a network with no 408 predefined topology, ideally no manual configuration of any kind, and 409 with nodes starting up from factory condition or after any form of 410 failure or sudden topology change. 412 Discovering services: Network services such as AAA should also be 413 discovered and not configured. Service discovery is required for 414 such tasks. An autonomic network can either leverage existing 415 service discovery functions, or use a new approach, or a mixture. 417 Thus the discovery mechanism could either be fully integrated with 418 autonomic signaling (next section) or could use an independent 419 discovery mechanism such as DNS Service Discovery or Service Location 420 Protocol. This choice could be made independently for each Autonomic 421 Service Agent, although the infrastructure might require some minimal 422 lowest common denominator (e.g., for discovering the security 423 bootstrap mechanism, or the source of intent distribution, 424 Section 4.5). 426 4.4. Signaling Between Autonomic Nodes 428 Autonomic nodes must communicate with each other, for example to 429 negotiate and/or synchronize technical objectives (i.e., network 430 parameters) of any kind and complexity. This requires some form of 431 signaling between autonomic nodes. Autonomic nodes implementing a 432 specific use case might choose their own signaling protocol, as long 433 as it fits the overall security model. However, in the general case, 434 any pair of autonomic nodes might need to communicate, so there needs 435 to be a generic protocol for this. A prerequisite for this is that 436 autonomic nodes can discover each other without any preconfiguration, 437 as mentioned above. To be generic, discovery and signaling must be 438 able to handle any sort of technical objective, including ones that 439 require complex data structures. The document "A Generic Discovery 440 and Negotiation Protocol for Autonomic Networking" 441 [I-D.ietf-anima-grasp] describes more detailed requirements for 442 discovery, negotiation and synchronization in an autonomic network. 443 It also defines a protocol, GDNP, for this purpose, including an 444 integrated but optional discovery protocol. 446 4.5. Intent Distribution 448 Intent is the policy language of an Autonomic Network; see 449 Section 8.2 for general information on Intent. The distribution of 450 Intent is also a function of the Autonomic Control Plane. It is 451 expected that Intent will be expressed as quite complex human- 452 readable data structures, and the distribution mechanism must be able 453 to support that. Some Intent items will need to be flooded to most 454 or all nodes, and other items of Intent may only be needed by a few 455 nodes. Various methods could be used to distribute Intent across an 456 autonomic domain. One approach is to treat it like any other 457 technical objective needing to be synchronized across a set of nodes. 458 In that case the autonomic signaling protocol could be used (previous 459 section). 461 4.6. Routing 463 All autonomic nodes in a domain must be able to communicate with each 464 other, and with autonomic nodes outside their own domain. Therefore, 465 an Autonomic Control Plane relies on a routing function. For 466 Autonomic Networks to be interoperable, they must all support one 467 common routing protocol. 469 4.7. The Autonomic Control Plane 471 The totality of autonomic interactions forms the "Autonomic Control 472 Plane". This control plane can be either implemented in the global 473 routing table of a node, such as IGPs in today's networks; or it can 474 be provided as an overlay network. The document "An Autonomic 475 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 476 the details. 478 5. Functional Overview 480 This section provides an overview on how the functions in the 481 Autonomic Networking Infrastructure work together, and how the 482 various documents about AN relate to each other. 484 The foundations of Autonomic Networking, definitions and gap analysis 485 in the context of the IETF are described in [RFC7575] and [RFC7576]. 487 Autonomic Networking is based on direct interactions between devices 488 of a domain. The Autonomic Networking Infrastructure (ANI) is 489 normally built on a hop-by-hop basis. Therefore, many interactions 490 in the ANI are based on the ANI adjacency table. There are 491 interactions that provide input into the adjacency table, and other 492 interactions that leverage the information contained in it. 494 The ANI adjacency table contains information about adjacent autonomic 495 nodes, at a minimum: node-ID, IP address in data plane, IP address in 496 ACP, domain, certificate. An autonomic node maintains this adjacency 497 table up to date. The adjacency table only contains information 498 about other nodes that are capable of Autonomic Networking; non- 499 autonomic nodes are normally not tracked here. However, the 500 information is tracked independently of the status of the peer nodes; 501 specifically, it contains information about non-enrolled nodes, nodes 502 of the same and other domains. The adjacency table MAY contain 503 information about the validity and trust of the adjacent autonomic 504 node's certificate, although all autonomic interactions must verify 505 validity and trust independently. 507 The adjacency table is fed by the following inputs: 509 o Link local discovery: This interaction happens in the data plane, 510 using IPv6 link local addressing only, because this addressing 511 type is itself autonomic. This way the nodes learns about all 512 autonomic nodes around itself. This is described in 513 [I-D.ietf-anima-grasp]. 515 o Vendor re-direct: A new device may receive information on where 516 its home network is through a vendor based MASA re-direct; this is 517 typically a routable address. See 518 [I-D.pritikin-bootstrapping-keyinfrastructures]. 520 o Non-autonomic input: A node may be configured manually with an 521 autonomic peer; it could learn about autonomic nodes through DHCP 522 options, DNS, and other non-autonomic mechanisms. Generally such 523 non-autonomic mechansims require some administrator intervention. 524 The key purpose is to by-pass a non-autonomic device or network. 526 As this pertains to new devices, it is covered in Section 5.3 of 527 [I-D.pritikin-bootstrapping-keyinfrastructures]. 529 The adjacency table is defining the behaviour of an autonomic node: 531 o If the node has not bootstrapped into a domain (i.e., doesn't have 532 a domain certificate), it rotates through all nodes in the 533 adjacency table that claim to have a domain, and will attempt 534 bootstrapping through them, one by one. One possible response is 535 a vendor MASA re-direct, which will be entered into the adjacency 536 table (see second bullet above). See 537 [I-D.pritikin-bootstrapping-keyinfrastructures]. 539 o If the node has bootstrapped into a domain (i.e., has a domain 540 certificate), it will act as a proxy for neighboring nodes that 541 need to be bootstrapped. See 542 [I-D.pritikin-bootstrapping-keyinfrastructures]. 544 o If the adjacent node has the same domain, it will authenticate 545 that adjacent node and establish the Autonomic Control Plane 546 (ACP). See [I-D.ietf-anima-autonomic-control-plane]. 548 o Other behaviours are possible, for example establishing the ACP 549 also with devices of a sub-domain, to other domains, etc. Those 550 will likely be controlled by Intent. They are outside scope for 551 the moment. Note that Intent is distributed through the ACP; 552 therefore, a node can only adapt Intent driven behaviour once it 553 has joined the ACP. At the moment, ANIMA does not consider 554 providing Intent outside the ACP; this can be considered later. 556 Once a node has joined the ACP, it will also learn the ACP addresses 557 of its adjacent nodes, and add them to the adjacency table, to allow 558 for communication inside the ACP. Further interactions will now 559 happen inside the ACP. At this moment, only negotiation / 560 synchronization via GRASP [I-D.ietf-anima-grasp] is being defined. 561 (Note that GRASP runs in the data plane, as an input in building the 562 adjacency table, as well as inside the ACP.) 564 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 565 run logically above the AN Infrastructure, and may use the adjacency 566 table, the ACP, negotiation and synchronization through GRASP in the 567 ACP, Intent and other functions of the ANI. Since the ANI only 568 provides autonomic interactions within a domain, autonomic functions 569 can also use any other context on a node, specifically the global 570 data plane. 572 6. Security and Trust Infrastructure 574 An Autonomic Network is self-protecting. All protocols are secure by 575 default, without the requirement for the administrator to explicitly 576 configure security. 578 Autonomic nodes have direct interactions between themselves, which 579 must be secured. Since an autonomic network does not rely on 580 configuration, it is not an option to configure for example pre- 581 shared keys. A trust infrastructure such as a PKI infrastructure 582 must be in place. This section describes the principles of this 583 trust infrastructure. 585 A completely autonomic way to automatically and securely deploy such 586 a trust infrastructure is to set up a trust anchor for the domain, 587 and then use an approach as in the document "Bootstrapping Key 588 Infrastructures" [I-D.pritikin-bootstrapping-keyinfrastructures]. 590 6.1. Public Key Infrastructure 592 An autonomic domain uses a PKI model. The root of trust is a 593 certification authority (CA). A registrar acts as a registration 594 authority (RA). 596 A minimum implementation of an autonomic domain contains one CA, one 597 Registrar, and network elements. 599 6.2. Domain Certificate 601 We need to define how the fields in a domain certificate are to be 602 used. [tbc] 604 6.3. The MASA 606 Explain briefly the function, point to 607 [I-D.pritikin-bootstrapping-keyinfrastructures]. [tbc] 609 6.4. Sub-Domains (*) 611 Explain how sub-domains are handled. (tbc) 613 6.5. Cross-Domain Functionality (*) 615 Explain how trust is handled between different domains. (tbc) 617 7. Autonomic Service Agents (ASA) 619 This section describes how autonomic services run on top of the 620 Autonomic Networking Infrastructure. 622 7.1. General Description of an ASA 624 general concepts, such as sitting on top of the ANI, etc. Also needs 625 to explain that on a constrained node not all ASAs may run, so we 626 have two classes of ASAs: Ones that run on an unconstrained node, and 627 limited function ASAs that run also on constrained nodes. We expect 628 unconstrained nodes to support all ASAs. 630 7.2. Specific ASAs for the Enrolment Process 632 The following ASAs provide essential, required functionality in an 633 autonomic network, and are therefore mandatory to implement on 634 unconstrained autonomic nodes. 636 7.2.1. The Enrolment ASA 638 This section describes the function of an autonomic node to bootstrap 639 into the domain with the help of an enrolment proxy (see previous 640 section). [tbc] 642 7.2.2. The Enrolment Proxy ASA 644 This section describes the function of an autonomic node that helps a 645 non-enrolled, adjacent devices to enrol into the domain. [tbc] 647 7.2.3. The Registrar ASA 649 This section describes the registrar function in an autonomic 650 network. It explains the tasks of a registrar element, and how 651 registrars are placed in a network, redundancy between several, etc. 652 [tbc] 654 8. Management and Programmability 656 This section describes how an Autonomic Network is managed, and 657 programmed. 659 8.1. How an AN Network Is Managed 661 Autonomic management usually co-exists with traditional management 662 methods in most networks. Thus, autonomic behavior will be defined 663 for individual functions in most environments. In fact, the co- 664 existence is twofold: autonomic functions can use traditional methods 665 and protocols (e.g., SNMP and NETCONF) to perform management tasks; 666 and autonomic functions can conflict with behavior enforced by the 667 same traditional methods and protocols. 669 The autonomic intent is defined at a high level of abstraction. 670 However, since it is necessary to address individual managed 671 elements, autonomic management needs to communicate in lower-level 672 interactions (e.g., commands and requests). For example, it is 673 expected that the configuration of such elements be performed using 674 NETCONF and YANG modules as well as the monitoring be executed 675 through SNMP and MIBs. 677 Conflict can occur between autonomic default behavior, autonomic 678 intent, traditional management methods. Conflict resolution is 679 achieved in autonomic management through prioritization [RFC7575]. 680 The rationale is that manual and node-based management have a higher 681 priority over autonomic management. Thus, the autonomic default 682 behavior has the lowest priority, then comes the autonomic Intent 683 (medium priority), and, finally, the highest priority is taken by 684 node-specific network management methods, such as the use of command 685 line interfaces [RFC7575]. 687 8.2. Intent (*) 689 This section describes Intent, and how it is managed. Intent and 690 Policy-Based Network Management (PBNM) is already described inside 691 the IETF (e.g., PCIM and SUPA) and in other SDOs (e.g., DMTF and TMF 692 ZOOM). 694 Intent can be describe as an abstract, declarative, high-level policy 695 used to operate an autonomic domain, such as an enterprise network 696 [RFC7575]. Intent should be limited to high level guidance only, 697 thus it does not directly define a policy for every network element 698 separately. In an ideal autonomic domain, only one intent provided 699 by human administrators is necessary to operate such domain 700 [RFC7576]. However, it is als expected intent definition from 701 autonomic function(s) and even from traditional network management 702 elements (e.g., OSS). 704 Intent can be refined to lower level policies using different 705 approaches, such as Policy Continuum model [ref]. This is expected 706 in order to adapt the intent to the capabilities of managed devices. 707 In this context, intent may contain role or function information, 708 which can be translated to specific nodes [RFC7575]. One of the 709 possible refinements of the intent is the refinement to Event 710 Condition Action (ECA) rules. Such rules, which are more suitable to 711 individual entities, can be defined using different syntax and 712 semantics. 714 Different parameters may be configured for intents. These parameters 715 are usually provided by the human operator. Some of these parameters 716 can influence the behavior of specific autonomic functions as well as 717 the way the intent is used to manage the autonomic domain (towards 718 intended operational point). 720 Some examples of parameters for intents are: 722 o Model version: The version of the model used to define the intent. 724 o Domain: The network scope in which the intent has effect. 726 o Name: The name of the intent which describes the intent for human 727 operators. 729 o Version: The version of the intent, which is primarly used to 730 control intent updates. 732 o Signature: The signature is used as a security mechanism to 733 provide authentication, integrity, and non-repudiation. 735 o Timestamp: The timestamp of the creation of the intent using the 736 format supported by the IETF [TBC]. 738 o Lifetime: The lifetime in which the intent may be observed. A 739 special case of the lifetime is the definition of permanent 740 intents. 742 Intent distribution is considered as one of the common control and 743 management functions of an autonomic network [RFC7575]. Since 744 distribution is fundamental for autonomic networking, it is necessary 745 a mechanism to provision intent by all devices in a domain 746 [I-D.ietf-anima-grasp]. The distribution of Intent is function of 747 the Autonomic Control Plane and several methods can be used to 748 distribute Intent across an autonomic domain [draft-behringer-anima- 749 reference-model]. Intent distribution might not use the ANIMA 750 signaling protocol itself [I-D.ietf-anima-grasp], but there is a 751 proposal to extend such protocol for intent delivery [draft-liu- 752 anima-intent-distribution]. 754 8.3. Aggregated Reporting (*) 756 Autonomic Network should minimize the need for human intervention. 757 In terms of how the network should behave, this is done through an 758 autonomic intent provided by the human administrator. In an 759 analogous manner, the reports which describe the operational status 760 of the network should aggregate the information produced in different 761 network elements in order to present the effectiveness of autonomic 762 intent enforcement. Therefore, reporting in an autonomic network 763 should happen on a network-wide basis [RFC7575]. The information 764 gathering and the reporting delivery should be done through the 765 autonomic control plane. 767 Several events can occur in an autonomic network in the same way they 768 can happen in a traditional network. These events can be produced 769 considering traditional network management protocols, such as SNMP 770 and syslog. However, when reporting to a human administrator, such 771 events should be aggregated in order to avoid advertisement about 772 individual managed elements. In this context, algorithms may be used 773 to determine what should be reported (e.g., filtering) and in which 774 way and how different events are related to each other. Besides 775 that, an event in an individual element can be compensated by changes 776 in other elements in order to maintain in a network-wide level which 777 is described in the autonomic intent. 779 Reporting in an autonomic network may be in the same abstraction 780 level of the intent. In this context, the visibility on current 781 operational status of an autonomic network can be used to switch to 782 different management modes. Despite the fact that autonomic 783 management should minimize the need for user intervention, possibly 784 there are some events that need to be addressed by human 785 administrator actions. An alternative to model this is the use of 786 exception-based management [RFC7575]. 788 8.4. Feedback Loops to NOC(*) 790 Feedback loops are required in an autonomic network to allow the 791 intervention of a human administrator or central control systems, 792 while maintaining a default behaviour. Through a feedback loop an 793 administrator can be prompted with a default action, and has the 794 possibility to acknowledge or override the proposed default action. 796 8.5. Control Loops (*) 798 Control loops are used in autonomic networking to provide a generic 799 mechanism to enable the Autonomic System to adapt (on its own) to 800 various factors that can change the goals that the Autonomic System 801 is trying to achieve, or how those goals are achieved. For example, 802 as user needs, business goals, and the ANI itself changes, self- 803 adaptation enables the ANI to change the services and resources it 804 makes available to adapt to these changes. 806 Control loops operate to continuously observe and collect data that 807 enables the autonomic management system to understand changes to the 808 behavior of the system being managed, and then provide actions to 809 move the state of the system being managed toward a common goal. 811 Self-adaptive systems move decision-making from static, pre-defined 812 commands to dynamic processes computed at runtime. 814 Most autonomic systems use a closed control loop with feedback. Such 815 control loops SHOULD be able to be dynamically changed at runtime to 816 adapt to changing user needs, business goals, and changes in the ANI. 818 The document [draft-strassner-anima-control-loop] defines the 819 requirements for an autonomic control loop, describes different types 820 of control loops, and explains how control loops are used in an 821 autonomic system. 823 8.6. APIs (*) 825 Most APIs are static, meaning that they are pre-defined and represent 826 an invariant mechanism for operating with data. An Autonomic Network 827 SHOULD be able to use dynamic APIs in addition to static APIs. 829 A dynamic API is one that retrieves data using a generic mechanism, 830 and then enables the client to navigate the retrieved data and 831 operate on it. Such APIs typically use introspection and/or 832 reflection. Introspection enables software to examine the type and 833 properties of an object at runtime, while reflection enables a 834 program to manipulate the attributes, methods, and/or metadata of an 835 object. 837 APIs MUST be able to express and preserve semantics across different 838 domains. For example, software contracts [Meyer97] are based on the 839 principle that a software-intensive system, such as an Autonomic 840 Network, is a set of communicating components whose interaction is 841 based on precisely-defined specifications of the mutual obligations 842 that interacting components must respect. This typically includes 843 specifying: 845 o pre-conditions that MUST be satisfied before the method can start 846 execution 848 o post-conditions that MUST be satisfied when the method has 849 finished execution 851 o invariant attributes that MUST NOT change during the execution of 852 the method 854 8.7. Data Model (*) 856 The following definitions are taken from [supa-model]: 858 An information model is a representation of concepts of interest to 859 an environment in a form that is independent of data repository, data 860 definition language, query language, implementation language, and 861 protocol. In contrast, a data model is a representation of concepts 862 of interest to an environment in a form that is dependent on data 863 repository, data definition language, query language, implementation 864 language, and protocol (typically, but not necessarily, all three). 866 The utility of an information model is to define objects and their 867 relationships in a technology-neutral manner. This forms a 868 consensual vocabulary that the ANI and ASAs can use. A data model is 869 then a technology-specific mapping of all or part of the information 870 model to be used by all or part of the system. 872 A system may have multiple data models. Operational Support Systems, 873 for example, typically have multiple types of repositories, such as 874 SQL and NoSQL, to take advantage of the different properties of each. 875 If multiple data models are required by an Autonomic System, then an 876 information model SHOULD be used to ensure that the concepts of each 877 data model can be related to each other without technological bias. 879 A data model is essential for certain types of functions, such as a 880 MRACL. More generally, a data model can be used to define the 881 objects, attributes, methods, and relationships of a software system 882 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 883 used to help design an API, as well as any language used to interface 884 to the Autonomic Network. 886 9. Coordination Between Autonomic Functions (*) 888 9.1. The Coordination Problem (*) 890 Different autonomic functions may conflict in setting certain 891 parameters. For example, an energy efficiency function may want to 892 shut down a redundant link, while a load balancing function would not 893 want that to happen. The administrator must be able to understand 894 and resolve such interactions, to steer autonomic network performance 895 to a given (intended) operational point. 897 Several interaction types may exist among autonomic functions, for 898 example: 900 o Cooperation: An autonomic function can improve the behavior or 901 performance of another autonomic function, such as a traffic 902 forecasting function used by a traffic allocation function. 904 o Dependency: An autonomic function cannot work without another one 905 being present or accessible in the autonomic network. 907 o Conflict: A metric value conflict is a conflict where one metric 908 is influenced by parameters of different autonomic functions. A 909 parameter value conflict is a conflict where one parameter is 910 modified by different autonomic functions. 912 Solving the coordination problem beyond one-by-one cases can rapidly 913 become intractable for large networks. Specifying a common 914 functional block on coordination is a first step to address the 915 problem in a systemic way. The coordination life-cycle consists in 916 three states: 918 o At build-time, a "static interaction map" can be constructed on 919 the relationship of functions and attributes. This map can be 920 used to (pre-)define policies and priorities on identified 921 conflicts. 923 o At deploy-time, autonomic functions are not yet active/acting on 924 the network. A "dynamic interaction map" is created for each 925 instance of each autonomic functions and on a per resource basis, 926 including the actions performed and their relationships. This map 927 provides the basis to identify conflicts that will happen at run- 928 time, categorize them and plan for the appropriate coordination 929 strategies/mechanisms. 931 o At run-time, when conflicts happen, arbitration is driven by the 932 coordination strategies. Also new dependencies can be observed 933 and inferred, resulting in an update of the dynamic interaction 934 map and adaptation of the coordination strategies and mechanisms. 936 Multiple coordination strategies and mechanisms exists and can be 937 devised. The set ranges from basic approaches such as random process 938 or token-based process, to approaches based on time separation and 939 hierarchical optimization, to more complex approaches such as multi- 940 objective optimization, and other control theory approaches and 941 algorithms family. 943 9.2. A Coordination Functional Block (*) 945 A common coordination functional block is a desirable component of 946 the ANIMA reference model. It provides a means to ensure network 947 properties and predictable performance or behavior such as stability, 948 and convergence, in the presence of several interacting autonomic 949 functions. 951 A common coordination function requires: 953 o A common description of autonomic functions, their attributes and 954 life-cycle. 956 o A common representation of information and knowledge (e.g., 957 interaction maps). 959 o A common "control/command" interface between the coordination 960 "agent" and the autonomic functions. 962 Guidelines, recommendations or BCPs can also be provided for aspects 963 pertaining to the coordination strategies and mechanisms. 965 10. Security Considerations 967 10.1. Threat Analysis 969 This is a preliminary outline of a threat analysis, to be expanded 970 and made more specific as the various Autonomic Networking 971 specifications evolve. 973 Since AN will hand over responsibility for network configuration from 974 humans or centrally established management systems to fully 975 distributed devices, the threat environment is also fully 976 distributed. On the one hand, that means there is no single point of 977 failure to act as an attractive target for bad actors. On the other 978 hand, it means that potentially a single misbehaving autonomic device 979 could launch a widespread attack, by misusing the distributed AN 980 mechanisms. For example, a resource exhaustion attack could be 981 launched by a single device requesting large amounts of that resource 982 from all its peers, on behalf of a non-existent traffic load. 983 Alternatively it could simply send false information to its peers, 984 for example by announcing resource exhaustion when this was not the 985 case. If security properties are managed autonomically, a 986 misbehaving device could attempt a distributed attack by requesting 987 all its peers to reduce security protections in some way. In 988 general, since autonomic devices run without supervision, almost any 989 kind of undesirable management action could in theory be attempted by 990 a misbehaving device. 992 If it is possible for an unauthorised device to act as an autonomic 993 device, or for a malicious third party to inject messages appearing 994 to come from an autonomic device, all these same risks would apply. 996 If AN messages can be observed by a third party, they might reveal 997 valuable information about network configuration, security 998 precautions in use, individual users, and their traffic patterns. If 999 encrypted, AN messages might still reveal some information via 1000 traffic analysis, but this would be quite limited (for example, this 1001 would be highly unlikely to reveal any specific information about 1002 user traffic). AN messages are liable to be exposed to third parties 1003 on any unprotected Layer 2 link, and to insider attacks even on 1004 protected Layer 2 links. 1006 11. IANA Considerations 1008 This document requests no action by IANA. 1010 12. Acknowledgements 1012 Many people have provided feedback and input to this document: Sheng 1013 Jiang, Roberta Maglione, Jonathan Hansford. 1015 13. References 1017 [I-D.behringer-anima-autonomic-addressing] 1018 Behringer, M., "An Autonomic IPv6 Addressing Scheme", 1019 draft-behringer-anima-autonomic-addressing-02 (work in 1020 progress), October 2015. 1022 [I-D.ietf-anima-autonomic-control-plane] 1023 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1024 Autonomic Control Plane", draft-ietf-anima-autonomic- 1025 control-plane-01 (work in progress), October 2015. 1027 [I-D.ietf-anima-grasp] 1028 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1029 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1030 grasp-01 (work in progress), October 2015. 1032 [I-D.jiang-auto-addr-management] 1033 Jiang, S., Carpenter, B., and Q. Qiong, "Autonomic 1034 Networking Use Case for Auto Address Management", draft- 1035 jiang-auto-addr-management-00 (work in progress), April 1036 2014. 1038 [I-D.pritikin-bootstrapping-keyinfrastructures] 1039 Pritikin, M., Behringer, M., and S. Bjarnason, 1040 "Bootstrapping Key Infrastructures", draft-pritikin- 1041 bootstrapping-keyinfrastructures-01 (work in progress), 1042 September 2014. 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, 1046 DOI 10.17487/RFC2119, March 1997, 1047 . 1049 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1050 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1051 . 1053 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1054 Addressing inside an IPv6 Network", RFC 7404, 1055 DOI 10.17487/RFC7404, November 2014, 1056 . 1058 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1059 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1060 Networking: Definitions and Design Goals", RFC 7575, 1061 DOI 10.17487/RFC7575, June 2015, 1062 . 1064 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1065 Analysis for Autonomic Networking", RFC 7576, 1066 DOI 10.17487/RFC7576, June 2015, 1067 . 1069 Authors' Addresses 1071 Michael H. Behringer (editor) 1072 Cisco Systems 1073 Building D, 45 Allee des Ormes 1074 Mougins 06250 1075 France 1077 Email: mbehring@cisco.com 1079 Brian Carpenter 1080 Department of Computer Science 1081 University of Auckland 1082 PB 92019 1083 Auckland 1142 1084 New Zealand 1086 Email: brian.e.carpenter@gmail.com 1088 Toerless Eckert 1089 Cisco 1091 Email: eckert@cisco.com 1092 Laurent Ciavaglia 1093 Alcatel Lucent 1094 Route de Villejust 1095 Nozay 91620 1096 France 1098 Email: laurent.ciavaglia@alcatel-lucent.com 1100 Bing Liu 1101 Huawei Technologies 1102 Q14, Huawei Campus 1103 No.156 Beiqing Road 1104 Hai-Dian District, Beijing 100095 1105 P.R. China 1107 Email: leo.liubing@huawei.com 1109 Jeferson Campos Nobre 1110 Federal University of Rio Grande do Sul 1111 Av. Bento Goncalves, 9500 1112 Porto Alegre 91501-970 1113 Brazil 1115 Email: jcnobre@inf.ufrgs.br 1117 John Strassner 1118 Huawei Technologies 1119 2330 Central Expressway 1120 Santa Clara, CA 95050 1121 USA 1123 Email: john.sc.strassner@huawei.com