One document matched: draft-behringer-anima-reference-model-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<rfc ipr="trust200902" docName="draft-behringer-anima-reference-model-03" category="info">
<front>
<title abbrev="AN Reference Model">A Reference Model for Autonomic Networking</title>
<author role="editor" fullname="Michael H. Behringer" initials="M." surname="Behringer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Building D, 45 Allee des Ormes</street>
<city>Mougins</city>
<region/>
<code>06250</code>
<country>France</country>
</postal>
<email>mbehring@cisco.com</email>
</address>
</author>
<author surname="Carpenter" initials="B. E." fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"/>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region/>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Toerless Eckert" initials="T." surname="Eckert">
<organization>Cisco</organization>
<address>
<email>eckert@cisco.com</email>
</address>
</author>
<author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
<organization>Alcatel Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region/>
<code>91620</code>
<country>France</country>
</postal>
<email>laurent.ciavaglia@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies </organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Jeferson Campos Nobre" initials="J.C." surname="Nobre">
<organization>Federal University of Rio Grande do Sul</organization>
<address>
<postal>
<street>Av. Bento Gonçalves, 9500</street>
<city>Porto Alegre</city>
<code>91501-970</code>
<country>Brazil</country>
</postal>
<email>jcnobre@inf.ufrgs.br</email>
</address>
</author>
<author fullname="John Strassner" initials="J." surname="Strassner">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara, CA</city>
<code>95050</code>
<country>USA</country>
</postal>
<email>john.sc.strassner@huawei.com</email>
</address>
</author>
<date day="30" month="June" year="2015"/>
<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>
<abstract>
<t>
This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The document "Autonomic Networking - Definitions and Design Goals" <xref target="RFC7575"/> explains the fundamental concepts behind Autonomic Networking, and defines the relevant terms in this space. In section 5 it describes a high level reference model. This document defines this reference model with more detail, to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG.</t>
<t>As discussed in <xref target="RFC7575"/>, the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach. </t>
<t>This is a living document and will evolve with the technical solutions developed in the ANIMA WG. Sections marked with (*) do not represent current charter items. While this document must give a long term architectural view, not all functions will be standardized at the same time.</t>
</section>
<!-- intro -->
<section anchor="network" title="The Network View">
<t>This section describes the various elements in a network with autonomic functions, and how these entities work together, on a high level. Subsequent sections explain the detailed inside view for each of the autonomic network elements, as well as the network functions (or interfaces) between those elements. </t>
<t><xref target="network-view"/> shows the high level view of an Autonomic Network. It consists of a number of autonomic nodes, which interact directly with each other. Those autonomic nodes provide a common set of capabilities across the network, called the "Autonomic Networking Infrastructure" (ANI). The ANI provides functions like naming, addressing, negotiation, synchronization, 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" (ASA), which are instantiated on nodes. </t>
<figure anchor='network-view' title="High level view of an Autonomic Network">
<artwork>
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : Autonomic Function 1 : :
: ASA 1 : ASA 1 : ASA 1 : ASA 1 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: : :
: +- - - - - - - - - - - - - - + :
: : Autonomic Function 2 : :
: : ASA 2 : ASA 2 : :
: +- - - - - - - - - - - - - - + :
: : :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
: Autonomic Networking Infrastructure :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+ : +--------+ : +--------+ : +--------+
| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
+--------+ : +--------+ : +--------+ : +--------+
</artwork>
</figure>
<t>In a horizontal view, autonomic functions span across the network, as well as the Autonomic Networking Infrastructure. In a vertical view, a node always implements the ANI, plus it may have one or several Autonomic Service Agents. </t>
<t>The Autonomic Networking Infrastructure (ANI) therefore is the foundation for autonomic functions. The current charter of the ANIMA WG is to specify the ANI, using a few autonomic functions as use cases. </t>
</section>
<!-- network -->
<section anchor="element" title="The Autonomic Network Element">
<section anchor="element-arch" title="Architecture">
<t>This section describes an autonomic network element and its internal architecture. The reference model explained in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> shows the sources of information that an autonomic service agent can leverage: Self-knowledge, network knowledge (through discovery), Intent, and feedback loops. Fundamentally, there are two levels inside an autonomic node: the level of Autonomic Service Agents, and the level of the Autonomic Networking Infrastructure, with the former using the services of the latter. <xref target="ref_model"/> illustrates this concept.
</t>
<t>
<figure anchor='ref_model' title="Model of an autonomic node">
<artwork>
+------------------------------------------------------------+
| |
| +-----------+ +------------+ +------------+ |
| | Autonomic | | Autonomic | | Autonomic | |
| | Service | | Service | | Service | |
| | Agent 1 | | Agent 2 | | Agent 3 | |
| +-----------+ +------------+ +------------+ |
| ^ ^ ^ |
| - - | - - API level - -| - - - - - - - |- - - |
| V V V |
|------------------------------------------------------------|
| Autonomic Networking Infrastructure |
| - Data structures (ex: certificates, peer information) |
| - Autonomic Control Plane |
| - discovery, negotiation and synchronisation functions |
| - Intent distribution |
| - aggregated reporting and feedback loops |
| - routing |
|------------------------------------------------------------|
| Basic Operating System Functions |
+------------------------------------------------------------+
</artwork>
</figure>
</t>
<t>The Autonomic Networking Infrastructure (lower part of <xref target="ref_model"/>) contains node specific data structures, for example trust information about itself and its peers, as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic, and support a variety of Autonomic Service Agents (upper part of <xref target="ref_model"/>). The Autonomic Control Plane is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services.</t>
<t>The use cases of "Autonomics" such as self-management, self-optimisation, etc, are implemented as Autonomic Service Agents. They use the services and data structures of the underlying autonomic networking infrastructure. The underlying Autonomic Networking Infrastructure should itself be self-managing. </t>
<t>The "Basic Operating System Functions" include the "normal OS", including the network stack, security functions, etc. </t>
</section>
<!-- element-architecture -->
<section anchor="un-constrained" title="Full AN Nodes">
<t>Full AN nodes have the full Autonomic Networking Infrastructure, with the full functionality (details to be worked out). They support all the capabilities outlined in the rest of the document. [tbc] </t>
</section>
<!-- unconstrained -->
<section anchor="constrained" title="Constrained AN Nodes (*)">
<t>Constrained nodes have a reduced ANI, with a well-defined minimal functionality (details to be worked out): They do need to be able to join the network, and communicate with at least a helper node which has full ANI functionality. Capabilities of constrained nodes need to be defined here. [tbc] </t>
</section>
<!-- constrained -->
</section>
<!-- element -->
<section anchor="ani" title="The Autonomic Networking Infrastructure">
<t>The Autonomic Networking Infrastructure provides a layer of common functionality across an Autonomic Network. It comprises "must implement" functions and services, as well as extensions. </t>
<t>An Autonomic Function, comprising of Autonomic Service Agents on nodes, can rely on the fact that all nodes in the network implement at least the "must implement" functions. </t>
<section anchor="naming" title="Naming">
<section title="Naming requirements">
<t><list style="symbols">
<t>Representing each device<list style="hanging">
<t>Inside a domain, each autonomic device needs a domain
specific identifier.</t>
<t>[Open Questions] Are there devices that don't need names?
Do ASAs need names?</t>
</list></t>
<t>Uniqueness<list style="hanging">
<t>The names MUST NOT collide within one autonomic
domain.</t>
<t>It is acceptable that the names in different domains
collide, since they could be distinguished by domains.</t>
</list></t>
<t>Semantic Encoding<list style="hanging">
<t>It is RECOMMENDED that the names encode some semantics
rather than meaningless strings. The semantics might
be:<list style="symbols">
<t>Location</t>
<t>Device type</t>
<t>Functional role</t>
<t>Ownership</t>
<t>etc.</t>
</list></t>
<t>This is for ease of management consideration that network
administrators could easily recognize the device directly
through the names.</t>
</list></t>
<t>Consistency<list style="hanging">
<t>The devices' naming SHOULD follow the same pattern within
a domain.</t>
</list></t>
</list></t>
</section>
<section title="Proposed Mechanisms">
<t><spanx/><list style="symbols">
<t>Structured Naming Pattern<list style="hanging">
<t>The whole name string could be divided into several
fields, each of which representing a specific semantic as
described above. For example:
Location-DeviceType-FunctionalRole-DistinguisherNumber@NameofDomain.</t>
<t>The structure should be flexible that some fields are
optional. When these optional fields are added, the name
could still be recognized as the previous one. In above
example, the "DistinguisherNumber" and "NameofDomain" are
mandatory whereas others are optional. At initial stage, the
devices might be only capable of self-generating the
mandatory fields and the "DeviceType" because of the lack of
knowledge. Later, they might have learned the "Location" and
"FunctionalRole" and added the fields into current name.
However, the other devices could still recognize it
according to the same "DistinguisherNumber".</t>
</list></t>
<t>Advertised Common Fields<list style="hanging">
<t>Some fields in the structured name might be common among
the domain (e.g. "Location" "NameofDomain"). Thus, these
part of the names could be advertised through Intent
Distribution<xref target="intent-distri"/>.</t>
</list></t>
<t>Self-generated Fields<list style="hanging">
<t>The mandatory fields SHOULD be self-generated so that one
device could name itself sufficiently without any advertised
knowledges.</t>
<t>There should various methods for a device to
extract/generate a proper word for each mandatory semantic
fields (e.g. "DeviceType", "DistinguisherNum") from its
self-knowledge.</t>
</list></t>
</list>Detailed design of specific naming patterns and methods are
out of scope of this document.</t>
</section>
</section>
<!-- naming -->
<section anchor="addressing" title="Addressing">
<t>Autonomic Service Agents (ASAs) need to communicate with each other, using the autonomic addressing of the node they reside on. This section describes the addressing approach of the Autonomic Networking Infrastructure, used by ASAs. It does NOT describe addressing approaches for the data plane of the network, which may be configured and managed in the traditional way, or negotiated as a service of an ASA. One use case for such an autonomic function is described in <xref target="I-D.jiang-auto-addr-management"/>. The addressing of the Autonomic Networking Infrastructure is in scope for this section, the address space they negotiate for the data plane is not. </t>
<t>Autonomic addressing is a function of the Autonomic Networking Infrastructure (lower part of <xref target="ref_model"/>). ASAs do not have their own addresses. They may use either API calls, or the autonomic addressing scheme of the Autonomic Networking Infrastructure. </t>
<section anchor="addr-req" title="Requirements and Fundamental Concepts">
<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 address management, tools, or address planning. </t>
<t>Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high level guidance only, expressed in Intent.</t>
<t>Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around, for the network to grow, split and merge. </t>
<t>Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. </t>
<t>Support for virtualization: Autonomic Nodes may support Autonomic Service Agents in different virtual machines or containers. The addressing scheme should support this architecture. </t>
<t>Simplicity: To make engineering simpler, and to give the 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 different addressing concepts in the future. </t>
</list>
</t>
<t>These are the fundamental concepts of autonomic addressing:
<list style="symbols">
<t>IPv6 only: Autonomic processes SHOULD (as defined in <xref target="RFC2119"/>) use exclusively IPv6, for simplicity reasons.</t>
<t>Usage: Autonomic addresses are exclusively used for self-management functions inside a trusted domain. They are not used for user traffic. Communications with entities outside the trusted domain use another address space, for example normally managed routable address space.</t>
<t>Separation: Autonomic address space is used separately from user address space and other address realms. This supports the robustness requirement. Link-local is considered not part of user address space for this purpose. </t>
<t>Overlay network: Routeable addresses for AN nodes are used exclusively in a secure overlay network which is the basis of the ACP. This means that these addresses will be assigned to the loopback interface in most operating systems. All other interfaces exclusively use IPv6 link local for autonomic functions. The usage of IPv6 link local addressing is discussed in <xref target="RFC7404"/>.</t>
<t>Use-ULA: For these overlay addresses of autonomic nodes, we use Unique Local Addresses (ULA), as specified in <xref target="RFC4193"/>. An alternative scheme was discussed, using assigned ULA addressing. The consensus was to use standard ULA, because it was deemed to be sufficient. </t>
<t>No external connectivity: They do not provide access to the Internet. If a node requires further reaching connectivity, it should use another, traditionally managed address scheme in parallel. </t>
</list></t>
</section>
<!-- addr-req -->
<section anchor="scheme" title="The Base Addressing Scheme">
<t>The Base ULA addressing scheme for autonomic nodes has the following format:</t>
<t><figure title="Base Addressing Scheme" anchor='base-addr-scheme'>
<artwork>
8 40 3 77
+--+--------------+------+------------------------------------------+
|FD| hash(domain) | Type | (sub-scheme) |
+--+--------------+------+------------------------------------------+
</artwork>
</figure></t>
<t>The first 48 bits follow the ULA scheme, as defined in <xref target="RFC4193"/>, to which a type field is added:
<list style="symbols">
<t>"FD" identifies a locally defined ULA address. </t>
<t>The "global ID" is set here to be a hash of the domain name, which results in a pseudo-random 40 bit value. It is calculated as the first 40 bits of the MD5 hash of the domain name, in the example "example.com".</t>
<t>Type: Set to 000 (3 zero bits). This field allows different address sub-schemes in the future. The goal is to start with a minimal number of sub-scheme initially, but to allow for extensions later if and when required. This addresses the "upgradability" requirement. Assignment of types for this field should be maintained by IANA.</t>
</list></t>
</section>
<!-- scheme -->
<section anchor="sub-schemes" title="Possible Sub-Schemes">
<t>The sub-schemes listed here are not intended to be all supported initially, but are listed for discussion. The final document should define ideally only a single sub-scheme for now, and leave the other "types" for later assignment. </t>
<section anchor="scheme-1" title="Sub-Scheme 1">
<t><figure title="Addressing Scheme 1" anchor='addr-scheme-1'>
<artwork>
51 13 64
+------------------------+---------+--------------------------------+
| (base scheme) | Zone ID | Device ID |
+------------------------+---------+--------------------------------+
</artwork>
</figure></t>
<t>The fields are defined as follows: [Editor's note: The lengths of the fields is for discussion.]
<list style="symbols">
<t>Zone ID: If set to all zero bits: Flat addressing scheme. Any other value indicates a zone. See section <xref target="hierarchy"/> on how this field is used in detail. </t>
<t>Device ID: A unique value for each device, typically assigned by a registrar. </t>
</list>
</t>
<t>The device ID is derived as follows: In an Autonomic Network, a registrar is enrolling new devices. As part of the enrolment process the registrar assigns a number to the device, which is unique for this registrar, but not necessarily unique in the domain. The 64 bit device ID is then composed as:
<list style="symbols">
<t>48 bit: Registrar ID, a number unique inside the domain that identifies the registrar which assigned the name to the device. A MAC address of the registrar can be used for this purpose. </t>
<t>16 bit: Device ID, a number which is unique for a given registrar, to identify the device. This can be a sequentially assigned number. </t>
</list>
</t>
<t>The "device ID" itself is unique in a domain (i.e., the Zone-ID is not required for uniqueness). Therefore, a device can be addressed either as part of a flat hierarchy (zone ID = 0), or with an aggregation scheme (any other zone ID). An address with zone-ID 0 (zero) could be interpreted as an identifier, with another zone-ID as a locator.</t>
</section>
<!-- scheme-1 -->
<section anchor="scheme-2" title="Sub-Scheme 2">
<t><figure title="Addressing Scheme 2" anchor='addr-scheme-2'>
<artwork>
51 13 64-V ?
+------------------------+---------+----------------------------+---+
| (base scheme) | Zone ID | Device ID | V |
+------------------------+---------+----------------------------+---+
</artwork>
</figure></t>
<t>The fields are defined as follows: [Editor's note: The lengths of the fields is for discussion.]
<list style="symbols">
<t>Zone ID: As in sub-scheme 1. </t>
<t>Device ID: As in sub-scheme 1.</t>
<t>V: Virtualization bit(s): 1 or more bits that indicate a virtual context on an autonomic node.</t>
</list>
</t>
<t>In addition the scheme 1 (<xref target="scheme-1"/>), this scheme allows the direct addressing of specific virtual containers / VMs on an autonomic node. An increasing number of hardware platforms have a distributed architecture, with a base OS for the node itself, and the support for hardware blades with potentially different OSs. The VMs on the blades could be considered as separate autonomic nodes, in which case it would make sense to be able to address them directly. Autonomic Service Agents (ASAs) could be instantiated in either the base OS, or one of the VMs on a blade. This addressing scheme allows for the easy separation of the hardware context.</t>
<t>The location of the V bit(s) at the end of the address allows to announce a single prefix for each autonomic node, while having separate virtual contexts addressable directly.</t>
</section>
<!-- scheme-2 -->
</section>
<!-- sub-schemes -->
<section anchor="hierarchy" title="Address Hierarchy">
<t>The "zone ID" allows for the definition of a simple address hierarchy. If set to zero, the address scheme is flat. In this case, the addresses primarily act as identifiers for the nodes. Used like this, aggregation is not possible. </t>
<t>If aggregation is required, the 13 bit value allows for up to 8191 zones. (Theoretically, the 13 bits for the zone ID would allow also for two levels of zones, introducing a sub-hierarchy. We do not think this is required at this point, but a new type could be used in the future to support such a scheme.)</t>
<t>Another way to introduce hierarchy is to use sub-domains in the naming scheme. The node names "node17.subdomainA.example.com" and "node4.subdomainB.example.com" would automatically lead to different ULA prefixes, which can be used to introduce a routing hierarchy in the network, assuming that the subdomains are aligned with routing areas. </t>
</section> <!-- hierarchy -->
</section>
<!-- addressing -->
<section anchor="discovery" title="Discovery">
<t>Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all, and therefore it needs to discover peers and other resources in the network. This section describes various discovery functions in an autonomic network.</t>
<t>Discovering nodes and their properties and capabilities: A core function to establish an autonomic domain is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may in principle either leverage existing discovery mechanisms, or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change.</t>
<t>Discovering services: Network services such as AAA should also be discovered and not configured. Service discovery is required for such tasks. An autonomic network can either leverage existing service discovery functions, or use a new approach, or a mixture.</t>
<t>Thus the discovery mechanism could either be fully integrated with autonomic signaling (next section) or could use an independent discovery mechanism such as DNS Service Discovery or Service Location Protocol. This choice could be made independently for each Autonomic Service Agent, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism, or the source of intent distribution, <xref target="intent-distri"/>).</t>
</section>
<!-- discovery -->
<section anchor="negotiation" title="Signaling Between Autonomic Nodes">
<t>Autonomic nodes must communicate with each other, for example to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be able to handle any sort of technical objective, including ones that require complex data structures. The document "A Generic Discovery and Negotiation Protocol for Autonomic Networking" <xref target="I-D.carpenter-anima-gdn-protocol"/> describes more detailed requirements for discovery, negotiation and synchronization in an autonomic network. It also defines a protocol, GDNP, for this purpose, including an integrated but optional discovery protocol.</t>
</section>
<!-- negotiation -->
<section anchor="intent-distri" title="Intent Distribution">
<t>Intent is the policy language of an Autonomic Network; see <xref target="intent"/> for general information on Intent. The distribution of Intent is also a function of the Autonomic Control Plane. It is expected that Intent will be expressed as quite complex human-readable data structures, and the distribution mechanism must be able to support that. Some Intent items will need to be flooded to most or all nodes, and other items of Intent may only be needed by a few nodes. Various methods could be used to distribute Intent across an autonomic domain. One approach is to treat it like any other technical objective needing to be synchronized across a set of nodes. In that case the autonomic signaling protocol could be used (previous section).</t>
</section>
<!-- intent-distri -->
<section anchor="routing" title="Routing">
<t>All autonomic nodes in a domain must be able to communicate with each other, and with autonomic nodes outside their own domain. Therefore, an Autonomic Control Plane relies on a routing function. For Autonomic Networks to be interoperable, they must all support one common routing protocol. </t>
</section>
<!-- routing -->
<section anchor="acp" title="The Autonomic Control Plane">
<t>The totality of autonomic interactions forms the "Autonomic Control Plane". This control plane can be either implemented in the global routing table of a node, such as IGPs in today's networks; or it can be provided as an overlay network. The document "An Autonomic Control Plane" (<xref target="I-D.behringer-anima-autonomic-control-plane"/>) describes the details. </t>
</section>
<!-- acp -->
</section>
<!-- ani -->
<section anchor="trust" title="Security and Trust Infrastructure">
<t>An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security. </t>
<t>Autonomic nodes have direct interactions between themselves, which must be secured. Since an autonomic network does not rely on configuration, it is not an option to configure for example pre-shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. </t>
<t>A completely autonomic way to automatically and securely deploy such a trust infrastructure is to set up a trust anchor for the domain, and then use an approach as in the document "Bootstrapping Key Infrastructures" <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/>.</t>
<section anchor="pki" title="Public Key Infrastructure">
<t>An autonomic domain uses a PKI model. The root of trust is a certification 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>
<!-- pki -->
<section anchor="cert" title="Domain Certificate">
<t>We need to define how the fields in a domain certificate are to be used. [tbc]</t>
</section>
<!-- cert -->
<section anchor="masa" title="The MASA">
<t>Explain briefly the function, point to <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/>. [tbc]</t>
</section>
<!-- masa -->
<section anchor="sub-domains" title="Sub-Domains (*)">
<t>Explain how sub-domains are handled. (tbc)</t>
</section>
<!-- sub-domains -->
<section anchor="cross-domain" title="Cross-Domain Functionality (*)">
<t>Explain how trust is handled between different domains. (tbc)</t>
</section>
<!-- sub-domains -->
</section>
<!-- trust -->
<section anchor="asa" title="Autonomic Service Agents (ASA)">
<t>This section describes how autonomic services run on top of the Autonomic Networking Infrastructure. </t>
<section anchor="asa-general" title="General Description of an ASA">
<t>general concepts, such as sitting on top of the ANI, etc. Also needs to explain that on a constrained node (see <xref target="constrained"/>) not all ASAs may run, so we have two classes of ASAs: Ones that run on an unconstrained node, and limited function ASAs that run also on constrained nodes. We expect unconstrained nodes to support all ASAs.</t>
</section>
<section anchor="specific-asas" title="Specific ASAs for the Enrolment Process">
<t>The following ASAs provide essential, required functionality in an autonomic network, and are therefore mandatory to implement on unconstrained autonomic nodes. </t>
<section anchor="enrolment" title="The Enrolment ASA">
<t>This section describes the function of an autonomic node to bootstrap into the domain with the help of an enrolment proxy (see previous section). [tbc]</t>
</section>
<!-- enrolment -->
<section anchor="enrolment-proxy" title="The Enrolment Proxy ASA">
<t>This section describes the function of an autonomic node that helps a non-enrolled, adjacent devices to enrol into the domain. [tbc]</t>
</section>
<!-- enrolment-proxy -->
<section anchor="registrar" title="The Registrar ASA">
<t>This section describes the registrar function in an autonomic network. It explains the tasks of a registrar element, and how registrars are placed in a network, redundancy between several, etc. [tbc]</t>
</section>
<!-- registrar -->
</section>
<!-- specific-asas -->
</section>
<!-- asa -->
<section anchor="management" title="Management and Programmability">
<t>This section describes how an Autonomic Network is managed, and programmed.</t>
<section anchor="management-general" title="How an AN Network Is Managed">
<t>Autonomic management usually co-exists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. In fact, the co-existence is twofold: autonomic functions can use traditional methods and protocols (e.g., SNMP and NETCONF) to perform management tasks; and autonomic functions can conflict with behavior enforced by the same traditional methods and protocols. </t>
<t>The autonomic intent is defined at a high level of abstraction. However, since it is necessary to address individual managed elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). For example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules as well as the monitoring be executed through SNMP and MIBs.</t>
<t>Conflict can occur between autonomic default behavior, autonomic intent, traditional management methods. Conflict resolution is achieved in autonomic management through prioritization [RFC7575]. The rationale is that manual and node-based management have a higher priority over autonomic management. Thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command line interfaces [RFC7575]. </t>
</section>
<!-- management-general -->
<section anchor="intent" title="Intent (*)">
<!-- Explaining ingest of intent, distribution, the nature (on top of what’s in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>). That intent is signed, time stamps, etc. Probably pointing back to <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>. (Note intent distribution is handled in <xref target="intent-distri"/>) [tbc] -->
<t>This section describes Intent, and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., PCIM and SUPA) and in other SDOs (e.g., DMTF and TMF ZOOM). </t>
<t>Intent can be describe as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC7575]. Intent should be limited to high level guidance only, thus it does not directly define a policy for every network element separately. In an ideal autonomic domain, only one intent provided by human administrators is necessary to operate such domain [RFC7576]. However, it is als expected intent definition from autonomic function(s) and even from traditional network management elements (e.g., OSS). </t>
<t>Intent can be refined to lower level policies using different approaches, such as Policy Continuum model [ref]. This is expected in order to adapt the intent to the capabilities of managed devices. In this context, intent may contain role or function information, which can be translated to specific nodes [RFC7575]. One of the possible refinements of the intent is the refinement to Event Condition Action (ECA) rules. Such rules, which are more suitable to individual entities, can be defined using different syntax and semantics. </t>
<t>Different parameters may be configured for intents. These parameters are usually provided by the human operator. Some of these parameters can influence the behavior of specific autonomic functions as well as the way the intent is used to manage the autonomic domain (towards intended operational point). </t>
<t>Some examples of parameters for intents are:
<list style="symbols">
<t>Model version: The version of the model used to define the intent. </t>
<t>Domain: The network scope in which the intent has effect. </t>
<t>Name: The name of the intent which describes the intent for human operators. </t>
<t>Version: The version of the intent, which is primarly used to control intent updates. </t>
<t>Signature: The signature is used as a security mechanism to provide authentication, integrity, and non-repudiation. </t>
<t>Timestamp: The timestamp of the creation of the intent using the format supported by the IETF [TBC]. </t>
<t>Lifetime: The lifetime in which the intent may be observed. A special case of the lifetime is the definition of permanent intents. </t>
</list> </t>
<t>Intent distribution is considered as one of the common control and management functions of an autonomic network [RFC7575]. Since distribution is fundamental for autonomic networking, it is necessary a mechanism to provision intent by all devices in a domain [draft-carpenter-anima-gdn-protocol]. The distribution of Intent is function of the Autonomic Control Plane and several methods can be used to distribute Intent across an autonomic domain [draft-behringer-anima-reference-model]. Intent distribution might not use the ANIMA signaling protocol itself [draft-carpenter-anima-gdn-protocol], but there is a proposal to extend such protocol for intent delivery [draft-liu-anima-intent-distribution]. </t>
</section>
<!-- intent -->
<section anchor="reporting" title="Aggregated Reporting (*)">
<!-- <t>An autonomic network offers through the autonomic control plane the possibility to aggregate information inside the network, before sending it to the admin of the network. While this can be seen or implemented as a specific form of negotiation, the use case is different and therefore mentioned here explicitly. </t> -->
<t>Autonomic Network should minimize the need for human intervention. In terms of how the network should behave, this is done through an autonomic intent provided by the human administrator. In an analogous manner, the reports which describe the operational status of the network should aggregate the information produced in different network elements in order to present the effectiveness of autonomic intent enforcement. Therefore, reporting in an autonomic network should happen on a network-wide basis [RFC7575]. The information gathering and the reporting delivery should be done through the autonomic control plane. </t>
<t>Several events can occur in an autonomic network in the same way they can happen in a traditional network. These events can be produced considering traditional network management protocols, such as SNMP and syslog. However, when reporting to a human administrator, such events should be aggregated in order to avoid advertisement about individual managed elements. In this context, algorithms may be used to determine what should be reported (e.g., filtering) and in which way and how different events are related to each other. Besides that, an event in an individual element can be compensated by changes in other elements in order to maintain in a network-wide level which is described in the autonomic intent. </t>
<t>Reporting in an autonomic network may be in the same abstraction level of the intent. In this context, the visibility on current operational status of an autonomic network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, possibly there are some events that need to be addressed by human administrator actions. An alternative to model this is the use of exception-based management [RFC7575]. </t>
</section>
<!-- reporting -->
<section anchor="feedback" title="Feedback Loops to NOC(*)">
<t>Feedback loops are required in an autonomic network to allow the intervention of a human administrator or central control systems, while maintaining a default behaviour. Through a feedback loop an administrator can be prompted with a default action, and has the possibility to acknowledge or override the proposed default action.</t>
</section>
<!-- feedback -->
<section anchor="control-loops" title="Control Loops (*)">
<t>Control loops provide a generic mechanism for self-adaptation. That
is, as user needs, business goals, and the ANI itself change, self-
adaptation enables the ANI to change the services and resources it
makes available to adapt to these changes. Self-adaptive systems
move decision-making from static, pre-defined commands to dynamic
processes computed at runtime.</t>
<t>Control loops operate to continuously capture data that enables the
understanding of the system, and then provide actions to move the
state of the system toward a common goal.</t>
<section anchor="types-of-control" title="Types of Control (*)">
<t>There are two generic types of closed loop control. Feedback
control adjusts the control loop based on measuring the output of
the system being managed to generate an error signal (the
deviation of the current state vs. its desired state). Action is
then taken to reduce the deviation.</t>
<t>In contrast, feedforward control anticipates future effects on a
controlled variable by measuring other variables whose values may
be more timely, and adjusts the process based on those variables.
In this approach, control is not error-based, but rather, based
on knowledge.</t>
<t>Autonomic control loops MAY require both feedforward and feedback
control.</t>
</section>
<!-- types-of-control -->
<section anchor="types-of-control-loops" title="Types of Control Loops (*)">
<t>There are many different types of control loops. In autonomics,
the most commonly cited loop is called Monitor-Analyze-Plan-Execute
(with Knowledge), called MAPE-K [Kephart03]. However, MAPE-K has a
number of systemic problems, as described in [Strassner09].
Therefore, other autonomic architectures, such as AutoI [autoi]
and FOCALE [Strassner07] and use control loops that evolved from
the OODA (Observe-Orient-Decide-Act) control loop [Boyd95]. The
reason for using this loop, and not the MAPE-K loop, is because
the OODA loop contains a critical step not contained in other
loops: orientation. Orientation determines how observations,
decisions, and actions are performed.</t>
<t><xref target="control-loop"/> shows a simplified model of a control loop containing both
feedforward and feedback elements.</t>
<t><figure title="Control Loop with Feedforward and Feedback Elements" anchor='control-loop'>
<artwork>
Input Variables
----------+-------------------------+
| |
| |
\ / \ /
+-----+------+ +----+----+
Set Point --->| Controller |------------>| Process |--+---> Output
+-----+------+ Deltas of +---------+ |
^ Control |
| Variable(s) |
| |
+---------------------------------+
</artwork>
</figure></t>
<t>Note that <xref target="control-loop"/> is a STATIC model. <xref target="adaptive-control-loop"/> is a dynamic version, called a Model-Reference Adaptive Control Loop (MRACL).</t>
<t><figure title="A Model-Reference Adaptive Control Loop" anchor='adaptive-control-loop'>
<artwork>
Model +--------------+
+-------+ Output | Adaptive |<----+
+--->| Model |--------->| Algorithm(s) | |
| +-------+ +---+-----+----+ |
| Adjusted | ^ |
Input | Parameters | | |
--------+ +----------------+ | |
| | | |
| | +---------+ |
| \ / | |
| +-----+------+ | +---------+ |
+--->| Controller |-----+------>| Process |--+---> Output
+-----+------+ Deltas of +---------+ |
^ Control |
| Variable(s) |
| |
+---------------------------------+
</artwork>
</figure></t>
<t>More complex adaptive control loops have been defined; these will
be described in a future I-D, so that an appropriate gap analysis
can be defined to recommend an architectural approach for ANIMA.</t>
</section>
<section anchor="management-of-control-loops" title="Management of an Autonomic Control Loop (*)">
<t>Both standard and adaptive control loops (e.g., as represented in
Figures X and X1, respectively) enable intervention by a human
administrator or central control systems, if required. Interaction
mechanisms include changing the behaviour of one or more elements
in the control loop, as well as providing mechanisms to bypass
parts of the control loop (e.g., skip the "decide" phase and go
directly to the "action" phase of an OODA loop, as is done in
FOCALE). This also enables the default behaviour to be changed if
necessary.</t>
</section>
<section anchor="elements-of-control-loops" title="Elements of an Autonomic Control Loop (*)">
<t>An autonomic control loop MUST be able to perform the following
functions as part of its operation:
<list style="symbols">
<t>Observe and collect data from the system being managed</t>
<t>Orient these data, so that their meaning and significance
can be understood in proper context</t>
<t>Analyze the collected data through filtering, correlation,
and other mechanisms to define a model of past and current
states</t>
<t>Plan different actions based on inferring trends,
determining root causes, and similar processes</t>
<t>Decide which plan(s) to take</t>
<t>Execute the plan, and then repeat these steps</t>
</list></t>
<t>In addition, an autonomic control loop SHOULD be able to execute
one or more machine learning algorithms that can learn from and
make predictions on monitored data. This enables more efficient
adaptivity. Note that machine learning is build from a model of
exemplar inputs in order to make decisions and predictions.
Supporting algorithms, such as those for data mining and analytics,
SHOULD also be supported.</t>
</section>
</section>
<!-- control-loops -->
<section anchor="apis" title="APIs (*)">
<t>Most APIs are static, meaning that they are pre-defined and
represent an invariant mechanism for operating with data. An
Autonomic Network SHOULD be able to use dynamic APIs in addition
to static APIs. APIs MUST be able to express and preserve
semantics across different domains.</t>
<section anchor="dynamic-apis" title="Dynamic APIs (*)">
<t>A dynamic API is one that retrieves data using a generic
mechanism, and then enables the client to navigate the
retrieved data and operate on it. Such APIs typically use
introspection and/or reflection (the former enables software
to examine the type and properties of an object at runtime,
while the latter enables a program to manipulate the attributes,
methods, and/or metadata of an object.</t>
</section>
<section anchor="apis-and-semantics" title="APIs and Semantics(*)">
<t>An API is NOT the same as an interface.</t>
<t>An interface is a boundary across which different components of
a system exchange information. An API is a set of software
(including tools, protocols, and programs) for building software
applications. An API defines a set of data structures, inputs,
outputs, and operations that can be used by a programmer to build
an application.</t>
<t>An Autonomic API must pay particular attention to semantics.
Previous designs have used the notion of a software contract to
build high-quality APIs that are distributed and modular. A
software contract [Meyer97] is based on the principle that a
software-intensive system, such as an Autonomic Network, is a
set of communicating components whose interaction is based on
precisely-defined specification of the mutual obligations that
interacting components must respect. For example, when a method
executes, the following must hold:
<list style="symbols">
<t>pre-conditions must be satisfied before the method can
start execution</t>
<t>post-conditions must be satisfied when the method has
finished execution</t>
<t>invariant attributes must not change during the execution
of the method</t>
</list></t>
</section>
<!-- APIs and semantics -->
<section anchor="api-considerations" title="API Considerations (*)">
<t>APIs should perform one function well, not perform many different
and unrelated functions. In software design, this is called the
Single Responsibility Principle [srp]</t>
</section>
<!-- api-considerations -->
</section>
<!-- apis -->
<section anchor="data-model" title="Data Model (*)">
<t>The following definitions are taken from [supa-model]:</t>
<t>An information model is a representation of concepts of interest
to an environment in a form that is independent of data repository,
data definition language, query language, implementation language,
and protocol. In contrast, a data model is a representation of
concepts of interest to an environment in a form that is dependent
on data repository, data definition language, query language,
implementation language, and protocol (typically, but not
necessarily, all three).</t>
<t>The utility of an information model is to define objects and their
relationships in a technology-neutral manner. This forms a
consensual vocabulary that the ANI and ASAs can use. A data model
is then a technology-specific mapping of all or part of the
information model to be used by all or part of the system.</t>
<t>A system may have multiple data models. Operational Support Systems,
for example, typically have multiple types of repositories, such as
SQL and NoSQL, to take advantage of the different properties of
each. If multiple data models are required by an Autonomic System,
then an information model SHOULD be used to ensure that the
concepts of each data model can be related to each other without
technological bias.</t>
<t>A data model is essential for certain types of functions, such as
a MRACL. More generally, a data model can be used to define the
objects, attributes, methods, and relationships of a software
system (e.g., the ANI, an autonomic node, or an ASA). A data
model can be used to help design an API, as well as any language
used to interface to the Autonomic Network.</t>
</section>
<!-- data model -->
</section>
<!-- management -->
<section anchor="coordination" title="Coordination Between Autonomic Functions (*)">
<section title="The Coordination Problem (*)">
<t>Different autonomic functions may conflict in setting certain parameters. For example, an energy efficiency function may want to shut down a redundant link, while a load balancing function would not want that to happen. The administrator must be able to understand and resolve such interactions, to steer autonomic network performance to a given (intended) operational point.</t>
<t>Several interaction types may exist among autonomic functions, for example:
<list style="symbols">
<t>Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function. </t>
<t>Dependency: An autonomic function cannot work without another one being present or accessible in the autonomic network.</t>
<t>Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions. </t>
</list> </t>
<t>Solving the coordination problem beyond one-by-one cases can rapidly become intractable for large networks. Specifying a common functional block on coordination is a first step to address the problem in a systemic way. The coordination life-cycle consists in three states:
<list style="symbols">
<t>At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities on 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 conflicts 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 driven by the coordination strategies. Also new dependencies can be observed and inferred, resulting in an update of the dynamic interaction map and adaptation of the coordination strategies and mechanisms.</t>
</list></t>
<t>Multiple coordination strategies and mechanisms exists and can be devised. 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 control theory approaches and algorithms family.</t>
</section>
<section title="A Coordination Functional Block (*)">
<t>A common coordination functional block is a desirable component of the ANIMA reference model. It provides a means to ensure network properties and predictable performance or behavior such as stability, and convergence, in the presence of several interacting autonomic functions.</t>
<t>A common coordination function requires:
<list style="symbols">
<t>A common description of autonomic functions, their attributes and life-cycle.</t>
<t>A common representation of information and knowledge (e.g., interaction maps).</t>
<t>A common “control/command” interface between the coordination "agent" and the autonomic functions. </t>
</list></t>
<t>Guidelines, recommendations or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms.</t>
</section>
</section>
<!-- coordination -->
<section anchor="security" title="Security Considerations">
<section title="Threat Analysis">
<t>This is a preliminary outline of a threat analysis, to be expanded and made more specific as the various Autonomic Networking specifications evolve.</t>
<t>Since AN will hand over responsibility for network configuration from humans or centrally established management systems to fully distributed devices, the threat environment is also fully distributed. On the one hand, that means there is no single point of failure to act as an attractive target for bad actors. On the other hand, it means that potentially a single misbehaving autonomic device could launch a widespread attack, by misusing the distributed AN mechanisms. For example, a resource exhaustion attack could be launched by a single device requesting large amounts of that resource from all its peers, on behalf of a non-existent traffic load.
Alternatively it could simply send false information to its peers, for example by announcing resource exhaustion when this was not the case.
If security properties are managed autonomically, a misbehaving device could attempt a distributed attack by requesting all its peers to reduce security protections in some way. In general, since autonomic devices run without supervision, almost any kind of undesirable management action could in theory be attempted by a misbehaving device. </t>
<t>If it is possible for an unauthorised device to act as an autonomic device, or for a malicious third party to inject messages appearing to come from an autonomic device, all these same risks would apply. </t>
<t>If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis, but this would be quite limited (for example, this would be highly unlikely to reveal any specific information about user traffic). AN messages are liable to be exposed to third parties on any unprotected Layer 2 link, and to insider attacks even on protected Layer 2 links. </t>
</section>
</section>
<!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>
</section>
<!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Many people have provided feedback and input to this document: Sheng Jiang, Roberta Maglione, Jonathan Hansford.</t>
</section>
<!-- ack -->
</middle>
<back>
<references title="References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4193'?>
<?rfc include='reference.RFC.7404'?>
<?rfc include='reference.RFC.7575'?>
<?rfc include="reference.I-D.pritikin-bootstrapping-keyinfrastructures.xml"?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.behringer-anima-autonomic-control-plane.xml"?>
<?rfc include="reference.I-D.behringer-anima-autonomic-addressing.xml"?>
<?rfc include="reference.I-D.carpenter-anima-gdn-protocol.xml"?>
<?rfc include="reference.I-D.jiang-auto-addr-management.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 02:59:12 |