This section describes how an Autonomic Network is managed and programmed.
Autonomic management usually coexists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. Examples of overlap are:
Autonomic functions can use traditional methods and protocols (e.g., SNMP and the Network Configuration Protocol (NETCONF)) to perform management tasks, inside and outside the ACP.
Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols.
Traditional functions can use the ACP, for example, if reachability on the data plane is not (yet) established.
The autonomic Intent is defined at a high level of abstraction. However, since it is necessary to address individual managed elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). For example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules as well as the monitoring be executed through SNMP and MIBs.
Conflict can occur between autonomic default behavior, autonomic Intent, and traditional management methods. Conflict resolution is achieved in autonomic management through prioritization [RFC 7575
]. The rationale is that manual and node-based management have a higher priority than autonomic management. Thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command-line interfaces.
Intent is not covered in the current implementation specifications. This section discusses a topic for further research.
This section gives an overview of Intent and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., Policy Core Information Model (PCIM)) and in other Standards Development Organizations (SDOs) (e.g., the Distributed Management Task Force (DMTF)).
Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC 7575
]. Intent should be limited to high-level guidance only; thus, it does not directly define a policy for every network element separately.
Intent can be refined to lower-level policies using different approaches. This is expected in order to adapt the Intent to the capabilities of managed devices. Intent may contain role or function information, which can be translated to specific nodes [RFC 7575
]. One of the possible refinements of the Intent is using Event-Condition-Action (ECA) rules.
Different parameters may be configured for Intent. These parameters are usually provided by the human operator. Some of these parameters can influence the behavior of specific autonomic functions as well as the way the Intent is used to manage the autonomic domain.
Intent is discussed in more detail in [ANIMA-INTENT
]. Intent as well as other types of information are distributed via GRASP; see [GRASP-DISTRIB
Aggregated reporting is not covered in the current implementation specifications. This section discusses a topic for further research.
An Autonomic Network should minimize the need for human intervention. In terms of how the network should behave, this is done through an autonomic Intent provided by the human administrator. In an analogous manner, the reports that describe the operational status of the network should aggregate the information produced in different network elements in order to present the effectiveness of autonomic Intent enforcement. Therefore, reporting in an Autonomic Network should happen on a network-wide basis [RFC 7575
Multiple simultaneous events can occur in an Autonomic Network in the same way they can happen in a traditional network. However, when reporting to a human administrator, such events should be aggregated to avoid notifications about individual managed elements. In this context, algorithms may be used to determine what should be reported (e.g., filtering), how it should be reported, and how different events are related to each other. Besides that, an event in an individual element can be compensated by changes in other elements to maintain a network-wide target that is described in the autonomic Intent.
Reporting in an Autonomic Network may be at the same abstraction level as Intent. In this context, the aggregated view of the current operational status of an Autonomic Network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, some events may need to be addressed by the actions of a human administrator.
Feedback loops are required in an Autonomic Network to allow the intervention of a human administrator or central control systems while maintaining a default behavior. Through a feedback loop, an administrator must be prompted with a default action and has the possibility to acknowledge or override the proposed default action.
Unidirectional notifications to the Network Operations Center (NOC) that do not propose any default action and do not allow an override as part of the transaction are considered like traditional notification services, such as syslog. They are expected to coexist with autonomic methods but are not covered in this document.
Control loops are not covered in the current implementation specifications. This section discusses a topic for further research.
Control loops are used in Autonomic Networking to provide a generic mechanism to enable the autonomic system to adapt (on its own) to various factors that can change the goals that the Autonomic Network is trying to achieve or how those goals are achieved. For example, as user needs, business goals, and the ANI itself changes, self- adaptation enables the ANI to change the services and resources it makes available to adapt to these changes.
Control loops operate to continuously observe and collect data that enables the autonomic management system to understand changes to the behavior of the system being managed and then provide actions to move the state of the system being managed toward a common goal. Self-adaptive systems move decision making from static, pre-defined commands to dynamic processes computed at runtime.
Most autonomic systems use a closed control loop with feedback. Such control loops should be able to be dynamically changed at runtime to adapt to changing user needs, business goals, and changes in the ANI.
] defines a conceptual outline for an API for the GeneRic Autonomic Signaling Protocol (GRASP). This conceptual API is designed for ASAs to communicate with other ASAs through GRASP. Full Standards Track API specifications are not covered in the current implementation specifications.
Most APIs are static, meaning that they are pre-defined and represent an invariant mechanism for operating with data. An Autonomic Network should be able to use dynamic APIs in addition to static APIs.
A dynamic API retrieves data using a generic mechanism and then enables the client to navigate the retrieved data and operate on it. Such APIs typically use introspection and/or reflection. Introspection enables software to examine the type and properties of an object at runtime, while reflection enables a program to manipulate the attributes, methods, and/or metadata of an object.
APIs must be able to express and preserve the semantics of data models. For example, software contracts [Meyer97
] are based on the principle that a software-intensive system, such as an Autonomic Network, is a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations that interacting components must respect. This typically includes specifying:
pre-conditions that must be satisfied before the method can start execution
post-conditions that must be satisfied when the method has finished execution
invariant attributes that must not change during the execution of the method
Data models are not covered in the current implementation specifications. This section discusses a topic for further research.
The following definitions of "data model" and "information model" are adapted from [SUPA-DATA
An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. In contrast, a data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol.
The utility of an information model is to define objects and their relationships in a technology-neutral manner. This forms a consensual vocabulary that the ANI and ASAs can use. A data model is then a technology-specific mapping of all or part of the information model to be used by all or part of the system.
A system may have multiple data models. Operational Support Systems, for example, typically have multiple types of repositories, such as SQL and NoSQL, to take advantage of the different properties of each. If multiple data models are required by an autonomic system, then an information model should be used to ensure that the concepts of each data model can be related to each other without technological bias.
A data model is essential for certain types of functions, such as a Model-Reference Adaptive Control Loop (MRACL). More generally, a data model can be used to define the objects, attributes, methods, and relationships of a software system (e.g., the ANI, an autonomic node, or an ASA). A data model can be used to help design an API, as well as any language used to interface to the Autonomic Network.