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