<?xml version="1.0" encoding="UTF-8"?><?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-anima-reference-model-10" category="info"> category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" number="8993" consensus="true">
<!-- xml2rfc v2v3 conversion 2.47.0 -->
<front>
<title abbrev="AN Reference Model">A abbrev="Reference Model for Autonomic Networking">A Reference Model for Autonomic Networking</title>
<seriesInfo name="RFC" value="8993"/>
<author role="editor" fullname="Michael H. Behringer" initials="M." surname="Behringer">
<address>
<email>Michael.H.Behringer@gmail.com</email>
</address>
</author>
<author surname="Carpenter" initials="B. E." initials="B" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"/>
<address>
<postal>
<street>Department
<street>School of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region/>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Toerless Eckert" initials="T." surname="Eckert">
<organization>Futurewei Technologies Inc.</organization> USA</organization>
<address>
<postal>
<street>2330 Central Expy</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
<country>United States of America</country>
</postal>
<email>tte@cs.fau.de</email>
<email>tte+ietf@cs.fau.de</email>
</address>
</author>
<author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
<organization>Nokia</organization>
<address>
<postal>
<street>Villarceaux</street>
<code>91460</code>
<city>Nozay</city>
<region/>
<country>FR</country>
<country>France</country>
</postal>
<email>laurent.ciavaglia@nokia.com</email>
</address>
</author>
<author fullname="Jeferson fullname="Jéferson Campos Nobre" initials="J.C." initials="J" surname="Nobre">
<organization>University
<organization abbrev="UFRGS">Federal University of Vale do Rio dos Sinos</organization> Grande do Sul (UFRGS)</organization>
<address>
<postal>
<street>Av. Unisinos, 950</street>
<city>São Leopoldo</city> Bento Gonçalves, 9500</street>
<city>Porto Alegre</city>
<region>RS</region>
<code>91501-970</code>
<country>Brazil</country>
</postal>
<email>jcnobre@unisinos.br</email>
<email>jcnobre@inf.ufrgs.br</email>
</address>
</author>
<date day="23" month="November" year="2018"/> month="May" year="2021"/>
<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>
<keyword>autonomous operation</keyword>
<keyword>self-management</keyword>
<keyword>infrastructure</keyword>
<keyword>intent</keyword>
<keyword>autonomic control plane</keyword>
<keyword>autonomic networking</keyword>
<abstract>
<t>
This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>
<t>The document "Autonomic Networking - Definitions and Design Goals" "<xref target="RFC7575" format="title"/>" <xref target="RFC7575"/> target="RFC7575" format="default"/> explains the fundamental concepts behind Autonomic Networking, Networking and defines the relevant terms in this space, as well as space and a high level high-level reference model. <xref target="RFC7576"/> target="RFC7576" format="default"/> provides a gap analysis between traditional and autonomic approaches. </t>
<t>This document defines this reference model with more detail, detail to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner. </t>
<t>As discussed in <xref target="RFC7575"/>, target="RFC7575" format="default"/>, the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach. </t>
<t>For example, it is possible in an existing, non-autonomic network to enrol enroll devices in a traditional way, way to bring up a trust infrastructure with certificates. This trust infrastructure could then be used to automatically bring up an Autonomic Control Plane (ACP), (ACP) and run traditional network operations over the secure and self-healing ACP. See <xref target="I-D.ietf-anima-stable-connectivity"/> target="RFC8368" format="default"/> for a description of this use case.</t>
<t>The scope of this model is therefore limited to networks that are to some extent managed by skilled human operators, loosely referred to as "professionally managed" networks. Unmanaged networks raise additional security and trust issues that this model does not cover.</t>
<t>This document describes a first, simple, implementable the first phase of an Autonomic Networking solution. solution that is both simple and implementable. It is expected that the experience from this phase will be used in defining updated and extended specifications over time. Some topics are considered architecturally in this document, document but are not yet reflected in the implementation specifications. They are marked with an (*).</t>
</section>
<!-- intro -->
<section anchor="network" title="The Network View"> numbered="true" toc="default">
<name>Network View</name>
<t>This section describes the various elements in a network with autonomic functions, functions and explains how these entities work together, together on a high level. Subsequent sections explain the detailed inside view for each of the autonomic network Autonomic Network elements, as well as the network functions (or interfaces) between those elements. </t>
<t><xref target="network-view"/> target="network-view" format="default"/> shows the high level high-level view of an Autonomic Network. It consists of a number of autonomic nodes, which interact directly with each other. Those autonomic nodes provide a common set of capabilities across the network, called the "Autonomic Networking Infrastructure" (ANI). Infrastructure (ANI)". The ANI provides functions like naming, addressing, negotiation, synchronization, discovery discovery, and messaging. </t>
<t>Autonomic functions typically span several, possibly all all, nodes in the network. The atomic entities of an autonomic function are called the "Autonomic Service Agents" (ASA), Agents (ASAs)", which are instantiated on nodes. </t>
<figure anchor='network-view' title="High level view anchor="network-view">
<name>High-Level View of an Autonomic Network">
<artwork> Network</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : Autonomic Function 1 : :
: ASA 1 : ASA 1 : ASA 1 : ASA 1 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : :
: +- - - - - - - - - - - - - - + :
: : Autonomic Function 2 : :
: : ASA 2 : ASA 2 : :
: +- - - - - - - - - - - - - - + :
: : :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: Autonomic Networking Infrastructure :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+ : +--------+ : +--------+ : +--------+
| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
+--------+ : +--------+ : +--------+ : +--------+
</artwork>
]]></artwork>
</figure>
<t>In a horizontal view, autonomic functions span across the network, as well as the Autonomic Networking Infrastructure. ANI. In a vertical view, a node always implements the ANI, plus it may have one or several Autonomic Service Agents. ASAs. ASAs may be standalone, standalone or use other ASAs in a hierarchical way.</t>
<t>The Autonomic Networking Infrastructure (ANI) therefore
<t>Therefore, the ANI is the foundation for autonomic functions. </t>
</section>
<!-- network -->
<section anchor="element" title="The Autonomic numbered="true" toc="default">
<name>Autonomic Network Element"> Element</name>
<t>This section explains the general architecture of an Autonomic Network Element element (<xref target="element-arch"/>), target="element-arch" format="default"/>), how it tracks its surrounding environment in an Adjacency Table adjacency table (<xref target="adjacency-table"/>), target="adjacency-table" format="default"/>), and the state machine which that defines the behaviour behavior of the network element (<xref target="state-machine"/>), target="state-machine" format="default"/>),
based on that adjacency table.</t>
<section anchor="element-arch" title="Architecture"> numbered="true" toc="default">
<name>Architecture</name>
<t>This section describes an autonomic network Autonomic Network element and its internal architecture. The reference model explained in the document "<xref target="RFC7575" format="title"/>" <xref target="RFC7575">"Autonomic Networking - Definitions and Design Goals"</xref> target="RFC7575" format="default"/> shows the sources of information that an autonomic service agent ASA can leverage: Self-knowledge, self-knowledge, network knowledge (through discovery), Intent (see <xref target="intent"/>), target="intent" format="default"/>), and feedback loops. There are two levels inside an autonomic node: the level of Autonomic Service Agents, ASAs and the level of the Autonomic Networking Infrastructure, ANI, with the former using the services of the latter. <xref target="ref_model"/> target="ref_model" format="default"/> illustrates this concept.
</t>
<t>
<figure anchor='ref_model' title="Model anchor="ref_model">
<name>Model of an autonomic node">
<artwork> Autonomic Node</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+------------------------------------------------------------+
| |
| +-----------+ +------------+ +------------+ |
| | Autonomic | | Autonomic | | Autonomic | |
| | Service | | Service | | Service | |
| | Agent 1 | | Agent 2 | | Agent 3 | |
| +-----------+ +------------+ +------------+ |
| ^ ^ ^ |
| - - | - - API level - -| - - - - - - - |- - - |
| V V V |
|------------------------------------------------------------|
| Autonomic Networking Infrastructure |
| - Data structures (ex: certificates, peer information) |
| - Generalized Autonomic Control Plane (GACP) |
| - Autonomic Node Addressing node addressing and naming |
| - Discovery, negotiation and synchronisation synchronization functions |
| - Distribution of Intent and other information |
| - Aggregated reporting and feedback loops |
| - Routing |
|------------------------------------------------------------|
| Basic Operating System Functions |
+------------------------------------------------------------+
</artwork>
]]></artwork>
</figure>
</t>
<t>The Autonomic Networking Infrastructure ANI (lower part of <xref target="ref_model"/>) target="ref_model" format="default"/>) contains node specific node-specific data structures, for example structures (for example, trust information about itself and its peers, peers) as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic, generic and support a variety of Autonomic Service Agents ASAs (upper part of <xref target="ref_model"/>). target="ref_model" format="default"/>). It contains addressing and naming of autonomic nodes, discovery, negotiation and synchronisation synchronization functions, distribution of information, reporting and reporting, feedback loops, as well as and routing inside the Autonomic Control Plane.</t> ACP.</t>
<t>The Generalized Autonomic Control Plane ACP (GACP) is the summary of all interactions of the Autonomic Networking Infrastructure ANI with other nodes and services. A specific implementation of the GACP is referred to here as the Autonomic Control Plane (ACP), ACP and described in <xref target="I-D.ietf-anima-autonomic-control-plane"/>.</t> target="RFC8994" format="default"/>.</t>
<t>The use cases of "Autonomics" such (such as self-management, self-optimisation, etc, self-optimization, etc.) are implemented as Autonomic Service Agents. ASAs. They use the services and data structures of the underlying Autonomic Networking Infrastructure, ANI, which should be self-managing. </t>
<t>The "Basic Basic Operating System Functions" Functions (lower part of <xref target="ref_model" format="default"/>) include the "normal OS", including normal OS (e.g., the network stack, stack and security functions, etc. functions). </t>
<t>Full AN Autonomic Network (AN) nodes have the full Autonomic Networking Infrastructure, ANI, with the full functionality described in this document. At a later stage stage, the ANIMA Working Group may define a scope for constrained nodes with a reduced ANI and well-defined minimal functionality. They These are currently out of scope. </t>
</section>
<!-- element-architecture -->
<section anchor="adjacency-table" title="The Adjacency Table">
<!-- old section 5 start --> numbered="true" toc="default">
<name>Adjacency Table</name>
<t>Autonomic Networking is based on direct interactions between devices of a domain. The Autonomic Control Plane (ACP) ACP is normally constructed on a hop-by-hop basis. Therefore, many interactions in the ANI are based on the ANI adjacency table. There are interactions that provide input into the adjacency table, table and other interactions that leverage the information contained in it.</t>
<t>The ANI adjacency table contains contains, at a minimum, information about adjacent autonomic nodes, at a minimum: node-ID, nodes: Node-ID, IP address in data plane, IP address in ACP, domain, and certificate. An autonomic node maintains this adjacency table up to date. The adjacency table only contains information about other nodes that are capable of Autonomic Networking; non-autonomic nodes are normally not tracked here.
However, the information is tracked independently of the status of the peer nodes; specifically, it the adjacency table contains information about non-enrolled nodes, nodes of the same and other domains. The adjacency table may contain information about the validity and trust level of the adjacent autonomic nodes.</t>
<t>The adjacency table is fed by the following inputs:
<list style="symbols">
<t>Link local
</t>
<ul spacing="normal">
<li>Link-local discovery: This interaction happens in the data plane, using IPv6 link local link-local addressing only, because this addressing type is itself autonomic. This way the nodes node learns about all autonomic nodes around itself. The related standards track Standards Track documents (<xref target="I-D.ietf-anima-grasp"/>, target="RFC8990" format="default"/>, <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, target="RFC8995" format="default"/>, and <xref target="I-D.ietf-anima-autonomic-control-plane"/>) target="RFC8994" format="default"/>) describe in detail how link local link-local discovery is used.</t>
<t>Vendor re-direct: used.</li>
<li>Vendor redirect: A new device may receive information on where its home network is through a vendor based vendor-based Manufacturer Authorized Signing Authority (MASA, see (MASA) (see <xref target="masa"/>) re-direct; target="masa" format="default"/>) redirect; this is typically a routable address. </t>
<t>Non-autonomic </li>
<li>Non-autonomic input: A node may be configured manually with an
autonomic peer; it could learn about autonomic nodes through DHCP
options, DNS, and other non-autonomic mechanisms. Generally Generally, such
non-autonomic mechansims mechanisms require some administrator
intervention. The key purpose is to by-pass bypass a non-autonomic device
or network. As this pertains to new devices, it is covered in appendix A Appendices
<xref target="RFC8995" sectionFormat="bare" section="A"/> and B <xref target="RFC8995" sectionFormat="bare" section="B"/> of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>
</list></t> target="RFC8995"/>.</li>
</ul>
<t>The adjacency table is defining defines the behaviour behavior of an autonomic node:
<list style="symbols">
<t>If
</t>
<ul spacing="normal">
<li>If the node has not bootstrapped into a domain (i.e., doesn't have a domain certificate), it rotates through all nodes in the adjacency table that claim to have a domain, domain and will attempt bootstrapping through them, one by one. One possible response is a re-direct redirect via a vendor MASA, which will be entered into the adjacency table (see second bullet above). See <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> target="RFC8995" format="default"/> for details. </t>
<t>If </li>
<li>If the adjacent node has the same domain, it will authenticate that adjacent node and, if successful, establish the Autonomic Control Plane (ACP). ACP. See <xref target="I-D.ietf-anima-autonomic-control-plane"/>.</t>
<t>Once target="RFC8994" format="default"/>.</li>
<li>Once the node is part of the ACP of a domain, it will use GRASP <xref target="I-D.ietf-anima-grasp"/> target="RFC8990" format="default"/> to find Registrar(s) the registrar(s) of its domain and potentially other services.</t>
<t>If services.</li>
<li>If the node is part of an ACP and has discovered at least one Registrar registrar in its domain via GRASP, it will start the "join assistant" ASA, join proxy ASA and act as a join assistant proxy for neighboring nodes that need to be bootstrapped. See <xref target="join-assitant"/> target="join-assitant" format="default"/> for details. </t>
<t>Other behaviours </li>
<li>Other behaviors are possible, for example example, establishing the ACP also with devices of a sub-domain, to subdomain or other domains, etc. Those domains. These will likely be controlled by Intent. They Intent and are outside scope for the moment. scope of this document. Note that Intent is distributed through the ACP; therefore, a node can only adapt Intent driven behaviour Intent-driven behavior once it has joined the ACP. At the moment, the ANIMA Working Group does not consider providing Intent outside the ACP; this can be considered later. </t>
</list></t> </li>
</ul>
<t>Once a node has joined the ACP, it will also learn the ACP addresses of its adjacent nodes, nodes and add them to the adjacency table, table to allow for communication inside the ACP. Further autonomic domain interactions will now happen inside the ACP. At this moment, only negotiation / and synchronization via GRASP <xref target="I-D.ietf-anima-grasp"/> is being target="RFC8990" format="default"/> are defined. (Note that GRASP runs in the data plane, as an input in building the adjacency table, as well as inside the ACP.) </t>
<t>Autonomic Functions functions consist of Autonomic Service Agents (ASAs). ASAs. They run logically above the AN Infrastructure, ANI and may use the adjacency table, the ACP, negotiation and synchronization through GRASP in the ACP, Intent Intent, and other functions of the ANI. Since the ANI only provides autonomic interactions within a domain, autonomic functions can also use any other context on a node, specifically the global data plane. </t>
</section>
<!-- end section adjacency table -->
<!-- old section 5 end -->
<section anchor="state-machine" title="State Machine"> numbered="true" toc="default">
<name>State Machine</name>
<t>Autonomic Networking applies during the full life-cycle life cycle of a node. This section describes a state machine of an autonomic node, node throughout its life.</t>
<t>A device is normally expected to store its domain specific domain-specific identity, the LDevID Local Device Identifier (LDevID) (see <xref target="cert"/>), target="cert" format="default"/>), in persistent storage, storage to be available after a powercycle power-cycle event. For device types that cannot store the LDevID in persistent storage, a powercycle power-cycle event is effectively equivalent to a factory reset. </t>
<section anchor="state-1" title="State numbered="true" toc="default">
<name>State 1: Factory Default"> Default</name>
<t>An autonomic node leaves the factory in this state. In this state, the node has no domain specific domain-specific configuration, specifically no LDevID, and could be used in any particular target network. It does however does, however, have a vendor/manufacturer specific vendor/manufacturer-specific ID, the IDevID Initial Device Identifier (IDevID) <xref target="IDevID"></xref>. target="IDevID" format="default"/>. Nodes without IDevID cannot be autonomically and securely enrolled into a domain; they require manual pre-staging, in which case the pre-staging takes them directly to state 2.</t>
<t>Transitions:
<list style="symbols">
<t>Bootstrap
</t>
<ul spacing="normal">
<li>Bootstrap event: The device enrols enrolls into a domain; as part of
this process it receives a domain identity (LDevID). If enrollment
is successful, the next state is state 2. See <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> Section 3 target="RFC8995" format="default"/> for details on enrollment.</t>
<t>Powercycle enrollment.</li>
<li>Power-cycle event: The device loses all state tables. It remains in state: 1.</t>
</list> </t> state 1.</li>
</ul>
</section>
<!-- state-1 -->
<section anchor="state-2" title="State numbered="true" toc="default">
<name>State 2: Enrolled"> Enrolled</name>
<t>An autonomic node is in the state "enrolled" state if it has a domain identity (LDevID), (LDevID) and has currently no ACP channel up. It may have further configuration or state, for example example, if it had been in state 3 before, before but lost all its ACP channels. The LDevID can only be removed from a device through a factory reset, which also removes all other state from the device. This ensures that a device has no stale domain specific domain-specific state when entering the "enrolled" state from state 1.</t>
<t>Transitions:
<list style="symbols">
<t>Joining
</t>
<ul spacing="normal">
<li>Joining ACP: The device establishes an ACP channel to an adjacent device. See <xref target="I-D.ietf-anima-autonomic-control-plane"/> target="RFC8994" format="default"/> for details. Next state: 3.</t>
<t>Factory 3.</li>
<li>Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1.</t>
<t>Powercycle 1.</li>
<li>Power-cycle event: The device loses all state tables, but not its domain identity (LDevID). it It remains in state: 2.</t>
</list> </t> state 2.</li>
</ul>
</section>
<!-- state-2 -->
<section anchor="state-3" title="State numbered="true" toc="default">
<name>State 3: In ACP"> ACP</name>
<t>In this state, the autonomic node has at least one ACP channel to another device. The node can now participate in further autonomic transactions, such as starting autonomic service agents ASAs (e.g., it must now enable the join assistant proxy ASA, to help other devices to join the domain. domain). Other conditions may apply to such interactions, for example example, to serve as a join assistant, proxy, the device must first discover a bootstrap Registrar. registrar. </t>
<t>Transitions:
<list style="symbols">
<t>Leaving
</t>
<ul spacing="normal">
<li>Leaving ACP: The device drops the last (or only) ACP channel to an adjacent device. Next state: 2.</t>
<t>Factory 2.</li>
<li>Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1.</t>
<t>Powercycle 1.</li>
<li>Power-cycle event: The device loses all state tables, tables but not its domain identity (LDevID). Next state: 2.</t>
</list> </t> 2.</li>
</ul>
</section>
<!-- state-3 -->
</section>
<!-- state-machine -->
</section>
<!-- element -->
<section anchor="ani" title="The Autonomic numbered="true" toc="default">
<name>Autonomic Networking Infrastructure"> Infrastructure</name>
<t>The Autonomic Networking Infrastructure ANI provides a layer of common functionality across an Autonomic Network. It provides the elementary functions and services, as well as extensions. An Autonomic Function, autonomic function, comprising of Autonomic Service Agents ASAs on nodes, uses the functions described in this section. </t>
<section anchor="naming" title="Naming"> numbered="true" toc="default">
<name>Naming</name>
<t>Inside a domain, each autonomic device should be assigned a unique name. The naming scheme should be consistent within a domain. Names are typically assigned by a Registrar registrar at bootstrap time and are persistent over the lifetime of the device. All Registrars registrars in a domain must follow the same naming scheme.</t>
<t>In the absence of a domain specific domain-specific naming scheme, a default naming scheme should use the same logic as the addressing scheme discussed in <xref target="I-D.ietf-anima-autonomic-control-plane"/>. target="RFC8994" format="default"/>. The device name is then composed of a Registrar ID Registrar-ID (for example example, taking a MAC Media Access Control (MAC) address of the Registrar) registrar) and a device number. An example name would then look like this: </t>
<t>0123-4567-89ab-0001</t>
<t>The first three fields are the MAC address, and the fourth field is the sequential number for the device.</t>
</section>
<!-- naming -->
<section anchor="addressing" title="Addressing">
<t>Autonomic Service Agents (ASAs) numbered="true" toc="default">
<name>Addressing</name>
<t>ASAs need to communicate with each other, using the autonomic addressing of the Autonomic Networking Infrastructure ANI of the node they reside on. This section describes the addressing approach of the Autonomic Networking Infrastructure, ANI used by ASAs. </t>
<t>Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way, way or negotiated as a service of an ASA. One use case for such an autonomic function is described in <xref target="I-D.ietf-anima-prefix-management"/>.</t> target="RFC8992" format="default"/>.</t>
<t>Autonomic addressing is a function of the Autonomic Networking Infrastructure ANI (lower part of <xref target="ref_model"/>), target="ref_model" format="default"/>), specifically the Autonomic Control Plane. ACP. ASAs do not have their own addresses. They may use either API calls, calls or the autonomic addressing scheme of the Autonomic Networking Infrastructure. ANI. </t>
<t>An autonomic addressing scheme has the following requirements:
<list style="symbols">
<t>Zero-touch
</t>
<ul spacing="normal">
<li>Zero-touch for simple networks: Simple networks should have complete self-management of addressing, addressing and not require any central address management, tools, or address planning. </t>
<t>Low-touch </li>
<li>Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high level high-level guidance only, expressed in Intent.</t>
<t>Flexibility: Intent.</li>
<li>Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around, around and for the network to grow, split split, and merge. </t>
<t>Robustness: </li>
<li>Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. </t>
<t>Stability: </li>
<li>Stability: The addressing scheme should be as stable as possible. However, implementations need to be able to recover from unexpected address changes. </t>
<t>Support </li>
<li>Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices, devices or at the level of virtual machines, containers containers, and networks. In particular, Autonomic Nodes autonomic nodes may support Autonomic Service Agents ASAs in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture. </t>
<t>Simplicity: To </li>
<li>Simplicity: The addressing scheme should be simple to make engineering simpler, easier and to give the human administrator an easy way to trouble-shoot troubleshoot autonomic functions. </t>
<t>Scale: </li>
<li>Scale: The proposed scheme should work in any network of any size. </t>
<t>Upgradability: </li>
<li>Upgradability: The scheme must be able to support different addressing concepts in the future. </t>
</list>
</t> </li>
</ul>
<t>The proposed addressing scheme is described in the document "An Autonomic Control Plane" (<xref target="I-D.ietf-anima-autonomic-control-plane"/>).</t> "<xref target="RFC8994" format="title"/>" <xref target="RFC8994" format="default"/>.</t>
</section>
<!-- addressing -->
<section anchor="discovery" title="Discovery"> numbered="true" toc="default">
<name>Discovery</name>
<t>Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all, and therefore all; therefore, it needs to discover peers and other resources in the network. This section describes various discovery functions in an autonomic network.</t>
<t>Discovering Autonomic Network.</t>
<t>First, discovering nodes and their properties and capabilities: A capabilities is a core function to establish an autonomic domain is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may may, in principle principle, either leverage existing discovery mechanisms, mechanisms or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change.</t>
<t>Discovering services: Network
<t>Second, network services such as AAA Authentication, Authorization, and Accounting (AAA) should also be discovered and not configured. Service discovery is required for such tasks. An autonomic network Autonomic Network can either leverage existing service discovery functions, or use a new approach, or use a mixture.</t>
<t>Thus
<t>Thus, the discovery mechanism could either be fully integrated with autonomic signaling (next section) or could use an independent discovery mechanism such as DNS DNS-based Service Discovery or the Service Location Protocol. This choice could be made independently for each Autonomic Service Agent, ASA, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism, mechanism or the source of information distribution, <xref target="info-distri"/>).</t> distribution (<xref target="info-distri" format="default"/>)).</t>
<t>Phase 1 of Autonomic Networking uses GRASP for discovery, described in <xref target="I-D.ietf-anima-grasp"/>.</t> target="RFC8990" format="default"/> for discovery.</t>
</section>
<!-- discovery -->
<section anchor="negotiation" title="Signaling Between numbered="true" toc="default">
<name>Signaling between Autonomic Nodes"> Nodes</name>
<t>Autonomic nodes must communicate with each other, for example example, to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be able to handle any sort of technical objective, including ones that require complex data structures. The document "A Generic Autonomic Signaling Protocol (GRASP)" "<xref target="RFC8990" format="title"/>" <xref target="I-D.ietf-anima-grasp"/> target="RFC8990" format="default"/> describes more detailed requirements for discovery, negotiation negotiation, and synchronization in an autonomic network. Autonomic Network.
It also defines a protocol, called GRASP, for this purpose, including purpose; GRASP includes an integrated but optional discovery protocol.</t> process.</t>
<t>GRASP is normally expected to run inside the Autonomic Control Plane (ACP; see ACP (see <xref target="acp"/>) target="acp" format="default"/>) and to depend on the ACP for security.
It may run insecurely for a short time during bootstrapping.</t>
<t>An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP
run in a single node, perhaps with different security properties, are not excluded. </t>
</section>
<!-- negotiation -->
<section anchor="routing" title="Routing"> numbered="true" toc="default">
<name>Routing</name>
<t>All autonomic nodes in a domain must be able to communicate with
each other, and in later phases phases, they must also be able to communicate
with autonomic nodes outside their own domain. Therefore, an Autonomic Control Plane
ACP relies on a routing function. For Autonomic
Networks to be interoperable, they must all support one common routing
protocol. </t>
<t>The routing protocol is defined in the ACP document <xref target="I-D.ietf-anima-autonomic-control-plane"/>.</t> target="RFC8994" format="default"/>.</t>
</section>
<!-- routing -->
<section anchor="acp" title="The Autonomic numbered="true" toc="default">
<name>Autonomic Control Plane"> Plane</name>
<t>The "Autonomic Control Plane" ACP carries the control protocols in an autonomic network. Autonomic Network. In the architecture described here, in this document, it is implemented as an overlay network. The document "An Autonomic Control Plane" (<xref target="I-D.ietf-anima-autonomic-control-plane"/>) "<xref target="RFC8994" format="title"/>" <xref target="RFC8994" format="default"/> describes the implementation details suggested here. in this document. This document uses the term "overlay" to mean a set of point-to-point adjacencies congruent with the underlying interconnection topology. The terminology may not be aligned with a common usage of the "overlay" term "overlay" in the routing context. See <xref target="I-D.ietf-anima-stable-connectivity"/> target="RFC8368" format="default"/> for uses cases for the ACP. </t>
</section>
<!-- acp -->
<section anchor="info-distri" title="Information numbered="true" toc="default">
<name>Information Distribution (*)"> (*)</name>
<t>Certain forms of information require distribution across an autonomic domain. The distribution of information runs inside the Autonomic Control Plane. ACP. For example, Intent is distributed across an autonomic domain, as explained in <xref target="RFC7575"/>.</t> target="RFC7575" format="default"/>.</t>
<t>Intent is the policy language of an Autonomic Network, see Network (see also <xref target="intent"/>. target="intent" format="default"/>). It is a high level policy, high-level policy and should change only infrequently (order of days). Therefore, information such as Intent should be simply flooded to all nodes in an autonomic domain, and there is currently no perceived need to have more targeted distribution methods. Intent is also expected to be monolithic, monolithic and flooded as a whole. One possible method for distributing Intent, as well as other forms of data, is discussed in <xref target="I-D.liu-anima-grasp-distribution"/>. target="I-D.ietf-anima-grasp-distribution" format="default"/>. Intent and information distribution are not part of phase 1 of ANIMA. the ANIMA Working Group charter. </t>
</section>
<!-- info-distri -->
</section>
<!-- ani -->
<section anchor="trust" title="Security numbered="true" toc="default">
<name>Security and Trust Infrastructure"> Infrastructure</name>
<t>An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure. </t>
<t>Autonomic nodes have direct interactions between themselves, which must be secured. Since an autonomic network Autonomic Network does not rely on configuration, it is not an option to configure, for example, pre-shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. In this first phase of autonomic networking, Autonomic Networking, a device is either 1) within the trust domain and fully trusted, trusted or 2) outside the trust domain and fully untrusted.</t>
<t>The default method to automatically bring up a trust infrastructure is defined in the document "Bootstrapping Key Infrastructures" <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>. "<xref target="RFC8995" format="title" />" <xref target="RFC8995" format="default" />. The ASAs required for this enrollment process are described in <xref target="specific-asas"/>. target="specific-asas" format="default"/>. An autonomic node must implement the enrollment and join assistant proxy ASAs. The registrar ASA may be implemented only on a sub-set subset of nodes. </t>
<section anchor="pki" title="Public numbered="true" toc="default">
<name>Public Key Infrastructure"> Infrastructure</name>
<t>An autonomic domain uses a PKI model. The root of trust is a certification authority Certification Authority (CA). A registrar acts as a registration authority Registration Authority (RA). </t>
<t>A minimum implementation of an autonomic domain contains one CA, one Registrar, registrar, and network elements.</t>
</section>
<!-- pki -->
<section anchor="cert" title="Domain Certificate"> numbered="true" toc="default">
<name>Domain Certificate</name>
<t>Each device in an autonomic domain uses a domain certificate (LDevID) to prove its identity. A new device uses its manufacturer provided manufacturer-provided certificate (IDevID) during bootstrap, bootstrap to obtain a domain certificate. <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> target="RFC8995" format="default"/> describes how a new device receives a domain certificate, certificate and defines the certificate format. </t>
</section>
<!-- cert -->
<section anchor="masa" title="The MASA"> numbered="true" toc="default">
<name>MASA</name>
<t>The Manufacturer Authorized Signing Authority (MASA) is a trusted service for bootstrapping devices. The purpose of the MASA is to provide ownership tracking of devices in a domain. The MASA provides audit, authorization, and ownership tokens to the registrar during the bootstrap process to assist in the authentication of devices attempting to join an Autonomic Domain, autonomic domain and to allow a joining device to validate whether it is joining the correct domain. The details for MASA service, security, and usage are defined in <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>. target="RFC8995" format="default"/>. </t>
</section>
<!-- masa -->
<section anchor="sub-domains" title="Sub-Domains (*)"> numbered="true" toc="default">
<name>Subdomains (*)</name>
<t>By default, sub-domains subdomains are treated as different domains. This implies no trust between a domain and its sub-domains, subdomains and no trust between sub-domains subdomains of the same domain. Specifically, no ACP is built, and Intent is valid only for the domain it is defined for explicitly. </t>
<t>In phase 2 of ANIMA, the ANIMA Working Group charter, alternative trust models should be defined, for example example, to allow full or limited trust between domain and sub-domain.</t> subdomain.</t>
</section>
<!-- sub-domains -->
<section anchor="cross-domain" title="Cross-Domain numbered="true" toc="default">
<name>Cross-Domain Functionality (*)"> (*)</name>
<t>By default, different domains do not interoperate, no ACP is built built, and no trust is implied between them. </t>
<t>In the future, models can be established where other domains can be trusted in full or for limited operations between the domains. </t>
</section>
<!-- sub-domains -->
</section>
<!-- trust -->
<section anchor="asa" title="Autonomic numbered="true" toc="default">
<name>Autonomic Service Agents (ASA)"> (ASAs)</name>
<t>This section describes how autonomic services run on top of the Autonomic Networking Infrastructure. ANI. </t>
<section anchor="asa-general" title="General numbered="true" toc="default">
<name>General Description of an ASA"> ASA</name>
<t>An Autonomic Service Agent (ASA) ASA is defined in <xref target="RFC7575"/> target="RFC7575" format="default"/> as "An agent implemented on an autonomic node
that implements an autonomic function, either in part (in the case of
a distributed function) or whole." Thus whole". Thus, it is a process that makes use
of the features provided by the ANI to achieve its own goals, usually including
interaction with other ASAs via the GRASP protocol <xref target="I-D.ietf-anima-grasp"/> target="RFC8990" format="default"/> or otherwise.
Of course course, it also interacts with the specific targets of its function, using
any suitable mechanism.
Unless its function is very simple, the ASA will need to handle overlapping asynchronous operations. It may therefore be a quite
complex piece of software in its own right, forming part of the application layer
above the ANI. ASA design guidelines are available in <xref target="I-D.carpenter-anima-asa-guidelines"/>.</t>
<t>Thus target="I-D.ietf-anima-asa-guidelines" format="default"/>.</t>
<t>Thus, we can distinguish at least three classes of ASAs:
<list style="symbols">
<t>Simple
</t>
<ul spacing="normal">
<li>Simple ASAs with a small footprint that could run anywhere.</t>
<t>Complex, anywhere.</li>
<li>Complex, possibly multi-threaded ASAs that have a significant resource requirement and will only
run on selected nodes.</t>
<t>A nodes.</li>
<li>A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself,
which must run in all autonomic nodes.
These are outlined in the following sections.</t>
</list></t> sections.</li>
</ul>
<t>Autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, derived from hardware, firmware firmware, or pre-installed software: They software; they are "self-aware". </t>
<t>The role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth,
tunnel or translation properties, etc. For example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so. </t>
<t>Following an initial discovery phase, the node node's properties and those of its neighbors are the foundation of the behavior of a specific node. A node and its ASAs have no pre-configuration for the particular network in which they are installed.</t>
<t>Since all ASAs will interact with the ANI, they will depend on appropriate application
programming interfaces (APIs). It is desirable that ASAs are portable between operating
systems, so these APIs need to be universal.
An API for GRASP is described in <xref target="I-D.ietf-anima-grasp-api"/>. target="RFC8991" format="default"/>. </t>
<t>ASAs will will, in general general, be designed and coded by experts in a particular technology
and use case, not by experts in the ANI and its components. Also, they
may be coded in a variety of programming languages, in particular including particular, languages
that support object constructs as well as traditional variables and structures. The APIs
should be designed with these factors in mind.</t>
<t>It must be possible to run ASAs as non-privileged (user space) processes except for those
(such as the infrastructure ASAs) that necessarily require kernel privilege. Also, it is
highly desirable that ASAs can be dynamically loaded on a running node.</t>
<t>Since autonomic systems must be self-repairing, it is of great importance that ASAs are
coded using robust programming techniques. All run-time runtime error conditions must be caught,
leading to suitable minimally disruptive recovery actions, also considering but a complete restart of the ASA. ASA must also be considered.
Conditions such as discovery failures or negotiation failures must be treated as routine,
with the ASA retrying the failed operation, preferably with an exponential back-off
in the case of persistent errors. When multiple threads are started within an ASA,
these threads must be monitored for failures and hangups, and appropriate action taken.
Attention must be given to garbage collection, so that ASAs never run out of resources.
There is assumed to be no human operator - operator; again, in the worst case, every ASA must
be capable of restarting itself. </t>
<t>ASAs will automatically benefit from the security provided by the ANI, and specifically
by the ACP and by GRASP. However, beyond that, they are responsible for their own security,
especially when communicating with the specific targets of their function. Therefore,
the design of an ASA must include a security analysis beyond 'use ANI security.' security'. </t>
</section>
<!-- general description of an ASA -->
<section anchor="asa-life-cycle" title="ASA numbered="true" toc="default">
<name>ASA Life-Cycle Management"> Management</name>
<t>ASAs operating on a given ANI may come from different providers and pursue different objectives. Management of ASAs and its their interactions with the ANI should follow the same operating principles, hence principles and thus comply to a generic life-cycle management model.</t>
<t>The ASA life-cycle life cycle provides standard processes to:
<list style="symbols">
<t>install
</t>
<ul spacing="normal">
<li>install ASA: copy the ASA code onto the node and start it,</t>
<t>deploy it.</li>
<li>deploy ASA: associate the ASA instance with a (some) managed network device(s) (or network function),</t>
<t>control function).</li>
<li>control ASA execution: when and how an ASA executes its control loop.</t>
</list></t>
<t>The life-cyle will cover the sequential states below: Installation, Deployment, Operation and the transitional states in-between. This Life-Cycle loop.</li>
</ul>
<t>This life cycle will also define which interactions ASAs have with the ANI in between the different states. The noticeable interactions are:
<list style="symbols">
<t>Self-description
</t>
<ul spacing="normal">
<li>Self-description of ASA instances at the end of deployment: its Its format needs to define the information required for the management of ASAs by ANI entities</t>
<t>Control entities.</li>
<li>Control of the ASA control-loop control loop during the operation: a signaling Signaling has to carry formatted messages to control ASA execution (at least starting and stopping the control loop)</t>
</list></t> loop).</li>
</ul>
</section>
<!-- asa-life-cycle -->
<section anchor="specific-asas" title="Specific numbered="true" toc="default">
<name>Specific ASAs for the Autonomic Network Infrastructure"> Networking Infrastructure</name>
<t>The following functions provide essential, required functionality in an autonomic network, Autonomic Network and are therefore mandatory to implement on unconstrained autonomic nodes. They are described here as ASAs that include the underlying infrastructure components, but implementation details might vary.</t>
<t>The first three together (pledge, join proxy, join registrar) support together the trust enrollment process
described in <xref target="trust"/>. target="trust" format="default"/>. For details see <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t> target="RFC8995" format="default"/>.</t>
<section anchor="enrollment" title="The enrollment ASAs"> numbered="true" toc="default">
<name>Enrollment ASAs</name>
<section anchor="enrollment-pledge" title="The numbered="true" toc="default">
<name>The Pledge ASA"> ASA</name>
<t>This ASA includes the function of an autonomic node that bootstraps into the domain with the help of an a join assitant proxy ASA (see below). Such a node is known as a Pledge pledge during the enrollment process. This ASA must be installed by default on all nodes that require an autonomic zero-touch bootstrap.</t>
</section>
<!-- enrollment -->
<section anchor="join-assitant" title="The numbered="true" toc="default">
<name>The Join Assistant ASA"> Proxy ASA</name>
<t>This ASA includes the function of an autonomic node that helps a non-enrolled, adjacent devices to enroll into the domain. This ASA must be installed on all nodes, although only one join assistant proxy needs to be active on a given LAN. See also <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t> target="RFC8995" format="default"/>.</t>
</section>
<!-- join-assistant -->
<section anchor="enrollment-registrar" title="The numbered="true" toc="default">
<name>The Join Registrar ASA"> ASA</name>
<t>This ASA includes the join registrar Join Registrar function in an autonomic network. Autonomic Network. This ASA does not need to be installed on all nodes, but only on nodes that implement the Join Registrar function.</t>
</section>
<!-- registrar -->
</section>
<section anchor="acp-asa" title="The ACP ASA"> numbered="true" toc="default">
<name>ACP ASA</name>
<t>This ASA includes the ACP function in an autonomic network. Autonomic Network. In particular particular, it acts to discover other potential ACP nodes, nodes and to support the establishment and teardown of ACP channels. This ASA must be installed on all nodes. For details details, see <xref target="acp"/> target="acp" format="default"/> and <xref target="I-D.ietf-anima-autonomic-control-plane"/>.</t> target="RFC8994" format="default"/>.</t>
</section>
<!-- acp -->
<section anchor="intent-asa" title="The Information numbered="true" toc="default">
<name>Information Distribution ASA (*)"> (*)</name>
<t>This ASA is currently out of scope in ANIMA, the ANIMA Working Group charter and is provided here only as background information.</t>
<t>This ASA includes the information distribution function in an autonomic network. Autonomic Network. In particular particular, it acts to announce the availability of Intent and other information to all other autonomic nodes. This ASA does not need to be installed on all nodes, but only on nodes that implement the information distribution function. For details details, see <xref target="info-distri"/>.</t> target="info-distri" format="default"/>.</t>
<t>Note that information distribution can be implemented as a function in any ASA. See <xref target="I-D.liu-anima-grasp-distribution"/> target="I-D.ietf-anima-grasp-distribution" format="default"/> for more details on how information is suggested to be distributed.</t>
</section>
<!-- registrar -->
</section>
<!-- specific-asas -->
</section>
<!-- asa -->
<section anchor="management" title="Management numbered="true" toc="default">
<name>Management and Programmability"> Programmability</name>
<t>This section describes how an Autonomic Network is managed, managed and programmed.</t>
<section anchor="management-general" title="Managing numbered="true" toc="default">
<name>Managing a (Partially) Autonomic Network"> Network</name>
<t>Autonomic management usually co-exists coexists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. Examples for of overlap are:
<list style="symbols">
<t>Autonomic
</t>
<ul spacing="normal">
<li>Autonomic functions can use traditional methods and protocols (e.g., SNMP and NETCONF) to perform the Network Configuration Protocol (NETCONF)) to perform management tasks, inside and outside the ACP;</t>
<t>Autonomic ACP.</li>
<li>Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols;</t>
<t>Traditional protocols.</li>
<li>Traditional functions can use the ACP, for example example, if reachability on the data plane is not (yet) established. </t>
</list></t> </li>
</ul>
<t>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.</t>
<t>Conflict can occur between autonomic default behavior, autonomic Intent, and traditional management methods. Conflict resolution is achieved in autonomic management through prioritization <xref target="RFC7575"/>. target="RFC7575" format="default"/>. The rationale is that manual and node-based management have a higher priority over 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 command-line interfaces. </t>
</section>
<!-- management-general -->
<section anchor="intent" title="Intent (*)"> numbered="true" toc="default">
<name>Intent (*)</name>
<t>Intent is not covered in the current implementation specifications. This section discusses a topic for further research.</t>
<t>This section gives an overview of Intent, Intent and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., PCIM) Policy Core Information Model (PCIM)) and in other SDOs Standards Development Organizations (SDOs) (e.g., DMTF and TMF ZOOM). the Distributed Management Task Force (DMTF)). </t>
<t>Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network <xref target="RFC7575"/>. target="RFC7575" format="default"/>. Intent should be limited to high level high-level guidance only, thus only; thus, it does not directly define a policy for every network element separately. </t>
<t>Intent can be refined to lower level 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 <xref target="RFC7575"/>. target="RFC7575" format="default"/>. One of the possible refinements of the Intent is using Event-Condition-Action (ECA) rules.</t>
<t>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. </t>
<t>Intent is discussed in more detail in <xref target="I-D.du-anima-an-intent"/>. target="I-D.du-anima-an-intent" format="default"/>. Intent as well as other types of information are distributed via GRASP, GRASP; see <xref target="I-D.liu-anima-grasp-distribution"/>.</t> target="I-D.ietf-anima-grasp-distribution" format="default"/>.</t>
</section>
<!-- intent -->
<section anchor="reporting" title="Aggregated numbered="true" toc="default">
<name>Aggregated Reporting (*)"> (*)</name>
<t>Aggregated reporting is not covered in the current implementation specifications. This section discusses a topic for further research.</t>
<t>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 which 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 Autonomic Network should happen on a network-wide basis <xref target="RFC7575"/>. target="RFC7575" format="default"/>. </t>
<t>Multiple simultaneous events can occur in an autonomic network 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) and in which way 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 which that is described in the autonomic Intent. </t>
<t>Reporting in an autonomic network 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 Autonomic Network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, possibly there are some events that may need to be addressed by the actions of a human administrator actions.</t> administrator.</t>
</section>
<!-- reporting -->
<section anchor="feedback" title="Feedback numbered="true" toc="default">
<name>Feedback Loops to NOC (*)"> (*)</name>
<t>Feedback loops are required in an autonomic network Autonomic Network to allow the intervention of a human administrator or central control systems, systems while maintaining a default behaviour. behavior. Through a feedback loop loop, an administrator must be prompted with a default action, action and has the possibility to acknowledge or override the proposed default action. </t>
<t>Uni-directional
<t>Unidirectional notifications to the NOC, Network Operations Center (NOC) that do not propose any default action, 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 co-exist coexist with autonomic methods, methods but are not covered in this draft.</t> document.</t>
</section>
<!-- feedback -->
<section anchor="control-loops" title="Control numbered="true" toc="default">
<name>Control Loops (*)"> (*)</name>
<t>Control loops are not covered in the current implementation specifications. This section discusses a topic for further research. </t>
<t>Control loops are used in autonomic networking Autonomic Networking to provide a generic
mechanism to enable the Autonomic System autonomic system to adapt (on its own) to
various factors that can change the goals that the autonomic network Autonomic Network
is trying to achieve, 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.</t>
<t>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, managed and then provide
actions to move the state of the system being managed toward a
common goal. Self-adaptive systems move decision-making decision making from
static, pre-defined commands to dynamic processes computed at
runtime.</t>
<t>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.</t>
</section>
<!-- control-loops -->
<section anchor="apis" title="APIs (*)">
<t>APIs numbered="true" toc="default">
<name>APIs (*)</name>
<t><xref target="RFC8991" format="default"/> 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. This section discusses a topic for further research.</t> </t>
<t>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. </t>
<t>A dynamic API is one that retrieves data using a generic
mechanism,
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.</t>
<t>APIs must be able to express and preserve the semantics of
data models. For example, software contracts <xref target="Meyer97"/> target="Meyer97" format="default"/> 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 precisely defined specifications of the
mutual obligations that interacting components must respect.
This typically includes specifying:
<list style="symbols">
<t>pre-conditions
</t>
<ul spacing="normal">
<li>pre-conditions that must be satisfied before the method can
start execution</t>
<t>post-conditions execution</li>
<li>post-conditions that must be satisfied when the method has
finished execution</t>
<t>invariant execution</li>
<li>invariant attributes that must not change during the execution
of the method</t>
</list>
</t> method</li>
</ul>
</section>
<!-- apis -->
<section anchor="data-model" title="Data numbered="true" toc="default">
<name>Data Model (*)"> (*)</name>
<t>Data models are not covered in the current implementation specifications. This section discusses a topic for further research. </t>
<t>The following definitions of "data model" and "information model" are adapted from <xref target="I-D.ietf-supa-generic-policy-data-model"/>:</t> target="I-D.ietf-supa-generic-policy-data-model" format="default"/>.</t>
<t>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 (typically, but not
necessarily, all three).</t> protocol.</t>
<t>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.</t>
<t>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, 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.</t>
<t>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.</t>
</section>
<!-- data model -->
</section>
<!-- management -->
<section anchor="coordination" title="Coordination Between numbered="true" toc="default">
<name>Coordination between Autonomic Functions (*)"> (*)</name>
<t>Coordination between autonomic functions is not covered in the current implementation specifications. This section discusses a topic for further research. </t>
<section title="The Coordination numbered="true" toc="default">
<name>Coordination Problem (*)"> (*)</name>
<t>Different autonomic functions may conflict in setting certain parameters. For example, an energy efficiency function may want to shut down a redundant link, while a load balancing load-balancing function would not want that to happen. The administrator must be able to understand and resolve such interactions, interactions to steer autonomic network Autonomic Network performance to a given (intended) operational point.</t>
<t>Several interaction types may exist among autonomic functions, for example:
<list style="symbols">
<t>Cooperation:
</t>
<ul spacing="normal">
<li>Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function. </t>
<t>Dependency: </li>
<li>Dependency: An autonomic function cannot work without another one being present or accessible in the autonomic network.</t>
<t>Conflict: Autonomic Network.</li>
<li>Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions. </t>
</list> </t> </li>
</ul>
<t>Solving the coordination problem beyond one-by-one cases can rapidly become intractable for large networks. Specifying a common functional block on coordination is a first step to address the problem in a systemic way. The coordination life-cycle life cycle consists in of three states:
<list style="symbols">
<t>At
</t>
<ul spacing="normal">
<li>At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities on for identified conflicts.</t>
<t>At conflicts.</li>
<li>At deploy-time, autonomic functions are not yet active/acting on the network. A "dynamic interaction map" is created for each instance of each autonomic functions and function on a per resource per-resource basis, including the actions performed and their relationships. This map provides the basis to identify conflicts that will happen at run-time, runtime, categorize them them, and plan for the appropriate coordination strategies/mechanisms.</t>
<t>At run-time, strategies and mechanisms.</li>
<li>At runtime, when conflicts happen, arbitration is driven by the coordination strategies. Also Also, new dependencies can be observed and inferred, resulting in an update of the dynamic interaction map and adaptation of the coordination strategies and mechanisms.</t>
</list></t> mechanisms.</li>
</ul>
<t>Multiple coordination strategies and mechanisms exist and can be devised. The set ranges from basic approaches such (such as random process or token-based process, process), to approaches based on time separation and hierarchical optimization, to more complex approaches such (such as multi-objective optimization, optimization and other control theory approaches and algorithms family.</t> algorithm families).</t>
</section>
<section title="A Coordination numbered="true" toc="default">
<name>Coordination Functional Block (*)"> (*)</name>
<t>A common coordination functional block is a desirable component of the ANIMA reference model. It provides a means to ensure network properties and predictable performance or behavior behavior, such as stability, stability and convergence, in the presence of several interacting autonomic functions.</t>
<t>A common coordination function requires:
<list style="symbols">
<t>A
</t>
<ul spacing="normal">
<li>A common description of autonomic functions, their attributes attributes, and life-cycle.</t>
<t>A life cycle.</li>
<li>A common representation of information and knowledge (e.g., interaction maps).</t>
<t>A maps).</li>
<li>A common “control/command” "control/command" interface between the coordination "agent" and the autonomic functions. </t>
</list></t> </li>
</ul>
<t>Guidelines, recommendations recommendations, or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms.</t>
</section>
</section>
<!-- coordination -->
<section anchor="security" title="Security Considerations"> numbered="true" toc="default">
<name>Security Considerations</name>
<t>In this section section, we distinguish outsider and insider attacks. In an outsider attack attack, all network elements and protocols are securely managed and operating, and an outside attacker can sniff packets in transit, inject inject, and replay packets. In an insider attack, the attacker has access to an autonomic node or other means (e.g. (e.g., remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform) to produce arbitrary payloads on the protected ACP channels.</t>
<t>If a system has vulnerabilities in the implementation or operation (configuration), an outside attacker can exploit such vulnerabilies vulnerabilities to become an insider attacker.</t>
<section title="Protection Against numbered="true" toc="default">
<name>Protection against Outsider Attacks"> Attacks</name>
<t>Here, we assume that all systems involved in an autonomic network Autonomic Network are secured and operated according to best current practices. These protection methods comprise traditional security implementation and operation methods (such as code security, strong randomization algorithms, strong passwords, etc.) as well as mechanisms specific to an autonomic network Autonomic Network (such as a secured MASA service).</t>
<t>Traditional security methods for both implementation and operation are outside the scope for of this document.</t>
<t>AN specific
<t>AN-specific protocols and methods must also follow traditional security methods, in that all packets that can be sniffed or injected by an outside attacker are:
<list style="symbols">
<t>protected
</t>
<ul spacing="normal">
<li>protected against modification.</t>
<t>authenticated.</t>
<t>protected modification</li>
<li>authenticated</li>
<li>protected against replay attacks.</t>
<t>confidentiality attacks</li>
<li>confidentiality protected (encrypted).</t>
<t>and that (encrypted)</li>
</ul>
<t>In addition, the AN protocols are should be robust against packet drops and man-in-the-middle attacks.</t>
</list>
</t>
<t>How these requirements are met is covered in the AN standards track Standards Track documents that define the methods used, specifically <xref target='I-D.ietf-anima-bootstrapping-keyinfra'/>, target="RFC8990" format="default"/>, <xref target='I-D.ietf-anima-grasp'/>, target="RFC8994" format="default"/>, and <xref target='I-D.ietf-anima-autonomic-control-plane'/>. target="RFC8995" format="default"/>. </t>
<t>Most AN messages run inside the cryptographically protected
ACP. The unprotected AN messages outside the ACP are limited to a
simple discovery method, defined in Section 2.5.2 of <xref target='I-D.ietf-anima-grasp'/>: The "Discovery target="RFC8990" sectionFormat="of" section="2.5.2"/>: the Discovery
Unsolicited Link-Local (DULL)" (DULL) message, with detailed rules on its
usage. </t>
<t>If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis. </t>
</section>
<section title="Risk numbered="true" toc="default">
<name>Risk of Insider Attacks"> Attacks</name>
<t>An autonomic network Autonomic Network consists of autonomic devices that form a distributed self-managing system. Devices within a domain have credentials issued from a common trust anchor and can use them to create mutual trust. This means that any device inside a trust domain can by default use all distributed functions in the entire autonomic domain in a malicious way.</t>
<t>If an autonomic node
<t>An inside attacker, or an outsider in the presence of protocol has vulnerabilities or is not securely operated, an outside attacker insecure operation, has the following generic ways to take control of an autonomic network: <list style='symbols'>
<t>Introducing Autonomic Network: </t>
<ul spacing="normal">
<li>Introducing a fake device into the trust domain, domain by subverting the authentication methods. This depends on the correct specification, implementation implementation, and operation of the AN protocols.</t>
<t>Subverting protocols.</li>
<li>Subverting a device which that is already part of a trust domain, domain and modifying its behavior. This threat is not specific to the solution discussed in this document, document and applies to all network solutions. </t>
<t>Exploiting </li>
<li>Exploiting potentially yet unknown protocol vulnerabilities in the AN or other protocols. Also this This is also a generic threat that applies to all network solutions.</t>
</list></t> solutions.</li>
</ul>
<t>The above threats are are, in principle principle, comparable to other solutions: In in the presence of design, implementation implementation, or operational errors, security is no longer guaranteed. However, the distributed nature of AN, specifically the Autonomic Control Plane, ACP, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP, ACP and can use all AN methods and protocols. </t>
<t>For the next phase of the ANIMA work Working Group, it is therefore recommended to introduce a sub-domain subdomain security model, model to reduce the attack surface and not expose a full domain to a potential intruder. Furthermore, additional security mechanisms on the ASA level should be considered for high-risk autonomic functions. </t>
</section>
</section>
<!-- security -->
<section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document requests has no action by IANA. </t>
</section>
<!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Many people have provided feedback and input to this document: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, Tianran Zhou and Christian Hopps.</t>
</section>
<!-- ack -->
<section anchor="contributors" title="Contributors">
<t>Significant contributions to this document have been made by John Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia.</t> IANA actions.</t>
</section>
<!-- contributors -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-anima-bootstrapping-keyinfra.xml"?>
<?rfc include="reference.I-D.ietf-anima-autonomic-control-plane.xml"?>
<?rfc include="reference.I-D.ietf-anima-grasp.xml"?>
<displayreference target="I-D.ietf-anima-asa-guidelines" to="ASA-GUIDELINES"/>
<displayreference target="I-D.du-anima-an-intent" to="ANIMA-INTENT"/>
<displayreference target="I-D.ietf-anima-grasp-distribution" to="GRASP-DISTRIB"/>
<displayreference target="I-D.ietf-supa-generic-policy-data-model" to="SUPA-DATA"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995">
<front>
<title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
<author initials="M" surname="Pritikin" fullname="Max Pritikin">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="M" surname="Behringer" fullname="Michael Behringer">
<organization/>
</author>
<author initials="K" surname="Watsen" fullname="Kent Watsen">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8995"/>
<seriesInfo name="DOI" value="10.17487/RFC8995"/>
</reference>
<reference anchor="RFC8994" target="https://www.rfc-editor.org/info/rfc8994">
<front>
<title>An Autonomic Control Plane (ACP)</title>
<author initials="T" surname="Eckert" fullname="Toerless Eckert" role="editor">
<organization/>
</author>
<author initials="M" surname="Behringer" fullname="Michael Behringer" role="editor">
<organization/>
</author>
<author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnason">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8994"/>
<seriesInfo name="DOI" value="10.17487/RFC8994"/>
</reference>
<reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8990">
<front>
<title>A GeneRic Autonomic Signaling Protocol (GRASP)</title>
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter" role="editor">
<organization/>
</author>
<author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8990"/>
<seriesInfo name="DOI" value="10.17487/RFC8990"/>
</reference>
<reference anchor="IDevID"
target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html"> target="https://1.ieee802.org/security/802-1ar">
<front>
<title>IEEE 802.1AR Standard for Local and metropolitan area networks - Secure Device Identifier</title> Identity
</title>
<author>
<organization>IEEE</organization>
</author>
</front>
<seriesInfo name="IEEE" value="802.1AR"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7576.xml"/>
<reference anchor="RFC8991" target="https://www.rfc-editor.org/info/rfc8991">
<front>
<title>GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)</title>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
<organization/>
</author>
<author initials="W" surname="Wang" fullname="Wendong Wang">
<organization/>
</author>
<author surname="IEEE Standard"></author> initials="X" surname="Gong" fullname="Xiangyang Gong">
<organization/>
</author>
<date month="December" year="2009" /> month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8991"/>
<seriesInfo name="DOI" value="10.17487/RFC8991"/>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7575'?>
<?rfc include='reference.RFC.7576'?>
<?rfc include="reference.I-D.ietf-anima-grasp-api.xml"?>
<?rfc include="reference.I-D.carpenter-anima-asa-guidelines"?>
<?rfc include="reference.I-D.du-anima-an-intent.xml"?>
<?rfc include="reference.I-D.ietf-anima-stable-connectivity.xml"?>
<?rfc include="reference.I-D.liu-anima-grasp-distribution.xml"?>
<?rfc include="reference.I-D.ietf-anima-prefix-management.xml"?>
<?rfc include="reference.I-D.ietf-supa-generic-policy-data-model"?>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-anima-asa-guidelines.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.du-anima-an-intent.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/>
<reference anchor="I-D.ietf-anima-grasp-distribution">
<front>
<title>Information Distribution over GRASP</title>
<author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
<organization/>
</author>
<author initials="X" surname="Xiao" fullname="Xun Xiao" role="editor">
<organization/>
</author>
<author initials="A" surname="Hecker" fullname="Artur Hecker">
<organization/>
</author>
<author initials="S" surname="Jiang" fullname="Sheng Jiang">
<organization/>
</author>
<author initials="Z" surname="Despotovic" fullname="Zoran Despotovic">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<date month="March" day="8" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-grasp-distribution-02"/>
</reference>
<reference anchor="RFC8992" target="https://www.rfc-editor.org/info/rfc8992">
<front>
<title>Autonomic IPv6 Edge Prefix Management in Large-Scale Networks
</title>
<author initials="S" surname="Jiang" fullname="Sheng Jiang" role="editor">
<organization/>
</author>
<author initials="Z" surname="Du" fullname="Zongpeng Du">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="Q" surname="Sun" fullname="Qiong Sun">
<organization/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8992"/>
<seriesInfo name="DOI" value="10.17487/RFC8992"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-supa-generic-policy-data-model.xml"/>
<reference anchor="Meyer97">
<front>
<title>Object-Oriented Software Construction (2nd edition)</title>
<author initials="B." surname="Meyer"></author> surname="Meyer"/>
<date year="1997" /> year="1997"/>
</front>
<seriesInfo name="Prentice-Hall," value='ISBN 978-0136291558' /> name="ISBN" value="978-0136291558"/>
<refcontent>Prentice Hall</refcontent>
</reference>
</references>
</references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The following people provided feedback and input to this document:
<contact fullname="Sheng Jiang"/>, <contact fullname="Roberta Maglione"/>, <contact fullname="Jonathan Hansford"/>, <contact fullname="Jason Coleman"/>, and <contact fullname="Artur Hecker"/>. Useful reviews were made by <contact fullname="Joel Halpern"/>, <contact fullname="Radia Perlman"/>, <contact fullname="Tianran Zhou"/>, and <contact fullname="Christian Hopps"/>.</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>Significant contributions to this document were made by <contact fullname="John Strassner"/> (Huawei), <contact fullname="Bing Liu"/>
(Huawei), and <contact fullname="Pierre Peloso"/> (Nokia).</t>
</section>
</back>
</rfc>