A Solution for Goal-oriented Policy Refinement in NFV Management and Orchestration Systems
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br http://cin.ufpe.br/~posgraduacao
Recife 2020
A Solution for Goal-oriented Policy Refinement in NFV Management and Orchestration Systems
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, como requisito parcial para obtenção do grau de Doutor em Ciência da Computação.
Área de Concentração: Redes de
Com-putadores e Raciocínio Automático.
Orientador: Stênio Flavio de Lacerda Fernandes Coorientador: Frederico Luiz Gonçalves de Freitas
Recife 2020
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
B713s Bonfim, Michel Sales
A solution for goal-oriented policy refinement in NFV manegement and orchestration systems / Michel Sales Bonfim. – 2020.
171f.: il., fig., tab.
Orientador: Stênio Flavio de Lacerda Fernandes.
Tese (Doutorado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2020.
Inclui referências e apêndice.
1. Redes de computadores. 2. Ontologia. I. Fernandes, Stênio Flavio de Lacerda (orientador). II. Título.
004.6 CDD (23. ed.) UFPE - CCEN 2020 - 67
Michel Sales Bonfim
“A Solution for Goal-oriented Policy Refinement in NFV Management
and Orchestration Systems”
Tese de Doutorado apresentada ao Programa
de Pós-Graduação em Ciência da
Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciência da Computação.
Aprovado em: 05/03/2020.
______________________________________________
Orientador: Prof. Stênio Flávio de Lacerda Fernandes
BANCA EXAMINADORA
______________________________________________ Prof. Dr. Nelson Souto Rosa
Centro de Informática
______________________________________________ Prof. Dr. Kelvin Lopes Dias
Centro de Informática / UFPE
______________________________________________ Profa. Dra. Anjolina Grisi de Oliveira
Centro de Informática / UFPE
______________________________________________ Prof. Dr. Lisandro Zambenedetti Granville
Instituto de Informática / UFRGS
______________________________________________ Prof. Dr. Rostand Edson Oliveira Costa
Em primeiro lugar agradeço a Deus pela saúde plena concedida e motivação ao longo desses quatro anos no Centro de Informática (CIn).
Agradeço meu orientador, Stênio Fernandes, que além de participar ativamente através de discussões e orientações para que essa tese fosse escrita, tornou-se um amigo que com-partilhou os mais diversos tipos de conhecimentos durante essa jornada, sendo importante não apenas para a conclusão dessa tese, mas para que eu me tornasse alguém melhor.
Agradeço também ao meu coorientador, Fred Freitas, que tive o prazer de conhecer por meio de uma disciplina e foi a pessoa que me fez gostar da área de Lógica Matemática e Raciocínio Automático, sem as suas colocações e contribuições, a conclusão desta Tese teria sido muito mais difícil.
Por ser a pessoa que mais acreditou, incentivou e apoiou em todos os momentos, um agradecimento mais que especial à minha esposa, Sarah Sales. Obrigado meu amor por estar ao meu lado todo esse tempo, pelos cuidados, amor e paciência. Um agradecimento especial também à minha filha, Maria Julia Sales, que mesmo sem saber, soube perdoar e compreender os momentos de ausência.
Agradeço à minha família que me deu o suporte necessário para que eu superasse diversas barreiras para chegar até aqui, especialmente minha mãe Maria das Graças Sales. Agradeço aos meus amigos pela paciência, discussões, momentos de descontração e apoio, especialmente Paulo, Márcio, Lincon, Marcos, Jeandro, Camilo, Enyo, Janael, Marcelo, Rafael, Flavio e Felipe.
Agradeço aos professores participantes da banca examinadora que dividiram comigo este momento tão importante: Dr. Nelson Rosa, Dr. Kelvin Dias, Dra. Anjolina Grisi, Dr. Lisandro Granville e Dr. Rostand Costa.
Finalmente, agradeço às diversas pessoas que apoiaram direta ou indiretamente o desenvolvimento deste trabalho, seja no âmbito pessoal, acadêmico e profissional.
Some studies are tackling the integration of Network Function Virtualization (NFV) and Software-Defined Networking (SDN) in different environments (e.g., Cloud Comput-ing and Wide Area Network). The use of NFV technology, along with SDN, will play a significant role in 5G networks, since they allow the network programmability and the fast delivery of new services. Although NFV/SDN architectures have clear potential benefits, they are still at an early stage of development. One of the main challenges is the defi-nition of high-level policies necessary to simplify the configuration of NFV Management and Orchestration (NFV-MANO) operations, such as resource allocation and optimiza-tion mechanisms, and to meet the customers’ requirements. In this thesis, we intend to tackle part of this problem, namely, issues in the policy refinement procedures. We present the problem for the creation of a policy refinement procedure for NFV systems, as well as the requirements that we consider necessary for their composition. In this sense, we point out the need to have an approach that provides a functional solution for automated policy refinement in policy-based NFV management and orchestration systems. Such a method must support several features such as goal-oriented refinement and detection and resolution of policy conflicts. In this context, we propose the AuT omated POlicy
Re-finement SysteM for NFV (ATOM), an automated solution for the policy reRe-finement
process for Policy-Based Management Systems (PBM) in NFV scenarios (NFV-PBM). To achieve its goal, the ATOM comprises 3 functional blocks: NSChecker,
NSPlan-ner, and Feedback Module. The NSChecker is a semantic verification system to find
inconsistencies among policies defined in NS Request (NS-Req) and global policies previ-ously created in the NFVI, i.e., application-specific policies. The NSPlanner provides a solution that enables NFV-MANO to record high-level goals extracted from Network Service Descriptor (NSD) and perform a fully automated policy refinement, that derives enforceable policies (Event-Condition-Action or ECA rules) to govern NFV-MANO be-havioral choices while satisfying the goals. Besides, NSPlanner performs policy analysis between management-specific policies, i.e., rules that will be generated by the refine-ment process and stored in NFV-PBM to govern system behavior. Finally, the Feedback Module is a monitoring system that aims to assist the operator in the task of verifying if the enforceable policies are fulfilling the high-level goals. We conducted a performance evaluation of both NSChecker and NSPlanner. The results demonstrate that NSChecker is efficient even in scenarios with 50,000 NFV Infrastructure Nodes (NFVI-Nodes), while NSPlanner is efficient even in scenarios with 1000 goals and 1000 alarms pre-registered. Keywords: Network function virtualization. Ontology. Description logic. Automated plan-ning. Hierarchical task network. Policy.
Diversos estudos estão lidando com a integração das tecnologias Network Function
Virtualization (NFV) e Software-Defined Networking (SDN) em diferentes ambientes. O
uso da tecnologia NFV, juntamente com SDN, terá uma função significante nas redes 5G, desde que elas permitem a programabilidade da rede e a rápida entrega de novos serviços. Embora as arquiteturas NFV/SDN tenham claros benefícios, elas ainda estão em um estágio inicial de desenvolvimento. Um dos principais desafios consiste na definição de políticas de alto nível para simplificar a configuração do NFV Management and
Orches-tration (NFV-MANO), tal como a alocação de recursos e a otimização de mecanismos.
Nesta Tese, nós atacamos esse problema, conhecido como refinamento de políticas. Nós apresentamos o problema para a criação do procedimento de refinamento de políticas para NFV, bem como os requisitos que nós consideramos necessários para a sua composição. Neste sentido, nós apontamos a necessidade de se ter uma abordagem que proponha uma solução funcional para o refinamento de políticas automatizado para o NFV-MANO. Tal método deve suportar diversas ferramentas, tais como refinamento orientado à obje-tivos e a detecção e resolução de conflito entre políticas. Neste contexto, nós propomos o AuTomated POlicy Refinement SysteM for NFV (ATOM), uma solução au-tomatizada para o processo de refinamento de políticas para Policy-Based Management
Systems (PBM) em NFV (NFV-PBM). Para alcançar este objetivo, o ATOM é composto
por 3 blocos funcionais: NSChecker, NSPlanner e Feedback Module. O NSChecker é um sistema de verificação semântica para encontrar possíveis inconsistências entre políti-cas definidas no NS Request (NS-Req) e polítipolíti-cas globais previamente criadas no NFVI, ou seja, políticas da aplicação. O NSPlanner provê uma solução que habilita o NFV-MANO a registrar objetivos de alto nível, extraídos do Network Service Descriptor (NSD), e realizar o refinamento de políticas. Neste caso, ele deriva políticas executáveis (regras
Event-Condition-Action ou ECA) para governar o comportamento do NFV-MANO
en-quanto satisfaz os objetivos. Além disso, o NSPlanner realiza a análise de políticas entre
políticas de gerenciamento, ou seja, regras que foram geradas pelo processo de
refina-mento e armazenadas no NFV-PBM para governar o comportarefina-mento do sistema. Final-mente, o Feedback Module é um sistema de monitoramento que tem por objetivo auxiliar o operador na tarefa de verificar se as políticas executáveis estão satisfazendo os objetivos de alto nível. Nós conduzimos uma avaliação de desempenho tanto do NSChecker como do NSPlanner. Os resultados demonstraram que o NSChecker é eficiente mesmo em cenários com 50.000 NFV Infrastructure Nodes (NFVI-Nodes), enquanto o NSPlanner é eficiente em cenários com 1000 objetivos e 1000 alarmes previamente cadastrados.
Palavras-chaves:Network function virtualization. Ontologia. Lógica de descrição.
Figure 1 – SDN Reference Architecture (MCKEOWN et al., 2008; KREUTZ et al.,
2015; ONF, 2015). . . 27
Figure 2 – NFV Architecture (ETSI, 2014a). . . 31
Figure 3 – Policy-driven management architecture. . . 34
Figure 4 – Policy refinement process: an analogy (ROCHAELI, 2009). . . 36
Figure 5 – Example of a performance management goal. . . 37
Figure 6 – Planning conceptual model (NAU; GHALLAB; TRAVERSO, 2004). . . 44
Figure 7 – Dock Worker Robots (DWR) example (NAU; GHALLAB; TRAVERSO, 2004). . . 46
Figure 8 – Hierarchical Task Network (HTN) overview (NAU; GHALLAB; TRAVERSO, 2004). . . 50
Figure 9 – High-level ATOM Architecture. . . 52
Figure 10 – ATOM overview. . . 54
Figure 11 – PerfChecker architecture. . . 57
Figure 12 – SFCMon as an SFC Component. . . 59
Figure 13 – Prototype Architecture. . . 60
Figure 14 – Feedback Module Architecture. . . 61
Figure 15 – The NSChecker architecture. . . 66
Figure 16 – Onto-NFV main classes. . . 68
Figure 17 – Describing an NFV Infrastructure (NFVI). . . 71
Figure 18 – Describing Network Service. . . 73
Figure 19 – Describing affinities and anti-affinities. . . 76
Figure 20 – The topology used in the validation process. . . 81
Figure 21 – VNFFG created in the validation scenario. . . 82
Figure 22 – Explanation for the inconsistency detected in Use Case 1. . . 82
Figure 23 – Explanation for the inconsistency detected in Use Case 2. . . 84
Figure 24 – Explanation for the inconsistency detected in Case Study 3. . . 85
Figure 25 – NSChecker performance evaluation results. . . 88
Figure 26 – The NSPlanner architecture. . . 99
Figure 27 – Onto-Planner main classes. . . 102
Figure 28 – Onto-Planner classes used after planning process. . . 103
Figure 29 – NFV interface specifications. . . 105
Figure 30 – ManagedEntityMethod subclasses. . . 106
Figure 31 – Describing NFV operators. . . 106
Figure 32 – Healing and Scaling subclasses. . . 107
Figure 35 – Describing high-level goals. . . 110
Figure 36 – Describing low-level policy rules. . . 111
Figure 37 – The Fault Management High-level Goals. . . 118
Figure 38 – The Fault Management - NFVI Redundancy. . . 120
Figure 39 – VNF agnostic NIC failover. . . 121
Figure 40 – VNF agnostic restorarion recovery. . . 121
Figure 41 – The Fault Management - VNF Redundancy. . . 123
Figure 42 – Stateful redundancy setup. . . 124
Figure 43 – Stateful redundancy VNFC migration. . . 124
Figure 44 – The Fault Management - QoS Degradation Prevented. . . 125
Figure 45 – The Fault Management - Failures Controlled. . . 127
Figure 46 – Explanation for the inconsistency detected in Use Case 1. . . 128
Figure 47 – Explanation for the inconsistency detected in Use Case 2. . . 130
Figure 48 – Explanation for the inconsistency detected in Use Case 3. . . 131
Figure 49 – Number of elements versus consistency check time. . . 133
Figure 50 – Number of elements versus planning time. . . 134
Table 2 – Syntax and semantics of some DL constructors. . . 42
Table 3 – Class Axioms for NFVI description (Manchester Syntax). . . 72
Table 4 – Class Axioms for Network Service (NS) definition (Manchester Syntax). 74 Table 5 – Axioms for affinities/anti-affinities object properties (Manchester Syntax). 77 Table 6 – Class Axioms for Resourse Usage (Manchester Syntax). . . 80
Table 7 – List of topologies used in the experiments. . . 86
Table 8 – List of factors and levels used in the experiments. . . 87
Table 9 – Class Axioms for Alarm description (Manchester Syntax). . . 109
Table 10 – Class Axioms for Goal description (Manchester Syntax). . . 111
Table 11 – Class Axioms for ECA Rule description (Manchester Syntax). . . 112
Table 12 – List of factors and levels used in the experiments. . . 132
AI Artificial Intelligence
API Application Programming Interface
CAPEX Capital Expenditures
CDM Conflict Detection Module
COTS Common Off-The-Shelf
DL Description Logic
DPI Deep Packet Inspection
ECA Event-Condition-Action
EMS Elemental Management Systems
ETSI European Telecommunications Standards Institute
GGS Goal Graph Structure
GPMM Goal-oriented Policy Management Module
HTN Hierarchical Task Network
IM Information Model
LCM Life Cycle Management
NAT Network Address Translation
NFV Network Function Virtualization
NFVIMM NFVI Resource Management Module
NFVI-Node NFV Infrastructure Node
NFVIPMM NFVI Policy Management Module
NFVI-PoP NFVI Point of Presence
NFV-IR NFV Instances Repository
NFVI-RR NFVI Resources Repository
NFVI-Pol NFVI Policy
NFV-MANO NFV Management and Orchestration
NFVI NFV Infrastructure
NFVO NFV Orchestrator
NS Network Service
NSMM Network Service Management Module
NSD Network Service Descriptor
NS-Req NS Request
NSO Network Service Orchestration
OPEX Operational Expenditures
OWA Open World Assumption
OWL Web Ontology Language
PAP Policy Authorization Point
PBM Policy-based Management
PDP Policy Decision Point
PEP Policy Enforcement Point
PGM Planner Generation Module
PNF Physical Network Function
PR Policy Repository
QoS Quality of Service
RO Resource Orchestration
SDN Software-Defined Networking
SDP Software Data Plane
SFC Service Function Chaining
SLA Service Level Agreement
SWRL Semantic Web Rule Language
TMM Threshold Management Module
VIM Virtualized Infrastructure Manager
VL Virtual Link
VM Virtual Machine
VNF Virtual Network Function
VNFC VNF Component
VNFFG VNF Forwarding Graph
1 INTRODUCTION . . . 16
1.1 CONTEXTUALIZATION . . . 16
1.2 MOTIVATION . . . 18
1.3 PROBLEM STATEMENT . . . 19
1.4 OBJECTIVES . . . 24
1.5 THESIS STATEMENT AND CONTRIBUTIONS . . . 25
1.6 THESIS STATEMENT . . . 26
2 BACKGROUND . . . 27
2.1 SOFTWARE-DEFINED NETWORKING . . . 27
2.1.1 OpenFlow . . . 28
2.1.2 SDN Controllers . . . 29
2.1.3 Programmable Data Planes . . . 30
2.2 NETWORK FUNCTION VIRTUALIZATION . . . 31
2.3 POLICY-BASED MANAGEMENT SYSTEMS . . . 33
2.4 POLICY REFINEMENT . . . 35
2.5 ONTOLOGIES . . . 39
2.5.1 The Description Logic 𝒮ℛ𝒪ℐ𝒬 . . . 41
2.5.2 Description Logic Reasoning Services . . . 42
2.6 AUTOMATED PLANNING . . . 44
2.6.1 Hierarchical Task Network (HTN) . . . 49
2.7 CONCLUDING REMARKS . . . 51
3 THE AUT OMATED POLICY REFINEMENT SYSTEM FOR NFV 52 3.1 FEEDBACK MODULE . . . 55
3.1.1 PerfChecker . . . 55
3.1.2 SFCMon . . . 58
3.1.3 Feedback Module Architecture . . . 62
3.2 CONCLUDING REMARKS . . . 62
4 A SEMANTIC-BASED POLICY ANALYSIS SOLUTION FOR THE DEPLOYMENT OF NFV SERVICES . . . 63
4.1 THE PROBLEM OF POLICY CONFLICTS IN NFV . . . 64
4.2 THE NSCHECKER . . . 66
4.2.1 NSChecker Architecture . . . 66
4.2.3.1 Describing NFVI resources . . . 70
4.2.3.2 Describing Network Services . . . 72
4.2.4 Managing Policies . . . 74
4.2.4.1 Network Function Precedence . . . 74
4.2.4.2 Location Constraints . . . 75
4.2.4.3 Resource Usage . . . 79
4.3 ONTO-NFV VALIDATION . . . 81
4.3.1 Use Case 1 - Testing Conflicts between Precedence Restrictions . . 82
4.3.2 Use Case 2 - Testing Conflicts between Placement and Affinity/Anti-Affinity Restrictions . . . 83
4.3.3 Use Case 3 - Testing Conflicts among Resouce Usage, Placement and Affinity Restrictions . . . 84
4.4 PERFORMANCE EVALUATION . . . 86
4.5 CONCLUDING REMARKS . . . 89
5 A GOAL-ORIENTED POLICY REFINEMENT PROCEDURE FOR NFV SYSTEMS . . . 91
5.1 TOWARDS AN AUTOMATED POLICY REFINEMENT PROCEDURE FOR NFV-MANO FUNCTIONS . . . 93
5.2 NSPLANNER . . . 98
5.2.1 NSPlanner Architecture . . . 98
5.2.2 Onto-Planner . . . 101
5.2.3 Describing NFV-MANO Operators . . . 103
5.2.4 Describing Alarms . . . 106
5.2.5 Describing Goals . . . 110
5.2.6 Describing Policy Rules . . . 111
5.2.7 Managing Policy Conflicts . . . 114
5.3 ONTO-PLANNER VALIDATION . . . 117
5.3.1 A Planning Domain Model for the Resilience Attribute . . . 118
5.3.1.1 Failures Prevented . . . 119
5.3.1.2 Failures Controlled . . . 126
5.3.2 Use Case 1 - Testing Conflicts between Alarms . . . 128
5.3.3 Use Case 2 - Testing Conflicts between Goals . . . 129
5.3.4 Use Case 3 - Testing Conflicts between Rules . . . 130
5.4 PERFORMANCE EVALUATION . . . 132
5.5 CONCLUDING REMARKS . . . 135
6 STATE OF ART . . . 137
6.3 POLICY REFINEMENT IN NFV SYSTEMS . . . 139
6.4 LOGICAL FORMALISMS FOR POLICY REFINEMENT . . . 140
6.5 CONCLUDING REMARKS . . . 143 7 CONCLUSIONS . . . 144 7.1 THREATS TO VALIDITY . . . 147 7.2 PUBLICATIONS . . . 148 7.3 FUTURE WORK . . . 150 REFERENCES . . . 151
1 INTRODUCTION
This chapter describes the context in which the proposed research is inserted. Initially, the main motivations for conducting the research are presented (Sections 1.1 and 1.2). Then, the research problem, hypotheses and objectives are defined (Sections 1.3 and 1.4). Moreover, the thesis statement and contributions are described (Sections 1.5). Finally, the general organization of the document is detailed (Section 1.6).
1.1 CONTEXTUALIZATION
Proprietary network hardware equipment is everywhere in businesses, homes, and data center networks. Each vendor explores and exploits the maximum capability of its plat-forms as a way to meet the performance, reliability, and availability requirements de-manded by the various types of users. However, such an approach has resulted in an incompatibility between different manufacturer’s technologies. Restricted licensing agree-ments and proprietary source code have further contributed to this limitation (ETSI, 2012).
Because of such incompatibility of platforms, as well as the need for network engineers to add new features into their networks (e.g., firewalls, load balancing), they often need to purchase new equipment from different vendors. Each item of equipment is responsible for a share of the traffic processing that requires specific management strategies. Difficulties in the management and configuration of such heterogeneous environments are the norm. The requirement to allow such flexibility in configuration and the deployment of new network functions must be met in new business and engineering models (ETSI, 2012). The
complexities of current networking environments result in high operational (OPEX) and capital (CAPEX) expenditure costs (MIJUMBI et al., 2016).
Furthermore, the network service provider market has become increasingly competi-tive. As a result, network operators are always looking for offering distinguished services, including mechanisms to deploy network services on-demand, thus increasing the flexibil-ity and agilflexibil-ity in delivering these services (ETSI, 2015a).
Network Function Virtualization (NFV) and Software-Defined Networking (SDN) have been the leading paradigms adopted to solve the above problems. Rather than dealing with proprietary hardware equipment, which includes a limited set of specific network applications, NFV allows users to transfer network functions (e.g., Firewall) from specific to Common Off-The-Shelf (COTS) hardware using virtualization technologies. These net-work functions are then called Virtual Netnet-work Functions (VNFs). NFV aims at creating NSs that interconnect one or more VNFs to support the creation and deployment of end-to-end network services. This approach allows cost reduction, increases the speed of
network creation and maintenance, and offers greater flexibility to deliver new services ( SZ-ABÓ et al., 2015).
On the other hand, SDN is a network paradigm. Its main feature is the separation of the network control plane from the data plane, compared to current networks where the IP layer integrates both planes vertically into the network devices (MCKEOWN et al., 2008).
The data plane, deployed as network devices, is responsible for forwarding data accord-ing to a set of rules. In its turn, the control plane, represented by a software called SDN Controller, is responsible for decisions on how to handle the underlying network traffic concerning network policies and rules. The SDN Controller can run on COTS systems, separated from the forwarding devices. It allows the creation and management of such rules through an Application Programming Interface (API) in the Northbound interface. Moreover, it performs direct control over the data plane elements through protocols in the Southbound interface. Such separation provides some advantages, such as simplifi-cation and flexibility in network policy enforcement, facilitating network configuration, development, and fostering innovation (KREUTZ et al., 2015). It also brings research and
development challenges that have attracted researchers from both industry and academia. According to Mijumbi et al. (2016) (MIJUMBI et al., 2016), “NFV and SDN have a lot in common since they both advocate for a passage toward open software and network hard-ware”. Even with different purposes, NFV and SDN represent complementary paradigms and technologies capable of providing one consolidated solution. To this end, SDN can provide connectivity between VNFs in a flexible and automated way, thus simplifying network management. Besides, NFV can make use of SDN as part of a NSs. In this case, both SDN Controllers and Management Applications can run as VNFs in a scalable en-vironment and hence benefit from essential features, such as availability, reliability, and elasticity.
Some studies are tackling the integration of NFV and SDN in different environments (e.g., Cloud Computing, Wide Area Network, Customer Premise Equipment, 5G, etc.). Industrial and academic research studies address several challenges, such as reliability, overall performance, and scalability (BONFIM; DIAS; FERNANDES, 2019). The use of NFV technology, along with SDN, will play a significant role in 5G networks, since they allow the network programmability and the fast delivery of new services, enabling Network Slicing and Mobile Edge Computing (MEC) implementation and orchestration (GROUP,
2017).
Although NFV/SDN architectures have clear potential benefits, they are still at an early stage of development. According to Bonfim et al. (BONFIM; DIAS; FERNANDES, 2019), one of the main challenges is the definition and enforcement of high-level policies necessary to simplify the configuration of NFV Management and Orchestration (NFV-MANO) operations, such as resource allocation and optimization mechanisms, and to
meet the customers’ requirements.
1.2 MOTIVATION
NFV-MANO is an NFV functional block that should provide the following features ( BON-FIM; DIAS; FERNANDES, 2019):
• Multi-domain orchestration of diverse programmable infrastructure technologies (e.g., radio-access, transport and core networks, data centers, etc.), possibly be-longing to different operators;
• Northbound interface providing multi-tenancy and multi-service support;
• End-to-end network services that are flexible to the dynamic requirements of differ-ent services (e.g., IoT, smart cities, etc.) and mobile operators, providing a multi-service and context-aware adaptation of network functions;
• Advanced autonomic network management platforms to address complexity in such scenarios.
For this, it performs both Network Service Orchestration (NSO) and Resource Or-chestration (RO). Such functionalities include the following non-exhaustive list of opera-tions (ETSI, 2014b):
• VNF and NS Life Cycle Management (LCM); • VNF and NS scaling;
• Resource orchestration and management in multi-domain scenarios; • Access control; and
• Performance and fault management.
Therefore, management in NFV scenarios is a complex task since delivering such VNFs and NSs over the physical infrastructure requires flexible and adaptable NFV-MANO sys-tems (GIOTIS; KRYFTIS; MAGLARIS, 2015). The increasing complexity of the NFV-MANO has increased the gap between human intention and the managed system behavior. In this context, new solutions are necessary to reduce this gap and improve the management of these complex systems.
In this context, Policy-based Management (PBM) systems can be used to enforce NFV-MANO functions as a way to deal with the increased complexity. In PBM, an op-erator specifies goals and constraints in the form of rules to govern the behavior of the system (SLOMAN, 1994). This brings the following advantages: reduction of the complex-ity of management tasks; less manual countermeasures and errors; automated analysis
and verification based on a formal foundation; and dynamic inspection and adaption at runtime, without demanding changes in the underlying implementation. PBM solutions have been applied in different scenarios, such as computer networks (Policy-based Network Management) and cloud computing (Policy-based Cloud Management).
According to European Telecommunications Standards Institute (ETSI) (ETSI, 2014b), PBM systems are the key enablers to provide flexibility and adaptability in NFV-MANO systems. Assisted by policies, NFV-MANO functions can be provided in a automatic fashion aiming to meet the changing requirements of NSO and RO. An NFV-PBM system refers to the management of rules governing the behavior of NFV-MANO functions.
1.3 PROBLEM STATEMENT
However, PBM is not a straightforward task (RIEKSTIN et al., 2016). This situation is exacerbated when we consider its application in the management of NFV systems since NFV-MANO must provide several functionalities in a flexible and adaptable way (as men-tioned in the previous section). In this scenario, an NFV-PBM system has the following key issues: policy analysis and policy refinement.
For the creation of NSs on an NFVI, one NS Request (NS-Req) must be submitted to the NFV-MANO. Such requests consist of Network Service Descriptors (NSDs) that specify one or more VNFs, virtual links, and define a topology for the interconnection of these elements. Additionally, an NS-Req may include one or more application-specific policies that may be associated with those elements or the service as a whole. Such policies are called NS Policys (NS-Pols) and supports the description of the following constraints: network functions’ precedence, resource usage, and location constraints.
However, once one NS-Req can contain many policies, detecting conflicts between them is an intricate work for both humans and computer systems. This situation is worsened by the fact that the NFVI can also include many policies, called NFVI Policy (NFVI-Pol), pre-emended by the operator or by the NFV-MANO itself. For example, consider that an NS-Req contains the following NS-Pols:
• Resource constraint: three dedicated CPU cores for VNF A and three dedicated CPU cores for VNF B;
• Affinity Rule: VNF A and VNF B must be instantiated on the same physical server. On the other hand, consider the following NFVI-Pol previously registered on the NFV system:
• Resource reservation constraint: Only four CPU cores per physical server must be reserved for VNF instantiation.
In this case, a conflict among these three policies, since we cannot allocate six CPU cores for VNF A and VNF B given that the NFV platform reserves only four cores per physical server.
Since disputes occur among a set of policies, pairwise detection will not suffice (BOUTEN et al., 2016). Therefore, we need to identify such conflicts before sending the NS-Req to the embedding algorithm, which is responsible for mapping VNFs and virtual links to the physical resources of the NFVI. Otherwise, this algorithm may exhibit poor behav-ior and never finish its execution, thus compromising the reliability and performance of NSs (BOUTEN et al., 2016).
In this context, an NFV-MANO must provide tools to check NS-Reqs validity and inform customers of potential conflicts between policies, also known as Policy Analysis. In addition to the techniques for detecting conflicts between policies, another critical problem is the need for solutions that derive enforceable policies from higher-level goals or higher level Event-Condition-Action (ECA) rules. Policy Refinement is the process of transforming high-level policies, which are not directly executable in a management system (e.g., NFV-MANO), into directly enforceable, low-level policies (BANDARA et al.,
2004).
In most systems, policy refinement is done manually (ROCHAELI, 2009). This situation imposes the following problems. First, whenever the refinement process is required, the presence of a knowledge expert will be necessary. Second, refining policies manually for large and complex systems is a tedious and challenging task. In this context, the scale of changes can be massive, which can lead to improper specifications of enforceable policies due to human errors. Therefore, for NFV systems, we argue that it is necessary to perform this procedure in an automated way. The automated refinement process, which is based on expert knowledge, should reduce the gap between human intention and the NFV system behavior.
The policy refinement is a nontrivial process, and it remains a much-neglected research area (MACHADO et al., 2017). It has been severely dismissed due probably to its inherent complexity. In this context, a fully automated refinement process is still an open issue. Besides, to the best of our knowledge, no other work in the literature has provided an automated refinement scenario applied to NFV-MANO operations. In this thesis, we in-tend to deal with this problem. Therefore, we argue that an NFV-PBM has the following refinement requirements (based on (RIEKSTIN et al., 2016)):
• Requirement 1 (RT1): Support Goal-oriented refinement;
• Requirement 2 (RT2): Support detection and resolution of policy conflicts;
• Requirement 3 (RT3): Verification of the impact of administrative guidelines on the performance of the managed systems;
• Requirement 4 (RT4): Support runtime decision making in a policy-managed envi-ronment;
• Requirement 5 (RT5): Dynamicity regarding current or future system state, and topology changes;
• Requirement 6 (RT6): Orchestration capabilities.
As mentioned in the previous Section, NFV-MANO is responsible for both NSO and RO. Therefore, the creation of enforceable policies (ECA rules) for the composition of new services, such as performance and fault management, is a very complex work given a large number of available operations. Besides, the direct use of ECA rules is not enough to deal with dynamic environments, such as NFV, since this type of language is based on fixed policy structures that perform enforcement through pre-defined directives (VERMA et al., 2017). To solve this problem, we argue that it is necessary to define policies as goals and use goal-oriented refinement methodologies as the means to the ground of the policy refinement process (RT1). According to (HAN; LEI, 2012), the use of goals allows the specification of the desired states, not a sequence of actions. In this context, we can declare the high-level goals, such as Service Level Agreements (SLAs), and hence generate enforceable policies to govern NFV-MANO behavioral choices while satisfying the goals — besides, goal-oriented refinement assists to reduce both Capital Expenditures (CAPEX) and Operational Expenditures (OPEX).
1 inst oblig r e q u e s t B a c k u p { on i n s t a n t i a t i o n _ r e q u e s t ( vnfc ) 3 s u b j e c t vnfm t a r g e t nfvo 5 do r e s o u r c e _ r e q u e s t ( vnfc ) when vnfc . n s_i d = 1 3 1 4 1 5 7 } 9 inst oblig s e n d C o n f i g u r a t i o n B a c k u p { on s u c c e s s _ r e s o u r c e _ r e s p o n s e ( vnfc , v n f c B k p ) 11 s u b j e c t vnfm t a r g e t v n f c B k p 13 do p e r f o r m _ v n f c _ c o n f i g u r a t i o n ( vnfcBkp , vnfc . c o n f i g u r a t i o n ) } 15 inst oblig r e q u e s t S t a t e T r a n s f e r { 17 on s u c c e s s _ r e s o u r c e _ r e s p o n s e ( vnfc , v n f c B k p ) s u b j e c t vnfm 19 t a r g e t vnfc do r e q u e s t _ s t a t e _ t r a n s f e r () 21 }
Listing 1.1 – Enforceable policies.
For a better understanding, let us consider the following high-level goal applied for all VNF Components (VNFCs) of an NS with id “131415”: “VNFC Redundancy Configured”.
Such a goal implements a failure prevention technique that determines that the VNF Manager (VNFM) must create a backup for the VNFC and that this VNFC must separate the state information and store it in a Logical Unit (LU), which implements a Virtual Storage and has the capability of synchronizing the content automatically. In turn, a goal-oriented refinement procedure will receive this goal and translate it to the ECA rules shown in Listing 1.1, which can be enforced directly in NFV-MANO.
Regarding Requirement 2 (RT2), there is a need to add policy analysis to the refine-ment process. According to Craven et al. (CRAVEN et al., 2010), a refinement solution must ensure that the refined specification achieves the requirements and is consistent with system properties and limitations, as well as with existing policies. Therefore,
pol-icy analysis is a prerequisite for refinement. In NFV systems, we can identify two types
of policies: application-specific and management-specific. The former consists of domain-specific policies that can be set for both a single NS (NS-Pol ) and globally for all services (NFVI-Pol) such as network function precedence, location constraints, and resource us-age. The latter consists of the rules that will be generated by the refinement process and stored in NFV-PBM to govern system behavior.
In turn, Requirement 3 (RT3) states that we should use monitoring mechanisms to determine whether lower-level or enforceable policies meet the requirements of the orig-inal high-level goal, in the way the operator or tenants expect (BANDARA et al., 2004). Requirement 4 (RT4) establishes that we need to optimize the refinement procedure such that it is feasible to use it for runtime decision making in an NFV-PBM. In this con-text, we should adopt solutions that allow the creation of practical implementations for production environments.
Moreover, it is worth noting that the refinement process proceeds by incrementally decomposing abstract requirements into successively more concrete ones. In this sense, Requirement 5 (RT5) determines that there should be a way to ensure that each stage of decomposition is correct and consistent. Therefore, this procedure must be dynamic, i.e., it must take decisions considering the current or future state of the managed system, as well as the changes of topologies (BANDARA et al., 2004).
Finally, Requirement 6 (RT6) states that the refinement process must be able to choose the best capabilities considering the system situation, enabling automatic selection of appropriate goal decompositions and strategies when multiple solutions can be derived. For this, it could use different metrics such as the number of derived policies and the sum of weights (NAU; GHALLAB; TRAVERSO, 2004). Besides, it must support additional policy
information such as the parameter values to be used with the management operations, low-level events, and constraints. Such additional information focuses on avoiding conflicting capabilities that lead to failures. For example, two functions that put the same device to sleep.
have a significant impact on the improvement of PBMs applied to the management and orchestration of NFV environments. But the realization of such an approach needs to overcome the problems that make it possible and beneficial; that is, it must meet the above requirements. To achieve this, we base our work on the following premises:
1. To accomplish policy analysis, configurations and states of VNFs should be described using formal description languages (SHIN et al., 2017), with adequately defined, un-ambiguous, whose meaning is defined via formal semantics. One approach to address this problem is to move these policies’ structure to a semantic level (SHETH, 1999), by defining ontologies for this domain;
2. To accomplish automated policy refinement, we can use logic-based formalisms to support expressing domain-specific information required by refinement procedures such as (BANDARA et al., 2004): objects and their organization into domains, avail-able management operations and the effect they have on the managed objects, and policy rules. By using reasoning methods, formalisms enable to account for the effect of policies on system state and can be used directly for policy analysis. Furthermore, formalisms support Goal Regression, a logical analysis technique to generate a se-quence of actions to satisfy a specified end goal (POLLOCK, 1998).
Thus, based on the previous assumptions, we investigate the following hypotheses: • Hypothesis 1: Efficient policy analysis can be carried out through Description
Logic (DL) inconsistency verification when a DL semantic reasoner is relied upon; • Hypothesis 2: It is possible to create an efficient automated policy refinement
procedure for NFV-PBM systems that meet the above requirements by combining the expressivity of DL with the efficiency of HTN planning systems;
• Hypothesis 3: It is possible to use SDN and Software Data Plane (SDP) to verify the impact of lower-level or enforceable policies on the performance of the managed systems.
After establishing these hypotheses, six (6) main research questions (RQ) appear to be answered in the course of the work:
• RQ1: How to perform Goal-oriented Policy Refinement for NFV systems?
• RQ2: How to improve the refinement procedure such that it is feasible for runtime decision making in a policy-managed environment?
• RQ4: How to derive additional policy information such as the parameter values to be used with the management operations, low-level events, and constraints?
• RQ5: How to measure and analyze the impact of lower-level or enforceable policies on the performance of the NFV systems?
• RQ6: How to provide a dynamic policy refinement procedure for NFV systems?
1.4 OBJECTIVES
To prove or refute our hypotheses and answer the research questions defined in the previ-ous section, the general objective of this thesis is: to provide a functional solution for au-tomated policy refinement in policy-based NFV management and orchestration systems. Such a solution must support the following features: goal-oriented refinement; detection and resolution of policy conflicts; verification of the impact of administrative guidelines on the performance of the managed systems; runtime decision making in a policy-managed environment; dynamicity regarding current or future system state, and topology changes; and capabilities orchestration. However, to achieve this goal, we need to accomplish the following specific objectives (EO):
• EO1: Perform a bibliographic review regarding logic-based formalisms and au-tomated planning systems, which can be applied to solve policy analysis and refine-ment problems;
• EO2: Define a goal-based policy specification that can be used in goal-oriented refinement procedures (RQ1);
• EO3: Provide an efficient solution that uses logic-based formalism to support
Policy Analysis, that can detect and diagnose conflicts between application-specific
and management-specific policies by reasoning (RQ3);
• EO4: Provide an efficient solution that uses logic-based formalism to perform automated goal-oriented policy refinament that meets the requirements specified above (RQ1, RQ2, RQ4, RQ6);
• EO5: Create an agent that monitors the state of both computer and network re-sources and and enables an operator to analyse the impact of administrative guide-lines on the performance of the NFV systems (RQ5);
1.5 THESIS STATEMENT AND CONTRIBUTIONS
In this thesis, we tackle the problem of policy refinement in policy-based NFV manage-ment and orchestration systems. In this context, we propose the AuT omated POlicy
Refinement SysteM for NFV (ATOM), an automated solution for the policy
refine-ment process for Policy-Based Managerefine-ment Systems (PBM) in NFV scenarios. To achieve its goal, the ATOM comprises three (3) independent subsystems:
1. NSChecker: is a semantic verification system to find inconsistencies among poli-cies defined in NS-Req (NS-Pol) and global polipoli-cies previously created in the NFVI (NFVI-Pol), i.e, application-specific policies. NSChecker has three primary func-tions. First, it enables the operator or NFV-MANO to record both NFVI physical and virtual resources as well as their policies (NFVI-Pols), working as an NFVI Resources Repository (NFVI-RR). Second, it enables the NFV-MANO to record all instantiated NSs, working as an NFV Instances Repository (NFV-IR). Finally, once an NS-Req is received, NSChecker enables NFV-MANO to record policies extracted from NSD and perform the detection and diagnosis of conflicts between NS-Pols and NFVI-Pols. To achieve its objectives, NSChecker uses a semantic model (ontology), called Onto-NFV, to describe the NFVI, NSs, and associated policies;
2. NSPlanner: provides a goal-oriented policy refinement and semantic verification system. It has three primary functions. First, it enables the operator to record differ-ent types of alarms that will be used in the refinemdiffer-ent process. Second, NSPlanner enables NFV-MANO to record high-level goals extracted from NSD and perform a fully automated policy refinement, that derives enforceable policies (ECA rules) to govern NFV-MANO behavioral choices while satisfying the goals. Finally, NSPlan-ner performs policy analysis between management-specific policies, i.e., rules that will be generated by the refinement process and stored in NFV-PBM to govern system behavior;
3. Feedback Module: a monitoring system that aims to capture monitoring data from both the network and computer resources. Thus, the operator can measure and analyze the results and verify if the enforceable policies are fulfilling the high-level goals. If any inconsistency is detected, the operator can proceed by updating the inconsistencies, creating new alarms, for example.
It is worth mentioning that, for this work, we consider a specific type of NFV/SDN architecture, where an NFV system makes use of one or more SDN controllers to provide its functionalities, such as the orchestrations of the intra-NFVI-PoP and inter-NFVI-PoP connectivity between components of a given VNF, or various VNFs in a VNF Forwarding Graph (VNFFG) as well as connectivity to the Physical Network Functions (PNFs) (ETSI,
2014c;BONFIM; DIAS; FERNANDES, 2019). Therefore, we will refer only to NFV technology throughout the text, because we consider that SDN will only be a secondary technology necessary to meet our objectives.
Moreover, it is noteworthy that the implementation of an NFV-PBM is not part of the scope of this thesis. ATOM aims to assist and improve the operation of these solutions. An example of an NFV-PBM architecture can be found in (ETSI, 2017). Besides,
we only consider obligation policies in this thesis (described in Section 2.3). Finally, we consider that the refinement procedure (described in Section 2.4) is performed by the Policy Authorization Point (PAP) component (described in Section 2.3).
1.6 THESIS STATEMENT
The remainder of the thesis is organized as follows.
• Chapter 2 describes the main concepts related to this thesis such as
Software-Defined Networking (SDN), Network Function Virtualization (NFV), Policy-Based Management Systems (PBMs), Policy Refinement, Ontologies, and Automated Plan-ning;
• Chapter 3 introduces the ATOM and its components. This framework aims to integrate NSChecker and NSPlanner to provide a solution for the automated goal-oriented policy refinement for NFV-PBM systems;
• Chapter 4 describes the NSChecker architecture, the proposed ontology (Onto-NFV), and details how NSChecker uses Onto-NFV to perform conflict detection and diagnosis;
• Chapter 5 describes the NSPlanner architecture, the proposed ontology (Onto-Planner), and details how NSPlanner uses Onto-Planner to perform policy refine-ment and conflict detection and diagnosis;
• Chapter 6 describes related works looking into two different aspects including: ontologies for NFV modelling, formal methods for network service verification, and logical formalisms to provide policy refinement procedures;
2 BACKGROUND
This chapter describes the main concepts related to this thesis.
2.1 SOFTWARE-DEFINED NETWORKING
As mentioned in Chapter 1, SDN is considered as a key technology to achieve our goals. Therefore, we present more details about this technology
SDN is a new network paradigm that was designed to overcome the difficulty in de-veloping and testing new solutions and protocols in production environments, where the underlying code running in business switches and routers are proprietary and closed ( MCK-EOWN et al., 2008).
According to Kreutz et al. (2015) (KREUTZ et al., 2015), currently, both control and data planes are integrated into most commercial networking devices, which makes IP net-works challenging to manage. Due to this, operators need to configure network policies into each device individually, often using low-level commands that are specific to the manufac-turer. Further, automatic reconfiguration mechanisms, necessary for network adaptation during failures and load changes, are non-existent in today’s networks. Such issues reduce the flexibility for deploying new network services and management strategies, as well as hindering development and innovation.
Network Operating System (SDN Controllers) Network Abstractions Open Northbound API SDN App 1
Open Southbound API
SDN App 2
...
SDN App N[GLOBAL NETWORK VIEW]]
[FORWARDING DEVICES]] D A T A P LA N E C O N TR O L P LA N E
Figure 1 – SDN Reference Architecture (MCKEOWN et al., 2008;KREUTZ et al., 2015;ONF, 2015).
The main feature of the SDN paradigm is the separation of the control and data planes. It has definite advantages where network programmability is achieved through the centralization of the control plane in conjunction with the availability of open APIs, thus making easier the process of creating and deploying new network applications. SDN
provides simplification and flexibility in network policy enforcement, facilitating network configuration, and management (KREUTZ et al., 2015).
The control plane, represented by a software called the SDN Controller, is responsible for decisions on how to handle network traffic, assuming the role of the “brain” of the network. The SDN Controller can run on COTS platforms, separated from the network equipment. The data plane, represented by the network devices, is responsible for for-warding traffic according to a set of rules (KREUTZ et al., 2015). Such rules are created
and managed by the SDN Controller. The SDN controller has a global view of the net-work topology and has direct control over the data plane elements through a southbound protocol, such as OpenFlow (ONF, 2015) (described later).
Figure 1 shows the given three layers of an SDN architecture and the APIs responsible for the interaction between them. The SDN Northbound API is responsible for providing support for communication between the application layer and the control plane layer. It also includes support for SDN Applications, such as traffic engineering, routing, firewall, quality of service, etc. The Southbound API is responsible for the communication between the SDN Controllers and switches.
2.1.1 OpenFlow
The development of OpenFlow began in 2007, and its evolution has received contributions from both academia and industry. Designed originally by researchers at Stanford Univer-sity and the UniverUniver-sity of California at Berkeley, this standard has been maintained by the Open Networking Foundation (ONF) (KREUTZ et al., 2015).
The OpenFlow comprises three main elements, namely switches, controllers, and pro-tocols (Southbound API). The OpenFlow Switches are responsible for the data packet forwarding (i.e., data plane) according to the rules created and maintained by the Con-troller (ONF, 2015). Multiple Flow Tables stores these rules. The controller is the main component of OpenFlow. In architectural terms, the controller supports the network ap-plications, determining the rules to be stored and applied by switches. There are several OpenFlow controllers available, such as OpenDaylight, Floodlight, ONOS, Ryu, POX, and NOX.
A controller can use two types of interfaces to create OpenFlow rules on switches: the OpenFlow Protocol and the Open vSwitch Database (OVSDB) Management Protocol. Both interfaces are described below.
OpenFlow Protocol: Defined in OpenFlow Specifications (ONF, 2015), this protocol
uses a secure and encrypted channel (TCP/TLS) for performing the management of switches. It includes a set of messages for different situations: establishment and configuration of the management channel (e.g., Hello, Echo Request/Reply, Features Request/Reply, Set-Config), receiving (Packet-in) and redirecting (Packet-out) data
packets, and OpenFlow rules management (Flow-mod). The OpenFlow protocol can coordinate all OpenFlow-enabled switches;
OVSDB Management Protocol: Defined in RFC 7047 (PFAFF; DAVIE, 2013), this
protocol uses a set of operations available in Open vSwitch (programmatic exten-sion) to manage OpenFlow rules. Such operations allow insertion, updating, and deletion of forwarding rules directly into the Open vSwitch Database. As a con-sequence, the OVSDB Management Protocol is limited to use in virtual switches based on Open vSwitch (COMMUNITY, 2018).
2.1.2 SDN Controllers
Below, we present a brief description of all SDN controllers used in the implementations of NFV/SDN architectures. Such controllers have been used as NFVI, VIM, or VNF components.
OpenDaylight (ODL) (FOUNDATION, 2018): The ODL is a modular SDN
open-source platform maintained by The Linux Foundation1. Written in Java, the ODL
aims to accelerate the development of solutions for SDN and NFV in production environments. ODL offers plugins that support different SDN Southbound API, such as OpenFlow (1.0 and 1.3), LISP, NETCONF, and OVSDB;
Open Network Operating System (ONOS) (ONF, 2018): ONOS comprises an
open-source SDN Controller focused on the construction of NFV/SDN solutions. Like ODL, ONOS was developed in Java on top of the Apache Karaf OSGi container and provided the following features: i) a GUI for the view the network state, support different SDN Southbound API, such as OpenFlow, NETCONF, and OpenConfig; ii) northbound abstractions to simplify the creation of intent-based virtualized net-works; iii) high availability and scalability support (e.g., cluster of ONOS instances);
Floodlight (NETWORKS, 2018): Floodlight is a SDN Controller written in Java that
supports the following OpenFlow versions: 1.0, 1.1, 1.2, 1.3, and 1.4. It is Apache-licensed and supported by engineers and developers from Big Switch Networks. In addition to OpenFlow controller, Floodlight provides a set of internal SDN applica-tions (e.g., firewall and load balancing) and a REST API for development of external applications;
Ryu (NTT, 2018): Ryu is an open-source framework (Apache 2.0 licensed) created by
NTT and written in Python. Ryu supports several southbound interfaces, such as OpenFlow, OF-config, and NETCONF. Regarding OpenFlow, Ryu supports the fol-lowing versions: 1.0, 1.2, 1.3, 1.4, and 1.5. A REST API is available to be used for
external SDN applications. Currently, Ryu is fully integrated into Neutron (Open-Stack Networking Service);
POX (NOXRepo.org, 2018): Developed at Stanford University, POX was one of the
first open-source developed SDN controllers. Written in Python, POX only supports OpenFlow version 1.0. It is currently a discontinued project.
2.1.3 Programmable Data Planes
Data plane programmability has attracted attention from both academia and industry. For example, there are several discussions within Open Networking Foundation (ONF) geared toward the definition of programmable switches already in the OpenFlow version 1.6. This technology is an evolution of the SDN paradigm. It aims to solve some of the traditional OpenFlow limitations. For instance, solutions based on OpenFlow are limited to the protocols supported by the technology as well as the lack of flexibility in the implementation of the actions for packet processing such as complex monitoring functions (e.g., sketch-based algorithms). The programmable data plane goes beyond the capability of an OpenFlow-enabled switch by providing flexibility to deploy new network protocols and complex in-switch packet processing algorithms. To this end, programmable switches allow an operator to define which packet headers should be parsed and manipulated in the forwarding tables and to introduce new processing actions in the operation (BOSSHART et al., 2014). Pioneering research in this field has focused on the following key technical aspects:
• Identification of new programmable switch architectures, e.g., SDPA (ZHU et al., 2015), FAST (MOSHREF et al., 2014), and OpenState (BIANCHI et al., 2014).
• High-level programming languages and compilers which could exploit programmable data planes. Examples: P4 (BOSSHART et al., 2014), Domino (SIVARAMAN et al., 2016), Stateful NetKAT (MCCLURG et al., 2016), and SNAP (ARASHLOO et al., 2016). Domain-specific programming languages, such as P4 (BOSSHART et al., 2014), have
been proposed to specify the packet processing logic of programmable data plane devices (and their ASICs) via high-level architecture-independent abstractions. P4 enables the development of new customized protocols that can be used to improve data forwarding and the overall operation of network devices. For this, it allows a developer to implement its actions using if-else clauses, algebraic and boolean expressions, and different types of counters and hash functions, allowing the calculation of in-switch high-level features and the creation of customizable traffic analysis mechanisms.
2.2 NETWORK FUNCTION VIRTUALIZATION
NFV is transforming the computer and communication networks industry. Rather than dealing with proprietary hardware equipment, which includes a limited set of specific network applications, NFV allows users to transfer network functions from specific to COTS hardware using virtualization technologies (ETSI, 2012). These network functions
are then called VNFs and perform different network operations: Firewall, Network Address Translation (NAT), Deep Packet Inspection (DPI), Load Balancing, among others.
NFV-MANO
NFVI Hardware Resources NFV Orchestrator (NFVO) VNF Manager (VNFM) Virtualized Infrastructure Manager (VIM) OSS/BSS EM 1 VNF 1 Computing Hardware EM 2 VNF 2 EM 3 VNF 3 Storage Hardware Network Hardware Virtualization Layer Virtual Resources Virtual Computing Virtual Storage Virtual Network NFV Service VNF Catalogue NFV Instance NFVI ResourceMain NFV Reference Points Other Reference Points Execution Reference Points
Vi-Vnfm Or-Vi Nf-Vi Ve-Vnfm-vnf Ve-Vnfm-em Or-Vnfm Os-Ma-Nfvo Vn-Nf
Figure 2 – NFV Architecture (ETSI, 2014a).
NFV aims at creating NSs that interconnect one or more VNFs to support the creation and deployment of end-to-end network services (SZABÓ et al., 2015). Some benefits of deploying network services as virtual functions are (ETSI, 2012):
• Flexibility in the allocation of network functions in general-purpose hardware; • Rapid implementation and deployment of new network services;
• Support of multiple versions of service and multi-tenancy scenarios; • Reduction in CAPEX costs by managing energy usage efficiently;
• Automation of the operational processes, thus improving efficiency and reducing OPEX costs.
From 2012, the European Telecommunications Standards Institute (ETSI) has led the standardization process for NFV technology through the NFV Industry Specification
Group (NFV ISG). The NFV ISG has already published tens of specifications documents, such as requirements, use cases, terminologies, proofs of concept, and the like (ETSI, 2014a). These specifications allow researchers and engineers to have a clear picture of the elements of a particular NFV infrastructure.
Figure 2 illustrates its high-level architecture, which comprises three (3) main func-tional blocks: VNF, NFVI, and NFV-MANO.
VNF is the virtualization of a specific network function, which should operate inde-pendently of the others. It may run on one or more virtual machines. A particular VNF can also be divided into several sub-functions called VNFCs, where there is one Virtual Machine (VM) implementing each VNFC. Elemental Management Systemss (EMSs) can be used for VNF monitoring and controlling.
On the other hand, NFVI comprises all hardware and software required to deploy, operate, and monitor VNFs. To this end, NFVI has a virtualization layer necessary for abstracting the hardware resources (processing, storage, and network connectivity). It ensures the independence of the VNF software from physical resources. The virtualization layer is usually composed of the server (e.g., Xen (FOUNDATION, 2016), KVM (PROJECT,
2016), VMware, etc.) and the network (e.g., VXLANs, NVGRE, OpenFlow(ONF, 2015), etc.) hypervisors. Finally, NFV-MANO performs both NSO and RO. Such functionalities include the following non-exhaustive list of operations (ETSI, 2014b):
• VNF and NS LCM; • VNF and NS scaling;
• Resource orchestration and management in multi-domain scenarios; • Access control; and
• Performance and fault management.
To this end, NFV-MANO comprises three components.
• The Virtualized Infrastructure Manager (VIM), which manages and controls the interaction of VNFs with physical resources under its control (e.g., allocation, deal-location, and inventory);
• The VNFM, which is responsible for managing the VNF life-cycle (e.g., initialization, suspension, and termination); and
• The NFV Orchestrator (NFVO), which is responsible for realizing NS on NFVI. It also performs monitoring operations of the NFVI as a way to collect information for operations and performance management.
Another component to be considered as part of the NFV framework is the Operations Support Systems and Business Support Systems (OSS/BSS). This element comprises the legacy management systems and assists NFV-MANO in the execution of network policies, either automatically or manually. Finally, other concepts must be defined to clarify the description of NFV, by ETSI terminology (ETSI, 2014d).
• NFVI Point of Presence (NFVI-PoP): defines a location for network function de-ployments as one or many VNFs;
• NFV Infrastructure Node (NFVI-Node): a physical device that provides functions necessary for running VNFs. An NFVI-Node is usually a general-purpose server; • Virtual Link (VL): a set of connection points that can interconnect two or more
entities (VNFCs or VNFs). A virtual network supports VL;
• VNFFG: is a graph formed by network functions connected by VLs, where at least one node is a VNF. A VNFFG allows you to describe the type of data flow that will go through these network functions;
• NFV-IR: stores all data related to VNF and NS instances. It assists the NFVO in operations of VNF and NS lifecycle management operations; and
• NFVI-RR: stores all data related to available, reserved, or allocated NFVI resources. It assists the NFVO in operations related to resource orchestration.
2.3 POLICY-BASED MANAGEMENT SYSTEMS
A policy can be defined as a goal or set of rules of an organization to achieve its objectives (MOFFETT; SLOMAN, 1994; WALDBUSSER et al., 2001). A policy expresses and enforces the desired behavior of a system and its components. Strassner et al. (STRASSNER, 2003) divides policies into two types:
• Obligation or management policy: a goal or action that states what be done in the system in the present or future, giver a certain condition or event; and
• Authorization or access control policy: a set of rules the restrict the system access, i.e., define what is allowed or not.
Furthermore, this classification can be extended with different levels of abstraction. Nowadays, it is generally accepted that there are two main levels of abstraction (KEPHART; WALSH, 2004): low- and high-level policies. Low-level polices consist of the domain- or
device-related actions, i.e., enforceable policies that can be assigned to and operated by agents. Such policies often follow the following paradigm: Event-Condition-Action
ON (Event) IF (Condition) THEN (Action)
The “Event” part consists of any system event under monitoring, such as an alarm notification. Its occurrence specifies that the “Action” (performs system state transition) should be triggered if the “Condition” (predicate expression including system parameters) is satisfied. Several policy languages allow formulating policies as ECA rules, such as Policy Description Language (PDL) (LOBO; BHATIA; NAQVI, 1999) and Ponder (DAMIANOU et al., 2001).
On the other hand, level policies are represented by Goals that defines high-level requirements such as enterprise’s business objectives or SLAs, which are not directly executable in a management system (HAN; LEI, 2012). Goals are more user-friendly than ECA rules. For example, a Goal policy can take the form of “Response time of Gold Class should be less than 100 ms”. According to Han et al. (HAN; LEI, 2012), the use of goals allows the specification of the desired states, not a sequence of actions. This brings the following advantages: reduction of the complexity of management tasks; and less manual countermeasures and errors. However, high-level policies must be refined into low-level policies for practical implementation (described in Section 2.4). We tackle this problem in this thesis. Policy-Driven Management Policy Decision Point (PDP) Policy Enforcement Point (PEP) Event/Request Response Event/Request Policy Repository (PR) Retrieve Policy Authorization Point (PAP) Manage
Figure 3 – Policy-driven management architecture.
Upon available, the low-level policies should be stored and enforced by a Policy-based Management (PBM) system. In a PBM system, an operator specifies goals and constraints in the form of rules to govern the behavior of the system (SLOMAN, 1994). For this, a PBM enables an operator to create low-level rules and, when an event occurs, these policies are accessed and evaluated automatically. Some of the benefits are: no need for manual intervention, automated analysis, and verification based on a formal foundation; and dynamic inspection and adaption at runtime, without demanding changes in the underlying implementation. PBM solutions have been applied in different scenarios, such as computer networks based Network Management) and cloud computing (Policy-based Cloud Management) (HAN; LEI, 2012;MACHADO et al., 2017).
The IETF (MOORE et al., 2001) defines a typical PBM architecture, as illustrated in Figure 3. It comprises three components: Policy Repository (PR), Policy Decision Point (PDP), and Policy Enforcement Point (PEP). Outside this architecture, there is still the PAP that provides a user-friendly interface to formulate, modify, analyze, and verify policies. In this thesis, we consider that this component performs the refinement procedure (described in Section 2.4). In this context, once generated by PAP, the low-level policies are stored in the PR. In parallel, the PDP is continuously monitoring the system. Once a specific event occurs, the PDP queries the PR for applicable policies. After that, the PDP assesses in which of these policies the conditions are met and selects them to the PEP. Finally, the PEP will enforce each of the corresponding actions from the selected policies.
PBM systems can be used to enforce NFV-MANO functions as a way to deal with the increased complexity. According to ETSI (ETSI, 2014b), PBM systems are the key enablers to provide flexibility and adaptability in MANO systems. Assisted by policies, NFV-MANO functions can be provided in a automatic fashion aiming to meet the changing requirements of NSO and RO. An NFV-PBM system refers to the management of rules governing the behavior of NFV-MANO functions.
However, it is noteworthy that the implementation of an NFV-PBM is not part of the scope of this thesis. ATOM aims to assist and improve the operation of these solutions. An example of an NFV-PBM architecture can be found in (ETSI, 2017).
2.4 POLICY REFINEMENT
Policy Refinement is the process of transforming high-level policies, which are not di-rectly executable in a management system (e.g., NFV-MANO), into didi-rectly enforceable, low-level policies (BANDARA et al., 2004). A policy refinement process has the following
objectives (MOFFETT; SLOMAN, 1994):
• Determine the resources that are needed to satisfy the requirements of the policy; • Translate high-level policies into operational policies that the system can enforce; • Verify that the lower level policies meet the requirements specified by the high-level
policy.
For a better understanding, let us consider an analogy between the policy refinement process and driving activity, as shown in Figure 4. In this scenario, the driver operates the car (managed system) using the following mechanisms: steering wheel, gear shaft, and brake pedals (management mechanisms). The driver aims to turn the car to the left (high-level policy or goal). To achieve this goal, the driver has to refine it (in his mind) to the following set of sub-tasks (low-level and enforceable policies): rotate the steering 130 degrees to the left, move into second gear and decelerate to 30 kph.
Figure 4 – Policy refinement process: an analogy (ROCHAELI, 2009).
Bandara et al (2003) (BANDARA; LUPU; RUSSO, 2003) proposes the following formal definition for policy refinement: “if there exists a set of policies 𝑃 𝑟𝑠 : 𝑝1, 𝑝2, ..𝑝𝑛, such that the enforcement of a combination of these policies results in a system behaving identically to a system that is enforcing some base policy Pb, it can be said that 𝑃 𝑟𝑠 is a refinement of 𝑃 𝑏. The set of policies 𝑃 𝑟𝑠 : 𝑝1, 𝑝2, ..𝑝𝑛 is referred to as the refined policy set”. Additionally, they have defined three properties that must be satisfied by a policy refinement process: correctness, consistency, and minimality. A refinement is correct if the conjunction of all the elements of a refined policy set is a refinement of the base policy. On the other hand, refinement is consistent if there are no conflicts (Policy Analysis) between the policies in the refined policy set. Finally, a refinement is minimal if it is correct, and if removing any policy from the refined policy set causes the refinement to be incorrect.
In most systems, including NFV, policy refinement is done manually (ROCHAELI, 2009; ETSI, 2020; FOKUS, 2020). This situation imposes the following problems. First, whenever the refinement process is required, the presence of a knowledge expert will be necessary. Second, refining policies manually for large and complex systems is a tedious and challenging task. In this context, the scale of changes can be massive, which can lead to improper specifications of enforceable policies due to human errors. Therefore, it is necessary to perform this procedure in an automated way to reduce the gap between human intention and the managed system behavior.
To accomplish automated policy refinement, different logic-based formalisms have been proposed in the literature. For instance, such formalisms support expressing domain-specific information required by refinement procedures such as (BANDARA et al., 2004): objects and their organization into domains, available management operations and the effect they have on the managed objects, and policy rules. By using reasoning methods, formalisms enable to account for the impact of policies on system state and can be used
