[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/