rfc8993xml2.original.xml		rfc8993.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc toc="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- You want a table of contents -->		-ietf-anima-reference-model-10" category="info" obsoletes="" updates="" submissi
	<?rfc symrefs="yes"?>		onType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" ver
	<!-- Use symbolic labels for references -->		sion="3" number="8993" consensus="true">
	<?rfc sortrefs="yes"?>
	<!-- This sorts the references -->
	<?rfc iprnotified="no" ?>
	<!-- Change to "yes" if someone has disclosed IPR for the draft -->
	<?rfc compact="yes"?>
	<rfc ipr="trust200902" docName="draft-ietf-anima-reference-model-10" category="i
	nfo">
	<front>
	<title abbrev="AN Reference Model">A Reference Model for Autonomi
	c Networking</title>
	<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." fullname="Brian Carp
	enter">
	<organization abbrev="Univ. of Auckland"/>
	<address>
	<postal>
	<street>Department of Computer Science</s
	treet>
	<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>
	<address>
	<postal>
	<street>2330 Central Expy</street>
	<city>Santa Clara</city>
	<code>95050</code>
	<country>USA</country>
	</postal>
	<email>tte@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>
	</postal>
	<email>laurent.ciavaglia@nokia.com</email>
	</address>
	</author>
	<author fullname="Jeferson Campos Nobre" initials="J.C." surname=
	"Nobre">
	<organization>University of Vale do Rio dos Sinos</organi
	zation>
	<address>
	<postal>
	<street>Av. Unisinos, 950</street>
	<city>São Leopoldo</city>
	<code>91501-970</code>
	<country>Brazil</country>
	</postal>
	<email>jcnobre@unisinos.br</email>
	</address>
	</author>
	<date day="23" month="November" year="2018"/>		<!-- xml2rfc v2v3 conversion 2.47.0 -->
	<area>Operations and Management</area>		<front>
	<workgroup>ANIMA</workgroup>		<title abbrev="Reference Model for Autonomic Networking">A Reference Model f
	<abstract>		or Autonomic Networking</title>
	<t>		<seriesInfo name="RFC" value="8993"/>
	This document describes a reference model for Autonomic N		<author role="editor" fullname="Michael H. Behringer" initials="M." surname=
	etworking for managed networks. It defines the behaviour of an autonomic node, h		"Behringer">
	ow the various elements in an autonomic context work together, and how autonomic		<address>
	services can use the infrastructure.</t>		<email>Michael.H.Behringer@gmail.com</email>
	</abstract>		</address>
	</front>		</author>
			<author surname="Carpenter" initials="B" fullname="Brian Carpenter">
			<organization abbrev="Univ. of Auckland"/>
			<address>
			<postal>
			<street>School of Computer Science</street>
			<street>University of Auckland</street>
			<street>PB 92019</street>
			<city>Auckland</city>
			<code>1142</code>
			<country>New Zealand</country>
			</postal>
			<email>brian.e.carpenter@gmail.com</email>
			</address>
			</author>
	<middle>		<author fullname="Toerless Eckert" initials="T." surname="Eckert">
	<section anchor="intro" title="Introduction">		<organization>Futurewei USA</organization>
	<t>The document "Autonomic Networking - Definitions and Design Goals" <xr		<address>
	ef target="RFC7575"/> explains the fundamental concepts behind Autonomic Network		<postal>
	ing, and defines the relevant terms in this space, as well as a high level refer		<street>2330 Central Expy</street>
	ence model. <xref target="RFC7576"/> provides a gap analysis between traditional		<city>Santa Clara</city>
	and autonomic approaches. </t>		<region>CA</region>
	<t>This document defines this reference model with more detail, to allow for fun		<code>95050</code>
	ctional and protocol specifications to be developed in an architecturally consis		<country>United States of America</country>
	tent, non-overlapping manner. </t>		</postal>
	<t>As discussed in <xref target="RFC7575"/>, the goal of this work is not		<email>tte+ietf@cs.fau.de</email>
	to focus exclusively on fully autonomic nodes or networks. In reality, most net		</address>
	works will run with some autonomic functions, while the rest of the network is t		</author>
	raditionally managed. This reference model allows for this hybrid approach. </t>		<author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
	<t>For example, it is possible in an existing, non-autonomic network to e		<organization>Nokia</organization>
	nrol devices in a traditional way, to bring up a trust infrastructure with certi		<address>
	ficates. This trust infrastructure could then be used to automatically bring up		<postal>
	an Autonomic Control Plane (ACP), and run traditional network operations over th		<street>Villarceaux</street>
	e secure and self-healing ACP. See <xref target="I-D.ietf-anima-stable-connectiv		<code>91460</code>
	ity"/> for a description of this use case.</t>		<city>Nozay</city>
	<t>The scope of this model is therefore limited to networks that are to s		<region/>
	ome extent managed by skilled human operators, loosely referred to as "professio		<country>France</country>
	nally managed" networks. Unmanaged networks raise additional security and trust		</postal>
	issues that this model does not cover.</t>		<email>laurent.ciavaglia@nokia.com</email>
	<t>This document describes a first, simple, implementable phase of an Aut		</address>
	onomic Networking solution. It is expected that the experience from this phase w		</author>
	ill be used in defining updated and extended specifications over time. Some topi
	cs are considered architecturally in this 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">		<author fullname="Jéferson Campos Nobre" initials="J" surname="Nobre">
	<t>This section describes the various elements in a network with autonomi		<organization abbrev="UFRGS">Federal University of Rio Grande do Sul (UFRG
	c functions, and how these entities work together, on a high level. Subsequent s		S)</organization>
	ections explain the detailed inside view for each of the autonomic network eleme		<address>
	nts, as well as the network functions (or interfaces) between those elements. </		<postal>
	t>		<street>Av. Bento Gonçalves, 9500</street>
			<city>Porto Alegre</city>
			<region>RS</region>
			<code>91501-970</code>
			<country>Brazil</country>
			</postal>
			<email>jcnobre@inf.ufrgs.br</email>
			</address>
			</author>
			<date month="May" year="2021"/>
			<area>Operations and Management</area>
			<workgroup>ANIMA</workgroup>
	<t><xref target="network-view"/> shows the high level view of an Autonomi		<keyword>autonomous operation</keyword>
	c Network. It consists of a number of autonomic nodes, which interact directly w		<keyword>self-management</keyword>
	ith each other. Those autonomic nodes provide a common set of capabilities acros		<keyword>infrastructure</keyword>
	s the network, called the "Autonomic Networking Infrastructure" (ANI). The ANI p		<keyword>intent</keyword>
	rovides functions like naming, addressing, negotiation, synchronization, discove		<keyword>autonomic control plane</keyword>
	ry and messaging. </t>		<keyword>autonomic networking</keyword>
	<t>Autonomic functions typically span several, possibly all nodes in the		<abstract>
	network. The atomic entities of an autonomic function are called the "Autonomic		<t>
	Service Agents" (ASA), which are instantiated on nodes. </t>		This document describes a reference model for Autonomic N
			etworking for managed networks. It defines the behavior of an autonomic node, ho
			w the various elements in an autonomic context work together, and how autonomic
			services can use the infrastructure.</t>
			</abstract>
			</front>
			<middle>
			<section anchor="intro" numbered="true" toc="default">
			<name>Introduction</name>
			<t>The document "<xref target="RFC7575" format="title"/>" <xref target="RF
			C7575" format="default"/> explains the fundamental concepts behind Autonomic Net
			working and defines the relevant terms in this space and a high-level reference
			model. <xref target="RFC7576" format="default"/> provides a gap analysis between
			traditional and autonomic approaches. </t>
			<t>This document defines this reference model with more detail to allow fo
			r functional and protocol specifications to be developed in an architecturally c
			onsistent, non-overlapping manner. </t>
			<t>As discussed in <xref target="RFC7575" format="default"/>, the goal of
			this work is not to focus exclusively on fully autonomic nodes or networks. In r
			eality, most networks will run with some autonomic functions, while the rest of
			the network is traditionally managed. This reference model allows for this hybri
			d approach. </t>
			<t>For example, it is possible in an existing, non-autonomic network to en
			roll devices in a traditional way to bring up a trust infrastructure with certif
			icates. This trust infrastructure could then be used to automatically bring up a
			n Autonomic Control Plane (ACP) and run traditional network operations over the
			secure and self-healing ACP. See <xref 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 so
			me extent managed by skilled human operators, loosely referred to as "profession
			ally managed" networks. Unmanaged networks raise additional security and trust i
			ssues that this model does not cover.</t>
			<t>This document describes the first phase of an Autonomic Networking solu
			tion that is both simple and implementable. It is expected that the experience
			from this phase will be used in defining updated and extended specifications ove
			r time. Some topics are considered architecturally in this document but are not
			yet reflected in the implementation specifications. They are marked with an (*).
			</t>
			</section>
	<figure anchor='network-view' title="High level view of an Autonomic Network">		<section anchor="network" numbered="true" toc="default">
	<artwork>		<name>Network View</name>
			<t>This section describes the various elements in a network with autonomic
			functions and explains how these entities work together on a high level. Subseq
			uent sections explain the detailed inside view for each of the Autonomic Network
			elements, as well as the network functions (or interfaces) between those elemen
			ts. </t>
			<t><xref target="network-view" format="default"/> shows the high-level vie
			w of an Autonomic Network. It consists of a number of autonomic nodes, which int
			eract directly with each other. Those autonomic nodes provide a common set of ca
			pabilities across the network, called the "Autonomic Networking Infrastructure (
			ANI)". The ANI provides functions like naming, addressing, negotiation, synchron
			ization, discovery, and messaging. </t>
			<t>Autonomic functions typically span several, possibly all, nodes in the
			network. The atomic entities of an autonomic function are called the "Autonomic
			Service Agents (ASAs)", which are instantiated on nodes. </t>
			<figure anchor="network-view">
			<name>High-Level View of an Autonomic Network</name>
			<artwork name="" type="" align="left" alt=""><![CDATA[
	+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +		+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
	: : Autonomic Function 1 : :		: : Autonomic Function 1 : :
	: ASA 1 : ASA 1 : ASA 1 : ASA 1 :		: ASA 1 : ASA 1 : ASA 1 : ASA 1 :
	+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +		+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
	: : :		: : :
	: +- - - - - - - - - - - - - - + :		: +- - - - - - - - - - - - - - + :
	: : Autonomic Function 2 : :		: : Autonomic Function 2 : :
	: : ASA 2 : ASA 2 : :		: : ASA 2 : ASA 2 : :
	: +- - - - - - - - - - - - - - + :		: +- - - - - - - - - - - - - - + :
	: : :		: : :
	+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +		+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
	: Autonomic Networking Infrastructure :		: Autonomic Networking Infrastructure :
	+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +		+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
	+--------+ : +--------+ : +--------+ : +--------+		+--------+ : +--------+ : +--------+ : +--------+
	| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |		| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
	+--------+ : +--------+ : +--------+ : +--------+		+--------+ : +--------+ : +--------+ : +--------+
	</artwork>		]]></artwork>
	</figure>		</figure>
	<t>In a horizontal view, autonomic functions span across the network, as		<t>In a horizontal view, autonomic functions span across the network, as w
	well as the Autonomic Networking Infrastructure. In a vertical view, a node alwa		ell as the ANI. In a vertical view, a node always implements the ANI, plus it ma
	ys implements the ANI, plus it may have one or several Autonomic Service Agents.		y have one or several ASAs. ASAs may be standalone or use other ASAs in a hierar
	ASAs may be standalone, or use other ASAs in a hierarchical way.</t>		chical way.</t>
	<t>The Autonomic Networking Infrastructure (ANI) therefore is the foundat		<t>Therefore, the ANI is the foundation for autonomic functions. </t>
	ion for autonomic functions. </t>		</section>
	</section>
	<!-- network -->
	<section anchor="element" title="The Autonomic Network Element">
	<t>This section explains the general architecture of an Autonomic Network Elemen		<section anchor="element" numbered="true" toc="default">
	t (<xref target="element-arch"/>), how it tracks its surrounding environment in		<name>Autonomic Network Element</name>
	an Adjacency Table (<xref target="adjacency-table"/>), and the state machine whi		<t>This section explains the general architecture of an Autonomic Network
	ch defines the behaviour of the network element (<xref target="state-machine"/>)		element (<xref target="element-arch" format="default"/>), how it tracks its surr
	,		ounding environment in an adjacency table (<xref target="adjacency-table" format
			="default"/>), and the state machine that defines the behavior of the network el
			ement (<xref target="state-machine" format="default"/>),
	based on that adjacency table.</t>		based on that adjacency table.</t>
			<section anchor="element-arch" numbered="true" toc="default">
	<section anchor="element-arch" title="Architecture">		<name>Architecture</name>
			<t>This section describes an Autonomic Network element and its internal
	<t>This section describes an autonomic network element an		architecture. The reference model explained in the document "<xref target="RFC75
	d its internal architecture. The reference model explained in the document <xref		75" format="title"/>" <xref target="RFC7575" format="default"/> shows the source
	target="RFC7575">"Autonomic Networking - Definitions and Design Goals"</xref> s		s of information that an ASA can leverage: self-knowledge, network knowledge (th
	hows the sources of information that an autonomic service agent can leverage: Se		rough discovery), Intent (see <xref target="intent" format="default"/>), and fee
	lf-knowledge, network knowledge (through discovery), Intent (see <xref target="i		dback loops. There are two levels inside an autonomic node: the level of ASAs an
	ntent"/>), and feedback loops. There are two levels inside an autonomic node: th		d the level of the ANI, with the former using the services of the latter. <xref
	e level of Autonomic Service Agents, and the level of the Autonomic Networking I		target="ref_model" format="default"/> illustrates this concept.
	nfrastructure, with the former using the services of the latter. <xref target="r		</t>
	ef_model"/> illustrates this concept.		<figure anchor="ref_model">
	</t>		<name>Model of an Autonomic Node</name>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure anchor='ref_model' title="Model of an autonomic node">
	<artwork>
	+------------------------------------------------------------+		+------------------------------------------------------------+
	| |		| |
	| +-----------+ +------------+ +------------+ |		| +-----------+ +------------+ +------------+ |
	| | Autonomic | | Autonomic | | Autonomic | |		| | Autonomic | | Autonomic | | Autonomic | |
	| | Service | | Service | | Service | |		| | Service | | Service | | Service | |
	| | Agent 1 | | Agent 2 | | Agent 3 | |		| | Agent 1 | | Agent 2 | | Agent 3 | |
	| +-----------+ +------------+ +------------+ |		| +-----------+ +------------+ +------------+ |
	| ^ ^ ^ |		| ^ ^ ^ |
	| - - | - - API level - -| - - - - - - - |- - - |		| - - | - - API level - -| - - - - - - - |- - - |
	| V V V |		| V V V |
	|------------------------------------------------------------|		|------------------------------------------------------------|
	| Autonomic Networking Infrastructure |		| Autonomic Networking Infrastructure |
	| - Data structures (ex: certificates, peer information) |		| - Data structures (ex: certificates, peer information) |
	| - Generalized Autonomic Control Plane (GACP) |		| - Generalized Autonomic Control Plane (GACP) |
	| - Autonomic Node Addressing and naming |		| - Autonomic node addressing and naming |
	| - Discovery, negotiation and synchronisation functions |		| - Discovery, negotiation and synchronization functions |
	| - Distribution of Intent and other information |		| - Distribution of Intent and other information |
	| - Aggregated reporting and feedback loops |		| - Aggregated reporting and feedback loops |
	| - Routing |		| - Routing |
	|------------------------------------------------------------|		|------------------------------------------------------------|
	| Basic Operating System Functions |		| Basic Operating System Functions |
	+------------------------------------------------------------+		+------------------------------------------------------------+
	</artwork>		]]></artwork>
	</figure>		</figure>
	</t>		<t>The ANI (lower part of <xref target="ref_model" format="default"/>) c
			ontains node-specific data structures (for example, trust information about itse
	<t>The Autonomic Networking Infrastructure (lower part of		lf and its peers) as well as a generic set of functions, independent of a partic
	<xref target="ref_model"/>) contains node specific data structures, for example		ular usage. This infrastructure should be generic and support a variety of ASAs
	trust information about itself and its peers, as well as a generic set of funct		(upper part of <xref target="ref_model" format="default"/>). It contains address
	ions, independent of a particular usage. This infrastructure should be generic,		ing and naming of autonomic nodes, discovery, negotiation and synchronization fu
	and support a variety of Autonomic Service Agents (upper part of <xref target="r		nctions, distribution of information, reporting, feedback loops, and routing ins
	ef_model"/>). It contains addressing and naming of autonomic nodes, discovery, n		ide the ACP.</t>
	egotiation and synchronisation functions, distribution of information, reporting		<t>The Generalized ACP (GACP) is the summary of all interactions of the
	and feedback loops, as well as routing inside the Autonomic Control Plane.</t>		ANI with other nodes and services. A specific implementation of the GACP is refe
			rred to here as the ACP and described in <xref target="RFC8994" format="default"
	<t>The Generalized Autonomic Control Plane (GACP) is the		/>.</t>
	summary of all interactions of the Autonomic Networking Infrastructure with othe		<t>The use cases of "Autonomics" (such as self-management, self-optimiza
	r nodes and services. A specific implementation of the GACP is referred to here		tion, etc.) are implemented as ASAs. They use the services and data structures o
	as the Autonomic Control Plane (ACP), and described in <xref target="I-D.ietf-an		f the underlying ANI, which should be self-managing. </t>
	ima-autonomic-control-plane"/>.</t>
	<t>The use cases of "Autonomics" such as self-management,
	self-optimisation, etc, are implemented as Autonomic Service Agents. They use t
	he services and data structures of the underlying Autonomic Networking Infrastru
	cture, which should be self-managing. </t>
	<t>The "Basic Operating System Functions" include the "no
	rmal OS", including the network stack, security functions, etc. </t>
	<t>Full AN nodes have the full Autonomic Networking Infrastruc
	ture, with the full functionality described in this document. At a later stage A
	NIMA may define a scope for constrained nodes with a reduced ANI and well-define
	d minimal functionality. They are currently out of scope. </t>
	</section>
	<!-- element-architecture -->
	<section anchor="adjacency-table" title="The Adjacency Table">
	<!-- old section 5 start -->
	<t>Autonomic Networking is based on direct interactions between devices o
	f a domain. The Autonomic Control Plane (ACP) is normally constructed on a hop-b
	y-hop basis. Therefore, many interactions in the ANI are based on the ANI adjace
	ncy table. There are interactions that provide input into the adjacency table, a
	nd other interactions that leverage the information contained in it.</t>
	<t>The ANI adjacency table contains information about adjacent autonomic
	nodes, at a minimum: node-ID, IP address in data plane, IP address in ACP, domai
	n, 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. Howeve
	r, the information is tracked independently of the status of the peer nodes; spe
	cifically, it contains information about non-enrolled nodes, nodes of the same a
	nd 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 discovery: This interaction happens in the data pla
	ne, using IPv6 link local addressing only, because this addressing type is itsel
	f autonomic. This way the nodes learns about all autonomic nodes around itself.
	The related standards track documents (<xref target="I-D.ietf-anima-grasp"/>, <x
	ref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, <xref target="I-D.ietf-ani
	ma-autonomic-control-plane"/>) describe in detail how link local discovery is us
	ed.</t>
	<t>Vendor re-direct: A new device may receive information on wher
	e its home network is through a vendor based Manufacturer Authorized Signing Aut
	hority (MASA, see <xref target="masa"/>) re-direct; this is typically a routable
	address. </t>
	<t>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 such non-autonomic mechansims req
	uire some administrator intervention. The key purpose is to by-pass a non-autono
	mic device or network. As this pertains to new devices, it is covered in appendi
	x A and B of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>
	</list></t>
	<t>The adjacency table is defining the behaviour of an autonomic node:
	<list style="symbols">
	<t>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, and will attempt bootstrapping through them, one by
	one. One possible response is a re-direct via a vendor MASA, which will be ente
	red into the adjacency table (see second bullet above). See <xref target="I-D.ie
	tf-anima-bootstrapping-keyinfra"/> for details. </t>
	<t>If the adjacent node has the same domain, it will authenticate
	that adjacent node and, if successful, establish the Autonomic Control Plane (A
	CP). See <xref target="I-D.ietf-anima-autonomic-control-plane"/>.</t>
	<t>Once the node is part of the ACP of a domain, it will use GRAS
	P <xref target="I-D.ietf-anima-grasp"/> to find Registrar(s) of its domain and p
	otentially other services.</t>
	<t>If the node is part of an ACP and has discovered at least one
	Registrar in its domain via GRASP, it will start the "join assistant" ASA, and a
	ct as a join assistant for neighboring nodes that need to be bootstrapped. See <
	xref target="join-assitant"/> for details. </t>
	<t>Other behaviours are possible, for example establishing the AC
	P also with devices of a sub-domain, to other domains, etc. Those will likely be
	controlled by Intent. They are outside scope for the moment. Note that Intent i
	s distributed through the ACP; therefore, a node can only adapt Intent driven be
	haviour once it has joined the ACP. At the moment, ANIMA does not consider provi
	ding Intent outside the ACP; this can be considered later. </t>
	</list></t>
	<t>Once a node has joined the ACP, it will also learn the ACP addresses o
	f its adjacent nodes, and add them to the adjacency table, to allow for communic
	ation inside the ACP. Further autonomic domain interactions will now happen insi
	de the ACP. At this moment, only negotiation / synchronization via GRASP <xref t
	arget="I-D.ietf-anima-grasp"/> is being defined. (Note that GRASP runs in the da
	ta plane, as an input in building the adjacency table, as well as inside the ACP
	.) </t>
	<t>Autonomic Functions consist of Autonomic Service Agents (ASAs). They r
	un logically above the AN Infrastructure, and may use the adjacency table, the A
	CP, negotiation and synchronization through GRASP in the ACP, Intent and other f
	unctions of the ANI. Since the ANI only provides autonomic interactions within a
	domain, autonomic functions can also use any other context on a node, specifica
	lly the global data plane. </t>
	</section>
	<!-- end section adjacency table -->
	<!-- old section 5 end -->
	<section anchor="state-machine" title="State Machine">		<t>The Basic Operating System Functions (lower part of <xref target="ref
			_model" format="default"/>) include the normal OS (e.g., the network stack and s
			ecurity functions). </t>
			<t>Full Autonomic Network (AN) nodes have the full ANI, with the full fu
			nctionality described in this document. At a later stage, the ANIMA Working Grou
			p may define a scope for constrained nodes with a reduced ANI and well-defined m
			inimal functionality. These are currently out of scope. </t>
			</section>
	<t>Autonomic Networking applies during the full life-cycle of a node. Thi		<section anchor="adjacency-table" numbered="true" toc="default">
	s section describes a state machine of an autonomic node, throughout its life.</		<name>Adjacency Table</name>
	t>
	<t>A device is normally expected to store its domain specific identity, t
	he LDevID (see <xref target="cert"/>), in persistent storage, to be available af
	ter a powercycle event. For device types that cannot store the LDevID in persist
	ent storage, a powercycle event is effectively equivalent to a factory reset. </
	t>
	<section anchor="state-1" title="State 1: Factory Default">		<t>Autonomic Networking is based on direct interactions between devices o
	<t>An autonomic node leaves the factory in this state. In		f a domain. The ACP is normally constructed on a hop-by-hop basis. Therefore, ma
	this state, the node has no domain specific configuration, specifically no LDev		ny interactions in the ANI are based on the ANI adjacency table. There are inter
	ID, and could be used in any particular target network. It does however have a v		actions that provide input into the adjacency table and other interactions that
	endor/manufacturer specific ID, the IDevID <xref target="IDevID"></xref>. Nodes		leverage the information contained in it.</t>
	without IDevID cannot be autonomically and securely enrolled into a domain; they		<t>The ANI adjacency table contains, at a minimum, information about adj
	require manual pre-staging, in which case the pre-staging takes them directly t		acent autonomic nodes: Node-ID, IP address in data plane, IP address in ACP, dom
	o state 2.</t>		ain, and certificate. An autonomic node maintains this adjacency table up to dat
			e. The adjacency table only contains information about other nodes that are capa
			ble of Autonomic Networking; non-autonomic nodes are normally not tracked here.
			However, the information is tracked independently of the status of the peer node
			s; specifically, the adjacency table contains information about non-enrolled nod
			es of the same and other domains. The adjacency table may contain information ab
			out the validity and trust level of the adjacent autonomic nodes.</t>
			<t>The adjacency table is fed by the following inputs:
			</t>
			<ul spacing="normal">
			<li>Link-local discovery: This interaction happens in the data plane,
			using IPv6 link-local addressing only, because this addressing type is itself au
			tonomic. This way the node learns about all autonomic nodes around itself. The r
			elated Standards Track documents (<xref target="RFC8990" format="default"/>, <xr
			ef target="RFC8995" format="default"/>, and <xref target="RFC8994" format="defau
			lt"/>) describe in detail how link-local discovery is used.</li>
			<li>Vendor redirect: A new device may receive information on where its
			home network is through a vendor-based Manufacturer Authorized Signing Authorit
			y (MASA) (see <xref target="masa" format="default"/>) redirect; this is typicall
			y a routable address. </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, such
			non-autonomic mechanisms require some administrator
			intervention. The key purpose is to bypass a non-autonomic device
			or network. As this pertains to new devices, it is covered in Appendice
			s
			<xref target="RFC8995" sectionFormat="bare" section="A"/> and <xref ta
			rget="RFC8995" sectionFormat="bare" section="B"/> of <xref target="RFC8995"/>.</
			li>
			</ul>
			<t>The adjacency table defines the behavior of an autonomic node:
			</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 and will attempt bootstrapping through them, one by one.
			One possible response is a redirect via a vendor MASA, which will be entered in
			to the adjacency table (see second bullet above). See <xref target="RFC8995" for
			mat="default"/> for details. </li>
			<li>If the adjacent node has the same domain, it will authenticate tha
			t adjacent node and, if successful, establish the ACP. See <xref target="RFC8994
			" format="default"/>.</li>
			<li>Once the node is part of the ACP of a domain, it will use GRASP <x
			ref target="RFC8990" format="default"/> to find the registrar(s) of its domain a
			nd potentially other services.</li>
			<li>If the node is part of an ACP and has discovered at least one regi
			strar in its domain via GRASP, it will start the join proxy ASA and act as a joi
			n proxy for neighboring nodes that need to be bootstrapped. See <xref target="jo
			in-assitant" format="default"/> for details. </li>
			<li>Other behaviors are possible, for example, establishing the ACP wi
			th devices of a subdomain or other domains. These will likely be controlled by I
			ntent and are outside the scope of this document. Note that Intent is distribute
			d through the ACP; therefore, a node can only adapt 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. </li>
			</ul>
			<t>Once a node has joined the ACP, it will also learn the ACP addresses
			of its adjacent nodes and add them to the adjacency table to allow for communica
			tion inside the ACP. Further autonomic domain interactions will now happen insid
			e the ACP. At this moment, only negotiation and synchronization via GRASP <xref
			target="RFC8990" format="default"/> are defined. (Note that GRASP runs in the da
			ta plane, as an input in building the adjacency table, as well as inside the ACP
			.) </t>
			<t>Autonomic functions consist of ASAs. They run logically above the ANI
			and may use the adjacency table, the ACP, negotiation and synchronization throu
			gh GRASP in the ACP, Intent, and other functions of the ANI. Since the ANI only
			provides autonomic interactions within a domain, autonomic functions can also us
			e any other context on a node, specifically the global data plane. </t>
			</section>
	<t>Transitions:		<section anchor="state-machine" numbered="true" toc="default">
	<list style="symbols">		<name>State Machine</name>
	<t>Bootstrap event: The device enrols into a domain; as p
	art of this process it receives a domain identity (LDevID). If enrollment is suc
	cessful, the next state is state 2. See <xref target="I-D.ietf-anima-bootstrappi
	ng-keyinfra"/> Section 3 for details on enrollment.</t>
	<t>Powercycle event: The device loses all state tables. I
	t remains in state: 1.</t>
	</list> </t>
	</section>
	<!-- state-1 -->
	<section anchor="state-2" title="State 2: Enrolled">		<t>Autonomic Networking applies during the full life cycle of a node. Th
	<t>An autonomic node is in the state "enrolled" if it has		is section describes a state machine of an autonomic node throughout its life.</
	a domain identity (LDevID), and has currently no ACP channel up. It may have fu		t>
	rther configuration or state, for example if it had been in state 3 before, but		<t>A device is normally expected to store its domain-specific identity,
	lost all its ACP channels. The LDevID can only be removed from a device through		the Local Device Identifier (LDevID) (see <xref target="cert" format="default"/>
	a factory reset, which also removes all other state from the device. This ensure		), in persistent storage to be available after a power-cycle event. For device t
	s that a device has no stale domain specific state when entering the "enrolled"		ypes that cannot store the LDevID in persistent storage, a power-cycle event is
	state from state 1.</t>		effectively equivalent to a factory reset. </t>
			<section anchor="state-1" numbered="true" toc="default">
			<name>State 1: Factory Default</name>
			<t>An autonomic node leaves the factory in this state. In this state,
			the node has no domain-specific configuration, specifically no LDevID, and could
			be used in any particular target network. It does, however, have a vendor/manuf
			acturer-specific ID, the Initial Device Identifier (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-s
			taging takes them directly to state 2.</t>
			<t>Transitions:
			</t>
			<ul spacing="normal">
	<t>Transitions:		<li>Bootstrap event: The device enrolls into a domain; as part of
	<list style="symbols">		this process it receives a domain identity (LDevID). If enrollment
	<t>Joining ACP: The device establishes an ACP channel to		is successful, the next state is state 2. See <xref target="RFC8995"
	an adjacent device. See <xref target="I-D.ietf-anima-autonomic-control-plane"/>		format="default"/> for details on enrollment.</li>
	for details. Next state: 3.</t>		<li>Power-cycle event: The device loses all state tables. It remains
	<t>Factory reset: A factory reset removes all configurati		in state 1.</li>
	on and the domain identity (LDevID) from the device. Next state: 1.</t>		</ul>
	<t>Powercycle event: The device loses all state tables, b		</section>
	ut not its domain identity (LDevID). it remains in state: 2.</t>
	</list> </t>
	</section>
	<!-- state-2 -->
	<section anchor="state-3" title="State 3: In ACP">		<section anchor="state-2" numbered="true" toc="default">
	<t>In this state, the autonomic node has at least one ACP		<name>State 2: Enrolled</name>
	channel to another device. The node can now participate in further autonomic tr		<t>An autonomic node is in the "enrolled" state if it has a domain ide
	ansactions, such as starting autonomic service agents (e.g., it must now enable		ntity (LDevID) and has currently no ACP channel up. It may have further configur
	the join assistant ASA, to help other devices to join the domain. Other conditio		ation or state, for example, if it had been in state 3 before but lost all its A
	ns may apply to such interactions, for example to serve as a join assistant, the		CP channels. The LDevID can only be removed from a device through a factory rese
	device must first discover a bootstrap Registrar. </t>		t, which also removes all other state from the device. This ensures that a devic
			e has no stale domain-specific state when entering the "enrolled" state from sta
			te 1.</t>
			<t>Transitions:
			</t>
			<ul spacing="normal">
			<li>Joining ACP: The device establishes an ACP channel to an adjacen
			t device. See <xref target="RFC8994" format="default"/> for details. Next state:
			3.</li>
			<li>Factory reset: A factory reset removes all configuration and the
			domain identity (LDevID) from the device. Next state: 1.</li>
			<li>Power-cycle event: The device loses all state tables, but not it
			s domain identity (LDevID). It remains in state 2.</li>
			</ul>
			</section>
	<t>Transitions:		<section anchor="state-3" numbered="true" toc="default">
	<list style="symbols">		<name>State 3: In ACP</name>
	<t>Leaving ACP: The device drops the last (or only) ACP c		<t>In this state, the autonomic node has at least one ACP channel to a
	hannel to an adjacent device. Next state: 2.</t>		nother device. The node can now participate in further autonomic transactions, s
	<t>Factory reset: A factory reset removes all configurati		uch as starting ASAs (e.g., it must now enable the join proxy ASA, to help other
	on and the domain identity (LDevID) from the device. Next state: 1.</t>		devices to join the domain). Other conditions may apply to such interactions, f
	<t>Powercycle event: The device loses all state tables, b		or example, to serve as a join proxy, the device must first discover a bootstrap
	ut not its domain identity (LDevID). Next state: 2.</t>		registrar. </t>
	</list> </t>		<t>Transitions:
	</section>		</t>
	<!-- state-3 -->		<ul spacing="normal">
			<li>Leaving ACP: The device drops the last (or only) ACP channel to
			an adjacent device. Next state: 2.</li>
			<li>Factory reset: A factory reset removes all configuration and the
			domain identity (LDevID) from the device. Next state: 1.</li>
			<li>Power-cycle event: The device loses all state tables but not its
			domain identity (LDevID). Next state: 2.</li>
			</ul>
			</section>
	</section>		</section>
	<!-- state-machine -->
	</section>		</section>
	<!-- element -->
	<section anchor="ani" title="The Autonomic Networking Infrastructure">
	<t>The Autonomic Networking Infrastructure provides a layer of common fun
	ctionality across an Autonomic Network. It provides the elementary functions and
	services, as well as extensions. An Autonomic Function, comprising of Autonomic
	Service Agents on nodes, uses the functions described in this section. </t>
	<section anchor="naming" title="Naming">
	<t>Inside a domain, each autonomic device should be assigned a unique
	name. The naming scheme should be consistent within a domain. Names are typical
	ly assigned by a Registrar at bootstrap time and persistent over the lifetime of
	the device. All Registrars in a domain must follow the same naming scheme.</t>
	<t>In the absence of a domain specific naming scheme, a default n
	aming scheme should use the same logic as the addressing scheme discussed in <xr
	ef target="I-D.ietf-anima-autonomic-control-plane"/>. The device name is then co
	mposed of a Registrar ID (for example taking a MAC address of the 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, the fourth field is the se
	quential number for the device.</t>
	</section>
	<!-- naming -->
	<section anchor="addressing" title="Addressing">
	<t>Autonomic Service Agents (ASAs) need to communicate with each other, u
	sing the autonomic addressing of the Autonomic Networking Infrastructure of the
	node they reside on. This section describes the addressing approach of the Auton
	omic Networking Infrastructure, used by ASAs. </t>
	<t>Addressing approaches for the data plane of the network are outside th
	e scope of this document. These addressing approaches may be configured and mana
	ged in the traditional way, or negotiated as a service of an ASA. One use case f
	or such an autonomic function is described in <xref target="I-D.ietf-anima-prefi
	x-management"/>.</t>
	<t>Autonomic addressing is a function of the Autonomic Networking
	Infrastructure (lower part of <xref target="ref_model"/>), specifically the Aut
	onomic Control Plane. ASAs do not have their own addresses. They may use either
	API calls, or the autonomic addressing scheme of the Autonomic Networking Infras
	tructure. </t>
	<t>An autonomic addressing scheme has the following requirements:
	<list style="symbols">
	<t>Zero-touch for simple networks: Simple networks should
	have complete self-management of addressing, and not require any central addres
	s management, tools, or address planning. </t>
	<t>Low-touch for complex networks: If complex networks re
	quire operator input for autonomic address management, it should be limited to h
	igh level guidance only, expressed in Intent.</t>
	<t>Flexibility: The addressing scheme must be flexible en
	ough for nodes to be able to move around, for the network to grow, split and mer
	ge. </t>
	<t>Robustness: It should be as hard as possible for an ad
	ministrator to negatively affect addressing (and thus connectivity) in the auton
	omic context. </t>
	<t>Stability: The addressing scheme should be as stable as possible. Howev
	er, implementations need to be able to recover from unexpected address changes.
	</t>
	<t>Support for virtualization: Autonomic functions can ex
	ist either at the level of the physical network and physical devices, or at the
	level of virtual machines, containers and networks. In particular, Autonomic Nod
	es may support Autonomic Service Agents in virtual entities. The infrastructure,
	including the addressing scheme, should be able to support this architecture. <
	/t>
	<t>Simplicity: To make engineering simpler, and to give t
	he human administrator an easy way to trouble-shoot autonomic functions. </t>
	<t>Scale: The proposed scheme should work in any network
	of any size. </t>
	<t>Upgradability: The scheme must be able to support diff
	erent addressing concepts in the future. </t>
	</list>
	</t>
	<t>The proposed addressing scheme is described in the document "A
	n Autonomic Control Plane" (<xref target="I-D.ietf-anima-autonomic-control-plane
	"/>).</t>
	</section>
	<!-- addressing -->
	<section anchor="discovery" title="Discovery">		<section anchor="ani" numbered="true" toc="default">
	<t>Traditionally, most of the information a node requires		<name>Autonomic Networking Infrastructure</name>
	is provided through configuration or northbound interfaces. An autonomic functi		<t>The ANI provides a layer of common functionality across an Autonomic Ne
	on should rely on such northbound interfaces minimally or not at all, and theref		twork. It provides the elementary functions and services, as well as extensions.
	ore it needs to discover peers and other resources in the network. This section		An autonomic function, comprising of ASAs on nodes, uses the functions describe
	describes various discovery functions in an autonomic network.</t>		d in this section. </t>
			<section anchor="naming" numbered="true" toc="default">
	<t>Discovering nodes and their properties and capabilitie		<name>Naming</name>
	s: A core function to establish an autonomic domain is the mutual discovery of a		<t>Inside a domain, each autonomic device should be assigned a unique na
	utonomic nodes, primarily adjacent nodes and secondarily off-link peers. This ma		me. The naming scheme should be consistent within a domain. Names are typically
	y in principle either leverage existing discovery mechanisms, or use new mechani		assigned by a registrar at bootstrap time and are persistent over the lifetime o
	sms tailored to the autonomic context. An important point is that discovery must		f the device. All registrars in a domain must follow the same naming scheme.</t>
	work in a network with no predefined topology, ideally no manual configuration		<t>In the absence of a domain-specific naming scheme, a default naming s
	of any kind, and with nodes starting up from factory condition or after any form		cheme should use the same logic as the addressing scheme discussed in <xref targ
	of failure or sudden topology change.</t>		et="RFC8994" format="default"/>. The device name is then composed of a Registrar
			-ID (for example, taking a Media Access Control (MAC) address of the registrar)
			and a device number. An example name would then look like this: </t>
			<t>0123-4567-89ab-0001</t>
	<t>Discovering services: Network services such as AAA sho		<t>The first three fields are the MAC address, and the fourth field is t
	uld also be discovered and not configured. Service discovery is required for suc		he sequential number for the device.</t>
	h tasks. An autonomic network can either leverage existing service discovery fun		</section>
	ctions, or use a new approach, or a mixture.</t>
	<t>Thus the discovery mechanism could either be fully int		<section anchor="addressing" numbered="true" toc="default">
	egrated with autonomic signaling (next section) or could use an independent disc		<name>Addressing</name>
	overy mechanism such as DNS Service Discovery or Service Location Protocol. This		<t>ASAs need to communicate with each other, using the autonomic address
	choice could be made independently for each Autonomic Service Agent, although t		ing of the ANI of the node they reside on. This section describes the addressing
	he infrastructure might require some minimal lowest common denominator (e.g., fo		approach of the ANI used by ASAs. </t>
	r discovering the security bootstrap mechanism, or the source of information dis		<t>Addressing approaches for the data plane of the network are outside t
	tribution, <xref target="info-distri"/>).</t>		he scope of this document. These addressing approaches may be configured and man
			aged in the traditional way or negotiated as a service of an ASA. One use case f
			or such an autonomic function is described in <xref target="RFC8992" format="def
			ault"/>.</t>
			<t>Autonomic addressing is a function of the ANI (lower part of <xref ta
			rget="ref_model" format="default"/>), specifically the ACP. ASAs do not have the
			ir own addresses. They may use either API calls or the autonomic addressing sche
			me of the ANI. </t>
			<t>An autonomic addressing scheme has the following requirements:
			</t>
			<ul spacing="normal">
			<li>Zero-touch for simple networks: Simple networks should have comple
			te self-management of addressing and not require any central address management,
			tools, or address planning. </li>
			<li>Low-touch for complex networks: If complex networks require operat
			or input for autonomic address management, it should be limited to high-level gu
			idance only, expressed in Intent.</li>
			<li>Flexibility: The addressing scheme must be flexible enough for nod
			es to be able to move around and for the network to grow, split, and merge. </li
			>
			<li>Robustness: It should be as hard as possible for an administrator
			to negatively affect addressing (and thus connectivity) in the autonomic context
			. </li>
			<li>Stability: The addressing scheme should be as stable as possible.
			However, implementations need to be able to recover from unexpected address chan
			ges. </li>
			<li>Support for virtualization: Autonomic functions can exist either a
			t the level of the physical network and physical devices or at the level of virt
			ual machines, containers, and networks. In particular, autonomic nodes may suppo
			rt ASAs in virtual entities. The infrastructure, including the addressing scheme
			, should be able to support this architecture. </li>
			<li>Simplicity: The addressing scheme should be simple to make enginee
			ring easier and to give the human administrator an easy way to troubleshoot auto
			nomic functions. </li>
			<li>Scale: The proposed scheme should work in any network of any size.
			</li>
			<li>Upgradability: The scheme must be able to support different addres
			sing concepts in the future. </li>
			</ul>
			<t>The proposed addressing scheme is described in the document "<xref ta
			rget="RFC8994" format="title"/>" <xref target="RFC8994" format="default"/>.</t>
			</section>
	<t>Phase 1 of Autonomic Networking uses GRASP for discove		<section anchor="discovery" numbered="true" toc="default">
	ry, described in <xref target="I-D.ietf-anima-grasp"/>.</t>		<name>Discovery</name>
	</section>		<t>Traditionally, most of the information a node requires is provided th
	<!-- discovery -->		rough configuration or northbound interfaces. An autonomic function should rely
			on such northbound interfaces minimally or not at all; therefore, it needs to d
			iscover peers and other resources in the network. This section describes variou
			s discovery functions in an Autonomic Network.</t>
			<t>First, discovering nodes and their properties and capabilities is a c
			ore function to establish an autonomic domain is the mutual discovery of autonom
			ic nodes, primarily adjacent nodes and secondarily off-link peers. This may, in
			principle, either leverage existing discovery mechanisms or use new mechanisms
			tailored to the autonomic context. An important point is that discovery must wo
			rk 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>Second, network services such as Authentication, Authorization, and A
			ccounting (AAA) should also be discovered and not configured. Service discovery
			is required for such tasks. An Autonomic Network can leverage existing service
			discovery functions, use a new approach, or use a mixture.</t>
			<t>Thus, the discovery mechanism could either be fully integrated with a
			utonomic signaling (next section) or use an independent discovery mechanism such
			as DNS-based Service Discovery or the Service Location Protocol. This choice co
			uld be made independently for each ASA, although the infrastructure might requir
			e some minimal lowest common denominator (e.g., for discovering the security boo
			tstrap mechanism or the source of information distribution (<xref target="info-d
			istri" format="default"/>)).</t>
			<t>Phase 1 of Autonomic Networking uses GRASP <xref target="RFC8990" for
			mat="default"/> for discovery.</t>
			</section>
	<section anchor="negotiation" title="Signaling Between Autonomic Nodes">		<section anchor="negotiation" numbered="true" toc="default">
	<t>Autonomic nodes must communicate with each other, for		<name>Signaling between Autonomic Nodes</name>
	example to negotiate and/or synchronize technical objectives (i.e., network para		<t>Autonomic nodes must communicate with each other, for example, to neg
	meters) of any kind and complexity. This requires some form of signaling between		otiate and/or synchronize technical objectives (i.e., network parameters) of any
	autonomic nodes. Autonomic nodes implementing a specific use case might choose		kind and complexity. This requires some form of signaling between autonomic nod
	their own signaling protocol, as long as it fits the overall security model. How		es. Autonomic nodes implementing a specific use case might choose their own sign
	ever, in the general case, any pair of autonomic nodes might need to communicate		aling protocol, as long as it fits the overall security model. However, in the g
	, so there needs to be a generic protocol for this. A prerequisite for this is t		eneral case, any pair of autonomic nodes might need to communicate, so there nee
	hat autonomic nodes can discover each other without any preconfiguration, as men		ds to be a generic protocol for this. A prerequisite for this is that autonomic
	tioned above. To be generic, discovery and signaling must be able to handle any		nodes can discover each other without any preconfiguration, as mentioned above.
	sort of technical objective, including ones that require complex data structures		To be generic, discovery and signaling must be able to handle any sort of techni
	. The document "A Generic Autonomic Signaling Protocol (GRASP)" <xref target="I-		cal objective, including ones that require complex data structures. The document
	D.ietf-anima-grasp"/> describes more detailed requirements for discovery, negoti		"<xref target="RFC8990" format="title"/>" <xref target="RFC8990" format="defaul
	ation and synchronization in an autonomic network. It also defines a protocol, G		t"/> describes more detailed requirements for discovery, negotiation, and synchr
	RASP, for this purpose, including an integrated but optional discovery protocol.		onization in an Autonomic Network.
	</t>		It also defines a protocol, called GRASP, for this purpose; GRASP includes an in
	<t>GRASP is normally expected to run inside the Autonomic		tegrated but optional discovery process.</t>
	Control Plane (ACP; see <xref target="acp"/>) and to depend on the ACP for secu		<t>GRASP is normally expected to run inside the ACP (see <xref target="a
	rity.		cp" format="default"/>) and to depend on the ACP for security.
	It may run insecurely for a short time during bootstrappi ng.</t>		It may run insecurely for a short time during bootstrappi ng.</t>
	<t>An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP		<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 pro perties, are not excluded. </t>		run in a single node, perhaps with different security pro perties, are not excluded. </t>
	</section>		</section>
	<!-- negotiation -->
	<section anchor="routing" title="Routing">		<section anchor="routing" numbered="true" toc="default">
	<t>All autonomic nodes in a domain must be able to communicate wi		<name>Routing</name>
	th each other, and later phases also with autonomic nodes outside their own doma		<t>All autonomic nodes in a domain must be able to communicate with
	in. Therefore, an Autonomic Control Plane relies on a routing function. For Auto		each other, and in later phases, they must also be able to communicate
	nomic Networks to be interoperable, they must all support one common routing pro		with autonomic nodes outside their own domain. Therefore, an
	tocol. </t>		ACP relies on a routing function. For Autonomic
	<t>The routing protocol is defined in the ACP document <xref targ		Networks to be interoperable, they must all support one common routing
	et="I-D.ietf-anima-autonomic-control-plane"/>.</t>		protocol. </t>
	</section>		<t>The routing protocol is defined in the ACP document <xref target="RFC
	<!-- routing -->		8994" format="default"/>.</t>
			</section>
	<section anchor="acp" title="The Autonomic Control Plane">		<section anchor="acp" numbered="true" toc="default">
	<t>The "Autonomic Control Plane" carries the control protocols in		<name>Autonomic Control Plane</name>
	an autonomic network. In the architecture described here, it is implemented as
	an overlay network. The document "An Autonomic Control Plane" (<xref target="I-D
	.ietf-anima-autonomic-control-plane"/>) describes the implementation details sug
	gested here. This document uses the term "overlay" to mean a set of point-to-poi
	nt adjacencies congruent with the underlying interconnection topology. The termi
	nology may not be aligned with a common usage of the "overlay" term in routing c
	ontext. See <xref target="I-D.ietf-anima-stable-connectivity"/> for uses cases f
	or the ACP. </t>
	</section>
	<!-- acp -->
	<section anchor="info-distri" title="Information Distribution (*)">		<t>The ACP carries the control protocols in an Autonomic Network. In the
	<t>Certain forms of information require distribution across an au		architecture described in this document, it is implemented as an overlay networ
	tonomic domain. The distribution of information runs inside the Autonomic Contro		k. The document "<xref target="RFC8994" format="title"/>" <xref target="RFC8994"
	l Plane. For example, Intent is distributed across an autonomic domain, as expla		format="default"/> describes the implementation details suggested in this docum
	ined in <xref target="RFC7575"/>.</t>		ent. This document uses the term "overlay" to mean a set of point-to-point adjac
	<t>Intent is the policy language of an Autonomic Network, see als		encies congruent with the underlying interconnection topology. The terminology m
	o <xref target="intent"/>. It is a high level policy, and should change only inf		ay not be aligned with a common usage of the term "overlay" in the routing conte
	requently (order of days). Therefore, information such as Intent should be simpl		xt. See <xref target="RFC8368" format="default"/> for uses cases for the ACP. </
	y flooded to all nodes in an autonomic domain, and there is currently no perceiv		t>
	ed need to have more targeted distribution methods. Intent is also expected to b		</section>
	e monolithic, and flooded as a whole. One possible method for distributing Inten
	t, as well as other forms of data, is discussed in <xref target="I-D.liu-anima-g
	rasp-distribution"/>. Intent and information distribution are not part of phase
	1 of ANIMA. </t>
	</section>
	<!-- info-distri -->
	</section>		<section anchor="info-distri" numbered="true" toc="default">
	<!-- ani -->		<name>Information Distribution (*)</name>
			<t>Certain forms of information require distribution across an autonomic
			domain. The distribution of information runs inside the ACP. For example, Inten
			t is distributed across an autonomic domain, as explained in <xref target="RFC75
			75" format="default"/>.</t>
			<t>Intent is the policy language of an Autonomic Network (see also <xref
			target="intent" format="default"/>). It is a high-level policy and should chang
			e only infrequently (order of days). Therefore, information such as Intent shoul
			d 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 exp
			ected to be monolithic and flooded as a whole. One possible method for distribut
			ing Intent, as well as other forms of data, is discussed in <xref target="I-D.ie
			tf-anima-grasp-distribution" format="default"/>. Intent and information distribu
			tion are not part of the ANIMA Working Group charter. </t>
			</section>
	<section anchor="trust" title="Security and Trust Infrastructure">		</section>
	<t>An Autonomic Network is self-protecting. All protocols are secure by d
	efault, without the requirement for the administrator to explicitly configure se
	curity, with the exception of setting up a PKI infrastructure. </t>
	<t>Autonomic nodes have direct interactions between themselves, which mus
	t be secured. Since an autonomic network does not rely on configuration, it is n
	ot 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 princi
	ples of this trust infrastructure. In this first phase of autonomic networking,
	a device is either within the trust domain and fully trusted, or outside the tru
	st 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.i
	etf-anima-bootstrapping-keyinfra"/>. The ASAs required for this enrollment proce
	ss are described in <xref target="specific-asas"/>. An autonomic node must imple
	ment the enrollment and join assistant ASAs. The registrar ASA may be implemente
	d only on a sub-set of nodes. </t>
	<section anchor="pki" title="Public Key Infrastructure">		<section anchor="trust" numbered="true" toc="default">
	<t>An autonomic domain uses a PKI model. The root of trust is a c		<name>Security and Trust Infrastructure</name>
	ertification authority (CA). A registrar acts as a registration authority (RA).		<t>An Autonomic Network is self-protecting. All protocols are secure by de
	</t>		fault, without the requirement for the administrator to explicitly configure sec
	<t>A minimum implementation of an autonomic domain contains one C		urity, with the exception of setting up a PKI infrastructure. </t>
	A, one Registrar, and network elements.</t>		<t>Autonomic nodes have direct interactions between themselves, which must
	</section>		be secured. Since an Autonomic Network does not rely on configuration, it is no
	<!-- pki -->		t an option to configure, for example, pre-shared keys. A trust infrastructure s
			uch as a PKI infrastructure must be in place. This section describes the princip
			les of this trust infrastructure. In this first phase of Autonomic Networking, a
			device is either 1) within the trust domain and fully 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 "<xref target="RFC8995" format="title" />" <xref target=
			"RFC8995" format="default" />. The ASAs required for this enrollment process are
			described in <xref target="specific-asas" format="default"/>. An autonomic node
			must implement the enrollment and join proxy ASAs. The registrar ASA may be imp
			lemented only on a subset of nodes. </t>
			<section anchor="pki" numbered="true" toc="default">
			<name>Public Key Infrastructure</name>
			<t>An autonomic domain uses a PKI model. The root of trust is a Certific
			ation Authority (CA). A registrar acts as a Registration Authority (RA). </t>
			<t>A minimum implementation of an autonomic domain contains one CA, one
			registrar, and network elements.</t>
			</section>
	<section anchor="cert" title="Domain Certificate">		<section anchor="cert" numbered="true" toc="default">
	<t>Each device in an autonomic domain uses a domain certificate (		<name>Domain Certificate</name>
	LDevID) to prove its identity. A new device uses its manufacturer provided certi		<t>Each device in an autonomic domain uses a domain certificate (LDevID)
	ficate (IDevID) during bootstrap, to obtain a domain certificate. <xref target="		to prove its identity. A new device uses its manufacturer-provided certificate
	I-D.ietf-anima-bootstrapping-keyinfra"/> describes how a new device receives a d		(IDevID) during bootstrap to obtain a domain certificate. <xref target="RFC8995"
	omain certificate, and the certificate format. </t>		format="default"/> describes how a new device receives a domain certificate and
	</section>		defines the certificate format. </t>
	<!-- cert -->		</section>
	<section anchor="masa" title="The MASA">		<section anchor="masa" numbered="true" toc="default">
	<t>The Manufacturer Authorized Signing Authority (MASA) is a trus		<name>MASA</name>
	ted service for bootstrapping devices. The purpose of the MASA is to provide ow		<t>The Manufacturer Authorized Signing Authority (MASA) is a trusted ser
	nership tracking of devices in a domain. The MASA provides audit, authorization		vice for bootstrapping devices. The purpose of the MASA is to provide ownership
	, and ownership tokens to the registrar during the bootstrap process to assist i		tracking of devices in a domain. The MASA provides audit, authorization, and o
	n the authentication of devices attempting to join an Autonomic Domain, and to a		wnership tokens to the registrar during the bootstrap process to assist in the a
	llow a joining device to validate whether it is joining the correct domain. The		uthentication of devices attempting to join an autonomic domain and to allow a j
	details for MASA service, security, and usage are defined in <xref target="I-D.		oining device to validate whether it is joining the correct domain. The details
	ietf-anima-bootstrapping-keyinfra"/>. </t>		for MASA service, security, and usage are defined in <xref target="RFC8995" for
	</section>		mat="default"/>. </t>
	<!-- masa -->		</section>
	<section anchor="sub-domains" title="Sub-Domains (*)">		<section anchor="sub-domains" numbered="true" toc="default">
	<t>By default, sub-domains are treated as different domains. This		<name>Subdomains (*)</name>
	implies no trust between a domain and its sub-domains, and no trust between sub		<t>By default, subdomains are treated as different domains. This implies
	-domains of the same domain. Specifically, no ACP is built, and Intent is valid		no trust between a domain and its subdomains and no trust between subdomains of
	only for the domain it is defined for explicitly. </t>		the same domain. Specifically, no ACP is built, and Intent is valid only for th
	<t>In phase 2 of ANIMA, alternative trust models should be define		e domain it is defined for explicitly. </t>
	d, for example to allow full or limited trust between domain and sub-domain.</t>		<t>In the ANIMA Working Group charter, alternative trust models should b
	</section>		e defined, for example, to allow full or limited trust between domain and subdom
	<!-- sub-domains -->		ain.</t>
			</section>
	<section anchor="cross-domain" title="Cross-Domain Functionality (*)">		<section anchor="cross-domain" numbered="true" toc="default">
	<t>By default, different domains do not interoperate, no ACP is b		<name>Cross-Domain Functionality (*)</name>
	uilt and no trust is implied between them. </t>		<t>By default, different domains do not interoperate, no ACP is built, a
	<t>In the future, models can be established where other domains c		nd no trust is implied between them. </t>
	an be trusted in full or for limited operations between the domains. </t>		<t>In the future, models can be established where other domains can be t
	</section>		rusted in full or for limited operations between the domains. </t>
	<!-- sub-domains -->		</section>
	</section>		</section>
	<!-- trust -->
	<section anchor="asa" title="Autonomic Service Agents (ASA)">		<section anchor="asa" numbered="true" toc="default">
	<t>This section describes how autonomic services run on top of the Auto		<name>Autonomic Service Agents (ASAs)</name>
	nomic Networking Infrastructure. </t>		<t>This section describes how autonomic services run on top of the ANI. <
			/t>
	<section anchor="asa-general" title="General Description of an ASA">		<section anchor="asa-general" numbered="true" toc="default">
			<name>General Description of an ASA</name>
	<t>An Autonomic Service Agent (ASA) is defined in <xref target="RFC7575"/> as		<t>An ASA is defined in <xref target="RFC7575" format="default"/> as "An
	"An agent implemented on an autonomic node		agent implemented on an autonomic node
	that implements an autonomic function, either in part (in the case of		that implements an autonomic function, either in part (in the case of
	a distributed function) or whole." Thus it is a process that makes use		a distributed function) or whole". Thus, it is a process that makes use
	of the features provided by the ANI to achieve its own goals, usually including		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-		interaction with other ASAs via GRASP <xref target="RFC8990" format="default"/>
	grasp"/> or otherwise.		or otherwise.
	Of course it also interacts with the specific targets of its function, using		Of course, it also interacts with the specific targets of its function, using
	any suitable mechanism.		any suitable mechanism.
	Unless its function is very simple, the ASA will need to handle overlapping asyn chronous operations. It may therefore be a quite		Unless its function is very simple, the ASA will need to handle overlapping asyn chronous operations. It may therefore be a quite
	complex piece of software in its own right, forming part of the application laye r		complex piece of software in its own right, forming part of the application laye r
	above the ANI. ASA design guidelines are available in <xref target="I-D.carpente		above the ANI. ASA design guidelines are available in <xref target="I-D.ietf-ani
	r-anima-asa-guidelines"/>.</t>		ma-asa-guidelines" format="default"/>.</t>
			<t>Thus, we can distinguish at least three classes of ASAs:
	<t>Thus we can distinguish at least three classes of ASAs:		</t>
	<list style="symbols">		<ul spacing="normal">
	<t>Simple ASAs with a small footprint that could run anywhere.</t>		<li>Simple ASAs with a small footprint that could run anywhere.</li>
	<t>Complex, possibly multi-threaded ASAs that have a significant resource requi		<li>Complex, possibly multi-threaded ASAs that have a significant reso
	rement and will only		urce requirement and will only
	run on selected nodes.</t>		run on selected nodes.</li>
	<t>A few 'infrastructure ASAs' that use basic ANI features in support of the AN		<li>A few 'infrastructure ASAs' that use basic ANI features in support
	I itself,		of the ANI itself,
	which must run in all autonomic nodes.		which must run in all autonomic nodes.
	These are outlined in the following sections.</t>		These are outlined in the following sections.</li>
	</list></t>		</ul>
			<t>Autonomic nodes, and therefore their ASAs, know their own capabilitie
	<t>Autonomic nodes, and therefore their ASAs, know their own capabilities and re		s and restrictions, derived from hardware, firmware, or pre-installed software;
	strictions, derived from hardware, firmware or pre-installed software: They are		they are "self-aware". </t>
	"self-aware". </t>		<t>The role of an autonomic node depends on Intent and on the surroundin
	<t>The role of an autonomic node depends on Intent and on the surrounding networ		g network behaviors, which may include forwarding behaviors, aggregation propert
	k behaviors, which may include forwarding behaviors, aggregation properties, top		ies, topology location, bandwidth,
	ology 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>		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 properties and those of its ne ighbors are the foundation of the behavior of a specific node. A node and its AS As have no pre-configuration for the particular network in which they are instal led.</t>
	<t>Since all ASAs will interact with the ANI, they will depend on appropriate ap		<t>Following an initial discovery phase, the node's properties and those
	plication		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 approp
			riate application
	programming interfaces (APIs). It is desirable that ASAs are portable between op erating		programming interfaces (APIs). It is desirable that ASAs are portable between op erating
	systems, so these APIs need to be universal.		systems, so these APIs need to be universal.
	An API for GRASP is described in <xref target="I-D.ietf-anima-grasp-api"/>. </t>		An API for GRASP is described in <xref target="RFC8991" format="default"/>. </t>
			<t>ASAs will, in general, be designed and coded by experts in a particul
	<t>ASAs will in general be designed and coded by experts in a particular technol		ar technology
	ogy
	and use case, not by experts in the ANI and its components. Also, they		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 lang uages		may be coded in a variety of programming languages, in particular, languages
	that support object constructs as well as traditional variables and structures. The APIs		that support object constructs as well as traditional variables and structures. The APIs
	should be designed with these factors in mind.</t>		should be designed with these factors in mind.</t>
			<t>It must be possible to run ASAs as non-privileged (user space) proces
	<t>It must be possible to run ASAs as non-privileged (user space) processes exce		ses except for those
	pt for those
	(such as the infrastructure ASAs) that necessarily require kernel privilege. Als o, it is		(such as the infrastructure ASAs) that necessarily require kernel privilege. Als o, it is
	highly desirable that ASAs can be dynamically loaded on a running node.</t>		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 import
	<t>Since autonomic systems must be self-repairing, it is of great importance tha		ance that ASAs are
	t ASAs are		coded using robust programming techniques. All runtime error conditions must be
	coded using robust programming techniques. All run-time error conditions must be		caught,
	caught,		leading to suitable minimally disruptive recovery actions, but a complete restar
	leading to suitable minimally disruptive recovery actions, also considering a co		t of the ASA must also be considered.
	mplete restart of the ASA.
	Conditions such as discovery failures or negotiation failures must be treated as routine,		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		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 AS A,		in the case of persistent errors. When multiple threads are started within an AS A,
	these threads must be monitored for failures and hangups, and appropriate action taken.		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 res ources.		Attention must be given to garbage collection, so that ASAs never run out of res ources.
	There is assumed to be no human operator - again, in the worst case, every ASA m ust		There is assumed to be no human operator; again, in the worst case, every ASA mu st
	be capable of restarting itself. </t>		be capable of restarting itself. </t>
			<t>ASAs will automatically benefit from the security provided by the ANI
	<t>ASAs will automatically benefit from the security provided by the ANI, and sp		, specifically
	ecifically
	by the ACP and by GRASP. However, beyond that, they are responsible for their ow n security,		by the ACP and by GRASP. However, beyond that, they are responsible for their ow n security,
	especially when communicating with the specific targets of their function. There fore,		especially when communicating with the specific targets of their function. There fore,
	the design of an ASA must include a security analysis beyond 'use ANI security.'		the design of an ASA must include a security analysis beyond 'use ANI security'.
	</t>		</t>
			</section>
	</section>		<section anchor="asa-life-cycle" numbered="true" toc="default">
	<!-- general description of an ASA -->		<name>ASA Life-Cycle Management</name>
			<t>ASAs operating on a given ANI may come from different providers and p
			ursue different objectives. Management of ASAs and their interactions with the A
			NI should follow the same operating principles and thus comply to a generic life
			-cycle management model.</t>
			<t>The ASA life cycle provides standard processes to:
			</t>
			<ul spacing="normal">
			<li>install ASA: copy the ASA code onto the node and start it.</li>
			<li>deploy ASA: associate the ASA instance with a (some) managed netwo
			rk device(s) (or network function).</li>
			<li>control ASA execution: when and how an ASA executes its control lo
			op.</li>
			</ul>
	<section anchor="asa-life-cycle" title="ASA Life-Cycle Management">		<t>This life cycle will also define which interactions ASAs have with th
	<t>ASAs operating on a given ANI may come from different provider		e ANI in between the different states. The noticeable interactions are:
	s and pursue different objectives. Management of ASAs and its interactions with		</t>
	the ANI should follow the same operating principles, hence comply to a generic l		<ul spacing="normal">
	ife-cycle management model.</t>		<li>Self-description of ASA instances at the end of deployment: Its fo
	<t>The ASA life-cycle provides standard processes to:		rmat needs to define the information required for the management of ASAs by ANI
	<list style="symbols">		entities.</li>
	<t>install ASA: copy the ASA code onto the node and start		<li>Control of the ASA control loop during the operation: Signaling ha
	it,</t>		s to carry formatted messages to control ASA execution (at least starting and st
	<t>deploy ASA: associate the ASA instance with a (some) m		opping the control loop).</li>
	anaged network device(s) (or network function),</t>		</ul>
	<t>control ASA execution: when and how an ASA executes it		</section>
	s control loop.</t>
	</list></t>
	<t>The life-cyle will cover the sequential states below: Installa
	tion, Deployment, Operation and the transitional states in-between. This Life-Cy
	cle will also define which interactions ASAs have with the ANI in between the di
	fferent states. The noticeable interactions are:
	<list style="symbols">
	<t>Self-description of ASA instances at the end of deployment: it
	s format needs to define the information required for the management of ASAs by
	ANI entities</t>
	<t>Control of ASA control-loop during the operation: a signaling
	has to carry formatted messages to control ASA execution (at least starting and
	stopping the control loop)</t>
	</list></t>
	</section>
	<!-- asa-life-cycle -->
	<section anchor="specific-asas" title="Specific ASAs for the Autonomic Ne		<section anchor="specific-asas" numbered="true" toc="default">
	twork Infrastructure">
	<t>The following functions provide essential, required functional
	ity in an autonomic network, and are therefore mandatory to implement on unconst
	rained autonomic nodes. They are described here as ASAs that include the underly
	ing infrastructure components, but implementation details might vary.</t>
	<t>The first three together support the trust enrollment process		<name>Specific ASAs for the Autonomic Networking Infrastructure</name>
	described in <xref target="trust"/>. For details see <xref target="I-D.ietf-anim		<t>The following functions provide essential, required functionality in
	a-bootstrapping-keyinfra"/>.</t>		an Autonomic Network and are therefore mandatory to implement on unconstrained a
	<section anchor="enrollment" title="The enrollment ASAs">		utonomic nodes. They are described here as ASAs that include the underlying infr
	<section anchor="enrollment-pledge" title="The Pledge ASA">		astructure components, but implementation details might vary.</t>
	<t>This ASA includes the function of an autonomic node th
	at bootstraps into the domain with the help of an join assitant ASA (see below).
	Such a node is known as a Pledge during the enrollment process. This ASA must b
	e installed by default on all nodes that require an autonomic zero-touch bootstr
	ap.</t>
	</section>
	<!-- enrollment -->
	<section anchor="join-assitant" title="The Join Assistant ASA">		<t>The first three (pledge, join proxy, join registrar) support together
	<t>This ASA includes the function of an autonomic node th		the trust enrollment process
	at helps a non-enrolled, adjacent devices to enroll into the domain. This ASA mu		described in <xref target="trust" format="default"/>. For details see <xref ta
	st be installed on all nodes, although only one join assistant needs to be activ		rget="RFC8995" format="default"/>.</t>
	e on a given LAN. See also <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/		<section anchor="enrollment" numbered="true" toc="default">
	>.</t>		<name>Enrollment ASAs</name>
	</section>		<section anchor="enrollment-pledge" numbered="true" toc="default">
	<!-- join-assistant -->		<name>The Pledge ASA</name>
			<t>This ASA includes the function of an autonomic node that bootstra
			ps into the domain with the help of a join proxy ASA (see below). Such a node is
			known as a pledge during the enrollment process. This ASA must be installed by
			default on all nodes that require an autonomic zero-touch bootstrap.</t>
			</section>
	<section anchor="enrollment-registrar" title="The Join Registrar		<section anchor="join-assitant" numbered="true" toc="default">
	ASA">		<name>The Join Proxy ASA</name>
	<t>This ASA includes the join registrar function in an au
	tonomic network. This ASA does not need to be installed on all nodes, but only o
	n nodes that implement the Join Registrar function.</t>
	</section>
	<!-- registrar -->
	</section>
	<section anchor="acp-asa" title="The ACP ASA">		<t>This ASA includes the function of an autonomic node that helps no
	<t>This ASA includes the ACP function in an autonomic net		n-enrolled, adjacent devices to enroll into the domain. This ASA must be install
	work. In particular it acts to discover other potential ACP nodes, and to suppor		ed on all nodes, although only one join proxy needs to be active on a given LAN.
	t the establishment and teardown of ACP channels. This ASA must be installed on		See also <xref target="RFC8995" format="default"/>.</t>
	all nodes. For details see <xref target="acp"/> and <xref target="I-D.ietf-anima		</section>
	-autonomic-control-plane"/>.</t>
	</section>		<section anchor="enrollment-registrar" numbered="true" toc="defau
	<!-- acp -->		lt">
			<name>The Join Registrar ASA</name>
			<t>This ASA includes the Join Registrar function in an Autonomic Net
			work. This ASA does not need to be installed on all nodes, but only on nodes tha
			t implement the Join Registrar function.</t>
			</section>
	<section anchor="intent-asa" title="The Information Distribution
	ASA (*)">
	<t>This ASA is currently out of scope in ANIMA, and provi
	ded here only as background information.</t>
	<t>This ASA includes the information distribution functio
	n in an autonomic network. In particular it acts to announce the availability of
	Intent and other information to all other autonomic nodes. This ASA does not ne
	ed to be installed on all nodes, but only on nodes that implement the informatio
	n distribution function. For details see <xref target="info-distri"/>.</t>
	<t>Note that information distribution can be implemented
	as a function in any ASA. See <xref target="I-D.liu-anima-grasp-distribution"/>
	for more details on how information is suggested to be distributed.</t>
	</section>		</section>
	<!-- registrar -->		<section anchor="acp-asa" numbered="true" toc="default">
			<name>ACP ASA</name>
			<t>This ASA includes the ACP function in an Autonomic Network. In part
			icular, it acts to discover other potential ACP nodes and to support the establi
			shment and teardown of ACP channels. This ASA must be installed on all nodes. Fo
			r details, see <xref target="acp" format="default"/> and <xref target="RFC8994"
			format="default"/>.</t>
			</section>
			<section anchor="intent-asa" numbered="true" toc="default">
			<name>Information Distribution ASA (*)</name>
			<t>This ASA is currently out of scope in the ANIMA Working Group chart
			er and is provided here only as background information.</t>
			<t>This ASA includes the information distribution function in an Auton
			omic Network. In particular, it acts to announce the availability of Intent and
			other information to all other autonomic nodes. This ASA does not need to be ins
			talled on all nodes, but only on nodes that implement the information distributi
			on function. For details, see <xref 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.ietf-anima-grasp-distribution" format="defaul
			t"/> for more details on how information is suggested to be distributed.</t>
			</section>
	</section>		</section>
	<!-- specific-asas -->
	</section>		</section>
	<!-- asa -->
	<section anchor="management" title="Management and Programmability">
	<t>This section describes how an Autonomic Network is managed, and progra
	mmed.</t>
	<section anchor="management-general" title="Managing a (Partially) Autono		<section anchor="management" numbered="true" toc="default">
	mic Network">		<name>Management and Programmability</name>
	<t>Autonomic management usually co-exists with traditional manage		<t>This section describes how an Autonomic Network is managed and programm
	ment methods in most networks. Thus, autonomic behavior will be defined for indi		ed.</t>
	vidual functions in most environments. Examples for overlap are:		<section anchor="management-general" numbered="true" toc="default">
	<list style="symbols">		<name>Managing a (Partially) Autonomic Network</name>
	<t>Autonomic functions can use traditional methods and protocols (e.g., SNMP and		<t>Autonomic management usually coexists with traditional management met
	NETCONF) to perform management tasks, inside and outside the ACP;</t>		hods in most networks. Thus, autonomic behavior will be defined for individual f
	<t>Autonomic functions can conflict with behavior enforced by the same tradition		unctions in most environments. Examples of overlap are:
	al methods and protocols;</t>		</t>
	<t>Traditional functions can use the ACP, for example if reachability on the dat		<ul spacing="normal">
	a plane is not (yet) established. </t>		<li>Autonomic functions can use traditional methods and protocols (e.g
	</list></t>		., SNMP and the Network Configuration Protocol (NETCONF)) to perform management
	<t>The autonomic Intent is defined at a high level of abstraction		tasks, inside and outside the ACP.</li>
	. However, since it is necessary to address individual managed elements, autonom		<li>Autonomic functions can conflict with behavior enforced by the sam
	ic management needs to communicate in lower-level interactions (e.g., commands a		e traditional methods and protocols.</li>
	nd requests). For example, it is expected that the configuration of such element		<li>Traditional functions can use the ACP, for example, if reachabilit
	s be performed using NETCONF and YANG modules as well as the monitoring be execu		y on the data plane is not (yet) established. </li>
	ted through SNMP and MIBs.</t>		</ul>
	<t>Conflict can occur between autonomic default behavior, autonom		<t>The autonomic Intent is defined at a high level of abstraction. Howev
	ic Intent, traditional management methods. Conflict resolution is achieved in au		er, since it is necessary to address individual managed elements, autonomic mana
	tonomic management through prioritization <xref target="RFC7575"/>. The rational		gement needs to communicate in lower-level interactions (e.g., commands and requ
	e is that manual and node-based management have a higher priority over autonomic		ests). For example, it is expected that the configuration of such elements be pe
	management. Thus, the autonomic default behavior has the lowest priority, then		rformed using NETCONF and YANG modules as well as the monitoring be executed thr
	comes the autonomic Intent (medium priority), and, finally, the highest priority		ough SNMP and MIBs.</t>
	is taken by node-specific network management methods, such as the use of comma		<t>Conflict can occur between autonomic default behavior, autonomic Inte
	nd line interfaces. </t>		nt, and traditional management methods. Conflict resolution is achieved in auton
	</section>		omic management through prioritization <xref target="RFC7575" format="default"/>
	<!-- management-general -->		. The rationale is that manual and node-based management have a higher priority
			than autonomic management. Thus, the autonomic default behavior has the lowest p
	<section anchor="intent" title="Intent (*)">		riority, then comes the autonomic Intent (medium priority), and, finally, the hi
	<t>Intent is not covered in the current implementation specificat		ghest priority is taken by node-specific network management methods, such as th
	ions. This section discusses a topic for further research.</t>		e use of command-line interfaces. </t>
	<t>This section gives an overview of Intent, and how it is manage		</section>
	d. Intent and Policy-Based Network Management (PBNM) is already described inside
	the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF and TMF ZOOM). </t>
	<t>Intent can be described as an abstract, declarative, high-leve
	l policy used to operate an autonomic domain, such as an enterprise network <xre
	f target="RFC7575"/>. Intent should be limited to high level guidance only, thus
	it does not directly define a policy for every network element separately. </t>
	<t>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 <xref target="RFC7575"/>. One of the possible refin
	ements of the Intent is using Event-Condition-Action (ECA) rules.</t>
	<t>Different parameters may be configured for Intent. These param
	eters are usually provided by the human operator. Some of these parameters can i
	nfluence the behavior of specific autonomic functions as well as the way the Int
	ent is used to manage the autonomic domain. </t>
	<t>Intent is discussed in more detail in <xref target="I-D.du-ani
	ma-an-intent"/>. Intent as well as other types of information are distributed vi
	a GRASP, see <xref target="I-D.liu-anima-grasp-distribution"/>.</t>
	</section>
	<!-- intent -->
	<section anchor="reporting" title="Aggregated Reporting (*)">		<section anchor="intent" numbered="true" toc="default">
	<t>Aggregated reporting is not covered in the current implementat		<name>Intent (*)</name>
	ion specifications. This section discusses a topic for further research.</t>		<t>Intent is not covered in the current implementation specifications. T
	<t>An Autonomic Network should minimize the need for human interv		his section discusses a topic for further research.</t>
	ention. In terms of how the network should behave, this is done through an auton		<t>This section gives an overview of Intent and how it is managed. Inten
	omic Intent provided by the human administrator. In an analogous manner, the rep		t and Policy-Based Network Management (PBNM) is already described inside the IET
	orts which describe the operational status of the network should aggregate the i		F (e.g., Policy Core Information Model (PCIM)) and in other Standards Developmen
	nformation produced in different network elements in order to present the effect		t Organizations (SDOs) (e.g., the Distributed Management Task Force (DMTF)). </t
	iveness of autonomic Intent enforcement. Therefore, reporting in an autonomic ne		>
	twork should happen on a network-wide basis <xref target="RFC7575"/>. </t>		<t>Intent can be described as an abstract, declarative, high-level polic
	<t>Multiple simultaneous events can occur in an autonomic network		y used to operate an autonomic domain, such as an enterprise network <xref targe
	in the same way they can happen in a traditional network. However, when reporti		t="RFC7575" format="default"/>. Intent should be limited to high-level guidance
	ng to a human administrator, such events should be aggregated to avoid notificat		only; thus, it does not directly define a policy for every network element separ
	ions about individual managed elements. In this context, algorithms may be used		ately. </t>
	to determine what should be reported (e.g., filtering) and in which way and how		<t>Intent can be refined to lower-level policies using different approac
	different events are related to each other. Besides that, an event in an individ		hes. This is expected in order to adapt the Intent to the capabilities of manage
	ual element can be compensated by changes in other elements to maintain a networ		d devices. Intent may contain role or function information, which can be transla
	k-wide target which is described in the autonomic Intent. </t>		ted to specific nodes <xref target="RFC7575" format="default"/>. One of the poss
	<t>Reporting in an autonomic network may be at the same abstracti		ible refinements of the Intent is using Event-Condition-Action (ECA) rules.</t>
	on level as Intent. In this context, the aggregated view of current operational		<t>Different parameters may be configured for Intent. These parameters a
	status of an autonomic network can be used to switch to different management mod		re usually provided by the human operator. Some of these parameters can influenc
	es. Despite the fact that autonomic management should minimize the need for user		e the behavior of specific autonomic functions as well as the way the Intent is
	intervention, possibly there are some events that need to be addressed by human		used to manage the autonomic domain. </t>
	administrator actions.</t>		<t>Intent is discussed in more detail in <xref target="I-D.du-anima-an-i
	</section>		ntent" format="default"/>. Intent as well as other types of information are dist
	<!-- reporting -->		ributed via GRASP; see <xref target="I-D.ietf-anima-grasp-distribution" format="
			default"/>.</t>
			</section>
	<section anchor="feedback" title="Feedback Loops to NOC (*)">		<section anchor="reporting" numbered="true" toc="default">
	<t>Feedback loops are required in an autonomic network to allow t		<name>Aggregated Reporting (*)</name>
	he intervention of a human administrator or central control systems, while maint		<t>Aggregated reporting is not covered in the current implementation spe
	aining a default behaviour. Through a feedback loop an administrator must be pro		cifications. This section discusses a topic for further research.</t>
	mpted with a default action, and has the possibility to acknowledge or override		<t>An Autonomic Network should minimize the need for human intervention.
	the proposed default action. </t>		In terms of how the network should behave, this is done through an autonomic In
	<t>Uni-directional notifications to the NOC, that do not propose		tent provided by the human administrator. In an analogous manner, the reports th
	any default action, and do not allow an override as part of the transaction are		at describe the operational status of the network should aggregate the informati
	considered like traditional notification services, such as syslog. They are expe		on produced in different network elements in order to present the effectiveness
	cted to co-exist with autonomic methods, but are not covered in this draft.</t>		of autonomic Intent enforcement. Therefore, reporting in an Autonomic Network sh
	</section>		ould happen on a network-wide basis <xref target="RFC7575" format="default"/>. <
	<!-- feedback -->		/t>
			<t>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 ab
			out individual managed elements. In this context, algorithms may be used to dete
			rmine 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 ind
			ividual element can be compensated by changes in other elements to maintain a ne
			twork-wide target that is described in the autonomic Intent. </t>
			<t>Reporting in an Autonomic Network may be at the same abstraction leve
			l as Intent. In this context, the aggregated view of the current operational sta
			tus 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 in
			tervention, some events may need to be addressed by the actions of a human admin
			istrator.</t>
			</section>
	<section anchor="control-loops" title="Control Loops (*)">		<section anchor="feedback" numbered="true" toc="default">
			<name>Feedback Loops to NOC (*)</name>
			<t>Feedback loops are required in an Autonomic Network to allow the inte
			rvention of a human administrator or central control systems while maintaining a
			default behavior. Through a feedback loop, an administrator must be prompted wi
			th a default action and has the possibility to acknowledge or override the propo
			sed default action. </t>
			<t>Unidirectional notifications to the Network Operations Center (NOC) t
			hat do not propose any default action and do not allow an override as part of th
			e transaction are considered like traditional notification services, such as sys
			log. They are expected to coexist with autonomic methods but are not covered in
			this document.</t>
			</section>
	<t>Control loops are not covered in the current implementation specification		<section anchor="control-loops" numbered="true" toc="default">
	s. This section discusses a topic for further research. </t>		<name>Control Loops (*)</name>
	<t>Control loops are used in autonomic networking to provide a generic		<t>Control loops are not covered in the current implementation specifica
	mechanism to enable the Autonomic System to adapt (on its own) to		tions. This section discusses a topic for further research. </t>
	various factors that can change the goals that the autonomic network		<t>Control loops are used in Autonomic Networking to provide a generic
	is trying to achieve, or how those goals are achieved. For example,		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-		as user needs, business goals, and the ANI itself changes, self-
	adaptation enables the ANI to change the services and resources it		adaptation enables the ANI to change the services and resources it
	makes available to adapt to these changes.</t>		makes available to adapt to these changes.</t>
			<t>Control loops operate to continuously observe and collect data
	<t>Control loops operate to continuously observe and collect data
	that enables the autonomic management system to understand changes		that enables the autonomic management system to understand changes
	to the behavior of the system being managed, and then provide		to the behavior of the system being managed and then provide
	actions to move the state of the system being managed toward a		actions to move the state of the system being managed toward a
	common goal. Self-adaptive systems move decision-making from		common goal. Self-adaptive systems move decision making from
	static, pre-defined commands to dynamic processes computed at		static, pre-defined commands to dynamic processes computed at
	runtime.</t>		runtime.</t>
			<t>Most autonomic systems use a closed control loop with feedback.
	<t>Most autonomic systems use a closed control loop with feedback.
	Such control loops should be able to be dynamically changed at		Such control loops should be able to be dynamically changed at
	runtime to adapt to changing user needs, business goals, and		runtime to adapt to changing user needs, business goals, and
	changes in the ANI.</t>		changes in the ANI.</t>
			</section>
	</section>		<section anchor="apis" numbered="true" toc="default">
	<!-- control-loops -->		<name>APIs (*)</name>
			<t><xref target="RFC8991" format="default"/> defines a conceptual outlin
	<section anchor="apis" title="APIs (*)">		e for an API for the GeneRic Autonomic Signaling Protocol (GRASP). This conceptu
			al API is designed for ASAs to communicate with other ASAs through GRASP. Full S
	<t>APIs are not covered in the current implementation specifications. This s		tandards Track API specifications are not covered in the current implementation
	ection discusses a topic for further research.</t>		specifications. </t>
			<t>Most APIs are static, meaning that they are pre-defined and
	<t>Most APIs are static, meaning that they are pre-defined and
	represent an invariant mechanism for operating with data. An		represent an invariant mechanism for operating with data. An
	Autonomic Network should be able to use dynamic APIs in addition		Autonomic Network should be able to use dynamic APIs in addition
	to static APIs. </t>		to static APIs. </t>
			<t>A dynamic API retrieves data using a generic
	<t>A dynamic API is one that retrieves data using a generic		mechanism and then enables the client to navigate the retrieved
	mechanism, and then enables the client to navigate the retrieved
	data and operate on it. Such APIs typically use introspection		data and operate on it. Such APIs typically use introspection
	and/or reflection. Introspection enables software to examine the		and/or reflection. Introspection enables software to examine the
	type and properties of an object at runtime, while reflection		type and properties of an object at runtime, while reflection
	enables a program to manipulate the attributes, methods, and/or		enables a program to manipulate the attributes, methods, and/or
	metadata of an object.</t>		metadata of an object.</t>
			<t>APIs must be able to express and preserve the semantics of
	<t>APIs must be able to express and preserve the semantics of		data models. For example, software contracts <xref target="Meyer97" format="d
	data models. For example, software contracts <xref target="Meyer97"/> are		efault"/> are
	based on the principle that a software-intensive system, such as		based on the principle that a software-intensive system, such as
	an Autonomic Network, is a set of communicating components whose		an Autonomic Network, is a set of communicating components whose
	interaction is based on precisely-defined specifications of the		interaction is based on precisely defined specifications of the
	mutual obligations that interacting components must respect.		mutual obligations that interacting components must respect.
	This typically includes specifying:		This typically includes specifying:
	<list style="symbols">		</t>
	<t>pre-conditions that must be satisfied before the method can		<ul spacing="normal">
	start execution</t>		<li>pre-conditions that must be satisfied before the method can
			start execution</li>
	<t>post-conditions that must be satisfied when the method has		<li>post-conditions that must be satisfied when the method has
	finished execution</t>		finished execution</li>
			<li>invariant attributes that must not change during the execution
	<t>invariant attributes that must not change during the execution		of the method</li>
	of the method</t>		</ul>
	</list>		</section>
	</t>
	</section>
	<!-- apis -->
	<section anchor="data-model" title="Data Model (*)">
	<t>Data models are not covered in the current implementation specifications.
	This section discusses a topic for further research. </t>
	<t>The following definitions are adapted from <xref target="I-D.ietf-supa-gen
	eric-policy-data-model"/>:</t>
	<t>An information model is a representation of concepts of interest		<section anchor="data-model" numbered="true" toc="default">
			<name>Data Model (*)</name>
			<t>Data models are not covered in the current implementation specificati
			ons. 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" format="def
			ault"/>.</t>
			<t>An information model is a representation of concepts of interest
	to an environment in a form that is independent of data repository,		to an environment in a form that is independent of data repository,
	data definition language, query language, implementation language,		data definition language, query language, implementation language,
	and protocol. In contrast, a data model is a representation of		and protocol. In contrast, a data model is a representation of
	concepts of interest to an environment in a form that is dependent		concepts of interest to an environment in a form that is dependent
	on data repository, data definition language, query language,		on data repository, data definition language, query language,
	implementation language, and protocol (typically, but not		implementation language, and protocol.</t>
	necessarily, all three).</t>		<t>The utility of an information model is to define objects and their
	<t>The utility of an information model is to define objects and their
	relationships in a technology-neutral manner. This forms a		relationships in a technology-neutral manner. This forms a
	consensual vocabulary that the ANI and ASAs can use. A data model		consensual vocabulary that the ANI and ASAs can use. A data model
	is then a technology-specific mapping of all or part of the		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>		information model to be used by all or part of the system.</t>
			<t>A system may have multiple data models. Operational Support Systems,
	<t>A system may have multiple data models. Operational Support Systems,
	for example, typically have multiple types of repositories, such as		for example, typically have multiple types of repositories, such as
	SQL and NoSQL, to take advantage of the different properties of		SQL and NoSQL, to take advantage of the different properties of
	each. If multiple data models are required by an Autonomic System,		each. If multiple data models are required by an autonomic system,
	then an information model should be used to ensure that the		then an information model should be used to ensure that the
	concepts of each data model can be related to each other without		concepts of each data model can be related to each other without
	technological bias.</t>		technological bias.</t>
			<t>A data model is essential for certain types of functions, such as
	<t>A data model is essential for certain types of functions, such as
	a Model-Reference Adaptive Control Loop (MRACL). More generally, a data mode l can be used to define the		a Model-Reference Adaptive Control Loop (MRACL). More generally, a data mode l can be used to define the
	objects, attributes, methods, and relationships of a software		objects, attributes, methods, and relationships of a software
	system (e.g., the ANI, an autonomic node, or an ASA). A data		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		model can be used to help design an API, as well as any language
	used to interface to the Autonomic Network.</t>		used to interface to the Autonomic Network.</t>
			</section>
	</section>
	<!-- data model -->
	</section>		</section>
	<!-- management -->
	<section anchor="coordination" title="Coordination Between Autono		<section anchor="coordination" numbered="true" toc="default">
	mic Functions (*)">		<name>Coordination between Autonomic Functions (*)</name>
	<t>Coordination between autonomic functions is not covered in the current im		<t>Coordination between autonomic functions is not covered in the current
	plementation specifications. This section discusses a topic for further research		implementation specifications. This section discusses a topic for further resear
	. </t>		ch. </t>
	<section title="The Coordination Problem (*)">		<section numbered="true" toc="default">
	<t>Different autonomic functions may conflict in setting		<name>Coordination Problem (*)</name>
	certain parameters. For example, an energy efficiency function may want to shut		<t>Different autonomic functions may conflict in setting certain paramet
	down a redundant link, while a load balancing function would not want that to ha		ers. For example, an energy efficiency function may want to shut down a redundan
	ppen. The administrator must be able to understand and resolve such interactions		t link, while a load-balancing function would not want that to happen. The admin
	, to steer autonomic network performance to a given (intended) operational point		istrator must be able to understand and resolve such interactions to steer Auton
	.</t>		omic Network performance to a given (intended) operational point.</t>
			<t>Several interaction types may exist among autonomic functions, for ex
			ample:
			</t>
			<ul spacing="normal">
			<li>Cooperation: An autonomic function can improve the behavior or per
			formance of another autonomic function, such as a traffic forecasting function u
			sed by a traffic allocation function. </li>
			<li>Dependency: An autonomic function cannot work without another one
			being present or accessible in the Autonomic Network.</li>
			<li>Conflict: A metric value conflict is a conflict where one metric i
			s influenced by parameters of different autonomic functions. A parameter value c
			onflict is a conflict where one parameter is modified by different autonomic fun
			ctions. </li>
			</ul>
	<t>Several interaction types may exist among autonomic fu		<t>Solving the coordination problem beyond one-by-one cases can rapidly
	nctions, for example:		become intractable for large networks. Specifying a common functional block on c
	<list style="symbols">		oordination is a first step to address the problem in a systemic way. The coordi
	<t>Cooperation: An autonomic function can improve the b		nation life cycle consists of three states:
	ehavior or performance of another autonomic function, such as a traffic forecast		</t>
	ing function used by a traffic allocation function. </t>		<ul spacing="normal">
	<t>Dependency: An autonomic function cannot work withou		<li>At build-time, a "static interaction map" can be constructed on th
	t another one being present or accessible in the autonomic network.</t>		e relationship of functions and attributes. This map can be used to (pre-)define
	<t>Conflict: A metric value conflict is a conflict wher		policies and priorities for identified conflicts.</li>
	e one metric is influenced by parameters of different autonomic functions. A par		<li>At deploy-time, autonomic functions are not yet active/acting on t
	ameter value conflict is a conflict where one parameter is modified by different		he network. A "dynamic interaction map" is created for each instance of each aut
	autonomic functions. </t>		onomic function on a per-resource basis, including the actions performed and the
	</list> </t>		ir relationships. This map provides the basis to identify conflicts that will ha
			ppen at runtime, categorize them, and plan for the appropriate coordination stra
			tegies and mechanisms.</li>
			<li>At runtime, when conflicts happen, arbitration is driven by the co
			ordination strategies. Also, new dependencies can be observed and inferred, resu
			lting in an update of the dynamic interaction map and adaptation of the coordina
			tion strategies and mechanisms.</li>
			</ul>
			<t>Multiple coordination strategies and mechanisms exist and can be devi
			sed. The set ranges from basic approaches (such as random process or token-based
			process), to approaches based on time separation and hierarchical optimization,
			to more complex approaches (such as multi-objective optimization and other cont
			rol theory approaches and algorithm families).</t>
	<t>Solving the coordination problem beyond one-by-one cas		</section>
	es can rapidly become intractable for large networks. Specifying a common functi		<section numbered="true" toc="default">
	onal block on coordination is a first step to address the problem in a systemic		<name>Coordination Functional Block (*)</name>
	way. The coordination life-cycle consists in three states:
	<list style="symbols">
	<t>At build-time, a "static interaction map" can be const
	ructed on the relationship of functions and attributes. This map can be used to
	(pre-)define policies and priorities on identified conflicts.</t>
	<t>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 on a per resource basis, including the actions
	performed and their relationships. This map provides the basis to identify confl
	icts that will happen at run-time, categorize them and plan for the appropriate
	coordination strategies/mechanisms.</t>
	<t>At run-time, when conflicts happen, arbitration is dri
	ven by the coordination strategies. Also new dependencies can be observed and in
	ferred, resulting in an update of the dynamic interaction map and adaptation of
	the coordination strategies and mechanisms.</t>
	</list></t>
	<t>Multiple coordination strategies and mechanisms exist		<t>A common coordination functional block is a desirable component of th
	and can be devised. The set ranges from basic approaches such as random process		e ANIMA reference model. It provides a means to ensure network properties and pr
	or token-based process, to approaches based on time separation and hierarchical		edictable performance or behavior, such as stability and convergence, in the pre
	optimization, to more complex approaches such as multi-objective optimization, a		sence of several interacting autonomic functions.</t>
	nd other control theory approaches and algorithms family.</t>		<t>A common coordination function requires:
	</section>		</t>
			<ul spacing="normal">
			<li>A common description of autonomic functions, their attributes, and
			life cycle.</li>
			<li>A common representation of information and knowledge (e.g., intera
			ction maps).</li>
			<li>A common "control/command" interface between the coordination "age
			nt" and the autonomic functions. </li>
			</ul>
			<t>Guidelines, recommendations, or BCPs can also be provided for aspects
			pertaining to the coordination strategies and mechanisms.</t>
			</section>
			</section>
	<section title="A Coordination Functional Block (*)">		<section anchor="security" numbered="true" toc="default">
	<t>A common coordination functional block is a desirable		<name>Security Considerations</name>
	component of the ANIMA reference model. It provides a means to ensure network pr		<t>In this section, we distinguish outsider and insider attacks. In an out
	operties and predictable performance or behavior such as stability, and converge		sider attack, all network elements and protocols are securely managed and operat
	nce, in the presence of several interacting autonomic functions.</t>		ing, and an outside attacker can sniff packets in transit, inject, and replay pa
	<t>A common coordination function requires:		ckets. In an insider attack, the attacker has access to an autonomic node or oth
	<list style="symbols">		er means (e.g., remote code execution in the node by exploiting ACP-independent
	<t>A common description of autonomic functions, t		vulnerabilities in the node platform) to produce arbitrary payloads on the prote
	heir attributes and life-cycle.</t>		cted ACP channels.</t>
	<t>A common representation of information and kno		<t>If a system has vulnerabilities in the implementation or operation (con
	wledge (e.g., interaction maps).</t>		figuration), an outside attacker can exploit such vulnerabilities to become an i
	<t>A common “control/command” interface between t		nsider attacker.</t>
	he coordination "agent" and the autonomic functions. </t>		<section numbered="true" toc="default">
	</list></t>		<name>Protection against Outsider Attacks</name>
	<t>Guidelines, recommendations or BCPs can also be provid		<t>Here, we assume that all systems involved in an Autonomic Network are
	ed for aspects pertaining to the coordination strategies and mechanisms.</t>		secured and operated according to best current practices. These protection meth
	</section>		ods comprise traditional security implementation and operation methods (such as
	</section>		code security, strong randomization algorithms, strong passwords, etc.) as well
	<!-- coordination -->		as mechanisms specific to an Autonomic Network (such as a secured MASA service).
			</t>
			<t>Traditional security methods for both implementation and operation ar
			e outside the scope of this document.</t>
			<t>AN-specific protocols and methods must also follow traditional securi
			ty methods, in that all packets that can be sniffed or injected by an outside at
			tacker are:
			</t>
			<ul spacing="normal">
			<li>protected against modification</li>
			<li>authenticated</li>
			<li>protected against replay attacks</li>
			<li>confidentiality protected (encrypted)</li>
			</ul>
			<t>In addition, the AN protocols should be robust against packet drops
			and man-in-the-middle attacks.</t>
			<t>How these requirements are met is covered in the AN Standards Track d
			ocuments that define the methods used, specifically <xref target="RFC8990" forma
			t="default"/>, <xref target="RFC8994" format="default"/>, and <xref target="RFC8
			995" format="default"/>. </t>
	<section anchor="security" title="Security Considerations">		<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 <xref target="RFC8990" sectionFormat=
			"of" section="2.5.2"/>: the Discovery
			Unsolicited Link-Local (DULL) message, with detailed rules on its
			usage. </t>
			<t>If AN messages can be observed by a third party, they might reveal va
			luable information about network configuration, security precautions in use, ind
			ividual users, and their traffic patterns. If encrypted, AN messages might still
			reveal some information via traffic analysis. </t>
			</section>
			<section numbered="true" toc="default">
			<name>Risk of Insider Attacks</name>
			<t>An Autonomic Network consists of autonomic devices that form a distri
			buted self-managing system. Devices within a domain have credentials issued fro
			m a common trust anchor and can use them to create mutual trust. This means tha
			t any device inside a trust domain can by default use all distributed functions
			in the entire autonomic domain in a malicious way.</t>
			<t>An inside attacker, or an outsider in the presence of protocol vulner
			abilities or insecure operation, has the following generic ways to take control
			of an Autonomic Network: </t>
			<ul spacing="normal">
			<li>Introducing a fake device into the trust domain by subverting the
			authentication methods. This depends on the correct specification, implementatio
			n, and operation of the AN protocols.</li>
			<li>Subverting a device that is already part of a trust domain and mod
			ifying its behavior. This threat is not specific to the solution discussed in th
			is document and applies to all network solutions. </li>
			<li>Exploiting potentially yet unknown protocol vulnerabilities in the
			AN or other protocols. This is also a generic threat that applies to all networ
			k solutions.</li>
			</ul>
			<t>The above threats are, in principle, comparable to other solutions: i
			n the presence of design, implementation, or operational errors, security is no
			longer guaranteed. However, the distributed nature of AN, specifically the ACP,
			increases the threat surface significantly. For example, a compromised device ma
			y have full IP reachability to all other devices inside the ACP and can use all
			AN methods and protocols. </t>
			<t>For the next phase of the ANIMA Working Group, it is therefore recomm
			ended to introduce a subdomain security model to reduce the attack surface and n
			ot expose a full domain to a potential intruder. Furthermore, additional securit
			y mechanisms on the ASA level should be considered for high-risk autonomic funct
			ions. </t>
			</section>
			</section>
	<t>In this section we distinguish outsider and insider attacks. In an outsider a		<section anchor="iana" numbered="true" toc="default">
	ttack all network elements and protocols are securely managed and operating, and		<name>IANA Considerations</name>
	an outside attacker can sniff packets in transit, inject and replay packets. In		<t>This document has no IANA actions.</t>
	an insider attack, the attacker has access to an autonomic node or other means		</section>
	(e.g. remote code execution in the node by exploiting ACP-independent vulnerabil
	ities in the node platform) to produce arbitrary payloads on the protected ACP c
	hannels.</t>
	<t>If a system has vulnerabilities in the implementation or operation (configura
	tion), an outside attacker can exploit such vulnerabilies to become an insider a
	ttacker.</t>
	<section title="Protection Against Outsider Attacks">		</middle>
			<back>
	<t>Here, we assume that all systems involved in an autonomic network are secured		<displayreference target="I-D.ietf-anima-asa-guidelines" to="ASA-GUIDELINES"/>
	and operated according to best current practices. These protection methods comp		<displayreference target="I-D.du-anima-an-intent" to="ANIMA-INTENT"/>
	rise traditional security implementation and operation methods (such as code sec		<displayreference target="I-D.ietf-anima-grasp-distribution" to="GRASP-DISTRIB"/
	urity, strong randomization algorithms, strong passwords, etc.) as well as mecha		>
	nisms specific to an autonomic network (such as a secured MASA service).</t>		<displayreference target="I-D.ietf-supa-generic-policy-data-model" to="SUPA-DATA
			"/>
	<t>Traditional security methods for both implementation and operation are outsid		<references>
	e scope for this document.</t>		<name>References</name>
			<references>
			<name>Normative References</name>
	<t>AN specific protocols and methods must also follow traditional security metho		<reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995">
	ds, in that all packets that can be sniffed or injected by an outside attacker a		<front>
	re:		<title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
	<list style="symbols">
	<t>protected against modification.</t>
	<t>authenticated.</t>
	<t>protected against replay attacks.</t>
	<t>confidentiality protected (encrypted).</t>
	<t>and that the AN protocols are robust against packet drops and man-in-the-mi
	ddle attacks.</t>
	</list>
	</t>
	<t>How these requirements are met is covered in the AN standards track documents		<author initials="M" surname="Pritikin" fullname="Max Pritikin">
	that define the methods used, specifically <xref target='I-D.ietf-anima-bootstr		<organization/>
	apping-keyinfra'/>, <xref target='I-D.ietf-anima-grasp'/>, and <xref target='I-D		</author>
	.ietf-anima-autonomic-control-plane'/>. </t>
	<t>Most AN messages run inside the cryptographically protected ACP. The unprotec		<author initials="M" surname="Richardson" fullname="Michael Richardson">
	ted AN messages outside the ACP are limited to a simple discovery method, define		<organization/>
	d in Section 2.5.2 of <xref target='I-D.ietf-anima-grasp'/>: The "Discovery Unso		</author>
	licited Link-Local (DULL)" message, with detailed rules on its usage. </t>
	<t>If AN messages can be observed by a third party, they might reveal valuable i
	nformation 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>		<author initials="T" surname="Eckert" fullname="Toerless Eckert">
			<organization/>
			</author>
	<section title="Risk of Insider Attacks">		<author initials="M" surname="Behringer" fullname="Michael Behringer">
	<t>An autonomic network consists of autonomic devices that form a distributed se		<organization/>
	lf-managing system. Devices within a domain have credentials issued from a comm		</author>
	on trust anchor and can use them to create mutual trust. This means that any de
	vice inside a trust domain can by default use all distributed functions in the e
	ntire autonomic domain in a malicious way.</t>
	<t>If an autonomic node or protocol has vulnerabilities or is not securely opera		<author initials="K" surname="Watsen" fullname="Kent Watsen">
	ted, an outside attacker has the following generic ways to take control of an au		<organization/>
	tonomic network: <list style='symbols'>		</author>
	<t>Introducing a fake device into the trust domain, by subverting the authenti
	cation methods. This depends on the correct specification, implementation and op
	eration of the AN protocols.</t>
	<t>Subverting a device which is already part of a trust domain, and modifying
	its behavior. This threat is not specific to the solution discussed in this docu
	ment, and applies to all network solutions. </t>
	<t>Exploiting potentially yet unknown protocol vulnerabilities in the AN or ot
	her protocols. Also this is a generic threat that applies to all network solutio
	ns.</t>
	</list></t>
	<t>The above threats are in principle comparable to other solutions: In the pres ence of design, implementation or operational errors, security is no longer guar anteed. However, the distributed nature of AN, specifically the Autonomic Contro l Plane, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP, and ca n use all AN methods and protocols. </t>		<date month="May" year="2021"/>
	<t>For the next phase of the ANIMA work it is therefore recommended to introduce		</front>
	a sub-domain security model, to reduce the attack surface and not expose a full		<seriesInfo name="RFC" value="8995"/>
	domain to a potential intruder. Furthermore, additional security mechanisms on		<seriesInfo name="DOI" value="10.17487/RFC8995"/>
	the ASA level should be considered for high-risk autonomic functions. </t>		</reference>
	</section>		<reference anchor="RFC8994" target="https://www.rfc-editor.org/info/rfc8994">
			<front>
			<title>An Autonomic Control Plane (ACP)</title>
	</section>		<author initials="T" surname="Eckert" fullname="Toerless Eckert" role="editor">
	<!-- security -->		<organization/>
			</author>
	<section anchor="iana" title="IANA Considerations">		<author initials="M" surname="Behringer" fullname="Michael Behringer" role="edit
	<t>This document requests no action by IANA. </t>		or">
	</section>		<organization/>
	<!-- iana -->		</author>
	<section anchor="ack" title="Acknowledgements">		<author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnason">
	<t>Many people have provided feedback and input to this d		<organization/>
	ocument: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur		</author>
	Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, Tianran Zhou an
	d Christian Hopps.</t>
	</section>
	<!-- ack -->
	<section anchor="contributors" title="Contributors">		<date month="May" year="2021"/>
	<t>Significant contributions to this document have been m
	ade by John Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia.</t
	>
	</section>
	<!-- contributors -->
	</middle>		</front>
	<back>		<seriesInfo name="RFC" value="8994"/>
	<references title="Normative References">		<seriesInfo name="DOI" value="10.17487/RFC8994"/>
	<?rfc include="reference.I-D.ietf-anima-bootstrapping-key		</reference>
	infra.xml"?>
	<?rfc include="reference.I-D.ietf-anima-autonomic-control
	-plane.xml"?>
	<?rfc include="reference.I-D.ietf-anima-grasp.xml"?>
	<reference anchor="IDevID"
	target="http://standards.ieee.org/findstds/standard/802.1AR-200
	9.html">
	<front>
	<title>IEEE 802.1AR Secure Device Identifier</title>
	<author surname="IEEE Standard"></author>		<reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8990">
			<front>
			<title>A GeneRic Autonomic Signaling Protocol (GRASP)</title>
	<date month="December" year="2009" />		<author initials="C" surname="Bormann" fullname="Carsten Bormann">
	</front>		<organization/>
	</reference>		</author>
	</references>		<author initials="B" surname="Carpenter" fullname="Brian Carpenter" role="editor
			">
			<organization/>
			</author>
	<references title="Informative References">		<author initials="B" surname="Liu" fullname="Bing Liu" role="editor">
	<?rfc include='reference.RFC.7575'?>		<organization/>
	<?rfc include='reference.RFC.7576'?>		</author>
	<?rfc include="reference.I-D.ietf-anima-grasp-api.xml"?>
	<?rfc include="reference.I-D.carpenter-anima-asa-guidelin
	es"?>
	<?rfc include="reference.I-D.du-anima-an-intent.xml"?>
	<?rfc include="reference.I-D.ietf-anima-stable-connectivi
	ty.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-dat
	a-model"?>
	<reference anchor="Meyer97">
	<front>
	<title>Object-Oriented Software Construction (2nd edition)</title>
	<author initials="B." surname="Meyer"></author>		<date month="May" year="2021"/>
	<date year="1997" />		</front>
			<seriesInfo name="RFC" value="8990"/>
			<seriesInfo name="DOI" value="10.17487/RFC8990"/>
			</reference>
			<reference anchor="IDevID" target="https://1.ieee802.org/security/802-1ar"
			>
			<front>
			<title>IEEE Standard for Local and metropolitan area networks - Secure
			Device Identity
			</title>
			<author>
			<organization>IEEE</organization>
			</author>
	</front>		</front>
	<seriesInfo name="Prentice-Hall," value='ISBN 978-0136291558' />		<seriesInfo name="IEEE" value="802.1AR"/>
	</reference>		</reference>
	</references>		</references>
	</back>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7575.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.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 initials="X" surname="Gong" fullname="Xiangyang Gong">
			<organization/>
			</author>
			<date month="May" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8991"/>
			<seriesInfo name="DOI" value="10.17487/RFC8991"/>
			</reference>
			<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.R
			FC.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"/>
			<date year="1997"/>
			</front>
			<seriesInfo 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"/>, a
			nd <contact fullname="Artur Hecker"/>. Useful reviews were made by <contact full
			name="Joel Halpern"/>, <contact fullname="Radia Perlman"/>, <contact fullname="T
			ianran 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 fullna
			me="John Strassner"/> (Huawei), <contact fullname="Bing Liu"/>
			(Huawei), and <contact fullname="Pierre Peloso"/> (Nokia).</t>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 119 change blocks.
	1098 lines changed or deleted		1230 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/