ETSI GS NGP 002 V1.1.1 (2017-05)

Next Generation Protocols (NGP); Self-Organizing Control and Management Planes

DGS/NGP-002

General Information

• Status: Published
• Publication Date: 23-May-2017
• Technical Committee: NGP - Next Generation Protocols
• Current Stage: 12 - Completion
• Due Date: 21-Apr-2017
• Completion Date: 24-May-2017

Standards Content (Sample)

GROUP SPECIFICATION
Next Generation Protocols (NGP);
Self-Organizing Control and Management Planes
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS NGP 002 V1.1.1 (2017-05)

Reference
DGS/NGP-002
Keywords
management plane, next generation protocol,
self-management, self-organizing

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS NGP 002 V1.1.1 (2017-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Overview . 8
5 Background . 9
5.1 Motivation of Self-Management and Control. 9
5.2 Evolution History of Network Control and Management . 9
5.3 Relationship with Existing Work . 10
6 Vision of Self-X Networks . 11
6.1 Overview . 11
6.2 Self Configuration . 11
6.3 Self Service Orchestration . 11
6.4 Self Fault Management . 12
6.5 Self Optimization . 12
6.6 Self Defence . 12
7 Considerations for Realizing Self-X Networks . 12
7.1 Request for New Protocols and Enhanced Infrastructure . 12
7.2 Distributed and Centralized Approaches . 13
7.3 Transition Considerations . 13
7.4 Security Considerations . 13
8 Architecture of Self-X Network . 14
8.1 Architecture Overview . 14
8.2 Self Knowledge on Autonomic Node . 14
8.3 Interaction Functions on Autonomic Node . 14
8.4 Autonomic Service Agents on Autonomic Node . 15
8.5 Network-wide Knowledge. 15
8.6 Interaction with External Input/Intervention . 15
8.7 Negotiation between Autonomic Nodes for Autonomic Decision . 15
8.8 AI Technologies for Autonomic Decision . 16
9 Autonomic Service Agents (ASAs) . 16
9.1 ASAs for Basic Connectivity . 16
9.2 ASAs for Management Infrastructure . 23
9.3 ASAs for Management Functions . 24
9.4 ASAs for Service Provisioning . 27
10 Use Cases of Self-X Network . 28
10.1 IP-based Radio Access Network Self-configuration (IPRANconf) . 28
10.2 Automated Cluster Organization (ACOr) . 30
10.3 Automated Cluster Optimization/re-organization (ACOp) . 30
11 Future Protocol and API Requirements . 31
11.1 Protocol Requirements . 31
11.2 API Requirements . 32
Annex A (informative): Authors & contributors . 33
ETSI
4 ETSI GS NGP 002 V1.1.1 (2017-05)
Annex B (informative): Bibliography . 34
Annex C (informative): Change history . 35
History . 36

ETSI
5 ETSI GS NGP 002 V1.1.1 (2017-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Next Generation
Protocols (NGP).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI GS NGP 002 V1.1.1 (2017-05)
1 Scope
The scope of the present document is to specify the self-organizing control and management planes for the Next
Generation Protocols (NGP), Industry Specific Group (ISG).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF RFC 7575: "Autonomic Networking: Definitions and Design Goals".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS AFI 002 (V1.1.1): "Autonomic network engineering for the self-managing Future
Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for
Autonomic Networking, Cognitive Networking and Self-Management)".
[i.2] IETF draft-ietf-anima-reference-model: "Reference Model for Autonomic Networking",
April 2016.
[i.3] IETF draft-pritikin-anima-bootstrapping-keyinfra: "Bootstrapping Key Infrastructures",
October 2016.
[i.4] IETF draft-ietf-anima-grasp: "Generic Autonomic Signaling Protocol (GRASP)", December 2016.
[i.5] ETSI TR 121 905: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Vocabulary for 3GPP Specifications
(3GPP TR 21.905)".
[i.6] ETSI TS 132 501: "Universal Mobile Telecommunications System (UMTS); LTE;
Telecommunication management; Self-configuration of network elements; Concepts and
requirements (3GPP TS 32.501)".
[i.7] ETSI GS NGP 006: "Next Generation Protocol (NGP); Intelligence-defined Network".
[i.8] NTECH(17)000013: "Requirements for Protocols and APIs for Enabling GANA based
Autonomics, Cognitive Networking and Self-Management of Networks and Services in Evolving
and Future Networks".
ETSI
7 ETSI GS NGP 002 V1.1.1 (2017-05)
[i.9] IETF RFC 4192: "Procedures for Renumbering an IPv6 Network without a Flag Day".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
NOTE: Some definitions are inherited from IETF RFC 7575 [1].
autonomic node: network node that supports a set of basic Self-organizing functions
NOTE: E.g. the ASAs for basic connectivity as described in clause 9.1.
autonomic domain: set of autonomic nodes compose a domain within which the autonomic node could create stable
connectivity with each other and share the same intent
autonomic service agent: agent implemented on an autonomic node that implements an autonomic function, either in
part (in the case of a distributed function) or whole (IETF RFC 7575 [1])
intent: abstract, high-level policy used to operate the network
NOTE: Its scope is an autonomic domain (IETF RFC 7575 [1])
network-wide knowledge: valuable information extracted from the data in various nodes or some network-level
policies/information input from the administrators
self-X Network: network supports a set of "Self-" features such as Self-Configuration, Self-Orchestration, etc. (as
described in clause 6) to form a self-organizing control and management plane
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TR 121 905 [i.5] and the following apply:
NOTE: Should apply to scenarios that include mobile network architectures.
ACO Automatic Cluster Optimization
ACP Autonomic Control Plane
AFI Autonomic Future Internet
AI Artificial Intelligence
AN Autonomic Network
ANI Autonomic Networking Infrastructure
API Application Programming Interface
ASA Autonomic Service Agent
ASG Aggregation Site Gateway
BRSKI Bootstrapping Remote Secure Key Infrastructures
BSS Business Support System
CA Certificate Authority
CSG Cell Site Gateway
DE Decision Element
DHCP Dynamic Host Configuration Protocol
ECMP Equal-cost Multi-path Routing
FCAPS Fault, Configuration, Accounting, Performance, Security
GANA Generic Autonomic Networking Architecture
GRASP Generic Autonomic Signalling Protocol
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IP Internet Protocol
IPRAN IP-based Radio Access Network
IRP Integration Reference Point
ETSI
8 ETSI GS NGP 002 V1.1.1 (2017-05)
ISG Industry Specific Group
ISIS Intermediate System to Intermediate System
ISP Internet Service Provider
MPLS Multi-Protocol Label Switching
ND Neighbour Discovery
NGP Next Generation Protocols
NMS Network Management System
OAM Operations, Administration, and Maintenance
OSPF Open Shortest Path First
OSS Operation Support System
PW Pseudo-Wire
RQ Requirement
RSG Radio Service Gateway
SDN Software Defined Network
SLAAC Stateless Address Autoconfiguration
SMN Self-Managed Network
SON Self-Organizing Networks
SXN Self-X Network
TE Traffic Engineering
ULA Unique Local Address
VPN Virtual Private Network
4 Overview
The ISG Next Generation Protocols (NGP) aims to review the future landscape of Internet Protocols, identify and
document future requirements and trigger follow up activities to drive a vision of a considerably more efficient Internet
that is far more attentive to user demand and more responsive whether towards humans, machines or things.
A measure of the success of NGP would be to remove historic sub-optimized IP protocol stacks and allow all next
generation networks to inter-work in a way that accelerates a post-2020 connected world unencumbered by past
developments.
The NGP ISG is foreseen as having a transitional nature that is a vehicle for the 5G community and other related
communications markets to first gather their thoughts together and prepare the case for the Internet community's
engagement in a complementary and synchronized modernization effort.
Therefore NGP ISG aims to stimulate closer cooperation over standardization efforts for generational changes in
communications and networking technology.
The present document introduces the NGP, ISG view on how the network could get self-managed, through interaction
between devices based on a set of new protocols. One important principle is taking an incremental approach that the
Self-X Networks (SXN) should co-exist and interact with current network.
The present document presents the vision of Self-Managed Networks in clause 6. The vision is separated into several
goals, which are mainly inherited from the classic FCAPS model. In clause 7, the present document discusses a couple
of important principles of designing the SXN.
Then, according to clause 6 and clause 7, the architecture of SXN is introduced in clause 8. The architecture is angled
from a node perspective; and the node is called Autonomic Node (AN). The essential component in an AN is the
Autonomic Service Agent (ASA), which could be considered as applications running in network devices to fulfil
specific network management functions/tasks without human intervene. There could be various kinds of ASAs to fulfil
different functions/tasks; some ASAs, which are considered as basic and common functions in a network, are
introduced in clause 9.
There are also two use cases of the proposed architecture introduced in clause 10. At last, a summary of future protocol
requirements are documented in clause 11.
ETSI
9 ETSI GS NGP 002 V1.1.1 (2017-05)
5 Background
5.1 Motivation of Self-Management and Control
The success of the Internet has made IP-based networks bigger and more complex. The scale of networks is quickly
increasing; the numbers of network devices are also quickly increasing. With the increasing of new features and
functionalities, network devices has been becoming more and more complicated and new network services have been
continuing emerging. Network controlling is becoming more multidimensional, beyond the routing reachability.
Diversified network management requirements are growing while the granularity of network management is required to
be finer and more precise. The controlled and managed objectives in the network have complicated relationships, which
have not yet been considered. The cooperation and interference among devices are complicated.
In the current IP based network systems, only routing functions may be considered as autonomic. Even that requires
manual provisioning of peer neighbours, route policies and other attributes to achieve the desired effect. It results in a
rigid network traffic management. Although several network management tools can automate repeatable work through
scripts, the overall network operations, control and management functions still require human intelligence and experts
with in-depth knowledge of all aspects.
Currently, the network controlling and management are mostly through the device parameters, which rely on the
decision and implement of network administrator. With the growing network infrastructures, network changes are more
frequent and impact vast geographies. A network administrator needs to modify configurations as often and in timely
manner. However, manual verification and validation processes are usually slow, painstaking and still error prone. It is
reported that most network problems (above 95 %) are caused by human's mis-configurations. The network
administrator is both the key and the bottleneck, even the source of problem.
All of the abovementioned situations are extremely demanding for dynamic management that needs to response to a
large amount of information. Human based management are not able to meet the requirements any more. A more
flexible, extensible and self-managing system is urgently needed. A completely automatic solution for network control
and management could simplify human management, avoid human errors, and reduce the cost of network maintenance.
Figure 1: Trend of Network Complexity and Impact of Introducing Self-managing Technologies
5.2 Evolution History of Network Control and Management
IP networking was initially designed with similar properties in mind. An IP network should be distributed and
redundant to withstand outages in any part of the network. Routing protocols such as OSPF and ISIS exhibit properties
of self-management and can thus be considered autonomic in the definition of the present document.
ETSI
10 ETSI GS NGP 002 V1.1.1 (2017-05)
However, as IP networking evolved, the ever-increasing intelligence of network elements was often not put into
protocols to follow this paradigm, but was put into external north-to-south configuration systems. This configuration
made network elements dependent on some process that manages them, either a human or a network management
system, which is still human based with some enhanced tools.
While the network scale keeps increasing, the complexity becomes a bigger issue. There are two diverted opinions
regarding to evolving directions:
a) Centralized control and management systems are introduced to ease the management of a large number of
devices and largely reduce the inconsistency/conflicts among devices However, centralization does not mean
more intelligence; rather, it only stands for the aggregation of information and the management is still
essentially relying on the intelligence of the administrators. The network complexity will increase beyond the
handling capability of human.
b) Distributed Intelligence should extend to other network aspects beyond the reachability. DHCP and ND are
also moving towards this direction, but these two protocols are only deployed in the edge network where the
end devices communicate with the network directly. This evolving direction emphasis more on sensing and
communication in the horizontal level among the network devices, and it can only deal with very limited
management tasks.
In a nutshell, to achieve a more self-managing network without increasing human burden, neither only aggregating
information and control centrally, nor simply increasing horizontal communication is enough. The essential thing is that
each of the network devices needs to be enhanced with more intelligence.
5.3 Relationship with Existing Work
1) 3GPP SON
3GPP has a set of technologies called "Self-Organizing Network (SON)". In one aspect, 3GPP SON focusing on
specific 3GPP systems while the SXN in the present document is more generic; in another aspect, current 3GPP SON is
mostly regarding to wireless interface self-optimization while the SXN could be the candidate architecture and technical
approaches for the 3GPP SON of the fixed network part.
2) AFI GANA
The AFI (Autonomic network engineering for the self-managing Future Internet) is an ETSI ISG that dedicated for
autonomic networking. AFI had launched the GANA (Generic Autonomic Network Architecture) reference model for
autonomic networking, cognitive networking and self-management in 2013 (the latest version, ETSI GS AFI 002 [i.1]).
GANA is a very generic and comprehensive model, of which the main objective is "to define, iteratively, a generic,
conceptual architectural reference model intended to serve as guideline for the design of the future generation networks
exhibiting autonomic characteristics or capabilities", as stated in the GANA document. The SXN essentially keeps
consistent with some important concepts in GANA. For example, the Autonomic Node defined in clause 8 is essentially
the same with Network Element in GANA; the ASAs described in clause 9 could be considered as specific instances of
the GANA Decision Element; the Network-wide Knowledge in clause 8 is a simple instance of Knowledge Plane
defined in GANA.
So, in general, the SXN is consistent with the GANA model, and there is no conflict. However, the SXN concepts and
technologies are not as generic as GANA; rather, they aim at defining specific components that much more closed to
implementation based on current network.
3) IETF Anima
Anima (Autonomic Networking Integrated Model and Approach) is an IETF working group aims at developing
protocols/mechanisms that could be directly implemented and integrated into current networks to improve the
autonomics. Anima's approach is to identify some very basic and common technical components that could be re-used
among different scenarios. These components are called ANI (Autonomic Network Infrastructure). Currently, there are
three technologies defined as ANI, as the following.
ETSI
11 ETSI GS NGP 002 V1.1.1 (2017-05)
• GRASP (GeneRic Autonomic Signalling Protocol):
GRASP is the protocol used between autonomic nodes to cooperate to fulfil management tasks. It provides
generic and basic communication schemes such as Discovery, Negotiation, Synchronization and Flood.
GRASP is a realization of the Discovery Agent and Information Distribution Agent in clause 9.
• ACP (Autonomic Control Plane):
ACP enables a secure and stable management channel between autonomic nodes without any manual
configuration. ACP is one realization fits into Autonomic Reliable Connectivity Agent in clause 9.
• BRSKI (Bootstrapping Remote Secure Key Infrastructures):
BRSKI allows new devices joining the Autonomic Domain by authentication of the device certificate; and also
makes the new devices assigned with Autonomic Domain certificates for secure communication afterwards. It
is a realization of Secure Bootstrap Agent in clause 9.
Overall, Anima provides specific IP-based realization of some functions specified in the present document; but the
present document has a more general scope and not binding to IP protocols. The present document only considers
Anima as an instance/reference of realizing corresponding self-managing functions.
6 Vision of Self-X Networks
6.1 Overview
This clause describes the high-level goals that are expected to be achieved by the SXN.
According to ISO FCAPS model, network management contains Fault Management, Configuration Management,
Accounting Management, Performance Management and Security Management. This classic model is also a very
suitable reference for setting up the high-level goals of the SON.
However, this clause excludes the Accounting from the FCAPS; and narrows down the Performance Management and
Security Management to Self Optimization and Self Defense. Apart from FCAPS, this clause includes Self Service
Orchestration into the scope.
6.2 Self Configuration
Self-configuration means that all the Autonomic Nodes are configured autonomically and dynamically.
"Autonomically" means the configuration is done by the node and the network without human intervene; while
"dynamically" means the configurations are not static rules but rather generated according to the node and the networks'
features and conditions.
The configurations mainly contain two parts:
1) Initial configuration: when a node newly joins in the Self-Managed Network, it needs to get the basic
connectivity configurations such as addressing, routing, etc. (clause 9.1 introduces ASAs for this purpose).
2) Service configuration: when the SXN wants to enable a service (e.g. MPLS VPN), it needs to make
configurations on a certain of nodes. (clause 9.3 introduces ASAs for this purpose).
Self-configuration could be considered as a very basic yet very important feature in SXN. Since the network can simply
begin to run after the Self-configuration.
6.3 Self Service Orchestration
When deploying a service, in a perspective of an Autonomic Node, there could be two approaches:
1) The nodes receive specific configurations which have been sorted out by a central management server or
controller, according to the service request. This is also the traditional manner in service orchestration.
ETSI
12 ETSI GS NGP 002 V1.1.1 (2017-05)
2) The nodes directly interpret the service request and sort out the configurations by themselves. When multiple
nodes are involved for one service, the ANs should be able to coordinate with each other autonomically.
In SXN, both of the approaches should be utilized. The former one is more suitable for sophisticated service layout
where the logic is complex and it is very difficult for the distributed nodes to cooperate; while the latter could be used in
the scenarios that does not has much complex logic so that some simple interactions between ANs can fulfil the task.
Whatever approach is taken, the common precondition is that the server/controller and ANs need to understand the
service requests and translate them into configurations without human intervene. This requires standardized interface of
the service request. More ideally, the service requests should be in an abstract or even nature language which can
simplify the users/administrators' burden to deliver the services to the SXN systems.
6.4 Self Fault Management
The Self Fault Management mainly includes two aspects: Self-Fault Discovery and Self Fault Recovery.
For Self Fault Discovery, sometimes it is not only regarding to a single node; and the fault might be very implicit that
could not be discovered a single node or even a group of nodes cooperated together. In these cases, sophisticated
analysis of logs from different devices might be needed. While in some other scenarios, the fault is more explicit and it
could be probably discovered by ANs through some real-time measurement.
The fault could be software fault and hardware fault. Ideally, the SXN should be able to fix all software faults.
Hardware fault is basically out of scope of SXN. However, in some cases, the SXN might reduce the impact of the fault
by simply isolating the fault devices.
6.5 Self Optimization
In massive scale systems, it is extremely difficult for a system administrator to tune parameters for best possible
network performance due to the lack of knowledge or time. A self-optimization module can smartly learn network
performance status and optimize the configurations without human intervention.
First of all, the SXN needs to learn about the current network performance. This could be done through
measurement/probing by the ANs. Then, the SXN could adjust the network resources allocation, the traffic paths,
and/or any other actions that could affect the network performance. After adjusting the configurations, the SXN could
again measure/probe the performance to check the effectiveness of the adjustment. Thus, a closed loop is formed.
6.6 Self Defence
The SXN needs to detect network attacks in real-time, and make defence accordingly. Similar to the Self Fault
Discovery, some attacks could be detected on a single node; while some might need sophisticated analysis.
Ideally, the SXN should not only be able to defend the known attacks automatically, but also recognize and defend
some new attacks. This could be possibly done through learning the network attack behaviours, so that the SXN could
extract some come criteria of detecting some kind of attacks.
Similar to Self Fault Recovery, SXN can do self-healing to the attacked devices/resources. It is not easy to fully heal the
attack, but there should be a bottom line that isolating compromised or faulty nodes and auto-upgrade of software
patches.
7 Considerations for Realizing Self-X Networks
7.1 Request for New Protocols and Enhanced Infrastructure
Towards achieving the SXN vision described above, it is no doubt that there needs to be some new protocols introduced
into the network. Behind the protocols, the essential thing is that new functions/features are needed. This is mainly
discussed in clause 9.
ETSI
13 ETSI GS NGP 002 V1.1.1 (2017-05)
Although one important principle of SXN is not to take a clean-slate approach, normally one new function cannot be
realized only through deploying on a single node (or even a small set of nodes). Thus, most of the functions need more
or less support from the infrastructure. Some functions (e.g. the ASAs discussed in clause 9.1) might even require every
node in the SXN to support. However, the new functions should be integrated into current devices as easy as possible.
7.2 Distributed and Centralized Approaches
The IP network was originally designed according to a distributed approach, which is mostly represented by the routing
protocols. Although there are also some centralized approaches such as network management. The core of the IP
network is in general distributed.
On the other hand, the hot trend of the network evolving is SDN (Software Defined Network), which is a typical
centralized approach.
These two approaches are not conflict with each other. In SXN, both of the two approaches would be used and should
be suitable for different scenarios or use cases respectively.
7.3 Transition Considerations
The SXN should evolve in an incremental way rather than a "flag day" approach or being deployed isolated with current
networks. So it is important to remain current network architecture and services not be impact significantly. Pieces of
autonomic mechanisms could be added one by one and co-exist with current network, to achieve a smooth transition to
SXN.
7.4 Security Considerations
Since there are lots of crucial behaviours of the SXN fully autonomic and without any human monitoring and auditing,
the SXN should have stronger security requirements than normal networks, to prevent malicious nodes joining the SXN
and making attacks which might also be propagate autonomically.
Major security requirements of SXN are as the following:
1) Access authentication of ANs
When an AN gets online, the SXN should be able to authenticate the identity of the node. This is a very basic
security requirement of SXN, and should be the bottom line.
A further requirement would be auditing whether the valid identity had been used in another network. This is
to prevent valid identity be stolen or misused.
2) Authentication between ANs
When ANs starting to communicate with each other, they also need to make sure the counterpart is a legal
node. Normally, the authentication scope could be based on domain, where the ANs might share a common
trust anchor.
3) Encrypt communications between ANs
The communication between ANs should be encrypting by default. If applicable, the encrypt communication
should be separated from normal data plane communications. This is to gain a high reliability that the
communication between ANs won't be affected by other traffic. In extreme case, even if the normal data
crashes, the ANs communication should also be stable and secure.
4) Authorization of prescriptive behaviour
Besides identity authentication and encryption, the authorization of some behaviour is also very important,
since one AN might receive indication which might contain some behaviours for the node to execute. Some
behaviour might have significant impact to the network, so the receiver should make sure the node that sent it
the indication has the right to do so.
SXN security mechanisms themselves should also be autonomic as much as possible, as they could be also considered
as a set of functions/tasks that shall be fulfilled by the SXN.
ETSI
14 ETSI GS NGP 002 V1.1.1 (2017-05)
8 Architecture of Self-X Network
8.1 Architecture Overview
Management Abstract Network-wide Interactive Network Historic
Intervention Report coordination Service Order Knowledge

Traditional
Network-wide Knowledge
NMS
Autonomic Node
Autonomic Service Agents
Generic
Internal Coordination
Autonomic
Signaling
Failure detect &
Auto Service
Performance
Protocol
recovery
Layout Agent
Management
Secure Auto Initial Routing Addr & Naming
Bootstrap Configuring Management Management
External
Communication
Autonomic
Local Historic
Reliable
Knowledge
Connectivity
Node Self Knowledge
Status & Measurement
Configurations
Figure 2: SXN Architecture Overview
As figure 2 shows, the architecture is angled from a node perspective; and the node is called Autonomic Node (AN).
The essential component in an AN is the Autonomic Service Agent (ASA), which could be considered as applications
running in network devices to fulfil specific network management functions/tasks without human intervene. There
could be various kinds of ASAs to fulfil different functions/tasks; some ASAs, which are considered as basic and
common functions in a network, are introduced in clause 9. The ASAs locate in different ANs communicate with each
other through the External Communication module.
The node is not a closed system; it can accept external management intervene, in a Network-wide Knowledge approach.
The network-wide knowledge is directly delivered to the node; and the node makes behaviour accordingly. The node
also reserves an interface to traditional NMS (Network Management System).
8.2 Self Knowledge on Autonomic Node
There is some information that one autonomic node can get by itself. For example, the node could easily get its current
configurations, which is usually valuable knowledge; or, the node does some measurement to learn the current status
such as bandwidth, delay, etc.
8.3 Interaction Functions on Autonomic Node
Autonomic nodes need to interact with each other. First of all, the nodes need to build up a stable and secure
communication channel automatically. One example of this kind of communication channel is the ACP (Autonomic
Control Plane), which under standardization in IETF. The ACP leverages the Ipv6 link-local addresses to build up
hop-by-hop secure tunnels; and leverage the ULA (Unique Local Address, which does not need to be applied from
registrar) addresses for domain routing. The whole process of ACP is without any human intervene. Besides, the ACP
does not allow manual configuration to get stability.
ETSI
15 ETSI GS NGP 002 V1.1.1 (2017-05)
The communication channel is only a basic communication utility. To fulfil autonomic control and management
functions, there shall be a standard protocol for the autonomic nodes to interact with each other. There is also an
example from the IETF, which is called GRASP (GeneRic Autonomic Signaling Protocol). GRASP has two basic
abilities: one is a discovery mechanism to find nodes that support some specific functions; the other is a negotiation
mechanism which allows multi-rounds interaction between two nodes to fulfil a control/management goal.
8.4 Autonomic Service Agents on Autonomic Node
An ASA is an application executed in an autonomic node, to do the control and management tasks. ASAs in different
autonomic nodes can discover and coordinate with each other through autonomic signalling protocol.
There could be various kinds of ASAs to fulfil different network control and management tasks respectively; one
autonomic node could host multiple ASAs which could be executed simultaneously.
An incomplete list of ASAs is described in clause 9.
8.5 Network-wide Knowledge
The Network-wide Knowledge is a concept that represents the valuable information extracted from the data in various
nodes or some network-level policies/information input from the administrators. In principle, extracting the Network-
wide Knowledge does not necessarily require a dedicated information exchange mechanism among nodes, although
these mechanisms might be present in some designs.
One example of the Network-wide Knowledge is the network wide coordination which could find conflicts between
different policies and make resolution. Such coordination should be done at the network-level.
Another example is to extract knowledge from historic data. The data could be nodes' configurations, logs, etc. Data
mining and machine learning might be used.
8.6 Interaction with External Input/Intervention
As well as the network to be self-managed of its own, it also needs to reserve input/output interfaces to external systems
or administrator intervention.
There are mainly two kinds of external input that needs to be processed:
• The network administrators' commands. When the administrators want to interfere the network's status, they
could input some commands to the network. And the network would interpret the commands and react
autonomically. To be noticed, the commands should not be as detailed as the traditional command lines; it
should be abstracted goal that the network needs to achieve. For example, the administrators could command
the network to run at power-saving mode.
• Service order. When there are new service orders requested from the customers, the service order system
(e.g. BSS) could input the orders to the self-managed network, and the network would execute the service
orders automatically.
Besides input, the self-managed network also needs to output the external systems. One typical output is to report the
current status of the network, or the results of an operation request. The report should be abstract and easy to review.
Visualization of complicated
...