ANIMA

Internet Engineering Task Force (IETF)                 M. Behringer, Ed.
Internet-Draft
Intended status:
Request for Comments: 8993
Category: Informational                                     B. Carpenter
Expires: May 27, 2019
ISSN: 2070-1721                                        Univ. of Auckland
                                                               T. Eckert
                                                           Futurewei Technologies Inc. USA
                                                            L. Ciavaglia
                                                                   Nokia
                                                                J. Nobre
                                     University of Vale do Rio dos Sinos
                                                       November 23, 2018
                                                                   UFRGS
                                                                May 2021

               A Reference Model for Autonomic Networking
                  draft-ietf-anima-reference-model-10

Abstract

   This document describes a reference model for Autonomic Networking
   for managed networks.  It defines the behaviour behavior of an autonomic node,
   how the various elements in an autonomic context work together, and
   how autonomic services can use the infrastructure.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents valid
   approved by the IESG are candidates for a maximum any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 27, 2019.
   https://www.rfc-editor.org/info/rfc8993.

Copyright Notice

   Copyright (c) 2018 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The  Network View  . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The  Autonomic Network Element . . . . . . . . . . . . . . . .   5
     3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  The  Adjacency Table . . . . . . . . . . . . . . . . . . .   6
     3.3.  State Machine . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.1.  State 1: Factory Default  . . . . . . . . . . . . . .   8
       3.3.2.  State 2: Enrolled . . . . . . . . . . . . . . . . . .   9
       3.3.3.  State 3: In ACP . . . . . . . . . . . . . . . . . . .   9
   4.  The  Autonomic Networking Infrastructure . . . . . . . . . . .  10
     4.1.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Addressing  . . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.4.  Signaling Between between Autonomic Nodes . . . . . . . . . . . .  12
     4.5.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.6.  The  Autonomic Control Plane . . . . . . . . . . . . . . .  13
     4.7.  Information Distribution (*)  . . . . . . . . . . . . . .  13
   5.  Security and Trust Infrastructure . . . . . . . . . . . . . .  14
     5.1.  Public Key Infrastructure . . . . . . . . . . . . . . . .  14
     5.2.  Domain Certificate  . . . . . . . . . . . . . . . . . . .  14
     5.3.  The  MASA  . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.4.  Sub-Domains  Subdomains (*) . . . . . . . . . . . . . . . . . . . . .  15
     5.5.  Cross-Domain Functionality (*)  . . . . . . . . . . . . .  15
   6.  Autonomic Service Agents (ASA)  . . . . . . . . . . . . . . .  15 (ASAs)
     6.1.  General Description of an ASA . . . . . . . . . . . . . .  15
     6.2.  ASA Life-Cycle Management . . . . . . . . . . . . . . . .  17
     6.3.  Specific ASAs for the Autonomic Network Networking Infrastructure  .  18
       6.3.1.  The enrollment  Enrollment ASAs . . . . . . . . . . . . . . . . .  18
       6.3.2.  The  ACP ASA . . . . . . . . . . . . . . . . . . . . .  19
       6.3.3.  The  Information Distribution ASA (*)  . . . . . . . .  19
   7.  Management and Programmability  . . . . . . . . . . . . . . .  19
     7.1.  Managing a (Partially) Autonomic Network  . . . . . . . .  19
     7.2.  Intent (*)  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.3.  Aggregated Reporting (*)  . . . . . . . . . . . . . . . .  21
     7.4.  Feedback Loops to NOC (*) . . . . . . . . . . . . . . . .  21
     7.5.  Control Loops (*) . . . . . . . . . . . . . . . . . . . .  22
     7.6.  APIs (*)  . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.7.  Data Model (*)  . . . . . . . . . . . . . . . . . . . . .  23
   8.  Coordination Between between Autonomic Functions (*)  . . . . . . . .  24
     8.1.  The  Coordination Problem (*)  . . . . . . . . . . . . . .  24
     8.2.  A  Coordination Functional Block (*) . . . . . . . . . . .  25
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
     9.1.  Protection Against against Outsider Attacks . . . . . . . . . . .  26
     9.2.  Risk of Insider Attacks . . . . . . . . . . . . . . . . .  27
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  28
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
     13.1.
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     13.2.
     11.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Acknowledgements
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30

1.  Introduction

   The document "Autonomic Networking - Networking: Definitions and Design Goals"
   [RFC7575] explains the fundamental concepts behind Autonomic
   Networking,
   Networking and defines the relevant terms in this space, as well as space and a high high-
   level reference model.  [RFC7576] provides a gap analysis between
   traditional and autonomic approaches.

   This document defines this reference model with more detail, detail to allow
   for functional and protocol specifications to be developed in an
   architecturally consistent, non-overlapping manner.

   As discussed in [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.

   For example, it is possible in an existing, non-autonomic network to
   enrol
   enroll devices in a traditional way, way to bring up a trust
   infrastructure with certificates.  This trust infrastructure could
   then be used to automatically bring up an Autonomic Control Plane
   (ACP),
   (ACP) and run traditional network operations over the secure and
   self-healing ACP.  See [I-D.ietf-anima-stable-connectivity] [RFC8368] for a description of this use case.

   The scope of this model is therefore limited to networks that are to
   some extent managed by skilled human operators, loosely referred to
   as "professionally managed" networks.  Unmanaged networks raise
   additional security and trust issues that this model does not cover.

   This document describes a first, simple, implementable the first phase of an Autonomic Networking solution.
   solution that is both simple and implementable.  It is expected that
   the experience from this phase will be used in defining updated and
   extended specifications over time.  Some topics are considered
   architecturally in this document, document but are not yet reflected in the
   implementation specifications.  They are marked with an (*).

2.  The  Network View

   This section describes the various elements in a network with
   autonomic functions, functions and explains how these entities work together, together on
   a high level.  Subsequent sections explain the detailed inside view
   for each of the autonomic network Autonomic Network elements, as well as the network
   functions (or interfaces) between those elements.

   Figure 1 shows the high level high-level view of an Autonomic Network.  It
   consists of a number of autonomic nodes, which interact directly with
   each other.  Those autonomic nodes provide a common set of
   capabilities across the network, called the "Autonomic Networking
   Infrastructure" (ANI).
   Infrastructure (ANI)".  The ANI provides functions like naming,
   addressing, negotiation, synchronization, discovery discovery, and messaging.

   Autonomic functions typically span several, possibly all all, nodes in
   the network.  The atomic entities of an autonomic function are called
   the "Autonomic Service Agents" (ASA), Agents (ASAs)", which are instantiated on
   nodes.

   +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
   :            :       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 |
   +--------+   :    +--------+   :    +--------+   :        +--------+

             Figure 1: High level view High-Level View of an Autonomic Network

   In a horizontal view, autonomic functions span across the network, as
   well as the Autonomic Networking Infrastructure. ANI.  In a vertical view, a node always implements the
   ANI, plus it may have one or several
   Autonomic Service Agents. ASAs.  ASAs may be standalone, standalone or
   use other ASAs in a hierarchical way.

   The Autonomic Networking Infrastructure (ANI) therefore

   Therefore, the ANI is the foundation for autonomic functions.

3.  The  Autonomic Network Element

   This section explains the general architecture of an Autonomic
   Network Element element (Section 3.1), how it tracks its surrounding
   environment in an Adjacency Table adjacency table (Section 3.2), and the state
   machine which that defines the behaviour behavior of the network element
   (Section 3.3), based on that adjacency table.

3.1.  Architecture

   This section describes an autonomic network Autonomic Network element and its internal
   architecture.  The reference model explained in the document
   "Autonomic Networking - Networking: Definitions and Design Goals" [RFC7575] shows
   the sources of information that an autonomic service agent ASA can leverage: Self-knowledge, self-knowledge,
   network knowledge (through discovery), Intent (see Section 7.2), and
   feedback loops.  There are two levels inside an autonomic node: the
   level of Autonomic Service Agents, ASAs and the level of the Autonomic Networking Infrastructure, ANI, with the former using the
   services of the latter.  Figure 2 illustrates this concept.

   +------------------------------------------------------------+
   |                                                            |
   | +-----------+        +------------+        +------------+  |
   | | Autonomic |        | Autonomic  |        | Autonomic  |  |
   | | Service   |        | Service    |        | Service    |  |
   | | Agent 1   |        | Agent 2    |        | Agent 3    |  |
   | +-----------+        +------------+        +------------+  |
   |       ^                    ^                     ^         |
   | -  -  | -  - API level -  -| -  -  -  -  -  -  - |-  -  -  |
   |       V                    V                     V         |
   |------------------------------------------------------------|
   | Autonomic Networking Infrastructure                        |
   |    - Data structures (ex: certificates, peer information)  |
   |    - Generalized Autonomic Control Plane (GACP)            |
   |    - Autonomic Node Addressing node addressing and naming                  |
   |    - Discovery, negotiation and synchronisation synchronization functions  |
   |    - Distribution of Intent and other information          |
   |    - Aggregated reporting and feedback loops               |
   |    - Routing                                               |
   |------------------------------------------------------------|
   |             Basic Operating System Functions               |
   +------------------------------------------------------------+

                    Figure 2: Model of an autonomic node
   The Autonomic Networking Infrastructure Node

   The ANI (lower part of Figure 2) contains node specific node-specific data structures, for example trust
   structures (for example, trust information about itself and its peers,
   peers) as well as a generic set of functions, independent of a
   particular usage.  This infrastructure should be
   generic, generic and support
   a variety of Autonomic Service Agents ASAs (upper part of Figure 2).  It contains addressing
   and naming of autonomic nodes, discovery, negotiation and synchronisation
   synchronization functions, distribution of information, reporting and reporting,
   feedback loops, as well as and routing inside the Autonomic Control Plane. ACP.

   The Generalized Autonomic Control Plane ACP (GACP) is the summary of all interactions of the Autonomic Networking Infrastructure
   ANI with other nodes and services.  A specific implementation of the
   GACP is referred to here as the Autonomic Control Plane (ACP), ACP and described in [I-D.ietf-anima-autonomic-control-plane]. [RFC8994].

   The use cases of "Autonomics" such (such as self-management, self-
   optimisation, etc,
   optimization, etc.) are implemented as Autonomic Service Agents. ASAs.  They use the services
   and data structures of the underlying Autonomic
   Networking Infrastructure, ANI, which should be self-managing. self-
   managing.

   The "Basic Basic Operating System Functions" Functions (lower part of Figure 2) include
   the "normal OS",
   including normal OS (e.g., the network stack, stack and security functions, etc. functions).

   Full AN Autonomic Network (AN) nodes have the full Autonomic Networking Infrastructure, ANI, with the full
   functionality described in this document.  At a later stage stage, the
   ANIMA Working Group may define a scope for constrained nodes with a
   reduced ANI and well-defined minimal functionality.  They  These are
   currently out of scope.

3.2.  The  Adjacency Table

   Autonomic Networking is based on direct interactions between devices
   of a domain.  The Autonomic Control Plane (ACP) ACP is normally constructed on a hop-by-hop basis.
   Therefore, many interactions in the ANI are based on the ANI
   adjacency table.  There are interactions that provide input into the
   adjacency table, table and other interactions that leverage the information
   contained in it.

   The ANI adjacency table contains contains, at a minimum, information about
   adjacent autonomic
   nodes, at a minimum: node-ID, nodes: Node-ID, IP address in data plane, IP
   address in ACP, domain, and certificate.  An autonomic node maintains
   this adjacency table up to date.  The adjacency table only contains
   information about other nodes that are capable of Autonomic
   Networking; non-
   autonomic non-autonomic nodes are normally not tracked here.
   However, the information is tracked independently of the status of
   the peer nodes; specifically, it the adjacency table contains
   information about non-enrolled nodes, nodes of the same and other domains.
   The adjacency table may contain information about the validity and
   trust level of the adjacent autonomic nodes.

   The adjacency table is fed by the following inputs:

   o  Link local

   *  Link-local discovery: This interaction happens in the data plane,
      using IPv6 link local link-local addressing only, because this addressing
      type is itself autonomic.  This way the nodes node learns about all
      autonomic nodes around itself.  The related standards track Standards Track
      documents ([I-D.ietf-anima-grasp],
      [I-D.ietf-anima-bootstrapping-keyinfra],
      [I-D.ietf-anima-autonomic-control-plane]) ([RFC8990], [RFC8995], and [RFC8994]) describe in detail
      how
      link local link-local discovery is used.

   o

   *  Vendor re-direct: redirect: A new device may receive information on where its
      home network is through a vendor based vendor-based Manufacturer Authorized
      Signing Authority (MASA, see (MASA) (see Section 5.3) re-direct; redirect; this is
      typically a routable address.

   o

   *  Non-autonomic input: A node may be configured manually with an
      autonomic peer; it could learn about autonomic nodes through DHCP
      options, DNS, and other non-autonomic mechanisms.  Generally  Generally, such
      non-autonomic mechansims mechanisms require some administrator intervention.
      The key purpose is to by-pass bypass a non-autonomic device or network.
      As this pertains to new devices, it is covered in appendix Appendices A and
      B of [I-D.ietf-anima-bootstrapping-keyinfra]. [RFC8995].

   The adjacency table is defining defines the behaviour behavior of an autonomic node:

   o

   *  If the node has not bootstrapped into a domain (i.e., doesn't have
      a domain certificate), it rotates through all nodes in the
      adjacency table that claim to have a domain, domain and will attempt
      bootstrapping through them, one by one.  One possible response is
      a re-direct redirect via a vendor MASA, which will be entered into the
      adjacency table (see second bullet above).  See
      [I-D.ietf-anima-bootstrapping-keyinfra] [RFC8995] for
      details.

   o

   *  If the adjacent node has the same domain, it will authenticate
      that adjacent node and, if successful, establish the Autonomic
      Control Plane (ACP). ACP.  See
      [I-D.ietf-anima-autonomic-control-plane].

   o
      [RFC8994].

   *  Once the node is part of the ACP of a domain, it will use GRASP
      [I-D.ietf-anima-grasp]
      [RFC8990] to find Registrar(s) the registrar(s) of its domain and potentially
      other services.

   o

   *  If the node is part of an ACP and has discovered at least one
      Registrar
      registrar in its domain via GRASP, it will start the "join
      assistant" ASA, join proxy
      ASA and act as a join assistant proxy for neighboring nodes that need to be
      bootstrapped.  See Section 6.3.1.2 for details.

   o

   *  Other behaviours behaviors are possible, for example example, establishing the ACP
      also
      with devices of a sub-domain, to subdomain or other domains, etc.  Those domains.  These will likely
      be controlled by Intent.  They Intent and are outside scope for the moment. scope of this
      document.  Note that Intent is distributed through the ACP;
      therefore, a node can only adapt Intent driven behaviour Intent-driven behavior once it
      has joined the ACP.  At the moment, the ANIMA Working Group does
      not consider providing Intent outside the ACP; this can be
      considered later.

   Once a node has joined the ACP, it will also learn the ACP addresses
   of its adjacent nodes, nodes and add them to the adjacency table, table to allow
   for communication inside the ACP.  Further autonomic domain
   interactions will now happen inside the ACP.  At this moment, only
   negotiation / and synchronization via GRASP [I-D.ietf-anima-grasp] is
   being [RFC8990] are defined.
   (Note that GRASP runs in the data plane, as an input in building the
   adjacency table, as well as inside the ACP.)

   Autonomic Functions functions consist of Autonomic Service Agents (ASAs). ASAs.  They run logically above the AN Infrastructure,
   ANI and may use the adjacency table, the ACP, negotiation and
   synchronization through GRASP in the ACP, Intent Intent, and other functions
   of the ANI.  Since the ANI only provides autonomic interactions
   within a domain, autonomic functions can also use any other context
   on a node, specifically the global data plane.

3.3.  State Machine

   Autonomic Networking applies during the full life-cycle life cycle of a node.
   This section describes a state machine of an autonomic node, node
   throughout its life.

   A device is normally expected to store its domain specific domain-specific identity,
   the LDevID Local Device Identifier (LDevID) (see Section 5.2), in persistent storage,
   storage to be available after a powercycle power-cycle event.  For device types
   that cannot store the LDevID in persistent storage, a powercycle power-cycle
   event is effectively equivalent to a factory reset.

3.3.1.  State 1: Factory Default

   An autonomic node leaves the factory in this state.  In this state,
   the node has no domain specific domain-specific configuration, specifically no
   LDevID, and could be used in any particular target network.  It does
   however does,
   however, have a vendor/manufacturer specific vendor/manufacturer-specific ID, the IDevID Initial Device
   Identifier (IDevID) [IDevID].  Nodes without IDevID cannot be
   autonomically and securely enrolled into a domain; they require
   manual pre-staging, in which case the pre-staging takes them directly
   to state 2.

   Transitions:

   o

   *  Bootstrap event: The device enrols enrolls into a domain; as part of this
      process it receives a domain identity (LDevID).  If enrollment is
      successful, the next state is state 2.  See
      [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 [RFC8995] for details
      on enrollment.

   o  Powercycle

   *  Power-cycle event: The device loses all state tables.  It remains
      in state: state 1.

3.3.2.  State 2: Enrolled

   An autonomic node is in the state "enrolled" state if it has a domain
   identity (LDevID), (LDevID) and has currently no ACP channel up.  It may have
   further configuration or state, for example example, if it had been in state
   3
   before, before but lost all its ACP channels.  The LDevID can only be
   removed from a device through a factory reset, which also removes all
   other state from the device.  This ensures that a device has no stale
   domain specific
   domain-specific state when entering the "enrolled" state from state
   1.

   Transitions:

   o

   *  Joining ACP: The device establishes an ACP channel to an adjacent
      device.  See [I-D.ietf-anima-autonomic-control-plane] [RFC8994] for details.  Next state: 3.

   o

   *  Factory reset: A factory reset removes all configuration and the
      domain identity (LDevID) from the device.  Next state: 1.

   o  Powercycle

   *  Power-cycle event: The device loses all state tables, but not its
      domain identity (LDevID). it  It remains in state: state 2.

3.3.3.  State 3: In ACP

   In this state, the autonomic node has at least one ACP channel to
   another device.  The node can now participate in further autonomic
   transactions, such as starting autonomic service agents ASAs (e.g., it must now enable the
   join assistant proxy ASA, to help other devices to join the domain. domain).  Other
   conditions may apply to such interactions, for
   example example, to serve as a
   join assistant, proxy, the device must first discover a bootstrap Registrar. registrar.

   Transitions:

   o

   *  Leaving ACP: The device drops the last (or only) ACP channel to an
      adjacent device.  Next state: 2.

   o

   *  Factory reset: A factory reset removes all configuration and the
      domain identity (LDevID) from the device.  Next state: 1.

   o  Powercycle

   *  Power-cycle event: The device loses all state tables, tables but not its
      domain identity (LDevID).  Next state: 2.

4.  The  Autonomic Networking Infrastructure

   The Autonomic Networking Infrastructure ANI provides a layer of common functionality across an Autonomic
   Network.  It provides the elementary functions and services, as well
   as extensions.  An
   Autonomic Function, autonomic function, comprising of Autonomic Service Agents ASAs on nodes,
   uses the functions described in this section.

4.1.  Naming

   Inside a domain, each autonomic device should be assigned a unique
   name.  The naming scheme should be consistent within a domain.  Names
   are typically assigned by a Registrar registrar at bootstrap time and are
   persistent over the lifetime of the device.  All Registrars registrars in a
   domain must follow the same naming scheme.

   In the absence of a domain specific domain-specific naming scheme, a default naming
   scheme should use the same logic as the addressing scheme discussed
   in [I-D.ietf-anima-autonomic-control-plane]. [RFC8994].  The device name is then composed of a Registrar ID Registrar-ID
   (for example example, taking a MAC Media Access Control (MAC) address of the
   Registrar)
   registrar) and a device number.  An example name would then look like
   this:

   0123-4567-89ab-0001

   The first three fields are the MAC address, and the fourth field is
   the sequential number for the device.

4.2.  Addressing

   Autonomic Service Agents (ASAs)

   ASAs need to communicate with each other, using the autonomic
   addressing of the Autonomic Networking
   Infrastructure ANI of the node they reside on.  This section
   describes the addressing approach of the Autonomic Networking Infrastructure, ANI used by ASAs.

   Addressing approaches for the data plane of the network are outside
   the scope of this document.  These addressing approaches may be
   configured and managed in the traditional way, way or negotiated as a
   service of an ASA.  One use case for such an autonomic function is
   described in [I-D.ietf-anima-prefix-management]. [RFC8992].

   Autonomic addressing is a function of the Autonomic Networking
   Infrastructure ANI (lower part of
   Figure 2), specifically the Autonomic
   Control Plane. ACP.  ASAs do not have their own
   addresses.  They may use either API calls, calls or the autonomic addressing
   scheme of the Autonomic
   Networking Infrastructure. ANI.

   An autonomic addressing scheme has the following requirements:

   o

   *  Zero-touch for simple networks: Simple networks should have
      complete self-management of addressing, addressing and not require any central
      address management, tools, or address planning.

   o

   *  Low-touch for complex networks: If complex networks require
      operator input for autonomic address management, it should be
      limited to high level high-level guidance only, expressed in Intent.

   o

   *  Flexibility: The addressing scheme must be flexible enough for
      nodes to be able to move around, around and for the network to grow, split
      split, and merge.

   o

   *  Robustness: It should be as hard as possible for an administrator
      to negatively affect addressing (and thus connectivity) in the
      autonomic context.

   o

   *  Stability: The addressing scheme should be as stable as possible.
      However, implementations need to be able to recover from
      unexpected address changes.

   o

   *  Support for virtualization: Autonomic functions can exist either
      at the level of the physical network and physical devices, devices or at
      the level of virtual machines, containers containers, and networks.  In
      particular, Autonomic Nodes autonomic nodes may support Autonomic Service Agents ASAs in virtual entities.
      The infrastructure, including the addressing scheme, should be
      able to support this architecture.

   o

   *  Simplicity: To The addressing scheme should be simple to make
      engineering simpler, easier and to give the human administrator an easy way
      to trouble-shoot troubleshoot autonomic functions.

   o

   *  Scale: The proposed scheme should work in any network of any size.

   o

   *  Upgradability: The scheme must be able to support different
      addressing concepts in the future.

   The proposed addressing scheme is described in the document "An
   Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). Plane (ACP)" [RFC8994].

4.3.  Discovery

   Traditionally, most of the information a node requires is provided
   through configuration or northbound interfaces.  An autonomic
   function should rely on such northbound interfaces minimally or not
   at all, and therefore all; therefore, it needs to discover peers and other resources in
   the network.  This section describes various discovery functions in
   an autonomic network.

   Discovering Autonomic Network.

   First, discovering nodes and their properties and capabilities: A capabilities is a
   core function to establish an autonomic domain is the mutual
   discovery of autonomic nodes, primarily adjacent nodes and
   secondarily off-link peers.  This may may, in principle principle, either leverage
   existing discovery
   mechanisms, mechanisms or use new mechanisms tailored to the
   autonomic context.  An important point is that discovery must work in
   a network with no predefined topology, ideally no manual
   configuration of any kind, and with nodes starting up from factory
   condition or after any form of failure or sudden topology change.

   Discovering services: Network

   Second, network services such as AAA Authentication, Authorization, and
   Accounting (AAA) should also be discovered and not configured.
   Service discovery is required for such tasks.  An autonomic network Autonomic Network
   can either leverage existing service discovery functions, or use a new
   approach, or use a mixture.

   Thus

   Thus, the discovery mechanism could either be fully integrated with
   autonomic signaling (next section) or could use an independent discovery
   mechanism such as DNS DNS-based Service Discovery or the Service Location
   Protocol.  This choice could be made independently for each Autonomic
   Service Agent, ASA,
   although the infrastructure might require some minimal lowest common
   denominator (e.g., for discovering the security bootstrap mechanism, mechanism
   or the source of information distribution,
   Section 4.7). distribution (Section 4.7)).

   Phase 1 of Autonomic Networking uses GRASP [RFC8990] for discovery, described
   in [I-D.ietf-anima-grasp]. discovery.

4.4.  Signaling Between between Autonomic Nodes

   Autonomic nodes must communicate with each other, for example example, to
   negotiate and/or synchronize technical objectives (i.e., network
   parameters) of any kind and complexity.  This requires some form of
   signaling between autonomic nodes.  Autonomic nodes implementing a
   specific use case might choose their own signaling protocol, as long
   as it fits the overall security model.  However, in the general case,
   any pair of autonomic nodes might need to communicate, so there needs
   to be a generic protocol for this.  A prerequisite for this is that
   autonomic nodes can discover each other without any preconfiguration,
   as mentioned above.  To be generic, discovery and signaling must be
   able to handle any sort of technical objective, including ones that
   require complex data structures.  The document "A Generic "GeneRic Autonomic
   Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] [RFC8990] describes more detailed
   requirements for discovery, negotiation negotiation, and synchronization in an autonomic network.
   Autonomic Network.  It also defines a protocol, called GRASP, for
   this
   purpose, including purpose; GRASP includes an integrated but optional discovery protocol.
   process.

   GRASP is normally expected to run inside the Autonomic Control Plane
   (ACP; see ACP (see Section 4.6)
   and to depend on the ACP for security.  It may run insecurely for a
   short time during bootstrapping.

   An autonomic node will normally run a single instance of GRASP, used
   by multiple ASAs.  However, scenarios where multiple instances of
   GRASP run in a single node, perhaps with different security
   properties, are not excluded.

4.5.  Routing

   All autonomic nodes in a domain must be able to communicate with each
   other, and in later phases phases, they must also be able to communicate
   with autonomic nodes outside their own domain.  Therefore, an Autonomic Control Plane ACP
   relies on a routing function.  For Autonomic Networks to be
   interoperable, they must all support one common routing protocol.

   The routing protocol is defined in the ACP document
   [I-D.ietf-anima-autonomic-control-plane]. [RFC8994].

4.6.  The  Autonomic Control Plane

   The "Autonomic Control Plane" ACP carries the control protocols in an
   autonomic network. Autonomic Network.  In
   the architecture described here, in this document, it is implemented as an
   overlay network.  The document "An Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) Plane (ACP)"
   [RFC8994] describes the implementation details suggested here. in this
   document.  This document uses the term "overlay" to mean a set of
   point-to-point adjacencies congruent with the underlying
   interconnection topology.  The terminology may not be aligned with a
   common usage of the "overlay" term "overlay" in the routing context.  See [I-D.ietf-anima-stable-connectivity]
   [RFC8368] for uses cases for the ACP.

4.7.  Information Distribution (*)

   Certain forms of information require distribution across an autonomic
   domain.  The distribution of information runs inside the Autonomic
   Control Plane. ACP.  For
   example, Intent is distributed across an autonomic domain, as
   explained in [RFC7575].

   Intent is the policy language of an Autonomic Network, see Network (see also
   Section 7.2. 7.2).  It is a high level policy, high-level policy and should change only
   infrequently (order of days).  Therefore, information such as Intent
   should be simply flooded to all nodes in an autonomic domain, and
   there is currently no perceived need to have more targeted
   distribution methods.  Intent is also expected to be monolithic, monolithic and
   flooded as a whole.  One possible method for distributing Intent, as
   well as other forms of data, is discussed in
   [I-D.liu-anima-grasp-distribution]. [GRASP-DISTRIB].  Intent
   and information distribution are not part of phase 1 of ANIMA. the ANIMA Working Group
   charter.

5.  Security and Trust Infrastructure

   An Autonomic Network is self-protecting.  All protocols are secure by
   default, without the requirement for the administrator to explicitly
   configure security, with the exception of setting up a PKI
   infrastructure.

   Autonomic nodes have direct interactions between themselves, which
   must be secured.  Since an autonomic network Autonomic Network does not rely on
   configuration, it is not an option to configure, for example, pre-
   shared keys.  A trust infrastructure such as a PKI infrastructure
   must be in place.  This section describes the principles of this
   trust infrastructure.  In this first phase of autonomic networking, Autonomic Networking, a
   device is either 1) within the trust domain and fully trusted, trusted or 2)
   outside the trust domain and fully untrusted.

   The default method to automatically bring up a trust infrastructure
   is defined in the document "Bootstrapping Remote Secure Key Infrastructures"
   [I-D.ietf-anima-bootstrapping-keyinfra].
   Infrastructure (BRSKI)" [RFC8995].  The ASAs required for this
   enrollment process are described in Section 6.3.  An autonomic node
   must implement the enrollment and join assistant proxy ASAs.  The registrar ASA
   may be implemented only on a sub-set subset of nodes.

5.1.  Public Key Infrastructure

   An autonomic domain uses a PKI model.  The root of trust is a
   certification authority
   Certification Authority (CA).  A registrar acts as a registration
   authority Registration
   Authority (RA).

   A minimum implementation of an autonomic domain contains one CA, one
   Registrar,
   registrar, and network elements.

5.2.  Domain Certificate

   Each device in an autonomic domain uses a domain certificate (LDevID)
   to prove its identity.  A new device uses its manufacturer provided manufacturer-provided
   certificate (IDevID) during bootstrap, bootstrap to obtain a domain certificate.  [I-D.ietf-anima-bootstrapping-keyinfra]
   [RFC8995] describes how a new device receives a domain certificate, certificate
   and defines the certificate format.

5.3.  The  MASA

   The Manufacturer Authorized Signing Authority (MASA) is a trusted
   service for bootstrapping devices.  The purpose of the MASA is to
   provide ownership tracking of devices in a domain.  The MASA provides
   audit, authorization, and ownership tokens to the registrar during
   the bootstrap process to assist in the authentication of devices
   attempting to join an Autonomic Domain, autonomic domain and to allow a joining device
   to validate whether it is joining the correct domain.  The details
   for MASA service, security, and usage are defined in
   [I-D.ietf-anima-bootstrapping-keyinfra]. [RFC8995].

5.4.  Sub-Domains  Subdomains (*)

   By default, sub-domains subdomains are treated as different domains.  This
   implies no trust between a domain and its sub-domains, subdomains and no trust
   between sub-domains subdomains of the same domain.  Specifically, no ACP is
   built, and Intent is valid only for the domain it is defined for
   explicitly.

   In phase 2 of ANIMA, the ANIMA Working Group charter, alternative trust models should
   be defined, for
   example example, to allow full or limited trust between
   domain and sub-domain. subdomain.

5.5.  Cross-Domain Functionality (*)

   By default, different domains do not interoperate, no ACP is built built,
   and no trust is implied between them.

   In the future, models can be established where other domains can be
   trusted in full or for limited operations between the domains.

6.  Autonomic Service Agents (ASA) (ASAs)

   This section describes how autonomic services run on top of the
   Autonomic Networking Infrastructure. ANI.

6.1.  General Description of an ASA

   An Autonomic Service Agent (ASA) ASA is defined in [RFC7575] as "An agent implemented on an
   autonomic node that implements an autonomic function, either in part
   (in the case of a distributed function) or
   whole."  Thus whole".  Thus, it is a
   process that makes use of the features provided by the ANI to achieve
   its own goals, usually including interaction with other ASAs via the
   GRASP protocol [I-D.ietf-anima-grasp] [RFC8990] or otherwise.  Of course course, it also interacts with the
   specific targets of its function, using any suitable mechanism.
   Unless its function is very simple, the ASA will need to handle
   overlapping asynchronous operations.  It may therefore be a quite
   complex piece of software in its own right, forming part of the
   application layer above the ANI.  ASA design guidelines are available
   in
   [I-D.carpenter-anima-asa-guidelines].

   Thus [ASA-GUIDELINES].

   Thus, we can distinguish at least three classes of ASAs:

   o

   *  Simple ASAs with a small footprint that could run anywhere.

   o

   *  Complex, possibly multi-threaded ASAs that have a significant
      resource requirement and will only run on selected nodes.

   o

   *  A few 'infrastructure ASAs' that use basic ANI features in support
      of the ANI itself, which must run in all autonomic nodes.  These
      are outlined in the following sections.

   Autonomic nodes, and therefore their ASAs, know their own
   capabilities and restrictions, derived from hardware, firmware firmware, or
   pre-installed software: They software; they are "self-aware".

   The role of an autonomic node depends on Intent and on the
   surrounding network behaviors, which may include forwarding
   behaviors, aggregation properties, topology location, bandwidth,
   tunnel or translation properties, etc.  For example, a node may
   decide to act as a backup node for a neighbor, if its capabilities
   allow it to do so.

   Following an initial discovery phase, the node node's properties and those
   of its neighbors are the foundation of the behavior of a specific
   node.  A node and its ASAs have no pre-configuration for the
   particular network in which they are installed.

   Since all ASAs will interact with the ANI, they will depend on
   appropriate application programming interfaces (APIs).  It is
   desirable that ASAs are portable between operating systems, so these
   APIs need to be universal.  An API for GRASP is described in
   [I-D.ietf-anima-grasp-api].
   [RFC8991].

   ASAs will will, in general general, be designed and coded by experts in a
   particular technology and use case, not by experts in the ANI and its
   components.  Also, they may be coded in a variety of programming
   languages, in particular including particular, languages that support object constructs as
   well as traditional variables and structures.  The APIs should be
   designed with these factors in mind.

   It must be possible to run ASAs as non-privileged (user space)
   processes except for those (such as the infrastructure ASAs) that
   necessarily require kernel privilege.  Also, it is highly desirable
   that ASAs can be dynamically loaded on a running node.

   Since autonomic systems must be self-repairing, it is of great
   importance that ASAs are coded using robust programming techniques.
   All run-time runtime error conditions must be caught, leading to suitable
   minimally disruptive recovery actions, also considering but a complete restart of the ASA.
   ASA must also be considered.  Conditions such as discovery failures
   or negotiation failures must be treated as routine, with the ASA
   retrying the failed operation, preferably with an exponential back-
   off in the case of persistent errors.  When multiple threads are
   started within an ASA, these threads must be monitored for failures
   and hangups, and appropriate action taken.  Attention must be given
   to garbage collection, so that ASAs never run out of resources.
   There is assumed to be no human operator - operator; again, in the worst case,
   every ASA must be capable of restarting itself.

   ASAs will automatically benefit from the security provided by the
   ANI, and specifically by the ACP and by GRASP.  However, beyond that,
   they are responsible for their own security, especially when
   communicating with the specific targets of their function.
   Therefore, the design of an ASA must include a security analysis
   beyond 'use ANI security.' security'.

6.2.  ASA Life-Cycle Management

   ASAs operating on a given ANI may come from different providers and
   pursue different objectives.  Management of ASAs and its their
   interactions with the ANI should follow the same operating principles, hence principles
   and thus comply to a generic life-cycle management model.

   The ASA life-cycle life cycle provides standard processes to:

   o

   *  install ASA: copy the ASA code onto the node and start it,

   o it.

   *  deploy ASA: associate the ASA instance with a (some) managed
      network device(s) (or network function),

   o function).

   *  control ASA execution: when and how an ASA executes its control
      loop.

   The life-cyle will cover the sequential states below: Installation,
   Deployment, Operation and the transitional states in-between.

   This
   Life-Cycle life cycle will also define which interactions ASAs have with
   the ANI in between the different states.  The noticeable interactions
   are:

   o

   *  Self-description of ASA instances at the end of deployment: its Its
      format needs to define the information required for the management
      of ASAs by ANI entities

   o entities.

   *  Control of the ASA control-loop control loop during the operation: a signaling Signaling
      has to carry formatted messages to control ASA execution (at least
      starting and stopping the control loop) loop).

6.3.  Specific ASAs for the Autonomic Network Networking Infrastructure

   The following functions provide essential, required functionality in
   an autonomic network, Autonomic Network and are therefore mandatory to implement on
   unconstrained autonomic nodes.  They are described here as ASAs that
   include the underlying infrastructure components, but implementation
   details might vary.

   The first three together (pledge, join proxy, join registrar) support together
   the trust enrollment process described in Section 5.  For details see
   [I-D.ietf-anima-bootstrapping-keyinfra].
   [RFC8995].

6.3.1.  The enrollment  Enrollment ASAs

6.3.1.1.  The Pledge ASA

   This ASA includes the function of an autonomic node that bootstraps
   into the domain with the help of an a join assitant proxy ASA (see below).  Such
   a node is known as a Pledge pledge during the enrollment process.  This ASA
   must be installed by default on all nodes that require an autonomic
   zero-touch bootstrap.

6.3.1.2.  The Join Assistant Proxy ASA

   This ASA includes the function of an autonomic node that helps a non-
   enrolled, adjacent devices to enroll into the domain.  This ASA must
   be installed on all nodes, although only one join assistant proxy needs to be
   active on a given LAN.  See also
   [I-D.ietf-anima-bootstrapping-keyinfra]. [RFC8995].

6.3.1.3.  The Join Registrar ASA

   This ASA includes the join registrar Join Registrar function in an autonomic
   network. Autonomic
   Network.  This ASA does not need to be installed on all nodes, but
   only on nodes that implement the Join Registrar function.

6.3.2.  The  ACP ASA

   This ASA includes the ACP function in an autonomic network. Autonomic Network.  In
   particular
   particular, it acts to discover other potential ACP nodes, nodes and to
   support the establishment and teardown of ACP channels.  This ASA
   must be installed on all nodes.  For details details, see Section 4.6 and
   [I-D.ietf-anima-autonomic-control-plane].
   [RFC8994].

6.3.3.  The  Information Distribution ASA (*)

   This ASA is currently out of scope in ANIMA, the ANIMA Working Group charter
   and is provided here only as background information.

   This ASA includes the information distribution function in an
   autonomic network.
   Autonomic Network.  In particular particular, it acts to announce the
   availability of Intent and other information to all other autonomic
   nodes.  This ASA does not need to be installed on all nodes, but only
   on nodes that implement the information distribution function.  For
   details
   details, see Section 4.7.

   Note that information distribution can be implemented as a function
   in any ASA.  See [I-D.liu-anima-grasp-distribution] [GRASP-DISTRIB] for more details on how information
   is suggested to be distributed.

7.  Management and Programmability

   This section describes how an Autonomic Network is managed, managed and
   programmed.

7.1.  Managing a (Partially) Autonomic Network

   Autonomic management usually co-exists coexists with traditional management
   methods in most networks.  Thus, autonomic behavior will be defined
   for individual functions in most environments.  Examples for of overlap
   are:

   o

   *  Autonomic functions can use traditional methods and protocols
      (e.g., SNMP and NETCONF) the Network Configuration Protocol (NETCONF)) to
      perform management tasks, inside and outside the ACP;

   o ACP.

   *  Autonomic functions can conflict with behavior enforced by the
      same traditional methods and protocols;

   o protocols.

   *  Traditional functions can use the ACP, for example example, if
      reachability on the data plane is not (yet) established.

   The autonomic Intent is defined at a high level of abstraction.
   However, since it is necessary to address individual managed
   elements, autonomic management needs to communicate in lower-level
   interactions (e.g., commands and requests).  For example, it is
   expected that the configuration of such elements be performed using
   NETCONF and YANG modules as well as the monitoring be executed
   through SNMP and MIBs.

   Conflict can occur between autonomic default behavior, autonomic
   Intent, and traditional management methods.  Conflict resolution is
   achieved in autonomic management through prioritization [RFC7575].
   The rationale is that manual and node-based management have a higher
   priority over than autonomic management.  Thus, the autonomic default
   behavior has the lowest priority, then comes the autonomic Intent
   (medium priority), and, finally, the highest priority is taken by
   node-specific network management methods, such as the use of command command-
   line interfaces.

7.2.  Intent (*)

   Intent is not covered in the current implementation specifications.
   This section discusses a topic for further research.

   This section gives an overview of Intent, Intent and how it is managed.
   Intent and Policy-Based Network Management (PBNM) is already
   described inside the IETF (e.g., PCIM) Policy Core Information Model
   (PCIM)) and in other SDOs Standards Development Organizations (SDOs)
   (e.g., DMTF
   and TMF ZOOM). the Distributed Management Task Force (DMTF)).

   Intent can be described 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 high-level guidance
   only, thus
   only; thus, it does not directly define a policy for every network
   element separately.

   Intent can be refined to lower level lower-level policies using different
   approaches.  This is expected in order to adapt the Intent to the
   capabilities of managed devices.  Intent may contain role or function
   information, which can be translated to specific nodes [RFC7575].
   One of the possible refinements of the Intent is using Event-
   Condition-Action (ECA) rules.

   Different parameters may be configured for Intent.  These parameters
   are usually provided by the human operator.  Some of these parameters
   can influence the behavior of specific autonomic functions as well as
   the way the Intent is used to manage the autonomic domain.

   Intent is discussed in more detail in [I-D.du-anima-an-intent]. [ANIMA-INTENT].  Intent as well
   as other types of information are distributed via
   GRASP, GRASP; see [I-D.liu-anima-grasp-distribution].
   [GRASP-DISTRIB].

7.3.  Aggregated Reporting (*)

   Aggregated reporting is not covered in the current implementation
   specifications.  This section discusses a topic for further research.

   An Autonomic Network should minimize the need for human intervention.
   In terms of how the network should behave, this is done through an
   autonomic Intent provided by the human administrator.  In an
   analogous manner, the reports which that describe the operational status of
   the network should aggregate the information produced in different
   network elements in order to present the effectiveness of autonomic
   Intent enforcement.  Therefore, reporting in an autonomic network Autonomic Network
   should happen on a network-wide basis [RFC7575].

   Multiple simultaneous events can occur in an autonomic network Autonomic Network in the
   same way they can happen in a traditional network.  However, when
   reporting to a human administrator, such events should be aggregated
   to avoid notifications about individual managed elements.  In this
   context, algorithms may be used to determine what should be reported
   (e.g., filtering) and in which way filtering), how it should be reported, and how different
   events are related to each other.  Besides that, an event in an
   individual element can be compensated by changes in other elements to
   maintain a network-wide target which that is described in the autonomic
   Intent.

   Reporting in an autonomic network Autonomic Network may be at the same abstraction
   level as Intent.  In this context, the aggregated view of the current
   operational status of an autonomic network Autonomic Network can be used to switch to
   different management modes.  Despite the fact that autonomic
   management should minimize the need for user intervention, possibly
   there are some
   events that may need to be addressed by the actions of a human
   administrator actions.
   administrator.

7.4.  Feedback Loops to NOC (*)

   Feedback loops are required in an autonomic network Autonomic Network to allow the
   intervention of a human administrator or central control systems, systems
   while maintaining a default behaviour. behavior.  Through a feedback loop loop, an
   administrator must be prompted with a default action, action and has the
   possibility to acknowledge or override the proposed default action.

   Uni-directional

   Unidirectional notifications to the NOC, Network Operations Center (NOC)
   that do not propose any default action, action and do not allow an override
   as part of the transaction are considered like traditional
   notification services, such as syslog.  They are expected to co-exist coexist
   with autonomic
   methods, methods but are not covered in this draft. document.

7.5.  Control Loops (*)

   Control loops are not covered in the current implementation
   specifications.  This section discusses a topic for further research.

   Control loops are used in autonomic networking Autonomic Networking to provide a generic
   mechanism to enable the Autonomic System autonomic system to adapt (on its own) to
   various factors that can change the goals that the autonomic network Autonomic Network
   is trying to achieve, achieve or how those goals are achieved.  For example,
   as user needs, business goals, and the ANI itself changes, self-
   adaptation enables the ANI to change the services and resources it
   makes available to adapt to these changes.

   Control loops operate to continuously observe and collect data that
   enables the autonomic management system to understand changes to the
   behavior of the system being managed, managed and then provide actions to move
   the state of the system being managed toward a common goal.
   Self-adaptive  Self-
   adaptive systems move decision-making decision making from static, pre-defined
   commands to dynamic processes computed at runtime.

   Most autonomic systems use a closed control loop with feedback.  Such
   control loops should be able to be dynamically changed at runtime to
   adapt to changing user needs, business goals, and changes in the ANI.

7.6.  APIs (*)

   APIs

   [RFC8991] defines a conceptual outline for an API for the GeneRic
   Autonomic Signaling Protocol (GRASP).  This conceptual API is
   designed for ASAs to communicate with other ASAs through GRASP.  Full
   Standards Track API specifications are not covered in the current
   implementation specifications.
   This section discusses a topic for further research.

   Most APIs are static, meaning that they are pre-defined and represent
   an invariant mechanism for operating with data.  An Autonomic Network
   should be able to use dynamic APIs in addition to static APIs.

   A dynamic API is one that retrieves data using a generic mechanism, mechanism and then
   enables the client to navigate the retrieved data and operate on it.
   Such APIs typically use introspection and/or reflection.
   Introspection enables software to examine the type and properties of
   an object at runtime, while reflection enables a program to
   manipulate the attributes, methods, and/or metadata of an object.

   APIs must be able to express and preserve the semantics of data
   models.  For example, software contracts [Meyer97] are based on the
   principle that a software-intensive system, such as an Autonomic
   Network, is a set of communicating components whose interaction is
   based on precisely-defined precisely defined specifications of the mutual obligations
   that interacting components must respect.  This typically includes
   specifying:

   o

   *  pre-conditions that must be satisfied before the method can start
      execution

   o

   *  post-conditions that must be satisfied when the method has
      finished execution

   o

   *  invariant attributes that must not change during the execution of
      the method

7.7.  Data Model (*)

   Data models are not covered in the current implementation
   specifications.  This section discusses a topic for further research.

   The following definitions of "data model" and "information model" are
   adapted from
   [I-D.ietf-supa-generic-policy-data-model]: [SUPA-DATA].

   An information model is a representation of concepts of interest to
   an environment in a form that is independent of data repository, data
   definition language, query language, implementation language, and
   protocol.  In contrast, a data model is a representation of concepts
   of interest to an environment in a form that is dependent on data
   repository, data definition language, query language, implementation
   language, and protocol (typically, but not necessarily, all three). protocol.

   The utility of an information model is to define objects and their
   relationships in a technology-neutral manner.  This forms a
   consensual vocabulary that the ANI and ASAs can use.  A data model is
   then a technology-specific mapping of all or part of the information
   model to be used by all or part of the system.

   A system may have multiple data models.  Operational Support Systems,
   for example, typically have multiple types of repositories, such as
   SQL and NoSQL, to take advantage of the different properties of each.
   If multiple data models are required by an Autonomic System, autonomic system, then an
   information model should be used to ensure that the concepts of each
   data model can be related to each other without technological bias.

   A data model is essential for certain types of functions, such as a
   Model-Reference Adaptive Control Loop (MRACL).  More generally, a
   data model can be used to define the objects, attributes, methods,
   and relationships of a software system (e.g., the ANI, an autonomic
   node, or an ASA).  A data model can be used to help design an API, as
   well as any language used to interface to the Autonomic Network.

8.  Coordination Between between Autonomic Functions (*)

   Coordination between autonomic functions is not covered in the
   current implementation specifications.  This section discusses a
   topic for further research.

8.1.  The  Coordination Problem (*)

   Different autonomic functions may conflict in setting certain
   parameters.  For example, an energy efficiency function may want to
   shut down a redundant link, while a load balancing load-balancing function would not
   want that to happen.  The administrator must be able to understand
   and resolve such interactions, interactions to steer autonomic network Autonomic Network performance
   to a given (intended) operational point.

   Several interaction types may exist among autonomic functions, for
   example:

   o

   *  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.

   o

   *  Dependency: An autonomic function cannot work without another one
      being present or accessible in the autonomic network.

   o Autonomic Network.

   *  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.

   Solving the coordination problem beyond one-by-one cases can rapidly
   become intractable for large networks.  Specifying a common
   functional block on coordination is a first step to address the
   problem in a systemic way.  The coordination life-cycle life cycle consists in of
   three states:

   o

   *  At build-time, a "static interaction map" can be constructed on
      the relationship of functions and attributes.  This map can be
      used to (pre-)define policies and priorities on for identified
      conflicts.

   o

   *  At deploy-time, autonomic functions are not yet active/acting on
      the network.  A "dynamic interaction map" is created for each
      instance of each autonomic functions and function on a per resource per-resource basis,
      including the actions performed and their relationships.  This map
      provides the basis to identify conflicts that will happen at run-
      time,
      runtime, categorize them them, and plan for the appropriate
      coordination
      strategies/mechanisms.

   o strategies and mechanisms.

   *  At run-time, runtime, when conflicts happen, arbitration is driven by the
      coordination strategies.  Also  Also, new dependencies can be observed
      and inferred, resulting in an update of the dynamic interaction
      map and adaptation of the coordination strategies and mechanisms.

   Multiple coordination strategies and mechanisms exist and can be
   devised.  The set ranges from basic approaches such (such as random
   process or token-based process, process), to approaches based on time
   separation and hierarchical optimization, to more complex approaches such
   (such as multi-
   objective optimization, multi-objective optimization and other control theory
   approaches and
   algorithms family. algorithm families).

8.2.  A  Coordination Functional Block (*)

   A common coordination functional block is a desirable component of
   the ANIMA reference model.  It provides a means to ensure network
   properties and predictable performance or behavior behavior, such as stability, stability
   and convergence, in the presence of several interacting autonomic
   functions.

   A common coordination function requires:

   o

   *  A common description of autonomic functions, their attributes attributes, and
      life-cycle.

   o
      life cycle.

   *  A common representation of information and knowledge (e.g.,
      interaction maps).

   o

   *  A common "control/command" interface between the coordination
      "agent" and the autonomic functions.

   Guidelines, recommendations recommendations, or BCPs can also be provided for aspects
   pertaining to the coordination strategies and mechanisms.

9.  Security Considerations

   In this section section, we distinguish outsider and insider attacks.  In an
   outsider attack attack, all network elements and protocols are securely
   managed and operating, and an outside attacker can sniff packets in
   transit, inject inject, and replay packets.  In an insider attack, the
   attacker has access to an autonomic node or other means (e.g. (e.g., remote
   code execution in the node by exploiting ACP-independent
   vulnerabilities in the node platform) to produce arbitrary payloads
   on the protected ACP channels.

   If a system has vulnerabilities in the implementation or operation
   (configuration), an outside attacker can exploit such vulnerabilies vulnerabilities
   to become an insider attacker.

9.1.  Protection Against against Outsider Attacks

   Here, we assume that all systems involved in an autonomic network Autonomic Network are
   secured and operated according to best current practices.  These
   protection methods comprise traditional security implementation and
   operation methods (such as code security, strong randomization
   algorithms, strong passwords, etc.) as well as mechanisms specific to
   an autonomic network Autonomic Network (such as a secured MASA service).

   Traditional security methods for both implementation and operation
   are outside the scope for of this document.

   AN specific

   AN-specific protocols and methods must also follow traditional
   security methods, in that all packets that can be sniffed or injected
   by an outside attacker are:

   o

   *  protected against modification.

   o  authenticated.

   o modification

   *  authenticated

   *  protected against replay attacks.

   o attacks

   *  confidentiality protected (encrypted).

   o  and that (encrypted)

   In addition, the AN protocols are should be robust against packet drops
   and man-
      in-the-middle man-in-the-middle attacks.

   How these requirements are met is covered in the AN standards track Standards Track
   documents that define the methods used, specifically
   [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], [RFC8990],
   [RFC8994], and
   [I-D.ietf-anima-autonomic-control-plane]. [RFC8995].

   Most AN messages run inside the cryptographically protected ACP.  The
   unprotected AN messages outside the ACP are limited to a simple
   discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]:
   The "Discovery [RFC8990]: the
   Discovery Unsolicited Link-Local (DULL)" (DULL) message, with detailed rules
   on its usage.

   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.

9.2.  Risk of Insider Attacks

   An autonomic network Autonomic Network consists of autonomic devices that form a
   distributed self-managing system.  Devices within a domain have
   credentials issued from a common trust anchor and can use them to
   create mutual trust.  This means that any device inside a trust
   domain can by default use all distributed functions in the entire
   autonomic domain in a malicious way.

   If an autonomic node

   An inside attacker, or an outsider in the presence of protocol has
   vulnerabilities or is not
   securely operated, an outside attacker insecure operation, has the following generic ways
   to take control of an autonomic network:

   o Autonomic Network:

   *  Introducing a fake device into the trust domain, domain by subverting the
      authentication methods.  This depends on the correct
      specification, implementation implementation, and operation of the AN protocols.

   o

   *  Subverting a device which that is already part of a trust domain, domain and
      modifying its behavior.  This threat is not specific to the
      solution discussed in this document, document and applies to all network
      solutions.

   o

   *  Exploiting potentially yet unknown protocol vulnerabilities in the
      AN or other protocols.  Also this  This is also a generic threat that applies
      to all network solutions.

   The above threats are are, in principle principle, comparable to other solutions: In
   in the presence of design, implementation implementation, or operational errors,
   security is no longer guaranteed.  However, the distributed nature of
   AN, specifically the Autonomic Control Plane, ACP, increases the threat surface significantly.
   For example, a compromised device may have full IP reachability to
   all other devices inside the ACP, ACP and can use all AN methods and
   protocols.

   For the next phase of the ANIMA work Working Group, it is therefore
   recommended to introduce a sub-domain subdomain security model, model to reduce the
   attack surface and not expose a full domain to a potential intruder.
   Furthermore, additional security mechanisms on the ASA level should
   be considered for high-risk autonomic functions.

10.  IANA Considerations

   This document requests has no action by IANA. IANA actions.

11.  Acknowledgements

   Many people have provided feedback and input to this document: Sheng
   Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur
   Hecker.  Useful reviews were made by Joel Halpern, Radia Perlman,
   Tianran Zhou and Christian Hopps.

12.  Contributors

   Significant contributions to this document have been made by John
   Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia.

13.  References

13.1.

11.1.  Normative References

   [I-D.ietf-anima-autonomic-control-plane]

   [IDevID]   IEEE, "IEEE Standard for Local and metropolitan area
              networks - Secure Device Identity", IEEE 802.1AR,
              <https://1.ieee802.org/security/802-1ar>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control-
              plane-18 (work in progress), August 2018.

   [I-D.ietf-anima-bootstrapping-keyinfra] RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Bjarnason,
              S.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures
              Infrastructure (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-17 (work in progress), November 2018.

   [I-D.ietf-anima-grasp]
              Bormann, C., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-15 (work in progress), July 2017.

   [IDevID]   IEEE Standard, , "IEEE 802.1AR Secure Device Identifier",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

13.2. RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

11.2.  Informative References

   [I-D.carpenter-anima-asa-guidelines]
              Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre,
              "Guidelines for Autonomic Service Agents", draft-
              carpenter-anima-asa-guidelines-05 (work in progress), June
              2018.

   [I-D.du-anima-an-intent]

   [ANIMA-INTENT]
              Du, Z., Jiang, S., Nobre, J., J. C., Ciavaglia, L., and M.
              Behringer, "ANIMA Intent Policy and Format", draft-du-
              anima-an-intent-05 (work Work in progress),
              Progress, Internet-Draft, draft-du-anima-an-intent-05, 14
              February 2017.

   [I-D.ietf-anima-grasp-api] 2017,
              <https://tools.ietf.org/html/draft-du-anima-an-intent-05>.

   [ASA-GUIDELINES]
              Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic
              Autonomic Signaling Protocol Application Program Interface
              (GRASP API)", draft-ietf-anima-grasp-api-02 (work in
              progress), June 2018.

   [I-D.ietf-anima-prefix-management] Ciavaglia, L., Jiang, S., Du, Z., and B. Carpenter, "Autonomic IPv6 Edge
              Prefix Management in Large-scale Networks", draft-ietf-
              anima-prefix-management-07 (work in progress), December
              2017.

   [I-D.ietf-anima-stable-connectivity]
              Eckert, T. and M. Behringer, "Using Autonomic Control
              Plane for Stable Connectivity of Network OAM", draft-ietf-
              anima-stable-connectivity-10 (work in progress), February
              2018.

   [I-D.ietf-supa-generic-policy-data-model]
              Halpern, J. and J. Strassner, "Generic Policy Data Model P. Peloso,
              "Guidelines for Simplified Use of Policy Abstractions (SUPA)", draft-
              ietf-supa-generic-policy-data-model-04 (work Autonomic Service Agents", Work in progress),
              June 2017.

   [I-D.liu-anima-grasp-distribution]
              Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-
              00, 14 November 2020, <https://tools.ietf.org/html/draft-
              ietf-anima-asa-guidelines-00>.

   [GRASP-DISTRIB]
              Liu, B., Jiang, S., Ed., Xiao, X., Ed., Hecker, A., and Z. Jiang, S.,
              Despotovic, Z., and B. Carpenter, "Information
              Distribution over GRASP", Work in Autonomic
              Networking", draft-liu-anima-grasp-distribution-09 (work
              in progress), October 2018. Progress, Internet-
              Draft, draft-ietf-anima-grasp-distribution-02, 8 March
              2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-
              distribution-02>.

   [Meyer97]  Meyer, B., "Object-Oriented Software Construction (2nd
              edition)", Prentice-Hall, Prentice Hall, ISBN 978-0136291558, 1997.

   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015, <https://www.rfc-
              editor.org/info/rfc7575>.
              <https://www.rfc-editor.org/info/rfc7575>.

   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
              Analysis for Autonomic Networking", RFC 7576,
              DOI 10.17487/RFC7576, June 2015, <https://www.rfc-
              editor.org/info/rfc7576>.
              <https://www.rfc-editor.org/info/rfc7576>.

   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
              Control Plane for Stable Connectivity of Network
              Operations, Administration, and Maintenance (OAM)",
              RFC 8368, DOI 10.17487/RFC8368, May 2018,
              <https://www.rfc-editor.org/info/rfc8368>.

   [RFC8991]  Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
              "GeneRic Autonomic Signaling Protocol Application Program
              Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
              May 2021, <https://www.rfc-editor.org/info/rfc8991>.

   [RFC8992]  Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun,
              "Autonomic IPv6 Edge Prefix Management in Large-Scale
              Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021,
              <https://www.rfc-editor.org/info/rfc8992>.

   [SUPA-DATA]
              Halpern, J. and J. Strassner, "Generic Policy Data Model
              for Simplified Use of Policy Abstractions (SUPA)", Work in
              Progress, Internet-Draft, draft-ietf-supa-generic-policy-
              data-model-04, 18 June 2017, <https://tools.ietf.org/html/
              draft-ietf-supa-generic-policy-data-model-04>.

Acknowledgements

   The following people provided feedback and input to this document:
   Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, and
   Artur Hecker.  Useful reviews were made by Joel Halpern, Radia
   Perlman, Tianran Zhou, and Christian Hopps.

Contributors

   Significant contributions to this document were made by John
   Strassner (Huawei), Bing Liu (Huawei), and Pierre Peloso (Nokia).

Authors' Addresses

   Michael H. Behringer (editor)

   Email: Michael.H.Behringer@gmail.com

   Brian Carpenter
   Department
   School of Computer Science
   University of Auckland
   PB 92019
   Auckland 1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

   Toerless Eckert
   Futurewei Technologies Inc. USA
   2330 Central Expy
   Santa Clara Clara, CA 95050
   USA
   United States of America

   Email: tte@cs.fau.de tte+ietf@cs.fau.de

   Laurent Ciavaglia
   Nokia
   Villarceaux
   Nozay
   91460
   FR Nozay
   France

   Email: laurent.ciavaglia@nokia.com

   Jeferson

   Jéferson Campos Nobre
   Federal University of Vale do Rio dos Sinos Grande do Sul (UFRGS)
   Av. Unisinos, 950
   Sao Leopoldo Bento Gonçalves, 9500
   Porto Alegre-RS
   91501-970
   Brazil

   Email: jcnobre@unisinos.br jcnobre@inf.ufrgs.br