ANIMA Intent Policy and Format
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
duzongpeng@huawei.com
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
jiangsheng@huawei.com
Federal University of Rio Grande do Sul
Porto Alegre
Brazil
jcnobre@inf.ufrgs.br
Alcatel Lucent
Route de Villejust
Nozay 91620
France
laurent.ciavaglia@alcatel-lucent.com
Cisco Systems
Building D, 45 Allee des Ormes
Mougins 06250
France
mbehring@cisco.com
Operations and Management
ANIMA WG
Autonomic Networking, Intent
One of the goals of autonomic networking is to simplify the
management of networks by human operators. Intent Based Networking (IBN)
is a possible approach to realize this goal. With IBN, the operator
indicates to the network what to do (i.e. her intent) and not how to do
it. In the field of Policy Based Management (PBM), the concept of intent
is called a declarative policy. This document proposes a refinement of
the intent concept initially defined in for
autonomic networks by providing a more complete definition, a life-cycle,
some use cases and a tentative format of the ANIMA Intent Policy.
One of the goals of autonomic networking is to simplify the
management of networks by human operators. Intent Based Networking (IBN)
is a possible approach to realize this goal. With IBN, the operator
indicates to the network what to do (i.e. her intent) and not how to do
it. In the field of Policy Based Management (PBM), the concept of intent
is called a declarative policy. This document proposes a refinement of
the intent concept initially defined in for
autonomic networks by providing a more complete definition, a life-cycle,
some use cases and a tentative format of the ANIMA Intent Policy.
An Autonomic Network must be able to operate with minimum
intervention from human operators. However, it still needs to receive
some form of guidance (e.g. ANIMA Intent Policies) in order to fulfil
the operator requirements.
In PBM, the Policy Continuum defines the levels at which the policies
are defined (policy creation point), consumed (policy execution point)
and translated (policy refinement point). Using PBM, the operator can
manage the network as a whole, and does not need to configure each
individual devices in the network. The transformation of the
high-level/abstract policies to the low-level device configurations is
realized automatically by a set of functions usually regrouped inside a
Policy Engine.
The use of policies and in particular of declarative policies assumes
that the entities in the Autonomic Network receiving the ANIMA Intent
Policy are capable of processing (refining and/or executing) the policy
with no ambiguity. For that, the format of the ANIMA Intent Policy and
the hierarchy of policy levels must be specified.
This document proposes a base format of the ANIMA Intent Policy.
Application-specific extensions of the base format should be defined on
a per need basis in dedicated documents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in when they appear in ALL CAPS. When these words are
not in ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as key words.
A feature or function which
requires no configuration, and can derive all required information
either through self-knowledge, discovery or through Intent.
A node which employs exclusively
Autonomic Functions.
A non-autonomic node, i.e., a node which
employs some non-autonomic functions.
A network containing exclusively
Autonomic Nodes. It may contain one or several Autonomic
Domains.
A collection of autonomic nodes that
instantiate the same Intent.
An agent implemented on an
Autonomic Node which implements an Autonomic Function.
An abstract, high-level policy used to operate
the network.
A declarative type of policy used
in Autonomic Networks.
Intent that is used to manage
the network infrastructure. (definition to be revised)
Intent that is used to intervene the
network services running over the network infrastructure.
(definition to be revised)
In the scope of autonomic networking, the definition of intent can be
found in , in which
intent is described as "an abstract, declarative, high-level policy used
to operate an autonomic domain, such as an enterprise network."
An Autonomic Network will comprise multiple ANIMA Intent Policies.
Different ANIMA Intent Policies will be "interpreted" by different
entities in autonomic networks, and the "level" of understanding of the
intent will impact how the intent will be presented to this entity. So
there should be "intermediate" mechanisms/functions that cater for the
intent translation continuum across the heterogeneity (in policy
capabilities) of the network entities. Also, ANIMA Intent Policies will
possibly overlap and this overlapping should be managed (e.g., avoid
conflicts, resolve applicable policies in context).
This section describes a top-down flow about how an ANIMA Intent Policy
is derived through an autonomic network.
Business goals: The network owner wants the network to follow
some business goals. These goals are initially not formalised in a particular way.
A Domain Specific Language (DSl) is used to format these goals in a form subsequent
components can interpret and process.
ANIMA Intent Policy (or Intent): Is the formalisation of business goals so that computer
can deal with them. It is encoded as a file (or several files), and
this file must be "given to the network".
Ingestion: The Intent file(s) get instantiated on an autonomic
node. On a particular node, an intent file is "ingested". After
that, it needs to be distributed.
Intent Distribution: Intent is flooded to all nodes in a network.
Every node has a copy of the original "Intent" file(s), without
modification. Each node re-distributes the original Intent files,
without modification. Therefore, Intent is optional and transitive
in nature. The Intent files must now be interpreted by each
node.
Editor's note: need to better defined meaning of "optional" and "transitive".
Intent splitting (on each node): Intent is split into sections,
one for the ANI itself, others for specific Autonomic Functions.
ASAs are notified if there is new Intent for them. Some intent
sections may not apply to a particular node. Now each component of a
node (ANI, all ASAs) know their respective Intent.
Intent Interpretation (on each node, by each function): The ANI
as well as all ASAs on a node interpret their respective Intent section(s). It
gets translated into a "target configuration", taking into account
local state. For this translation, it may be necessary for ASAs to
communicate with ASAs on other nodes, to pass on resources (IP
addresses), to negotiate, etc. All such communications may be
triggered by Intent, but the communications themselves are not
Intent. (NB: This interpretation could also be done centrally, and
the resulting configurations distributed; This is of course an option, but
out the scope of ANIMA.) After interpreting Intent locally on each
node, each node has target configlet to apply.
Editor's note: define new terms such as "configlet"
Conflict Resolution with non-autonomic management (on each node):
The target configlet resulting from Intent has the lowest priority;
meanwhile, any other management method (CLI, NETCONF, etc.)
overrides Intent.
Conflict Resolution between autonomic components (on each node):
Each autonomic function needs to register with a "conflict
resolution function" which parameters it modifies; in case of
conflict, the conflict resolution function takes a decision and
feeds that back to the autonomic functions. This may modify the
target configlet.
Applying the target configlet.
Feedback loops to NOC: The NOC needs to know about certain
conditions, such as conflicts with non-autonomic management. Not all
conflicts can be resolved automatically, so they may require NOC
actions. Undesirable states (deviations from expected default
behaviour) may have to be communicated too. To some extent, Intent
itself can specify which conditions should trigger feedback loops to
the NOC. Feedback loops may happen at other phases as well (ex:
8).
In this section, some use cases are introduced to clarify the concept
of ANIMA Intent Policy.
A typical ANIMA Intent Policy can be found in . It is suggested that the
prefix lengths for the CSG, ASG, RSG (different roles in IP RAN) can
be assigned as an "intent". The information carried in the intent are
distributed in the autonomic domain to influence the detail
configurations on each autonomic node.
Intent could perfectly well cover a high level policy such as "all
nodes of type x do this; type y does that". However, it should not be
abused. For example, policies like "node 17: here is your CLI; node
23: here is your CLI; node 37: here is your CLI" should not be
considered as an intent.
This example is about "arranging VM guest distribution". The
autonomic network is supposed to be able to monitor the CPU/power
utilization on each host machine, and control the status of each host
machine (e.g. turn on/off). The operator may have an intent "there
should be enough hosts to keep CPU utilization less than 70%", and
also another one "there are few enough hosts powered so that
electricity isn't wasted".
These two intents can both influence the ASA responsible for
controlling how many hosts are needed. The decision is made according
to multiple factors, including network environment and intents entered
by the operators.
In this case, the first intent should have a higher priority than
the later one. The two intents should be analyzed and coordinated to
ensure the ASA act rightly.
Autonomic Network of Operator A is composed of Autonomic Function
Agents such as load balancing (LB_AFA) and energy saving (ES_AFA).
Operator A wants to limit the proportion of links loaded over a
certain threshold and thus defines an Intent to activate load
balancing if the load is superior to 0.6 on more than 30% of the
links.
Meanwhile, operator A wants different load balancing policies per
(technology, administrative, topology) domain. Let's consider a
metropolitan network domain and a core network domain, or different LB
policy for border routers than interior routers. For the metropolitan
network domain, Operator A defines an Intent to minimize the link load
variance. For the core network domain, Operator A applies the
previously defined intent (activate load balancing if the load is
superior to 0.6 on more than 30% of the links).
The intents will be distributed to the right network domain, and
take effect after being interpreted and coordinated, and it is easy to
change them without the need to configure every device manually.
In the development of ASAs, some network-level parameters for a
specific autonomic function can also be defined in an ANIMA Intent
Policy. GRASP is a candidate protocol for distributing and synchronizing
these ASA parameters (or ANIMA Intent Policies) after the definition by
human administrators.
{Editor Notes: it is still at a preliminary stage, and the owner of
an autonomic function should decide what is needed when the autonomic
function is developed. A better understanding of what Intent can and
cannot contain requires more research and experience. At this moment we
include any item (parameter, policy, etc) which should be flooded across
the network.}
The Autonomic Networks are supposed to be self-managed. It includes
managing the network infrastructure, and also the network services that
are running over the network infrastructure. However, the network
services have different features against network administration, as
listed below. Hence, it may be better introduce a hierarchy and to
organize them into separated Administrative (Network) Intent and Service
Intent.
A Service Intent has a different scope than the Administrative
Intent because only the nodes related to the service need to know
this intent. Although it may only affect a few nodes, the Service
Intent may also be propagated domain wide.
A Service Intent may have a limited lifetime, while the
Administrative Intents are normally permanent although the content
of the Administrative Intent may be updated from time to time.
There could be many Service Intents in the Autonomic Domain.
The distribution of intent can be done by using GRASP and ACP . The operator can
issue a new intent or modify an intent through any authorized nodes in
the autonomic network. After that, the intent will be flooded to all the
nodes in the autonomic network, or more accurately, to a group of nodes
that are influenced by that intent.
Another scenario is that when a new node joins into an autonomic
domain, it may receive an intent from its neighbor.
As mentioed in Section 3.1, the intent may consist of different
parts, so that partial updating should also be supported. Detailed
mechanisms for intent distribution can be found in .
Every Autonomic Node in the Autonomic domain should own an intent
with the same version. Any updating of intent, even partial updating,
will cause the change of the intent version number. To ensure all the
nodes own the same intent, the nodes should be able to communicate with
neighbors in the domain about the version of the intent. If its neighbor
has a newer version of intent, it can request an intent update.
If the operator issues a new intent or modify intents, it will
trigger a domain level updating of intent. Nodes in the Autonomic
Network should be aware which domain it belongs to, and accept intent
for that domain.
{Editor Notes: talk about the questions as follows. When/on which
triggers are intents generated, updated? How the domain(s) are defined
and recognized (if I am an AFA, how do I know I am part of domain x, y
or z...?). }
After receiving an intent, the Autonomic Node should confirm whether
it is acceptable, according to the domain name information, intent
version, signature, and so on. If it passes the validation, an intent
interpretation module will be involved to decide which ASAs will be
involved in. Coordination of intents may be needed before the execution
of the policies interpreted from the intent.
{Editor Notes: talk about the questions as follows. How the AFAs
receive, understand and react to an intent? }
{Editor Notes: It is still remaining an open issue for the way that
intent may be organized. Should the intent be a single one in a given AN
domain with a hierarchical version, or multiple intents, each of which
targets different Autonomic Service Agent? For now, the below text takes
the later approach.}
This section proposes a uniform intent format. It uses the tag-based
format.
The root tag for the Autonomic
Network Intent.
It indicates the intent type, which is
associated with a specific Autonomic Service Agent.
It indicates the domain of the
Autonomic Network. It is also the scope of the Autonomic Network
Intent.
It indicates the version of the ANIMA
Intent Policy. This is an important feature for synchronization.
The version of the model used to define
the intent.
The name of the intent which describes the
intent for human operators.
The signature is used as a security
mechanism to provide authentication, integrity, and
non-repudiation.
The timestamp of the creation of the intent
using the format supported by the IETF [TBC].
The lifetime in which the intent may be
observed. A special case of the lifetime is the definition of
permanent intents.
It contains the main information of the
intent. It may include objects, policies, goals and configuration
data. The detailed contents and formats should be defined under
their specific situations by documents that specifies the Autonomic
Service Agent. Within the content, there may be sub_intents.
{Editor Notes: JSON is one of the term candidates for the Autonomic
Network Intent format.}
Relevant security issues are discussed in . The ANIMA Intent Policy requires strong
security environment from the start, because it would be great risk if
the ANIMA Intent Policy had been maliciously tampered. The Autonomic
Intent should employ a signature scheme to provide authentication,
integrity, and non-repudiation.
This document defines one new format. The IANA is requested to
establish a new assigned list for it.
The authors of this draft would like to thank the following persons
for their valuable feedback and comments: Bing Liu, Brian Carpenter,
Michael Richardson, Joel M. Halpern, John Strassner, and Jason
Coleman.
This document was produced using the xml2rfc tool .
draft-du-anima-an-intent-00: original version, 2015-06-11.
draft-du-anima-an-intent-01: add intent use case section, add some
elements for the format section, and coauthor Jeferson Campos Nobre and
Laurent Ciavaglia, 2015-07-06.
draft-du-anima-an-intent-02: add the intent concept section, and some
other sections, 2015-10-14.
draft-du-anima-an-intent-03: modify the use case section, and add
some other contents, 2016-03-17.
draft-du-anima-an-intent-04: modify the use case section, add the
procedure section, and reorganize contents, 2016-07-08.