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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/