idnits 2.17.1 draft-ciavaglia-anima-knowledge-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2952 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ciavaglia-anima-coordination' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'I-D.peloso-anima-autonomic-function' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'I-D.behringer-anima-reference-model' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 609, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ciavaglia-anima-coordination-00 == Outdated reference: A later version (-01) exists of draft-peloso-anima-autonomic-function-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA L. Ciavaglia 3 Internet-Draft P. Peloso 4 Intended status: Informational Nokia 5 Expires: September 22, 2016 March 21, 2016 7 Knowledge Exchange in Autonomic Networks 8 draft-ciavaglia-anima-knowledge-00.txt 10 Abstract 12 This document describes a solution to manage the exchange and 13 processing of information and knowledge between autonomic functions. 14 The objective is to provide a unified interface to enable an 15 interoperable management of information flows among autonomic 16 functions by insuring the use common mechanisms. The protocol 17 negotiate and automatically adapt to the communication and 18 information capabilities, requirements and constraints of the 19 participating entities. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 This document may not be modified, and derivative works of it may not 57 be created, except to format it for publication as an RFC or to 58 translate it into languages other than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Knowledge Exchange Interface . . . . . . . . . . . . . . . . 3 64 2.1. Information Collection and Dissemination - ICD . . . . . 4 65 2.2. Information Storage and Indexing - ISI . . . . . . . . . 5 66 2.3. Information Processing and Knowledge Production - IPKP . 5 67 2.4. Information Flow Establishment and Optimization - IFEO . 7 68 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 6.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 The ANIMA autonomic management framework addresses the growing 79 management complexity of the highly decentralized and dynamic 80 environment of service provider networks. The ANIMA autonomic 81 management framework will help to produce the unification, 82 governance, and "plug and play" for autonomic networking solutions 83 within existing and future management ecosystems. Three main 84 functional blocks namely the Governance, Coordination and Knowledge 85 functionalities are essential to ensure a proper management and 86 interworking of Autonomic Service Agents (ASAs). This document 87 describes a solution to manage the exchange and processing of 88 information and knowledge between autonomic functions. The objective 89 is to provide a unified interface to enable an interoperable 90 management of information flows among autonomic functions by insuring 91 the use common mechanisms. The protocol negotiate and automatically 92 adapt to the communication and information capabilities, requirements 93 and constraints of the participating entities. The Knowledge 94 functionality plays the role of information / knowledge collection, 95 aggregation, storage/registry, knowledge production and distribution 96 across all the ANIMA functional components (i.e. ANI and ASAs). 98 The Knowledge block is composed of the following functions: 100 o Information Collection and Dissemination - ICD 102 o Information Storage and Indexing - ISI 104 o Information Processing and Knowledge Production - IPKP 106 o Information Flow Establishment and Optimization - IFEO 108 The Knowledge Block offers basic information/knowledge manipulation 109 functionalities to the ANIMA entities through the Knowledge Exchange 110 Interface. A second interface, the Knowledge Management Interface, 111 handles information flow management that includes configuration 112 actions towards the optimal handling of the information/knowledge in 113 the management system. 115 2. Knowledge Exchange Interface 117 An Autonomic Service Agent needs two different types of interfaces to 118 deal with the exchange of knowledge. 120 Knowledge Exchange Interface: Interfaces through which the 121 information are actually exchanged. 123 Knowledge Management Interface: Interfaces through which the 124 information flows are negotiated, and information capacities are 125 being discovered/advertised. This interface provides 126 configuration actions towards the optimal handling of the 127 information/knowledge in the ASA. 129 The most important concept is the knowledge exchange flow, which is 130 being set between two knowledge exchange interfaces. It is 131 determined by the two endpoints of the flow and by the type of 132 information that is being conveyed over the flow. Some additional 133 parameters define the way the information are being exchanged (Push 134 or Pull mode plus additional parameters to determine the frequency 135 and conditions of the actual information exchange). 137 The features of the knowledge exchange flow are being negotiated by 138 Knowledge Management Interfaces and possibly a third party in charge 139 of optimizing the information flows over the whole system. The 140 objective of this negotiation is to determine the characteristics of 141 the exchange flow, which will then be enforced between two/multiple 142 knowledge exchange interfaces. 144 2.1. Information Collection and Dissemination - ICD 146 The Information Collection and Dissemination (ICD) function is 147 responsible for information collection, sharing, retrieval and 148 dissemination. The ASAs can act as sources or sinks of information. 149 The sources subscribe to the Information Catalog by exposing the type 150 of information they can produce. On the one hand, each information 151 source should subscribe information availability and the equivalent 152 collection constraints (e.g., the supported granularity of 153 collection). On the other hand, each information sink should 154 subscribe information retrieval requirements with a similar process. 155 The subscription process takes place during the ASA bootstrapping. 156 The matching of constraints with requirements takes place during an 157 equivalent negotiation process. 159 Information can be directly retrieved from or shared with a dedicated 160 Knowledge Sharing system (a sort of ASA which roles is limited to be 161 used as a store and sharing entity at the service of other ASAs). As 162 an information collection process is triggered by a component 163 requesting the information, a catalog of the available information 164 has to be built and kept. This catalog indexes which ASA can produce 165 which information. Then upon a bootstrapping ASA requesting a given 166 information to work, the entity in charge of this catalog would then 167 inform requesting ASA of the source ASA. This process could be 168 supported by GRASP discovery mechanism. 170 The information collection process may be optimized by the 171 Information Flow Establishment and Optimization - IFEO or another 172 utility ASA in charge of optimizing the flows. This ASA acts as the 173 third party during the negotiation phase between an information 174 source and an information sink. If many information sink need the 175 same information, the negotiation entity, is liable to enforce the 176 use of an intermediate Knowledge Sharing system that would collect 177 the information from the source before flooding to sinks according to 178 their requirements. 180 The collected information may either be directed to the Information 181 Processing and Knowledge Production function for a further processing 182 (e.g., aggregation or knowledge production) and then optionally 183 stored/indexed to the Information Storage and Indexing - ISI 184 function. The storage option may be provided or demanded based on 185 the nature of the information, ASA demands, optimization goals, etc. 186 After this stage, the information or produced knowledge could be 187 passed back to the ICD function for dissemination. 189 2.2. Information Storage and Indexing - ISI 191 The Information Storage and Indexing (ISI) function is a logical 192 construct representing a distributed repository for registering ASAs, 193 indexing (and optionally storing) information/knowledge. The ISI 194 function stores information, such as ASA registration information and 195 knowledge. The ISI functionality includes methods and functions for 196 keeping track of information sources, including information 197 registration and naming, constraints of information sources, 198 information directory and indexing. An important storage aspect, 199 which can assist the knowledge production handled by the Information 200 Processing and Knowledge Production function, is the inherent support 201 of historical capabilities. For example, an ASA could request 202 information and/or knowledge that was stored in the past using an 203 appropriate time stamp. It should be noted that knowledge production 204 functionality is not part of the ISI function, but it supports the 205 storing of knowledge derived due to some earlier calculations. The 206 ISI optionally stores knowledge produced from the Information 207 Processing and Knowledge Production function (for extended-scoped 208 knowledge) or Knowledge Building ASAs (for locally-scoped knowledge). 209 The different ANIMA entities either requesting or storing information 210 to the Knowledge block, do not directly communicate with the ISI. 211 The ICD function handles information collection or dissemination 212 between the storage points and the ASAs. Furthermore, ISI supports: 213 (i) publish/subscribe information dissemination capabilities, (ii) 214 alternative storage structures (i.e., centralized versus distributed 215 or hierarchical) and database technologies based on the context, and 216 (iii) information and knowledge caching. 218 2.3. Information Processing and Knowledge Production - IPKP 220 The Information Processing and Knowledge Production function (IPKP) 221 is responsible for operations related to information processing 222 (i.e., aggregation) and knowledge production. The IPKP provides to 223 ASAs and the ANIMA management functions the necessary tool kit to 224 produce different information abstractions, including processed 225 information and extended-scoped knowledge. The Knowledge Production 226 (KP) operation handles and produces knowledge that may be extended- 227 scoped. The latter type of knowledge is being produced out of 228 aggregated information or locally-scoped knowledge. Locally-scoped 229 knowledge can be built from the Knowledge Building ASAs out of data/ 230 information directly collected from the managed entities, i.e., its 231 scope is limited to those entities. In all cases of knowledge 232 production, reasoning and inference mechanisms are required. These 233 mechanisms are based on different techniques depending on the exact 234 problem addressed, the type of inputs used and the type of output 235 that needs to be acquired. Such techniques come from scientific 236 areas like statistics, clustering, reasoning, Fuzzy or machine 237 learning (including supervised, unsupervised and reinforcement 238 learning techniques). All the above information (e.g., problem 239 addressed, type of inputs / outputs, inference/reasoning mechanisms 240 etc) must be described in a proper ontology, ready to be looked up 241 from the IPKP function when such a demand appears. An ASA or ANIMA 242 management function that requires the IPKP functionalities requests 243 to utilize either an Information Aggregation (IA) or a Knowledge 244 Production (KP) operation. The ICD function handles the 245 communication of the ANIMA management component with the internal 246 IPKP functionalities and the IPKP controller is responsible to 247 control the internal IPKP components. The two IPKP operations (i.e., 248 information aggregation and knowledge production) require a number of 249 basic steps: 251 Step 1: Determining the information aggregation or knowledge 252 production parameters (e.g., information filtering configuration, 253 the inference/reasoning algorithm to use, translation 254 requirements, whether aggregation is required and/or information/ 255 knowledge post-processing requirements). This process is being 256 handled from the IPKP controller, which matches the ANIMA 257 component's requirements and the type of problem to solve with the 258 relevant information. The parameters are being communicated to 259 all relevant internal IPKP components. 261 Step 2: Collection of input information either from an ANIMA 262 component that produces it or from the ISI function (i.e., the 263 knowledge storage). A collection request is being passed back 264 from the IPKP controller to the ICD function. 266 Step 3: Pre-processing of the input information (e.g., applying 267 information filtering) that may be required. The pre-processing 268 requirements are being set from the IPKP controller. 270 Step 4: The input information is being passed to the IA operation 271 in case of information aggregation, where an aggregation process 272 takes place according the requirements (e.g., aggregation function 273 used) being set from the IPKP controller. In case of knowledge 274 production, this step may be bypassed or not (i.e., the higher- 275 level knowledge production processes may require aggregation 276 before the inference/reasoning process). 278 Step 5: In case of knowledge production, the input information may 279 need to be translated in a convenient representation, e.g., to 280 OWL. The translation configuration is being set from the IPKP 281 controller to match the requirements of the inference/reasoning 282 mechanism identified from the (TBD) ANIMA ontology. 284 Step 6: The actual inference/reasoning process takes place in this 285 step. The input information (i.e., in an appropriate form) and 286 the relevant knowledge production rules are being passed to the 287 identified inference/reasoning mechanism. A rule description 288 language that can be used is the Semantic Web Rule Language 289 (SWRL). The output of this process is the produced Knowledge. 290 This step may be bypassed, in case of a request for information 291 aggregation without knowledge production. 293 Step 7: The produced knowledge or aggregated information may need 294 a post-processing (e.g., filtering). This step is optional. 296 Step 8: At this stage, the result is being communicated to the ICD 297 function, to find its way to the requesting ANIMA component. The 298 produced knowledge or aggregated information can be optionally 299 stored in the ISI function so as to be available for ANIMA 300 management mechanisms or ASAs when requested/needed. 302 2.4. Information Flow Establishment and Optimization - IFEO 304 The information flow negotiation and optimization aspects are crucial 305 processes overseen from the Information Flow Establishment and 306 Optimization (IFEO) function. The IFEO function, besides organizing 307 internal optimization aspects (e.g., setting filtering or information 308 accuracy objectives), also regulates the information flow based on 309 the current state and the locations of the participating ANIMA 310 components (e.g., the ASAs producing or requiring information). All 311 relevant communication between the knowledge functions and the ANIMA 312 components takes place through the Knowledge Management interface, 313 unless it is otherwise stated. 315 For clarity purposes, we define the specifications of the IFEO 316 function along with a representative example. We assume the 317 following two ASAs: (a) the Virtual Infrastructure Management (VIM) 318 ASA that provides management and control facilities for virtual 319 infrastructures, including support of traffic monitoring; and (b) the 320 Placement Optimization (PO) ASA that optimizes the data flow over a 321 virtual network through adapting the positioning of communicating 322 nodes (e.g., data servers) in response to the dynamic network 323 conditions. In this example, the VIM ASA provides traffic monitoring 324 information from a particular virtual network to the PO ASA. The PO 325 ASA takes optimization decisions for the network based on this 326 information, i.e., repositions communicating nodes in order to 327 optimize network communication. The information flow negotiation and 328 optimization processes include a number of basic phases, elaborated 329 below: 331 Phase 1 - Registration: In this phase the ASAs, as part of their 332 registration process with the knowledge block (i.e., described in 333 section 3.6.2), will communicate the following information to the 334 knowledge: 336 Information they can offer instantly or after an information 337 collection process. 339 Knowledge they can offer instantly or after a knowledge 340 production process. 342 Information/knowledge they would require (mandatory or 343 optional). 345 The above information is embedded in the description of the ASA 346 instance description. In our example, the VIM ASA registers the 347 information it can offer (e.g., the topology information and 348 measurements on the link loads). This information can be offered 349 instantly (i.e., does not require an information collection 350 process to start, since it monitors the network continuously). 351 The PO ASA registers the same information type as mandatory 352 information required. 354 Phase 2 - An ANIMA management function requesting knowledge: In 355 this phase a process in an ANIMA management function (like a 356 supervision process in management or a knowledge production 357 mechanism or a coordination mechanism) demands to register to a 358 given piece of information produced by a given ASA. This 359 information is expressed as a information specification. In that 360 case, the Knowledge Management Interface of the requesting entity 361 is calling a TBD knowledge method named to request the registered 362 information. 364 Phase 3 - Information Flow Negotiation: In the third phase, the 365 knowledge block through its IFEO function handles a flow 366 negotiation process between entities (i.e., ASAs or management 367 mechanisms) requiring information and those can provide it. The 368 two entities exchange information flow related parameters with the 369 knowledge block, in order to confirm that all information-related 370 requirements can be satisfied under the given constraints. An 371 information flow is either established between the two entities 372 directly or between an entity and the knowledge block itself, in 373 case the requested information is available in the knowledge 374 storage. The negotiation process includes flow-level optimization 375 aspects as well. This phase is composed of the following steps: 377 Step 1 - Preselecting the information flow ends: Whenever a ASA 378 registers it advertises requested information/knowledge (under 379 a specific format TBD), the knowledge block fetches in its 380 indexing storage the appropriate entity (ASA or management 381 mechanism) that can produce the requested information/ 382 knowledge. It may either select an entity by considering the 383 type of information/knowledge required or, in case of 384 alternative options, assign the first entity it finds and 385 enlist the other potential choices in a queue. In case the 386 required information is in the knowledge storage, an 387 information flow is created with the knowledge. The same 388 process happens when a ANIMA management entity requests some 389 knowledge, depending on the form of the request (i.e., a 390 fetching from the indexing storage may or may not be required): 392 ASA information: already specifies which is the Instance ID 393 of the ASA producing the information. 395 ANIMA information: a fetching from the index table is 396 required to pick the appropriate flow ends. 398 Management information: then the fetching does not concern 399 finding a flow end, but finding all the flow ends matching 400 the pattern provided by the management information in order 401 to establish as many flows as indexed ANIMA information 402 objects inheriting from the management information (this 403 corresponds to a supervision mechanism requesting to 404 register to ASA utilities, hence a flow for each ASA capable 405 of advertising its utility will be created). Reversely, 406 knowledge may have postponed flow establishments of some 407 requested information because at the time the request was 408 received, no entity producing this information was 409 registered. In that case, knowledge checks with every 410 received instance description whether the advertised 411 information matches previously unsolved requests. After 412 that, the IFEO proceeds to Step 2. In the studied example, 413 the knowledge block preselects the VIM ASA as information 414 source for the PO ASA that acts as the information sink. 415 This selection was based on the matching information URIs 416 referenced in the registered ANIMA information data 417 structures from the two ASAs. 419 Step 2 -Communicating the negotiation parameters: in step 2, a 420 negotiation process is initiated between the entity requiring 421 information/knowledge (i.e., the information sink entity) and 422 the selected information source entity. The negotiation begins 423 with the two entities communicating additional negotiation 424 parameters to the knowledge block. Specifically, the 425 information sink entity communicates an augmented version of 426 the ANIMA information with: 428 -QoS Requirements on the information/knowledge it requires. 430 -Preferred information communication method (i.e., either 431 push/pull or pub/sub). 433 -List of Knowledge Exchange interfaces (addresses) on which 434 the information can be received and possibly an internal 435 metric regarding the internal costs to use this information 436 from each of these interfaces. 438 -REST callback functions that may be required at this end of 439 communication (e.g., in case of an information subscribe 440 method). 442 In a similar way, the information source entity communicates 443 the following to the knowledge block: 445 -QoS Constraints on the information/knowledge it can offer. 447 -Supported(and preferred) information communication method 448 (i.e., either push/pull or pub/sub). 450 -Whether for this requested information/knowledge an 451 "information collection/knowledge production" process is 452 already activated or needs to be initiated. 454 -List of Knowledge Exchange interfaces (addresses) on which 455 the information can be provided and possibly an internal 456 metric regarding their internal cost to bring this 457 information up to the interface. 459 -REST Callback functions for the relevant capabilities 460 (i.e., triggering functions for information collection or 461 knowledge production - if relevant). 463 Practically, the knowledge block initiates a new negotiation 464 with the execution of the sink and source parameters 465 negotiation methods of the Knowledge Management Interface. 466 Both methods take as input the specifications of the 467 information to be communicated from the established 468 communication flow, represented as an ANIMA information data 469 structure. In the reference scenario, the VIM ASA communicates 470 to the knowledge: (i) the QoS constraints of the topology and 471 link load information it can offer, e.g., monitors information 472 once per 10 secs, and (ii) a number of available Knowledge 473 Exchange interfaces that can provide the information. The PO 474 ASA communicates to the knowledge: (i) the QoS requirements of 475 the required information, e.g., once per 30 secs, and (ii) a 476 number of available Knowledge Exchange interfaces that can 477 receive the information. 479 Step 3 - Completing the negotiation: The knowledge block 480 matches information flow requirements with constraints, 481 determines the information flow parameters with flow 482 optimization considerations and then issues a Knowledge 483 Exchange Policy summarizing an information flow contract to 484 both entities. knowledge also stores the Knowledge Exchange 485 Policy through the Information Flow Configuration and 486 Statistics operation of the IFEO function. In case of an 487 unsuccessful negotiation (i.e., the requirements do not match 488 the constraints), it may disengage or trigger a new 489 negotiation: 491 a) With the same information source entity but lower 492 requirements. 494 >b) With another information source entity that waits in the 495 queue, until the queue is exhausted. 497 The Information Exchange Policies for the corresponding flow 498 are being produced from the Information Quality Controller 499 operation of the IFEO knowledge block function and include: 501 -Location/addresses of the participating Knowledge Exchange 502 Interfaces in the information flow. 504 -Internal knowledge optimization decisions that may impact 505 the information flow (e.g., optimal knowledge aggregation/ 506 storage points), in case the knowledge block is the one end 507 of the flow. 509 -Addresses of triggering callback functions for knowledge 510 production or information collection - if relevant. 512 These policies are considering the requirements/constraints of the 513 participating entities and the global performance objective coming 514 from the operator (e.g. via the ANIMA Intent Policy). The knowledge 515 establishes the information flow using a set flow method of the 516 Knowledge Management Interface, that takes as an input the decided 517 Information Flow Exchange Policies, represented as a flow data 518 structure. 520 The decided Information Exchange Policies are being applied to the 521 network through the respective ASAs or communicated to the knowledge 522 functions they are associated with. Since the appropriate context 523 environment for the new information flow is prepared, a suitable path 524 between the participating nodes is established next. This process 525 considers the locations of the entities producing and requiring 526 information and the required knowledge nodes (e.g., aggregation 527 points, storage points etc) as well as the potential traffic 528 characteristics. After that, the Knowledge Exchange interface can be 529 accessed anytime from the information sink entity to receive the 530 needed information/knowledge. In our reference scenario, the 531 knowledge block matches the information flow constraints (e.g., 532 supported monitoring rate) of the VIM ASA with the information flow 533 requirements from the PO ASA. Then it selects the most appropriate 534 Knowledge Exchange interfaces to communicate the information from the 535 VIM to the PO ASA. A new information flow contract is established 536 and communicated to the two ASAs and stored in the knowledge block. 537 The information flow is established and the PO ASA can retrieve the 538 required information from the VIM ASA via the appropriate Knowledge 539 Exchange interface. The PO ASA can now begin taking network 540 optimization decisions using that information. 542 Knowledge-level Optimization: Furthermore, knowledge supports a 543 global optimization process that is triggered periodically or when a 544 global performance objective change is requested from the GOV. This 545 process takes optimization decisions using the aggregated information 546 from the configuration of all established information flows and is 547 related with a restructuring of the knowledge functions themselves. 548 In other words, global-optimization algorithms may discard or update 549 Knowledge Exchange Policies enforced for established information 550 flows. It takes as an input the global picture of all the 551 established information flow contacts and provides as an output 552 different contracts aligned better to the new updated demands (e.g., 553 a new received global objective). This process may initiate re- 554 negotiations that include requesting again from the entities what 555 their requirements and capabilities are. For example, the 556 distributed knowledge nodes may be increased, decreased or 557 repositioned in order to accommodate all established information 558 flows and the global optimization goal better. The optimization 559 process is triggered by the IFEO function and regulates the 560 information flow based on the current state and the locations of the 561 participating ANIMA components. In particular, the IFEO controls 562 information collection handled from the ICD function, information 563 aggregation, and aggregation node placement. Furthermore, it guides 564 a filtering system for information collection and aggregation points 565 that can significantly reduce the communication overhead. 567 3. Acknowledgments 569 This draft was written using the xml2rfc project. 571 The content of this draft builds upon work achieved during the EU FP7 572 UniverSelf project (www.univerself-project.eu). 574 4. IANA Considerations 576 This memo includes no request to IANA. 578 5. Security Considerations 580 TBD 582 6. References 584 6.1. Normative References 586 [I-D.ciavaglia-anima-coordination] 587 Ciavaglia, L. and P. Peloso, "Autonomic Functions 588 Coordination", draft-ciavaglia-anima-coordination-00 (work 589 in progress), July 2015. 591 [I-D.peloso-anima-autonomic-function] 592 Peloso, P. and L. Ciavaglia, "A Day in the Life of an 593 Autonomic Function", draft-peloso-anima-autonomic- 594 function-00 (work in progress), October 2015. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 6.2. Informative References 603 [I-D.behringer-anima-reference-model] 604 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 605 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 606 for Autonomic Networking", draft-behringer-anima- 607 reference-model-04 (work in progress), October 2015. 609 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 610 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 611 Networking: Definitions and Design Goals", RFC 7575, 612 DOI 10.17487/RFC7575, June 2015, 613 . 615 Authors' Addresses 617 Laurent Ciavaglia 618 Nokia 619 Villarceaux 620 Nozay 91460 621 FR 623 Email: laurent.ciavaglia@nokia.com 625 Pierre Peloso 626 Nokia 627 Villarceaux 628 Nozay 91460 629 FR 631 Email: pierre.peloso@nokia.com