ANIMA WG X. Xiao INTERNET-DRAFT A. Hecker Intended Status: Standard Track Z. Despotovic GRC, Huawei Technologies Expires: April 29, 2018 October 30, 2017 Event Service in Autonomic Networking draft-xiao-anima-event-service-00 Abstract Event service is an asynchronous communication model between interacting parties, e.g. autonomic functions (AFs), instead of a tightly coupled point-to-point (P2P) synchronous communication model. Event service enables autonomic nodes in ANI to publish data information, which will be made network distributable autonomously, and subscribers who register interests to specific events will be notified if the information is available. This draft describes how to support event service (ES) for autonomic networking. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. X. Xiao Expires April 29, 2018 [Page 1] INTERNET DRAFT Event Service in ANI October 30, 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Event Service Use Cases . . . . . . . . . . . . . . . . . . . . 3 3.1 Long Communication Intervals between AFs . . . . . . . . . . 3 3.2 Common Interest Distribution among AFs . . . . . . . . . . . 4 3.3 Distributed Coordination among AFs . . . . . . . . . . . . . 4 4. Event Service Design . . . . . . . . . . . . . . . . . . . . . 4 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Event Queue . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Information Storage . . . . . . . . . . . . . . . . . . . . 5 4.4 Interface between IS and EQ Modules . . . . . . . . . . . . 6 5. Integration with ANI . . . . . . . . . . . . . . . . . . . . . 6 5.1 ES Module as an ASA . . . . . . . . . . . . . . . . . . . . 6 5.2 ES Module as an Core Component in ANI . . . . . . . . . . . 7 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 X. Xiao Expires April 29, 2018 [Page 2] INTERNET DRAFT Event Service in ANI October 30, 2017 1 Introduction In autonomic networking, autonomic functions (AFs) running on autonomic nodes utilize the autonomic networking infrastructure (ANI) to realize various control purposes [RFC7575]. Due to the distributed nature of a network system, AFs need to exchange information constantly, either for control plane signaling, for data plane service or both. In the current ANI design [I-D.behringer-anima-reference-model], a direct point-to-point (P2P) communication model is provided where a sender specifically builds a connection and sends information (e.g. control message, synchronization data and so on) to the receiver. This works well if the information and data exchanged or events triggered are short and instant. In addition to this short and instant communication, there are also many scenarios involving longer and more complicated communication types, where a direct P2P model may not work properly. In this sense, it is important to provide asynchronous communications for the class of distributed systems that operate in a loosely-coupled and autonomous fashion, and which require operational immunity from network failures. This draft describes the design of an event service (ES) for AFs in the ANI that supports asynchronous communication model and that is customized for AF groups with different objectives. With ES, AFs communicate through a publish and subscribe (Pub/Sub) paradigm, where publishing and subscribing introduce events to the system and the ES module is responsible for organizing the published information and delivering it to the receivers that have registered an interest. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Event Service Use Cases Following use cases in autonomic networking are considered as scenarios that fit well asynchronous communication patterns. 3.1 Long Communication Intervals between AFs The time interval of communication is not necessarily always short and instant. More advanced AFs rather may involve heavy jobs/tasks when gearing the network, so the direct mode may introduce unnecessary pending time and be less efficient. For example, an AF may access another AF for a database lookup. Similar use cases may X. Xiao Expires April 29, 2018 [Page 3] INTERNET DRAFT Event Service in ANI October 30, 2017 include AF migration, AF authentication and authorization. In a direct mode, the AF has to wait until the tasks finish and return. The ES mechanism decouples the dependency between the two parties. Once the jobs are finished, AFs will get notified. 3.2 Common Interest Distribution among AFs Some information types are common interests among AFs. A typical example is distributing network intent, which will be distributed to network nodes enrolled in the autonomic control plane (ACP) [I- D.behringer-anima-autonomic-control-plane]. As the network intents are the common interest of all nodes that participate in the ANI, network nodes through ES can register for the network intent event and get notified if applicable. Network intent updates can follow the same logic. So far, such information is delivered by (selective) flooding via GRASP [I-D.liu-anima-grasp-distribution]. Note that because of network dynamic not every node can be ready at the moment when the network intent is flooded as nodes join in the network sequentially. However, the owner of the intent will be proactively probed from time to time. ES takes over this and automatically replies upon the registration of new comers with the latest intent. 3.3 Distributed Coordination among AFs Hosting AFs on distributed network elements naturally assumes computing and storage resources on the network nodes. When executing, AFs not only consume but also generate data information for other AFs. One example is AFs coordinating with each other as distributed schedulers, responding to service requests and balancing the load in the network, thus it is critical for those AFs to make correct decisions based on local information, which might be asymmetric as well. Furthermore, AFs may also need synthetic/aggregated data information (e.g. statistic info, like average values of several AFs, etc.) to make decisions. In these scenarios, AFs will need an efficient way to form a common view of the network (e.g. about resource consumption, bandwidth and statistics). This calls for a scalable, common, yet distributed data layer, on which AFs can store and share information. The ES module aims at making data information distributable and providing an event-driven Pub/Sub paradigm to share them. 4. Event Service Design 4.1 Overview The main functions of the event service (ES) module are to 1) decide where to store the published information, 2) create event queues to announce published information, 3) match published and subscribed X. Xiao Expires April 29, 2018 [Page 4] INTERNET DRAFT Event Service in ANI October 30, 2017 events and 4) deliver information if event matching succeeds. Specifically, for publishers, the ES module is to 1) receive publishing requests from AFs (also from ASAs), 2) decide where to store the published information, 3) update corresponding event queues. For subscribers, the ES module is to 1) register interests, 2) monitor event queues in the system and 3) trigger information retrieval and delivery if information of registered events are ready. The ES module is further decomposed into two sub-modules: 1) event queue (EQ) module and 2) information storage (IS) module shown in Figure. 1. We introduce details of the two sub-modules in the following sections. +---------------------------------------+ | +---------------+ +---------------+ | | | Event Queue |-|-| Info. Storage | | | +---------------+ +---------------+ | +---------------------------------------+ Figure 1. Components of Event Service Module 4.2 Event Queue Event Queue (EQ) module is responsible for event classification, event prioritization and event matching. First, EQ module provides isolated event queues customized for different event groups. Specifically, two groups of AFs could have completely different purposes or interests, therefore EQ classification allows to create multiple message queues where only AFs interested in the same category of events will be aware of the corresponding event queue. Second, events generated may have to be processed with different priorities. Some of them are more urgent than the normal and regular ones. Also between two event queues, their priorities may be different. EQ prioritization allows AFs to set different priorities on the information they published. Based on the priority settings in the event queue, matching and delivery of them will be adjusted. EQ module can provide several pre-defined priority levels for both intra-queue and inter-queue prioritizations. Third, events in queues will be listened and if a publishing event is found and matched by a registration event, information retrieval will be triggered. 4.3 Information Storage X. Xiao Expires April 29, 2018 [Page 5] INTERNET DRAFT Event Service in ANI October 30, 2017 Events are closely related to the information. IS module handles how to efficiently save and retrieve information for AFs across the network according to announced events. Any information that is published by AFs will be sent to the IS module, and the IS module decides where to store the information and how to index and retrieve it. The IS module defines a syntax to index information, not only generating the hash index value (e.g. a key) for the information, but also mapping the hash index to a certain network node in ANI. When data information is published by an AF (i.e. publishing events), it will be sent to the IS module. The IS module calculates its hash index (i.e. the key) and the location responsible for storing the information. The IS module confirms with the node chosen to store the information by negotiation. After that, if available, the IS module sends the information to there. When data information has to be retrieved (i.e. subscribing events), a request from an AF will be also received by the IS module. IS module, by parsing the request, identifies the hash index of the information, which tells the location of the information as well. After that, the IS module requests the desired information and retrieves it once it is ready. IS module can reuse distributed databases and key value stores like NoSQL, Cassandra, DHT technologies. storage and retrieval of information are all event-driven responsible by the EQ module. 4.4 Interface between IS and EQ Modules EQ and IS modules are correlated. When an AF publishes information, not only an publishing event is translated and sent to EQ module, but also the information is indexed and stored simultaneously. Similarly, when an AF subscribes information, not only subscribing event is triggered and sent to EQ module, but also the information will be retrieved by IS module at the same time. 5. Integration with ANI There are several alternatives to integrate the ES module into the current ANI. 5.1 ES Module as an ASA With this approach, ES module is an ASA as a third-party application implemented in the user space on the network node. In this case, ES X. Xiao Expires April 29, 2018 [Page 6] INTERNET DRAFT Event Service in ANI October 30, 2017 module will be integrated with individual AFs. Multiple ES module instances may existing on the same network node but serve for specific AFs. The node architecture is illustrated in Figure 2. +--------------------------------------------------------+ | +--------Autonomic Function 1-------+ | | +-----------+ | +------------+ +------------+ | | | | | | | | | Event | | | | | ASAs | | | ASA-1 | | Service | | | | | | | | | | ASA | | | | +-----------+ | +------------+ +------------+ | | | +-----------------------------------+ | | ^ ^ ^ | | - - | - - API level - -| - - - - - - |- - - | | V V V | |--------------------------------------------------------| | ANI (BRSKI, GRASP, ACP) | |--------------------------------------------------------| | Basic Operating System Functions | +--------------------------------------------------------+ Figure 2. An Example of ES Module as an ASA Users of the ANI can benefit from the flexibility of this approach where the ES module can be developed by the user who may have specific preferences on event distribution and information storage. For example, one user may prefer a centralized way for information storage while a distributed way for event queues. However, bringing ES module as a customized ASA may ruin the integrity of the ANI. First of all, since individual users will have to implement the ES modules in their own ways, this increases the difficulty to use the ANI, which was supposed to be autonomic. Second, co-existences of multiple private ES module instances may have conflicts and consume unnecessary resource. Third, at system level, optimizing and coordinating those multiple private ES module instances are also challenging. 5.2 ES Module as an Core Component in ANI This approach turns the ES module as must-implement ASA in the kernel space on the network node, together included in ANI itself. In this case, ES module is shared by different AFs and how to realize such a module is transparent to individual AF. This is illustrated in Figure. 3. X. Xiao Expires April 29, 2018 [Page 7] INTERNET DRAFT Event Service in ANI October 30, 2017 +-------------------------------------------------+ | +-----------+ +-----------+ +-----------+ | | | | | | | | | | | ASA-1 | | ASA-2 | | ASA-3 | | | | | | | | | | | +-----------+ +-----------+ +-----------+ | | ^ ^ ^ | | - - | - - API Level -| - - - - - | - | | V V V | |-------------------------------------------------| | +-------------------+ | | | Event Service | | | +-------------------+ | | ANI (BRSKI, GRASP, ACP) | |-------------------------------------------------| | Basic Operating System Functions | +-------------------------------------------------+ Figure 3. An Example of ES Module as a Core Component in ANI Specifically, all asynchronous communications requests from different AFs are handled by a common ES module where events are classified, prioritizations are given, and information published are distributed and stored. Different event queues are created as needed, and event matching is done by the ES module. In this way, the common ES module across every network nodes in the ANI domain forms a distributed event service system. APIs will be provided to the user space and technical details are transparent to AFs. This may involve slight extensions of the current ANI by integrating the ES module. For example, the API set of GRASP [I-D.ietf-anima- grasp-api] will need to be extended with new APIs to access ES module. GRASP itself will also need to be extended for ES module signaling. 6 Security Considerations TBD. X. Xiao Expires April 29, 2018 [Page 8] INTERNET DRAFT Event Service in ANI October 30, 2017 7 IANA Considerations TBD. 8 References [RFC7575] Behringer, M., "Autonomic Networking: Definitions and Design Goals", RFC 7575, June 2015 [I-D.behringer-anima-autonomic-control-plane] Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "AnAutonomic Control Plane", draft-behringer-anima- autonomiccontrol-plane-12 (Standard Track), October 2017. [I-D.behringer-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Liu, B., Jeff, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-behringer-animareference- model-05, October 2017. [I-D.du-anima-an-intent] Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. Behringer, "ANIMA Intent Policy and Format", draft- duanima-an-intent-05 (work in progress), February 2017. [I-D.ietf-anima-grasp] Bormann, D., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf- animagrasp-15 (Standard Track), October 2017. [I-D.liu-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", draft-liu-anima-grasp-api-05 (Standard Track), October 2017. [I-D.liu-anima-grasp-distribution] Liu, B. and S. Jiang, "Information Distribution over GRASP", draft-liu-anima-grasp-distribution-04, May 2017. X. Xiao Expires April 29, 2018 [Page 9] INTERNET DRAFT Event Service in ANI October 30, 2017 Authors' Addresses Xun Xiao German Research Center Huawei technologies Riesstr. 25, 80992, Muenchen, Germany Emails: xun.xiao@huawei.com Artur Hecker German Research Center Huawei technologies Riesstr. 25, 80992, Muenchen, Germany Emails: artur.hecker@huawei.com Zoran Despotovic German Research Center Huawei technologies Riesstr. 25, 80992, Muenchen, Germany Emails: zoran.despotovic@huawei.com X. Xiao Expires April 29, 2018 [Page 10]