Internet DRAFT - draft-xiao-anima-event-service
draft-xiao-anima-event-service
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]
