UNIVERSIDADE FEDERAL DE PERNAMBUCO PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CENTRO DE INFORMÁTICA
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE REDES
RECIFE 2016
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE REDES
Dissertação apresentada 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 mestre em Ciência da Computação.
Prof. Dr. Carlos André Guimarães Ferraz – Orientador
RECIFE 2016
V285c Vanz, Giorge.
Comparação de estratégias para gerência de configuração de redes / Giorge Vanz – 2016.
122f.: quad., tab.
Orientador: Carlos André Guimarães Ferraz.
Dissertação (Mestrado profissional) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2016.
Inclui referências e apêndices.
1. Redes de computadores. 2. Gerência de configuração. I. Ferraz, Carlos André Guimarães (Orientador). II. Titulo.
GIORGE VANZ
COMPARAÇÃO DE ESTRATÉGIAS PARA GERÊNCIA DE CONFIGURAÇÃO DE REDES
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para obtenção do grau de Mestre, à banca examinadora formada por:
Aprovado em: 18/11/2016
_________________________________________________ Presidente: Prof. Dr. Daniel Carvalho da Cunha, UFPE
_________________________________________________ Membro: Profa. Dra. Juliana Regueira Basto Diniz, UFRPE
_________________________________________________ Membro: Prof. Dr. Carlos André Guimarães Ferraz, Orientador, UFPE
AGRADECIMENTOS
Agradeço primeiramente ao meu poder superior, Deus, que me deu força e coragem para completar com ânimo este valioso estágio da minha vida.
Ao meu orientador Prof. Dr. Carlos André Guimarães Ferraz, que me aceitou como orientando após uma breve conversa mesmo sabendo que eu estaria geograficamente distante nas próximas reuniões. Pela confiança depositada no meu trabalho e por compartilhar o seu conhecimento e vivências não somente como professor, mas como pessoa. Seus ensinamentos foram fundamentais para a construção desse trabalho.
Ao meu Prof. Dr. Alexandre Savaris por estar ao meu lado, desde o início da minha vida acadêmica, sempre disposto a oferecer todo o apoio necessário para que eu pudesse conquistar todos os meus objetivos.
Aos meus pais Ademar Jorge Vanz e Rita Pagno Vanz, por terem abdicado e me blindado de muitas coisas, priorizando o que era importante para mim, fazendo com que eu conseguisse realizar o meu sonho. Serei grato pelo resto da minha vida a ambos.
Ao Instituto Federal Catarinense (IFC) pelo apoio financeiro para o cumprimento de todas as etapas do mestrado.
À empresa Teltec Solutions pelo apoio tecnológico no fornecimento do equipamento para realização dos testes.
Conceda-nos, Senhor, a serenidade necessária para aceitar as coisas que não podemos modificar. Coragem para modificar aquelas que podemos, e sabedoria para distinguir umas das outras.
RESUMO
Atualmente as redes de computadores podem ser encontradas em diversos ambientes, apresentando escalas de crescimento que comumente não seguem um padrão bem definido, interligando pessoas, equipamentos e dados. Essas redes integram cenários acadêmicos ou empresariais, apoiam backbones onde as grandes operadoras estão em constante busca por desempenho aliado à alta disponibilidade, e estão presentes também nas operadoras de telecomunicações regionais de pequeno porte, que almejam propiciar a custos acessíveis uma infraestrutura de acesso à internet com qualidade equivalente à última milha. Diante desses cenários, na maioria das vezes compostos por equipamentos de interconexão heterogêneos (por exemplo, roteadores e switches), um grande desafio da gerência de configuração de redes é encontrar ferramentas computacionais que apoiem o trabalho do administrador de redes. O presente trabalho compara estratégias com o propósito de superar os problemas da heterogeneidade de hardware, estabelecendo o mapeamento das tarefas de gerência de configuração com a utilização das arquiteturas Service Oriented Architecture – Arquitetura Orientada a Serviço (SOA) e Resource Oriented Architecture – Arquitetura Orientada a Recurso (ROA) por meio de Web Services – Serviços Web (WS), do protocolo Network
Configuration – Configuração de Rede (NETCONF) e também, através da Command Line Interface – Interface de Linha de Comando (CLI) disponível no dispositivo gerenciado.
Valendo-se das estratégias estabelecidas, o trabalho procura estabelecer a melhor abordagem no desenvolvimento de ferramentas direcionadas à configuração de equipamentos heterogêneos, reduzindo o tempo de resposta e a quantidade de tráfego gerado durante a alteração de topologias. A experimentação proposta nos mostrou que os melhores resultados são obtidos por meio de uma abordagem baseada nas estratégias CLI/NETCONF, quando as ferramentas desenvolvidas são executadas no mesmo segmento da rede de gerência dos equipamentos de interconexão. Por sua vez, se considerarmos uma solução distribuída, acessível através da internet com base em dispositivos cliente heterogêneos (por exemplo,
desktops, notebooks e smartphones), a arquitetura ROA é considerada a melhor escolha.
Palavras-chave: Redes de Computadores. Gerência de Configuração. Arquiteturas Orientadas a Serviços – SOA e Recursos – ROA. NETCONF. CLI.
ABSTRACT
Nowadays, computer networks can be found in a number of environments, presenting growing scales that usually do not follow a well-established pattern, and encompass links between people, equipments and data. These networks integrate academic and business backgrounds, support backbone networks where companies are constantly looking for performance combined with high availability, and are present in small-sized regional telecommunication companies, which aim to provide, with affordable costs, an infrastructure for access to the internet with similar quality to the last mile. Facing these environments, usually composed by heterogeneous interconnection equipments (e.g. routers and switches), a big challenge for the management of network configuration is to find computational tools to support the work of the network manager. This work compares strategies established to overcome problems from hardware heterogeneity, mapping tasks for configuration management using Service Oriented Architecture (SOA) and Resource Oriented Architecture (ROA) through Web Services (WS), the Network Configuration protocol (NETCONF), and the Command Line Interface (CLI) available on the managed device. Using the established strategies, the work aims to identify the best approach for the development of tools directed to the management of heterogeneous equipments, reducing the response time and the amount of data exchanged during topology changes. The performed experiments achieved the best results using an approach based on CLI/NETCONF, when the developed computational tools are executed in the same segment of the management network used by the interconnection equipments. On the other hand, if a distributed, internet-accessible solution based on heterogeneous client devices (e.g. desktop computers, notebooks, smartphones) is considered, a ROA-based approach is the best choice.
Keywords: Computer Networks. Configuration Management. Service Oriented Architecture – SOA and Resources – ROA. NETCONF. CLI.
LISTA DE ILUSTRAÇÕES
Figura 1 – Síntese da divisão funcional do modelo FCAPS. ... 20
Figura 2 – Formas de conexão para acesso à CLI do dispositivo gerenciado. ... 23
Figura 3 – Variabilidade semântica em uma topologia VRRP. ... 24
Figura 4 – Arquitetura em camadas do protocolo NETCONF. ... 28
Figura 5 – Estrutura de um serviço na arquitetura SOA... 33
Figura 6 – Paradigma e componentes da arquitetura SOA. ... 36
Figura 7 – Elementos e condições de uma aplicação REST... 46
Figura 8 – Definição da arquitetura do sistema. ... 52
Figura 9 – Diagrama de classes da API CLI. ... 61
Figura 10 – Diagrama de classes da API NETCONF. ... 65
Figura 11 – Diagrama de sequência das aplicações REST e SOAP. ... 71
Figura 12 – Diagrama de sequência da aplicação CLI. ... 74
Figura 13 – Diagrama de sequência da aplicação NETCONF. ... 76
LISTA DE QUADROS
Quadro 1 – Levantamento das tarefas de gerência de configuração de redes. ... 54
Quadro 2 – Comandos CLI responsáveis pelas tarefas 1, 2 e 12. ... 55
Quadro 3 – Comandos NETCONF responsáveis pelas tarefas 1, 2 e 12... 55
Quadro 4 – Mapeamento das tarefas dentro de cada estratégia. ... 57
Quadro 5 – Definição do formato de retorno do resultado para cada estratégia. ... 58
Quadro 6 – Mapeamento da configuração de interface de rede através da API CLI. ... 59
Quadro 7 – Conexão com o dispositivo de rede através da API CLI. ... 60
Quadro 8 – Método responsável pela execução dos comandos através da API CLI... 60
Quadro 9 – Fábrica de conexões da API NETCONF. ... 62
Quadro 10 – Fábrica de sessões da API NETCONF. ... 63
Quadro 11 – Método responsável pela execução de comandos através da API NETCONF. .. 63
Quadro 12 – Declaração das constantes utilizadas pela API NETCONF. ... 64
Quadro 13 – Tarefas de gerência de configuração transformadas em web services REST. ... 66
Quadro 14 – WS REST que retorna as configurações de um dispositivo de rede. ... 67
Quadro 15 – WS REST que configura uma interface de rede. ... 67
Quadro 16 – WS REST que exclui uma entrada na tabela de roteamento estático. ... 68
Quadro 17 – Tarefas de gerência de configuração transformadas em web services SOAP. .... 69
Quadro 18 – WS SOAP que retorna as configurações de um dispositivo de rede. ... 70
Quadro 19 – WS SOAP que configura uma interface de rede. ... 70
Quadro 20 – Trecho de código da aplicação CLI. ... 73
Quadro 21 – Trecho de código da aplicação NETCONF. ... 75
Quadro 22 – Comandos utilizados para configuração do roteador Cisco 2921. ... 79
Quadro 23 – VLANs utilizada no cenário de testes. ... 80
Quadro 24 – Direções e filtros aplicados para captura de pacotes. ... 84
Quadro 25 – Organização e visualização dos dados coletados ... 86
Quadro 26 – Mensagem XML enviada pelo dispositivo no momento da conexão. ... 99
Quadro 27 – Mensagem XML enviada pelo cliente para concretizar a conexão. ... 99
Quadro 28 – Mensagem XML enviada ao dispositivo de rede solicitando a desconexão. .... 100
Quadro 29 – Mensagem XML enviada pelo dispositivo confirmando a desconexão. ... 100
Quadro 30 – Comandos CLI para as tarefas de gerência de configuração. ... 118
Quadro 31 – Comandos NETCONF para as tarefas de gerência de configuração. ... 119
Quadro 32 – Tarefas de gerência de configuração transformadas em web services REST. ... 121
LISTA DE TABELAS
Tabela 1 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa 1. ... 87 Tabela 2 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 1. ... 88 Tabela 3 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 2 e 3. ... 89 Tabela 4 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 2 e 3. ... 89 Tabela 5 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 4, 5, 6 e 7. ... 90 Tabela 6 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 4, 5, 6 e 7. ... 90 Tabela 7 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa 8. ... 91 Tabela 8 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 8. ... 91 Tabela 9 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 9 e 10. ... 92 Tabela 10 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 9 e 10. ... 93 Tabela 11 – Valores médios da quantidade de bytes trafegados durante a execução da tarefa 11. ... 93 Tabela 12 – Valores médios dos tempos de resposta obtidos para a realização da tarefa 11. .. 94 Tabela 13 – Valores médios da quantidade de bytes trafegados durante a execução das tarefas 12, 13 e 14. ... 94 Tabela 14 – Valores médios dos tempos de resposta obtidos para a realização das tarefas 12, 13 e 14. ... 95 Tabela 15 – Agrupamento dos valores médios da quantidade de bytes trafegados de todas as tarefas... 96 Tabela 16 – Valores médios da quantidade de bytes trafegados durante a conexão utilizando CLI e NETCONF. ... 98 Tabela 17 – Valores médios da quantidade de bytes trafegados durante a desconexão
utilizando CLI e NETCONF. ... 100 Tabela 18 – Soma dos valores médios da quantidade de bytes trafegados na conexão e
desconexão para CLI e NETCONF. ... 101 Tabela 19 – Agrupamento dos valores médios dos tempos de resposta obtidos para todas as tarefas... 102
LISTA DE SIGLAS E ABREVIATURAS
ACL Access Control List – Lista de Controle de Acesso
API Application Programming Interface – Interface de Programação de Aplicativos
BEEP Blocks Extensible Exchange Protocol
CLI Command Line Interface – Interface de Linha de Comando
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit – Unidade de Processamento Central
CRUD Create, Read, Update and Delete – Criar, Ler, Atualizar e Deletar
DCOM Distributed Component Object Model
DMZ Demilitarized Zone – Zona Desmilitarizada
DTD Document Type Definition – Definição de Tipo de Documento
FCAPS Fault, Configuration, Accounting, Performance, Security – Falha,
Configuração, Contabilidade, Desempenho, Segurança
FTP File Transfer Protocol – Protocolo de Transferência de Arquivo
GUI Graphical User Interface – Interface Gráfica do Usuário
HP Hewlett-Packard
HTTP Hypertext Transfer Protocol – Protocolo de Transferência de Hipertexto
HTTPS Hyper Text Transfer Protocol Secure – Protocolo Seguro de Transferência de
Hipertexto ID Identificador
IDE Integrated Development Environment – Ambiente Integrado de
Desenvolvimento
IETF Internet Engineering Task Force
IFC Instituto Federal Catarinense
IP Internet Protocol – Protocolo de Internet
IPv6 Internet Protocol Version 6 – Protocolo de Internet Versão 6
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
ITU-T International Telecommunication Union Telecommunication Standardization Sector
JDK Java Development Kit
JRE Java Runtime Environment
JSON JavaScript Object Notation – Notação de Objeto Javascript
LMAP Large-Scale Measurement of Broadband Performance
MIB Management Information Base
MTU Maximum Transmission Unit – Unidade Máxima de Transmissão
NETCONF Network Configuration – Configuração de Rede
NOC Network Operations Center – Centro de Operações de Rede
NOS Network Operating System – Sistema Operacional de Rede
NVEs Network Virtualization Environments – Ambientes de Virtualização de Rede
PCAP Packet Capture
QoS Quality of Service – Qualidade de Serviço
REST Representational State Transfer – Transferência de Estado Representacional
RFC Request for Comments
ROA Resource Oriented Architecture – Arquitetura Orientada a Recurso
RPC Remote Procedure Call – Chamada de Procedimento Remoto
SDN Software Defined Networking – Redes Definidas por Software
SFP Small Form-Factor Pluggable
SLA Service Level Agreement – Acordo de Nível de Serviço
SMI Structure of Management Information – Gerenciamento da Estrutura de
SMING Structure of Management Information, Next Generation – Próxima Geração
para Gerenciamento da Estrutura de Informação
SMTP Simple Mail Transfer Protocol – Protocolo de Transferência de Correio Simples
SOA Service Oriented Architecture – Arquitetura Orientada a Serviço
SOAP Simple Object Access Protocol – Protocolo Simples de Acesso a Objeto
SSH Secure Shell – Shell Seguro
SSH-2 Secure Shell Version 2 – Shell Seguro Versão 2
STI Setor de Tecnologia da Informação
TCP Transmission Control Protocol – Protocolo de Controle de Transmissão
TFTP Trivial File Transfer Protocol
TI Tecnologia da Informação
TLS Transport Layer Security – Segurança da Camada de Transporte
UDDI Universal Description, Discovery and Integration
UDP User Datagram Protocol
VLAN Virtual Lan – Rede Local Virtual
VRRP Virtual Router Redundancy Protocol – Protocolo de Redundância Virtual de
Roteador
URI Uniform Resource Identifier – Identificador Uniforme de Recurso
VNs Virtual Networks – Redes Virtuais
VRs Virtual Routers – Roteadores Virtuais
VTY Virtual Teletype
VPN Virtual Private Network – Rede Virtual Privada
WADL Web Application Description Language – Linguagem de Descrição de
Aplicação Web
WS Web Services – Serviços Web
WSDL Web Services Description Language – Linguagem de Descrição de Serviços Web
W3C World Wide Web Consortium
XHTML eXtensible Hypertext Markup Language
XML Extensible Markup Language – Linguagem de Marcação Extensível
XPath XML Path Language
SUMÁRIO 1 INTRODUÇÃO ... 10 1.1 MOTIVAÇÃO E JUSTIFICATIVA ... 10 1.2 OBJETIVOS DA PESQUISA ... 12 1.2.1 Objetivo Geral ... 12 1.2.2 Objetivos Específicos ... 12 1.3 ESTRUTURA DO TRABALHO... 13 2 REVISÃO DA LITERATURA ... 15 2.1 GERÊNCIA DE REDES ... 15 2.1.1 Modelo FCAPS ... 16
2.1.2 Artefatos para Gerência de Configuração ... 20
2.1.2.1 Simple Network Management Protocol (SNMP) ... 21
2.1.2.2 Command Line Interface (CLI) ... 22
2.1.2.3 Network Configuration (NETCONF) ... 24
2.2 WEB SERVICES ... 30 2.3 SOA ... 32 2.3.1 Componentes e Paradigma ... 34 2.3.2 Características da Arquitetura ... 36 2.3.3 Tecnologias Relacionadas ... 38 2.4 ROA ... 39
2.4.1 REST – A Base da Arquitetura ... 40
2.4.2 Condições Norteadoras de REST ... 42
2.5 TRABALHOS RELACIONADOS ... 46
2.5.1 SOA e SOAP ... 46
2.5.2 ROA e REST ... 47
3 COMPARAÇÃO DAS ESTRATÉGIAS PARA GERÊNCIA DE
CONFIGURAÇÃO DE REDES ... 51
3.1 DEFINIÇÃO DA ARQUITETURA DO SISTEMA ... 51
3.2 DEFINIÇÃO DAS TAREFAS DE GERÊNCIA DE CONFIGURAÇÃO ... 54
3.3 COMPOSIÇÃO DAS ESTRATÉGIAS ... 56
3.3.1 Mapeamento e Desenvolvimento ... 56
3.3.1.1 APIs: implementações intermediárias ... 58
3.3.1.2 Estratégia baseada em web services REST e SOAP ... 65
3.3.1.3 Estratégia baseada em CLI e NETCONF ... 72
3.4 CENÁRIO DE TESTES ... 77
3.4.1 Equipamentos utilizados ... 78
3.4.2 Descrição do cenário ... 80
3.4.3 Definição das métricas e descrição das ferramentas de medição... 81
3.4.4 Descrição da coleta ... 83
4 ANÁLISE DOS RESULTADOS ... 86
4.1 ORGANIZAÇÃO E VISUALIZAÇÃO DOS DADOS COLETADOS ... 86
4.2 COMPARAÇÃO DAS ESTRATÉGIAS ... 87
4.3 DISCUSSÕES ... 95 5 CONCLUSÕES ... 105 5.1 CONTRIBUIÇÕES DO TRABALHO ... 106 5.2 DIFICULDADES E LIMITAÇÕES ... 107 5.3 TRABALHOS FUTUROS ... 109 REFERÊNCIAS ... 111
APÊNDICE A – LISTAGEM DOS COMANDOS CLI ... 118
APÊNDICE B – LISTAGEM DOS COMANDOS NETCONF ... 119
APÊNDICE C – TAREFAS MAPEADAS EM WS REST ... 121
1 INTRODUÇÃO
Neste capítulo são apresentadas as motivações e justificativas que nortearam a realização deste trabalho. Também são descritos os objetivos geral e específicos seguidos de uma breve exposição das condições necessárias para o cumprimento dos mesmos. Ao final, o capítulo é encerrado com uma seção que expõe a estrutura utilizada para construção deste trabalho.
1.1 MOTIVAÇÃO E JUSTIFICATIVA
À medida que os recursos de rede se tornam indispensáveis, que as aplicações dos usuários requerem um tempo máximo de resposta a requisições, e que a alta confiabilidade e disponibilidade se apresentam como fatores críticos ao bom andamento dos trabalhos dentro das instituições acadêmicas ou empresarias (seja no acesso a sistemas disponíveis em outros
sites, ou mesmo no suporte a projetos de redes de experimentação), o correto gerenciamento
dos equipamentos dispostos nestes ambientes torna-se uma tarefa essencial.
Para auxiliar a administração destes cenários, Hedstrom et al. (2015) propõe que as tarefas de gerência neste ambiente incidam em duas frentes: na operação, monitorando o ambiente como um todo durante o seu funcionamento ou falha, e na manutenção, atuando sobre a configuração de equipamentos mediante a percepção de um comportamento anômalo previamente identificado pela operação, na instalação e também na alteração de topologias de rede.
Subdividindo ainda mais o gerenciamento de uma rede de computadores e com o objetivo de fornecer artefatos específicos para determinadas ações, a International
Telecommunication Union Telecommunication Standardization Sector (ITU-T) e a International Organization for Standardization (ISO) definiram um modelo funcional
denominado Fault, Configuration, Accounting, Performance, Security – Falha, Configuração, Contabilidade, Desempenho, Segurança (FCAPS). Esse modelo trata das melhores práticas definidas dentro dessas cinco áreas funcionais, fazendo com que a divisão de responsabilidades contribua com a qualidade do serviço prestado pelas áreas responsáveis por gerenciar os cenários onde, na maioria das vezes, a heterogeneidade de equipamentos e a
variabilidade semântica na configuração, com o intuito de garantir a interoperabilidade dos mesmos, pode se tornar um problema.
Nota-se que a correta configuração da rede é fundamental para a eficácia e a eficiência das aplicações como um todo, incorrendo que a realização de alterações em topologias através da configuração de vários dispositivos e a análise do impacto destas alterações no ambiente são atividades fundamentais (STALLINGS, 2005; TERAMOTO et al., 2013).
A possibilidade de abstrair as tarefas de gerência de configuração dos dispositivos de rede através da modelagem e do desenvolvimento de ferramentas distribuídas baseadas em serviços ou recursos que otimizem o trabalho do administrador pode ser considerada um ponto fundamental para superar um dos principais desafios que a heterogeneidade de
hardware que este ambiente de larga escala (redes corporativas, acadêmicas ou de Datacenter) impõe (LU et al., 2008; ANEDDA; ATZORI, 2009). O princípio do
gerenciamento de configuração da rede, que rotineiramente se concentra na centralização dessas atividades em uma única ferramenta (por facilidade de manutenção e suporte), muitas vezes não utiliza todo o recurso disponibilizado pelas várias arquiteturas e protocolos que possibilitam a execução deste trabalho de maneira distribuída ou remota.
Portanto, definir estratégias para contornar os problemas de um ambiente de rede heterogêneo e comparar o desempenho das tecnologias que ofereçam suporte ao desenvolvimento de ferramentas amigáveis, que possibilitem a realização da gerência de configuração de equipamentos de rede durante alterações de topologias, com um menor tempo de resposta a requisições e um menor tráfego durante as execuções, através da utilização das arquiteturas Service Oriented Architecture – Arquitetura Orientada a Serviço (SOA) e
Resource Oriented Architecture – Arquitetura Orientada a Recurso (ROA) por meio da
implementação de web services Simple Object Access Protocol1 (SOAP) e Representational
State Transfer2 (REST) (respectivamente), do protocolo NETCONF e também, através da
interação direta com a Command Line Interface3 (CLI) é o maior motivador para o desenvolvimento do presente trabalho.
Por fim, espera-se que os resultados apresentados por este estudo corroborem a área funcional da gerência de configuração, definida pelo modelo FCAPS, através da redução dos
1
Protocolo de Acesso Simples a Objetos 2 Transferência de Estado Representacional 3 Interface de Linha de Comando
erros de provisionamento e também na diminuição do tempo durante a abertura de janelas de paradas programadas que objetivam, dentre outras demandas, a alteração de topologias de rede.
1.2 OBJETIVOS DA PESQUISA
Nesta seção serão descritos os objetivos geral e específicos que se buscam alcançar por meio deste trabalho.
1.2.1 Objetivo Geral
Este trabalho tem o objetivo de criar e comparar estratégias para execução das atividades pertinentes à área funcional da gerência de configuração de redes, instituída pelo modelo Fault, Configuration, Accounting, Performance, Security – Falha, Configuração, Contabilidade, Desempenho, Segurança (FCAPS).
1.2.2 Objetivos Específicos
Para alcançar o objetivo geral da proposta, os seguintes objetivos específicos foram determinados:
elencar um conjunto de tarefas de gerência de configuração realizadas rotineiramente por um administrador de redes;
definir quatro estratégias de gerência de configuração baseadas nas arquiteturas SOA, ROA, no protocolo NETCONF e na forma de acesso CLI, através do mapeamento das tarefas elencadas em um conjunto de ferramentas computacionais;
compor um ambiente de testes que se aproxime ao máximo de uma topologia de rede real e que possibilite a aderência das ferramentas implementadas;
elaborar e executar um plano de testes através das ferramentas desenvolvidas;
comparar o custo efetivo de cada abordagem através da análise dos resultados obtidos;
identificar as estratégias mais rápidas e menos invasivas – que possibilitem uma redução do tráfego – durante a execução das tarefas de gerência de configuração.
Para atingir estes objetivos será necessário o desenvolvimento de uma infraestrutura de software que possibilite a conexão ao equipamento de rede e a execução de determinado comando, bem como a obtenção do seu retorno, variando neste ponto a forma como é apresentado o resultado ao usuário, seja na utilização de web services SOAP, REST para atender respectivamente aos princípios das arquiteturas SOA e ROA, através de respostas oriundas do protocolo NETCONF ou das interações por meio da CLI. Com o objetivo de possibilitar a parametrização e configuração de diversos equipamentos de rede (desde que estes disponham do suporte mínimo exigido pelas estratégias propostas), essa infraestrutura deverá possuir um baixo nível de acoplamento. Essa implementação deve ser planejada e modelada de modo que as estratégias escolhidas se enquadrem às necessidades da gerência de configuração e possam ser devidamente avaliadas em um cenário que simule um ambiente real de trabalho.
1.3 ESTRUTURA DO TRABALHO
A organização deste trabalho se dá como segue. Neste primeiro capítulo foi apresentada a introdução do trabalho com a finalidade de contextualizar o leitor nos temas abordados por esta dissertação. Ainda neste capítulo são apresentadas as motivações e justificativas, bem como os objetivos geral e específicos.
O segundo capítulo tem como objetivo apresentar os conceitos de gerenciamento de redes, o modelo FCAPS e alguns artefatos para a realização da gerência de configuração. Nesta seção, que trata dos artefatos, são abordadas algumas características do protocolo
Simple Network Management Protocol – Protocolo Simples de Gerenciamento de Redes
(SNMP), da forma de acesso CLI e, como estratégia complementar, do protocolo NETCONF, que com suas características específicas propõe a criação de padrões. Cabe salientar que todos os artefatos abordados buscam equalizar as características de utilização da área funcional de gerência de configuração, área essa que é o foco principal deste trabalho. Ainda neste capítulo é realizada uma apresentação sobre a tecnologia de web services e suas características, seguidas das arquiteturas SOA e ROA. Por fim, são descritos trabalhos relacionados,
selecionados a partir de uma busca com base em abordagens práticas relativas aos temas envolvidos.
No capítulo 3 são apresentados os materiais e métodos utilizados no desenvolvimento da dissertação. Neste capítulo, são apresentadas as estratégias para o gerenciamento de configuração de equipamentos de rede baseadas nas formas de acesso expostas nos objetivos específicos. É apresentada também, de forma descritiva e através de figuras e diagramas, a implementação da solução para a execução automatizada das tarefas de gerência de configuração. Dando sequência à estrutura do capítulo, foram elencadas as tarefas comumente executadas pelos administradores de rede na área funcional do modelo FCAPS da gerência de configuração de equipamentos. Posterior à definição das tarefas, foi realizado o mapeamento dessas por meio das ferramentas desenvolvidas onde, ao final, este mapeamento se concretizou através da disponibilização de métodos, serviços ou recursos, dependendo da estratégia abordada. Ainda neste capítulo, foram definidos os equipamentos utilizados para a criação de um cenário de rede que serviu de base para a instalação das ferramentas computacionais implementadas, simulando assim um ambiente de produção. Com o ambiente finalizado e as ferramentas configuradas foram executados os testes para cada estratégia e tarefas. A última seção do capítulo 3 apresenta uma descrição de como foi realizada a coleta desses dados.
O capítulo 4 apresenta uma combinação dos resultados obtidos ao término da execução dos testes. Neste capítulo é apresentado como os dados foram organizados e, em seguida, são realizadas as comparações e discussões, por meio da exibição de tabelas, sobre os resultados alcançados. Este capítulo é encerrado com uma discussão adicional e abrangente que trata da realização de uma inspeção mais profunda, seguida de uma análise diante do comportamento de cada estratégia.
Ao final, no capítulo 5, a dissertação é encerrada com a apresentação das conclusões, contribuições, dificuldades, limitações e também das sugestões de possíveis trabalhos futuros.
2 REVISÃO DA LITERATURA
Neste capítulo serão apresentados os aspectos teóricos a serem utilizados com a finalidade de orientar a pesquisa, dando suporte à implementação das estratégias para gerência de configuração de dispositivos de redes e, por conseguinte, ao alcance dos objetivos apresentados pelo trabalho.
2.1 GERÊNCIA DE REDES
A complexidade de uma rede de computadores é derivada do hardware de interconexão (switches, roteadores e access points) em que ela se apoia, em conjunto a uma série de protocolos, softwares e servidores que executam o processamento ou armazenamento de dados que serão entregues aos dispositivos finais de usuários ou instituições. Esses elementos formam uma estrutura que demanda acompanhamento, de forma que a comunicação entre os dispositivos de hardware e os componentes de software flua de maneira que as operações realizadas sejam estáveis e que as respostas sejam condizentes com as requisições – sem falhas e em um tempo aceitável. Para alcançar esse nível de qualidade é necessário gerenciar o ambiente onde esses componentes de hardware e software estão inseridos.
Segundo Hedstrom et al. (2015) a gerência de redes pode ser composta por dois cenários de atuação bem definidos:
operação – abrange o monitoramento do ambiente como um todo, incluindo a detecção de falhas e a disponibilização de alertas à administração da rede. Decisões sobre intervenção são tomadas a partir do resultado da coleta de dados estatísticos de desempenho ou de indicadores de utilização do usuário final para efeitos de posterior cobrança. Prevê também a atuação em áreas que cercam a segurança da rede mantendo o sistema confiável;
manutenção – engloba as rotinas de verificação e atualização de equipamentos. Aborda as falhas executando correções necessárias e garante a execução de rotinas de backup e restauração de equipamentos ou configurações. Com o intuito de atender a demandas oriundas da implantação de políticas ou alterações de topologias de rede, atua na ativação de novos recursos ou reconfiguração de equipamentos.
Com a junção desses dois cenários, define-se o gerenciamento de rede como a capacidade de sistematizar os processos de acompanhamento durante o funcionamento ou em momentos de falha dos componentes de hardware que compõem o ambiente (KUROSE; ROSS, 2010). A utilização de ferramentas computacionais visa dar suporte ao fluxo de trabalho do gerenciamento de redes, dividindo as tarefas em três eixos principais. O primeiro eixo é responsável pelo monitoramento, sendo caracterizado pela obtenção dos dados brutos do ambiente gerenciado (configurações ou dados de desempenho). O segundo eixo, por sua vez, visa o processo de análise baseado na interpretação dos dados coletados. Por fim, no terceiro eixo tem-se a fase de ação – onde são realizadas as operações reativas frente a eventos de falha, reconfigurações ou otimizações (GUIMARAES et al., 2016).
Objetivando estabelecer estratégias para realizar o gerenciamento dos equipamentos de interconexão, é apresentado a seguir um modelo de gerenciamento que será utilizado como guia para o presente trabalho. O modelo é complementado pela descrição de formas de acesso, arquiteturas e protocolos que serão empregados na construção de componentes de
software para auxiliar na gerência de configuração de redes.
2.1.1 Modelo FCAPS
Oferecer suporte e acompanhar o rápido desenvolvimento de uma rede de computadores (de backbone, acadêmica ou empresarial) para que a mesma sirva como instrumento primário de conexão entre dispositivos heterogêneos, transportando dados com a máxima disponibilidade, é um dos principais objetivos que norteiam o desenvolvimento de rotinas de controle dos dispositivos (roteadores, switches, access points, dentre outros) que compõem este ambiente de múltiplas conexões.
Para atingir este objetivo (que envolve uma série de tarefas complexas) e que, sem a definição de um plano poderia causar certa confusão, a International Telecommunication
Union Telecommunication Standardization Sector (ITU-T) e a International Organization for Standardization (ISO) instituíram um modelo funcional de gerenciamento de redes através da
criação de cinco áreas funcionais (JACOBS, 2014; WEISS; SOLOMON, 2015). Esse modelo, denominado FCAPS, é um acrônimo para Fault, Configuration, Accounting, Performance
and Security, e abrange respectivamente as áreas de gerenciamento de falhas, configuração,
contabilização, desempenho e segurança (INTERNATIONAL TELECOMMUNICATION UNION, 2000).
O detalhamento das cinco áreas funcionais de gerenciamento do modelo FCAPS é apresentado a seguir.
Fault (falha) – executa uma série de ações que incidem na localização,
isolamento e reparação/substituição de componentes que apresentem um comportamento anômalo dentro de um ambiente de rede, afetando negativamente o tempo de atividade, implicando em um baixo desempenho e degradação do serviço. O gerenciamento de falhas deve seguir o problema até a sua resolução (SINH et al., 2015), e pode ser dividido em dois subsistemas (BOUTABA; POLYRAKIS, 2001; FOROUZAN, 2010):
reativo – subsistema responsável pela detecção, isolamento, correção e documentação de falhas em curto prazo;
proativo – subsistema que tenta prever e prevenir comportamentos anômalos da rede.
Configuration (configuração) – define os parâmetros de funcionamento dos
dispositivos de rede através da alteração de sua configuração inicial para o atendimento a mudanças de topologia ou o estabelecimento de critérios mais rigorosos de Quality of Service – Qualidade de Serviço (QoS) ou Service Level
Agreement – Acordo de Nível de Serviço (SLA) em uma porção da rede ou
serviço em particular (BOUTABA; POLYRAKIS, 2001). Para Goyal, Mikkilineni e Ganti (2009) a gerência de configuração envolve tarefas complexas, sendo que a falha ou o atraso na realização dessas atividades pode gerar um impacto negativo sobre os serviços disponibilizados pela TI e que fazem o uso da rede como meio para troca de informações. Cabe também a esta área funcional a coleta dos dados de configuração de dispositivos com a finalidade de propiciar um funcionamento contínuo ou preparar-se para a inicialização e o encerramento de serviços de interconexão de maneira correta (GOROD; SAUSER; BOARDMAN, 2008). Para Dooley e Rooney (2013) e Hedstrom et al. (2015) outra funcionalidade da gerência de configuração é a realização do backup/restore das informações de dispositivos de interconexão de rede, que aliado à correta configuração dos mesmos contribui na redução de erros de provisionamento e na diminuição do intervalo de tempo durante a abertura das janelas de paradas programadas que
objetivam a alteração de topologias de rede. A gerência de configuração pode ser organizada em duas vertentes, descritas como segue (FOROUZAN, 2010):
reconfiguração – abrange as alterações de hardware, sejam elas na realocação física de equipamentos ou na alteração de sua configuração para atendimento a mudanças de topologia;
documentação – especifica o registro de cada mudança física ou de configuração no/dos dispositivos de rede. Este registro pode ser realizado através de diagramas que apresentem a localização física em uma planta, possibilitando também o apontamento lógico das configurações agregadas a cada equipamento dentro do cenário de rede administrado. Cabe também a esta vertente as especificações de cada dispositivo de interconexão, tais como marca, modelo e número de série.
Accounting (contabilização) – objetiva a tarifação dos dispositivos de rede
baseada na sua utilização (largura de banda, uso da Central Processing Unit – Unidade de Processamento Central (CPU), memória ou até mesmo as prioridades em agendamentos durante a execução de computação em supercomputadores) (ANDRZEJ, 2012). A gerência de contabilização trabalha na coleta, na análise e no agrupamento de métricas para entender o comportamento de um usuário ou grupo de usuários dentro de um determinado segmento da rede, com o propósito de estabelecer cotas individuais ou coletivas na utilização de recursos (DOOLEY; ROONEY, 2013). Cabe salientar que os mesmos indicadores utilizados para tarifação da utilização podem ser aplicados no atendimento a demandas que envolvem processos de auditoria.
Performance (desempenho) – caracteriza-se pelo reconhecimento dos limites da
comunicação de dados entre componentes, com o objetivo de estabelecer parâmetros de qualidade e oferecer a possibilidade de predição de comportamento ao administrador da rede. Este segmento da gerência de redes está fortemente relacionado com as técnicas de controle de tráfego como, por exemplo, traffic
shaping (BOUTABA; POLYRAKIS, 2001). Para mensurar o desempenho de uma
rede Forouzan (2010) e SINH et al. (2015) estabelecem que esta área funcional necessita fazer o uso de quantidades mensuráveis (estatísticas de rede) como taxa de erro, capacidade, tráfego, throughput ou tempo de resposta. Similar à divisão
citada por Hedstrom et al. (2015) para a gerência de redes no início da seção 2.1, Stallings (2005) expõe que a área de desempenho também pode ser subdividida em duas categorias funcionais, como segue:
monitoramento – categoria que busca acompanhar o funcionamento da rede e coletar informações para medição, com o intuito de escrutinar o comportamento da rede como um todo;
controle – função que se apoia nas métricas coletadas pelo monitoramento da rede. A principal característica do controle é possibilitar ao gerenciamento de desempenho a realização dos ajustes necessários para proporcionar níveis elevados de qualidade na comunicação entre dispositivos.
Security (segurança) – concentra-se no controle, na auditoria de acesso a redes de
computadores e no apoio à aplicação de políticas de segurança (GOROD; SAUSER; BOARDMAN, 2008; GOYAL; MIKKILINENI; GANTI, 2009). Esta área funcional absorve também os procedimentos de segurança necessários para evitar que os equipamentos, responsáveis pelo armazenamento ou tráfego de dados, venham a sofrer ataques que objetivam a degradação do desempenho, sobrecarregando, reconfigurando ou causando mau funcionamento do sistema como um todo. É atribuição da gerência de segurança o suporte e reação frente ao comportamento às vezes inusitado do usuário, protegendo as informações contra danos involuntários (BOUTABA; POLYRAKIS, 2001).
Percebe-se que, através da divisão exposta, é possível controlar todos os segmentos de uma rede garantindo a disponibilidade e a integridade da mesma, desde que seguidas as condições e requisitos únicos de cada área e dos dispositivos de interconexão que são utilizados para o tráfego das informações entre pessoas ou instituições (HEDSTROM et al., 2015).
Com o objetivo de elucidar os conceitos previamente apresentados, a figura 1 exibe a divisão do modelo funcional FCAPS sucedida de uma síntese com as principais características, ações e formas para cada área.
Figura 1 – Síntese da divisão funcional do modelo FCAPS.
Fonte: Estrutura da figura baseada em Forouzan (2010) e síntese elaborada pelo autor.
Doravante neste trabalho e com o objetivo de delimitar o escopo da pesquisa, quando citado o modelo FCAPS, a área funcional de gerência de configuração será abordada com destaque.
2.1.2 Artefatos para Gerência de Configuração
Os administradores de rede, durante configurações para o atendimento às tarefas que visam a manutenção ou provisionamento de novos serviços, instalação, realocação física de equipamentos ou pontos de rede, fazem uso de algum tipo de software. Procedimentos simples como a alteração de uma topologia de rede frente à necessidade de mudança de um setor que dispõe de uma Virtual Lan – Rede Local Virtual (VLAN) específica para outro local, pode envolver a configuração de um ou vários equipamentos dependendo do alcance da topologia e do que se utiliza na rede.
Em redes corporativas, a homogeneidade dos equipamentos de interconexão não é uma premissa que possa ser tratada como verdadeira. Diante desse cenário, e da necessidade de configuração de dispositivos de rede dentro de um ambiente heterogêneo, vários esforços têm sido empregados para contornar o problema que a variabilidade da rede apresenta
(causada pelo fato de que diferentes fornecedores de equipamentos dispõem de variadas funcionalidades, interfaces e modelos de programação e customização para seus dispositivos) (WONG et al., 2005).
Esforços têm sido feitos para organizar este ambiente que é composto de componentes de hardware não uniformes e que, na maioria das vezes, demanda interoperabilidade. O gerenciamento de configuração destes dispositivos pode acontecer através de protocolos ou meios específicos como SNMP, CLI, Network Configuration – Configuração de Rede (NETCONF) por meio da linguagem de modelagem YANG, métodos proprietários ou Application Programming Interface – Interface de Programação de Aplicativos (API) que, por sua vez, podem emular chamadas de configurações e apresentar ao usuário uma Graphical User Interface – Interface Gráfica do Usuário (GUI) web amigável, utilizando-se de tecnologias como Extensible Markup Language – Linguagem de Marcação Extensível (XML), Representational State Transfer – Transferência de Estado Representacional (REST) ou JavaScript Object Notation – Notação de Objeto Javascript (JSON) (STADLER, 2013; HEDSTROM et al., 2015).
2.1.2.1 Simple Network Management Protocol (SNMP)
Segundo Xu e Xiao (2006), o protocolo SNMP tem sido amplamente utilizado no monitoramento de falhas e desempenho; entretanto, quase não é utilizado para o gerenciamento de configuração. A razão do não uso reside no fato de o referido protocolo apresentar limitações de aplicação no contexto de grandes redes. Essas limitações são diretamente relacionadas à representação de dados que retratam a configuração dos dispositivos de rede por meio de Structure of Management Information – Gerenciamento da Estrutura de Informação (SMI) ou Structure of Management Information, Next Generation – Próxima Geração para Gerenciamento da Estrutura de Informação (SMIng), que é a linguagem de definição de dados que visa fornecer uma representação independente de protocolo. Outra razão pela qual o protocolo SNMP é pouco utilizado para gerência de configuração é não trabalhar bem com grandes transferências de dados por meio de operações
snmpgetbulk, bem como a densidade do protocolo que cresce em paralelo junto à
complexidade de configuração dos dispositivos através de operações get e set (Hedstrom et al., 2015; Santos, P. R., Esteves e Granville, 2015). Essa densidade é observada através da
utilização excessiva de parâmetros durante as operações de configuração e recuperação de informações do dispositivo alvo.
O fato do protocolo SNMP utilizar User Datagram Protocol (UDP) como protocolo de transporte entre agentes gerenciadores e componentes gerenciados pode ser tratado como um problema durante a gerência de configuração. O não estabelecimento de uma conexão, característica intrínseca do protocolo UDP entre os pares, faz com que sua utilização seja tida como não confiável e, com o objetivo de contornar esse problema, cabe à aplicação executar o tratamento de erros que venham a acontecer até na camada de transporte, realizando as retransmissões necessárias (DOUGLAS; KEVIN, 2005; LOUREIRO; GONÇALVES; NOGUEIRA, 2012).
Cabe ressaltar, porém, que o SNMP agregado ao UDP foi um protocolo desenvolvido para ser utilizado em redes instáveis, ponto de encontro das áreas funcionais da gerência de falhas e desempenho citadas acima e, frente a um cenário problemático, nada mais justo que evitar a inundação de retransmissões do Transmission Control Protocol – Protocolo de Controle de Transmissão (TCP) que busca o retorno da confiabilidade perdida. Portanto, frente às dificuldades apresentadas pelo protocolo SNMP, gerenciar um ambiente instável através de um padrão que se utiliza de mecanismos que não transmitam confiança durante a comunicação pode fazer com que a gerência de configuração seja alvo comum das áreas de gerência de falha e desempenho (YU; AJARMEH, 2010).
2.1.2.2 Command Line Interface (CLI)
Outra forma de realizar a gerência de configuração é através da CLI. Para Guimarães et al. (2016) os administradores de rede estão familiarizados e rotineiramente utilizam de ferramentas tradicionais para executar a gerência de configuração, sendo que muitas dessas ferramentas baseiam-se em CLI. Essa utilização se firma na elasticidade da personalização de uso através dos inúmeros comandos e parametrização pré-estabelecidas (FILIPPETTI, 2011).
A CLI continua sendo a base para o provisionamento de novas funcionalidades e, quanto mais complexas se tornam as tarefas do administrador de rede, mais provável é que elas sejam provisionadas de maneira mais manual do que automática. Outra característica, já citada anteriormente, remete aos desafios que a interoperabilidade semântica apresenta na configuração de dispositivos heterogêneos. Contudo, a popularidade da CLI é balizada na sua eficiência de uso, bem como na capacidade de comunicação direta com o dispositivo. Um
exemplo clássico de CLI é o UNIX CLI para bourne shell (programas sh em sistemas operacionais UNIX). Usualmente administradores de rede utilizam a CLI de sistemas UNIX como ponto de partida para realizar a conexão em dispositivos de interconexão de rede através de protocolos que estabelecem sessões Virtual Teletype (VTY) TELNET, Secure Shell (SSH) ou Trivial File Transfer Protocol (TFTP) (ODOM, 2008; HEDSTROM et al., 2015).
As formas de conexão SSH, TELNET e também através de uma interface auxiliar para acesso à CLI de um dispositivo de rede são apresentadas na figura 2.
Figura 2 – Formas de conexão para acesso à CLI do dispositivo gerenciado.
Fonte: Elaborada pelo autor.
Pode-se notar a variabilidade semântica na configuração de dispositivos de rede diante da necessidade de interoperabilidade entre estes equipamentos durante a utilização, por exemplo, do Virtual Router Redundancy Protocol – Protocolo de Redundância de Roteador Virtual (VRRP). O VRRP adiciona redundância e aumenta a disponibilidade da rede, possibilitando que dois ou mais roteadores compartilhem um único endereço Internet
Protocol – Protocolo de Internet (IP) virtual. Um dos roteadores trabalha como dispositivo
mestre enquanto os outros atuam como backup: se o equipamento mestre falhar, ou se o link configurado nas interfaces com o endereço IP virtual falhar, um dos roteadores de backup assume como mestre da topologia (NADAS, 2010).
Para que o protocolo VRRP funcione conforme o padrão estabelecido por sua
Request for Comments (RFC), as interfaces que interligam os equipamentos assumem
endereços únicos; porém, essas interfaces compartilham de um único IP virtual. Com o objetivo de exemplificar a configuração do protocolo VRRP, a figura 3 apresenta uma topologia de rede Internet Protocol Version 4 – Protocolo de Internet Versão 4 (IPv4) onde os comandos são executados por meio da CLI. Percebe-se na figura a diferença entre comandos que essencialmente executam a mesma função, porém em equipamentos de marcas diferentes.
Figura 3 – Variabilidade semântica em uma topologia VRRP.
Fonte: Topologia baseada em Nadas (2010) e configurações CLI elaboradas pelo autor.
2.1.2.3 Network Configuration (NETCONF)
Diferente da CLI, onde cada fornecedor (não se preocupando com padronização) especifica uma série de parâmetros para realizar a gerência de configuração de cada dispositivo de rede, a Internet Engineering Task Force (IETF) propôs a criação de um protocolo através da RFC 6241 (ENNS et al., 2011), que visa fornecer novos mecanismos padronizados para contornar a abordagem complexa e dependente da CLI, que muitas vezes dificulta a interoperabilidade de equipamentos durante as atividades de criação de topologias mais complexas.
O protocolo NETCONF é utilizado para o gerenciamento de rede através de métodos para instalar, manipular e excluir configurações de dispositivos de rede utilizando-se de uma codificação baseada em XML para as mensagens de protocolo e também de configuração (SEHGAL et al., 2012; NARISETTY et al., 2013). Sua utilização, por meio de algumas características específicas, possibilita a automatização do gerenciamento em ambientes complexos (quantidade e heterogeneidade de equipamentos) proporcionando maior segurança e confiabilidade durante as alterações das topologias de rede desses cenários (LOUREIRO; GONÇALVES; NOGUEIRA, 2012). Yu e Ajarmeh (2010) comentam, ainda na fase draft (rascunho) do protocolo na IETF, que sua utilização será um passo importante para a criação de sistemas de gerenciamento de redes baseados em XML, e que através de NETCONF são
definidas as operações para gerenciar dispositivos de rede onde os dados de configuração podem ser enviados, recuperados ou manipulados de forma parcial ou na sua totalidade.
NETCONF utiliza o paradigma cliente/servidor e tem por base a uniformidade na representação dos dados (ELBADAWI; YU, 2011). Neste cenário, um servidor é um dispositivo de rede (por exemplo, um roteador) e o cliente pode ser uma aplicação que acessa o roteador para executar determinadas operações por meio do referido protocolo. Esse protocolo tem como requisito principal a estratégia de que suas operações devem ser orientadas à conexão, provendo um meio de comunicação entre cliente/servidor confiável, devendo atender a alguns requisitos básicos como: entrega garantida e na sequência de mensagens, autenticação, integridade e confidencialidade – características essas estabelecidas pela camada de transporte (ENNS et al., 2011).
O projeto do protocolo NETCONF baseia-se em uma arquitetura modular composta de quatro camadas que desempenham funções únicas e bem definidas (TAVARES; GONÇALVES; OLIVEIRA, 2011; HALLÉ, CHERKAOUI; VALTCHEV, 2012; KREJCI, 2013; STEINMETZ, 2015):
camada de transporte – é a primeira camada, em uma visão bottom-up, que define um canal de comunicação seguro entre cliente e servidor para troca de mensagens necessárias à execução de procedimentos remotos. O NETCONF pode ser utilizado sobre qualquer protocolo de transporte desde que atenda aos requisitos expostos anteriormente. Dentre os possíveis protocolos a serem utilizados podemos relacionar o SSH, Transport Layer Security – Segurança da Camada de Transporte (TLS), Blocks Extensible Exchange Protocol (BEEP)/TLS, SOAP/HTTP/TLS. Cabe salientar que segundo a RFC 6242 (WASSERMAN, 2011) o NETCONF deve apoiar-se no SSH como protocolo para a camada de transporte;
camada de mensagem – o modelo de comunicação utilizado entre cliente e servidor é baseado no paradigma Remote Procedure Call – Chamada de Procedimento Remoto (RPC), onde um cliente codifica uma requisição RPC (<rpc>) em XML e a envia para um servidor com um atributo de identificação obrigatório (message-id). Baseado na requisição do cliente, o servidor envia uma resposta RPC (<rpc-reply>) também codificada em XML. Cabe salientar que o sucesso na execução de uma mensagem (<ok>), bem como a falha da mesma
(<rpc-error>) e seus subelementos (<error-type>, <error-info>, dentre outros), também são tratados através de uma resposta RPC com elementos específicos. Ambos os pares envolvidos na conexão compreendem a sintaxe XML descrita durante a troca de mensagens, pois a mesma pode ser definida em um arquivo
Document Type Definition – Definição de Tipo de Documento (DTD) ou schema
XML;
camada de operações – esta camada é composta por um conjunto básico de operações utilizadas para a realização do gerenciamento de configuração. A tarefa definida por esta camada é a de oferecer métodos para recuperar, configurar, copiar e excluir parâmetros em dispositivos de rede, com o objetivo de alterar o seu status atual. Também são descritas como operações básicas as funcionalidades de bloqueio e desbloqueio que permitem acesso exclusivo em um determinado momento aos parâmetros de configuração;
camada de conteúdo – também pode ser definida como a camada de dados que estabelece os parâmetros de configuração de cada dispositivo. Pelo fato de existirem inúmeros retornos a parâmetros, esta camada torna-se independente do protocolo NETCONF.
A camada de conteúdo do NETCONF é desprendida de padrões, e cada fornecedor pode defini-la utilizando-se de suas próprias especificações. Contudo, para equacionar essa independência de tecnologia a IETF propôs, através da RFC 6020 (BJORKLUND, 2010), uma linguagem para descrever as informações das tarefas de gerenciamento de rede. YANG é uma linguagem de modelagem de dados extensível e utilizada pelo protocolo NETCONF para definir uma árvore hierárquica de dados utilizados nas mensagens RPC de configuração, operação e notificação, permitindo uma descrição completa entre cliente e servidor. As informações são divididas em módulos de forma que cada módulo define uma validação sintática e semântica de fácil entendimento (GOLLING et al., 2014; MEDVED et al., 2014; SASSI et al., 2014; AKHTAR, 2015).
Para Bajpai e Schönwälder (2014) o protocolo NETCONF e a possibilidade de utilização de uma linguagem de modelagem de dados como YANG formam a base de uma nova estrutura de gerenciamento de rede, aumentando a capacidade de interoperabilidade de dispositivos.
O protocolo NETCONF suporta várias formas de configuração, as quais devem ser anunciadas através de elementos específicos (<capabilities>) pelo dispositivo durante a primeira troca de mensagens e identificadas através de Uniform Resource Identifier – Identificador Uniforme de Recurso (URI). Quando uma sessão é aberta entre os pares, o servidor envia um elemento <hello>, incluindo um identificador de sessão (<session-id>) seguido de sua lista de recursos disponíveis (<capabilities>). Para concretizar essa sessão NETCONF o cliente deve, impreterivelmente, responder ao servidor com outra mensagem contendo o elemento <hello> e os recursos que deseja dispor durante as tarefas de configuração. Caso não seja respeitada a sequência e a estrutura da mensagem a sessão é encerrada automaticamente pelo servidor. As capacidades adicionais, utilizadas para estender o protocolo, são apresentadas a seguir (TAVARES; GONÇALVES; OLIVEIRA, 2011; KREJCI, 2013):
writable-running – representa a alteração da configuração em um dispositivo que
está em execução, onde as modificações realizadas nesse modo afetam o sistema em produção;
candidate-configuration – indica que um dispositivo suporta o armazenamento de
dados de configuração que podem ser manipulados sem afetar a configuração atual (em execução). Através de uma operação de commit a configuração marcada como candidata poderá entrar em execução;
confirmed-commit – permite que uma alteração seja revertida caso não seja
realizada em um limite de tempo pré-definido;
rollback-on-error – capacidade que permite ao servidor voltar ao estado anterior
em caso de erro;
validate – oferece a capacidade de validação das configurações antes da sua
execução;
distinct-startup – possibilita que as operações realizadas em modo writable-running não surtam efeito caso o dispositivo seja reiniciado;
URL – capacidade que permite aos dispositivos a exposição de características adicionais através de URLs com o argumento esquemas (http, ftp, file);
XPath – permite que os pares utilizem expressões XML Path Language (XPath) dentro dos elementos <filter>.
Outra característica de NETCONF é que, através de mensagens assíncronas (notificações), o protocolo possibilita que o cliente, mediante uma espécie de assinatura por meio do elemento <create-subscription> enviado na mensagem, receba anúncios que o alertam da ocorrência de algum evento através do elemento <notification> na resposta do servidor (KREJCI, 2013).
A arquitetura do protocolo NETCONF, bem como alguns exemplos utilizados em cada camada, é detalhada na figura 4.
Figura 4 – Arquitetura em camadas do protocolo NETCONF.
Fonte: Elaborada pelo autor com base em Tavares, Gonçalves e Oliveira (2011) e Krejci (2013).
Fundamentando-se na união do protocolo NETCONF com princípios de REST, apresentados na seção 2.4.1, um novo protocolo para gerência de redes denominado RESTCONF (BIERMAN; BJORKLUND; WATSEN, 2016) está em fase de desenvolvimento pela IETF. O protocolo pode ser descrito como a busca pela simplificação do protocolo NETCONF, utilizando-se dos mecanismos do Hyper Text Transfer Protocol Secure – Protocolo Seguro de Transferência de Hipertexto (HTTPS) para acesso aos dados, através da linguagem YANG, de equipamentos com suporte a NETCONF (VILALTA et al., 2015).
O protocolo RESTCONF pode ser descrito em um quadro composto de quatro modelos (PRIETO; LEUNG; ROCKWELL, 2015):
modelo de recurso – em REST um recurso é, informalmente, qualquer informação que pode ser nomeada e posteriormente acessada. No contexto de
RESTCONF um recurso apresenta os elementos gerenciáveis de cada equipamento;
modelo de mensagem – cada mensagem do protocolo realiza uma única operação em um único recurso; logo, para cada tarefa da gerência de configuração deve ser realizada uma operação HTTP;
modelo de datastore (armazenamento de dados) – os dados são armazenados conceitualmente em um único local, sendo esse a união das configurações de execução e do estado operacional do dispositivo;
modelo de conteúdo – o conteúdo é estabelecido através da linguagem YANG e disponibilizado por meio de um URI.
As operações RESTCONF são definidas pela interface uniforme fornecida por REST e codificadas em HTTP. Cada operação inclui o método HTTP e um URI, que identifica o recurso de destino através de um nó de dados YANG. As operações de leitura a recursos (aquisição da configuração ou estado operacional de um equipamento) são alcançadas através do método GET; já as operações que alteram as configurações atuais do equipamento são definidas por meio dos métodos DELETE, PATCH, POST e PUT. Essas operações podem ser refinadas valendo-se de parâmetros de consulta inseridos diretamente na URI ou em dados enviados no cabeçalho do protocolo HTTP.
A utilização do protocolo RESTCONF não tem como objetivo tornar-se uma substituta do NETCONF, mas sim procura fornecer um meio adicional de acesso, através de HTTPS, para o gerenciamento de dispositivos de rede. Valendo-se de métodos e protocolos largamente utilizados, o que induz a sua facilidade nos quesitos que tangem a interoperabilidade, vem chamando a atenção de controladores Software Defined Networking – Redes Definidas por Software (SDN), como OpenDayligth (OpenDaylight Platform, 2016), que inclui um cliente RESTCONF para gerenciamento de sua Northbound Interface (interface norte), responsável pela comunicação entre o plano de gerenciamento que contém as aplicações de rede e o plano de controle que contém o Network Operating System – Sistema Operacional de Rede (NOS) (MEDVED et al., 2014; ZHOU et al., 2014; AUTENRIETH et al., 2015).
2.2 WEB SERVICES
A possibilidade de realizar a gerência de configuração de uma rede de computadores por meio de técnicas baseadas em princípios distribuídos e com a disponibilização de uma
interface amigável ao administrador do ambiente tem como principal objetivo transpor as
limitações impostas pelo modelo tradicional de configuração, e que se dá muitas vezes pelo acesso individual e direto à CLI de cada componente. A tecnologia de web services pode ser utilizada para fornecer meios que possibilitem o desenvolvimento de ferramentas que permitam o mapeamento desses comandos executados na CLI durante a realização das tarefas da gerência de configuração através de serviços ou recursos distribuídos (GIOVANNI; LUIGI, 2012).
Com o intuito de refinar, padronizar e também sugerir a forma como web services devem funcionar, uma definição inicial é apresentada pela World Wide Web Consortium (W3C), citada também por Austin et al. (2004) e Berners-lee, Fielding e Masinter (2005). Nessa apresentação web services são abordados como aplicativos identificados por um
Uniform Resource Identifier – Identificador Uniforme de Recurso (URI) cujas interfaces e
ligações são descritas, definidas e descobertas por outras aplicações através de Extensible
Markup Language – Linguagem de Marcação Extensível (XML) utilizando-se de meios de
transporte definidos por protocolos da internet. Resultantes dessa definição inicial, apresentações distintas foram surgindo com o objetivo de comparar web services a outras estratégias de middleware ou a fim de fornecer uma visão mais genérica e centrada no contorno dos problemas de comunicação entre aplicações totalmente heterogêneas, orientando o desenvolvimento de software no sentido de incorporar características como flexibilidade e reutilização de componentes.
Segundo Tanenbaum e Steen (2006) e Coulouris et al. (2011) web services são aplicações desenvolvidas de forma modular baseadas em componentes de software, implementadas de modo a serem independentes de plataforma de hardware, sistema operacional, infraestrutura de rede ou linguagem de programação. São também aplicações auto-descritas, acessíveis e descobertas através da internet e que possibilitam a comunicação e a integração de sistemas distintos ou mesmo a interoperabilidade entre componentes de
software instalados em infraestruturas diferentes, desde que executem funções bem
específicas. Para atingir esse nível de interoperabilidade, ambas as aplicações provedoras e consumidoras de web services devem respeitar um conjunto de padrões previamente
