ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
149
NETCONF – Gerenciamento das Novas Redes
Lílian Lyra Villela
Guilherme Augusto Barucke Marcondes
Nova Telefônica Brasil – Vivo
lilian.villela@vivo.com.br
Instituto Nacional de Telecomunicações - Inatel
guilherme@inatel.br
Abstract—Study on the Network Configuration Protocol
(NETCONF) developed by the Internet Engineering Task Force
(IETF) as a quality alternative to the Simple Network
Management Protocol (SNMP) in the managing of dispositives in
complex nets, accomplishing robust operations safely and using
standard data structured with Extensible Markup Language
(XML). NETCONF structure, challenges and advancements are
exposed based on throughout research on updated specialized
scientific production. The undoubtedly superior performance of
the NETCONF in the achievement of multiple configuration
transactions and the involvement of the market leaders
manufacturers in the production of several researches and the
development of integrated solutions indicate an upcoming
adhesion in a mixed gradual model with the temporary
association of the technologies
Index terms—Network Management, NETCONF, Network
Configuration Protocol, XML.
Resumo – Estudo sobre o protocolo de Configuração de Rede
NETCONF (Network Configuration Protocol) desenvolvido pelo
IETF (Internet Engineering Task Force) como alternativa de
qualidade ao SNMP (Simple Network Management Protocol) no
gerenciamento de dispositivos em redes complexas, realizando
operações robustas com segurança e usando estrutura de dados
padronizada com XML (Extensible Markup Language). A
estrutura, os desafios e avanços do NETCONF são apresentados
a partir de extensa pesquisa realizada com base na recente
produção
científica
especializada.
O
desempenho
indiscutivelmente superior do NETCONF na realização de
transações múltiplas de configuração e o envolvimento de
fabricantes líderes de mercado na produção de diversas pesquisas
e desenvolvimento de soluções integradas indicam uma adesão
próxima em modelo misto e gradual com a convivência
temporária das tecnologias.
Palavras chave—Gerenciamento de Rede, NETCONF,
Protocolo de Configuração de Rede, XML
virtuais são a realidade deste século. Crianças brincam on-line.
Estudantes experimentam on-line. Profissões e especialidades
surgem e se expandem também à luz desta realidade. Há
quinze anos, no Brasil, os cursos de Informática de terceiro
grau estavam limitados ao processamento de dados e as
especializações à análise de sistemas. Atualmente, observamse as diversas carreiras oferecidas e as mais variadas
especialidades do mercado de profissionais de TI (Tecnologia
da Informação). Também na Medicina e ciência biomédica
estão disponíveis novas especialidades de profissionais
municiados com recursos tecnológicos. Esses são alguns dos
indicadores concretos de que novas carreiras estão sendo
forjadas a partir da tecnologia.
A complexidade dos dispositivos e a garantia do seu alcance
são bens intrínsecos da sociedade cada vez mais digital que
troca, recebe, envia, comercializa, aprende, ensina e transfere
muito mais informação do que a produzida em séculos da era
outrora considerada mágica da imprensa.
Coincidentemente, e não por acaso, os três princípios
básicos: confiabilidade, integridade e disponibilidade norteiam
a segurança da informação.
Neste cenário encontra-se o papel estratégico do
gerenciamento de redes, capaz de garantir o desempenho dos
dispositivos nas transações do atual relacionamento digital
humano de forma satisfatória, acordada e contratada.
O propósito deste trabalho é apresentar o NETCONF
(Network Configuration Protocol) como o recurso idealizado
pelo IETF (Internet Engineering Task Force) para atender os
requisitos atuais impostos pela diversidade e quantidade de
elementos envolvidos nas aplicações de serviços e dados das
redes do nosso século.
I. INTRODUÇÃO
II. O PAPEL DAS REDES
Redes de computadores fazem parte da rotina da população
mundial de forma tão intensa e próxima como se assim o fosse
desde sempre. Transações simples como uma pequena
mensagem enviada para um amigo envolvem recursos
computacionais integrados entre si para garantir a
comunicação ágil, segura e disponível. Nossos contatos
Esta seção estabelece o desafio do gerenciamento de redes e
a necessidade de protocolo capaz de endereçar questões de
configuração em ambiente complexo em diversidade e
quantidade de componentes envolvidos.
Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de
Telecomunicações, como parte dos requisitos para a obtenção do Certificado
de Pós-Graduação em Engenharia e Gestão de Telecomunicações. Orientador:
Prof. Guilherme Augusto Barucke Marcondes. Trabalho aprovado em
09/2011.
A. Visão Histórica
Em 1960 a rede dominante no mundo era a rede telefônica
[1] usando comutação de circuitos na transmissão de
mensagens entre a fonte e o destino.
A interligação dos computadores de alto custo naquela
época para permitir seu compartilhamento com usuários
geograficamente distantes em operações não exclusivas levou
150
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
ao desenvolvimento da comutação de pacotes. [1] Baseada no
princípio da intermitência do tráfego (rajadas), a ARPAnet
(rede da Agência de Projetos de Pesquisa Avançada –
Advanced Research Projects Agency Networks) foi lançada em
1967, sendo a precursora da Internet
Até 1980, as redes se expandiram de forma proprietária,
isoladamente. [1] O trabalho de criação da rede das redes foi
liderado pelas pesquisas da DARPA (Agência de Projetos de
Pesquisa Avançada de Defesa - Defense Advanced Research
Projects Agency). Segundo os autores em [1], o número de
máquinas ligadas à Internet pública chegou a 100 mil no
período de dez anos entre 1980 e 1990.
Na década de 90 viveu-se o fenômeno da “World Wide
Web” alavancando a operação comercial da Internet, agora
ultrapassando as fronteiras acadêmicas e reservadas, e
invadindo lares e empresas com crescentes oportunidades de
novos serviços.
Em paralelo, foi iniciada a convergência das redes de
telecomunicações que, migrando de geração em geração,
acabaram por adotar o mundo de pacotes IP (Internet
Protocol) e a digitalização de sua planta de equipamentos. A
arquitetura de redes baseadas em comutação de circuitos foi
ampliada com a nova perspectiva [2] de entrega do tráfego de
circuitos sobre uma rede IP onde as conexões com redes
externas são conduzidas por meio de media gateways.
Este é o cenário encontrado hoje: um mundo digital com
números astronômicos de dispositivos conectados e
executando funções inseparáveis do cotidiano cultural da
população.
B. Conceitos
Uma rede pode ser considerada como um conjunto de
recursos interligados.
Redes de computadores têm na Internet seu exemplo mais
amplo e envolvem [1] servidores, estações de trabalho,
notebooks, netbooks, consoles de video-games, PDA´s
(Personal Digital Assistants), tablets, smart phones e, mais
recentemente no Brasil, as Smart TV´s (televisões com acesso
à Internet). Todos esses dispositivos se conectam e trocam
informações.
As redes de telecomunicações englobam plataformas de
comutação e serviços. Assim como, considerando a sua
periferia, uma rede de comutadores de pacote e enlaces que
interconectam tais recursos.
Redes envolvem hardware, software e muita interação:
enlaces, computadores, roteadores – entre outros dispositivos
físicos – e protocolos que controlam e coordenam tais
componentes.
Protocolos estabelecem o formato da comunicação.
Na rede ancestral de pacotes ARPAnet o protocolo NCP
(Network Control Protocol) foi definido pela histórica e
primeira RFC (Request for Comments), a RFC 001 [9], e
permitiu o desenvolvimento de aplicações para a rede (no
caso, o primeiro programa de e-mail desenvolvido em 1972
[1]).
C. Desafios
Como exposto até aqui, a diversidade e quantidade de
equipamentos envolvidos em uma rede é grande e tende a
aumentar continuamente sob os dois aspectos.
Em janeiro de 2011 havia aproximadamente 800 milhões de
servidores (hosts) cadastrados segundo o ISC (Internet
Systems Consortium) [9]. Esta contagem indica apenas o
número de endereços IP associados a um determinado
domínio na Internet. O número real de servidores nas redes
públicas e privadas em muito excederá este total, considerando
o grau de automação das empresas e o uso de gateways de
comunicação com a rede pública.
Além dos hosts, são componentes próprios das redes os
servidores, estações móveis, comutadores de pacote, modems,
estações-base, telefones celulares e as torres de telefonia
celular.
Os gadgets do mundo moderno desempenham papel de
cliente relativo. O consumo de informações deixou de
representar a única prática dos dispositivos de interação com a
rede. Clientes mais e mais estão servindo à rede. Tanto
consomem, quanto fornecem informação, gerando e
compartilhando dados.
Em resumo, a gerência de rede é disciplina que enfrenta
tremendos desafios provocados pelo mundo digital das
conexões. Protocolos de gerenciamento de rede devem ser
considerados como interlocutores da inteligência a ser
aplicada nos dispositivos e na rede para garantir sua
disponibilidade eficiente.
III. CENÁRIO ATUAL
O protocolo mais amplamente difundido entre os
componentes de redes atuais é o SNMP (Simple Network
Management Protocol) [8] segundo pesquisa realizada. Esta
seção conceitua o processo de gerência de rede, apresenta um
breve histórico da evolução desse protocolo até a versão atual
e identifica seus pontos fortes e lacunas no gerenciamento de
dispositivos na rede.
A. Gerência de Rede
As redes originais estavam voltadas ao compartilhamento
de recursos caros e restritas a determinados ambientes onde
falhas representavam impacto proporcional à extensão de
dispositivos conectados e contavam com muita tolerância por
parte dos usuários da rede, que compreendiam suas limitações
como um ônus componente daquele cenário.
A sofisticação evolutiva do ambiente de rede trouxe a
necessidade vital de um processo para monitorar seu
funcionamento e administradores responsáveis por sua
qualidade e disponibilidade. É o processo de gerência da rede,
responsável por assegurar seu funcionamento conforme
previsto ou contratado.
O gerenciamento de redes encontra-se definido pela ISO
(International Organization for Standardization) em relação à
sua arquitetura de integração de sistemas abertos (OSI, Open
Systems Interconnection) como [35] o processo que “provê
mecanismos para a monitoração, controle e coordenação de
recursos em um ambiente OSI e define os padrões de
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
protocolo OSI para troca de informações entre estes recursos”.
O modelo OSI foi padronizado em cinco áreas funcionais
[35]:
1. Desempenho (vazão e taxa de erros)
2. Falhas (comportamento anormal)
3. Configuração (dados e estados da rede)
4. Contabilidade (uso de recursos)
5. Segurança (acesso)
Tais áreas são similares em se tratando de redes de
telecomunicações ou de dados [4]. Para atender as
funcionalidades de cada área são desenvolvidos aplicativos
(softwares) de gerenciamento [35] apropriados ao ambiente
distribuído.
As ferramentas da central de operações de rede para o
exercício daquelas tarefas se comunicam com os dispositivos
por meio de componentes ou funcionalidades que tais recursos
disponibilizem. Esta organização é conhecida hoje como o
NOC (Network Operations Center) [1] e utiliza ferramentas
do tipo cliente/servidor que envolvem um cliente no
equipamento e um servidor conectado na ferramenta de
controle alinhados para a comunicação por meio do mesmo
protocolo.
No modelo de gerenciamento OSI [35], representado pela
Figura 1, são definidos conceitualmente os papéis:
a) Gerente: função de gerenciamento sobre os
objetos gerenciados, transmite operações e recebe
notificações dos agentes.
b) Agente: intermediário entre gerentes e objetos
gerenciados, recebe operações dos gerentes para
atuação sobre os objetos gerenciados e recebe as
notificações geradas pelos objetos gerenciados
para repasse ao gerente.
c) Objeto Gerenciado: representação dos recursos
físicos ou lógicos e seus atributos gerenciados
pelo sistema, recebe as operações de
gerenciamento e emite notificações.
Figura 1 Gerenciamento OSI [35]
A multiplicidade de equipamentos em uma rede e a
necessidade de controle e monitoramento levaram ao
desenvolvimento de protocolos específicos para o
gerenciamento de redes. Tendo sido o SNMP uma dessas
iniciativas e, até este momento, a mais disseminada entre os
fabricantes de componentes [4] [8].
B. Evolução do SNMP
O IETF é uma organização aberta com contribuições
voluntárias que tem como missão “cuidar para que a Internet
funcione melhor” [11]. Este esforço é representado pela
151
criação e documentação de padrões que contribuam para tal
aprimoramento.
Membros do IETF desenvolveram o SNMP [12] como um
protocolo padrão para o gerenciamento de redes IP. Desde
então, passou por revisões que resultaram na atual versão 3.0,
definida pela RFC 3410 [13] onde passa a integrar um
framework ou arcabouço de gerenciamento padrão para a
Internet. A principal aquisição das novas versões em relação à
original foi segurança, inicialmente envolvendo transmissão
da senha até o suporte atual a algoritmos criptográficos.
Sua estrutura básica é a mesma em qualquer uma das três
versões [13] e é composta por:
· Uma entidade agente em cada dispositivo para
prover acesso remoto ao seu gerenciamento,
· Pelo menos uma entidade gerente, responsável pela
tarefa de gerenciamento
· Protocolo de comunicação entre as entidades
· A informação de gerenciamento
O framework do SNMPv.3 (versão atual do Simple Network
Management Protocol) envolve [13]:
1. Linguagem de definição de dados
2. Base de informação de gerenciamento (MIB,
Management Information Base)
3. Definição do protocolo
4. Segurança e administração
Os módulos MIB mantém dados gerenciáveis dos objetos
da rede, disponibilizados por meio dos agentes para
manipulação pelas aplicações de gerenciamento usando o
protocolo [13].
Tais módulos são definidos de acordo com as regras de
especificação da linguagem de definição de dados, e, segundo
a RFC 3741 [13], já existia na época de sua publicação a
definição de cerca de 10.000 objetos e um número
desconhecido de outros objetos definidos unilateralmente por
empresas, grupos de pesquisa e fornecedores de equipamentos.
O SNMP [8] emprega a ASN.1 (Abstract Syntax Notation
One) para a descrição do tipo sintático dos objetos da MIB.
Adota o protocolo UDP (User Datagram Protocol) [13]
para o transporte de mensagens, o que acarreta problemas de
falta de confiabilidade e limitação no tamanho de mensagens,
por não ser orientado a conexão.
C. Vantagens do SNMP
Adoção bastante ampla nos últimos vinte anos em função de
sua simplicidade e flexibilidade [8]. É usado principalmente
para gerenciamento de falhas e de desempenho [4].
D. Limitações do SNMP
A complexidade e diversidade das redes representam hoje
um desafio além da sua capacidade no que diz respeito ao
monitoramento, gerenciamento da configuração e de falhas.
Especificamente, o SNMP não atende os requisitos ideais
para ser considerado um protocolo excelente [6] em relação a:
a) Segurança: garantia de controle de acesso onde
usuários sem direitos são bloqueados para
realização de tarefas e dados do equipamento
protegidos de acesso ou leitura indevidos.
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
152
b) Monitoramento: seus métodos para obter
informações da rede em tempo real são menos
eficientes porque os conjuntos de dados dos
dispositivos e seus estados não estão dissociados.
c) Configuração: o protocolo não provê toda a
variedade de operações de configuração da rede.
Apesar dos avanços no suporte a segurança, nem todos os
equipamentos suportam a terceira versão.
Os dados de dispositivos e os respectivos estados dos
dispositivos estão associados na mesma base, o que torna
menos ágil o processo de obtenção de informações da rede.
Sua aplicação na gerencia de configuração é especialmente
limitada em relação [4] à configuração de sistemas com nós
múltiplos e no provisionamento de serviço.
Complementando as limitações do SNMP em relação a
demandas complexas, [8] uma grande parte da configuração
também é realizada com CLI (Command-Line Interface).
Muitos dispositivos de rede oferecem tal opção como método
para seu gerenciamento por meio de comandos de linha numa
interface própria. Resultando em esforço maior sendo
empregado [8] no aprendizado dos comandos próprios de cada
dispositivo além das limitações do CLI relacionadas à falta de
respostas de erro estruturadas e de uma organização
padronizada para as informações de gerenciamento coletadas
na rede.
IV. NETCONF
O Network Configuration Protocol (NETCONF) foi
definido pelo IETF originalmente por meio da RFC 4741 [17]
de dezembro de 2006, recentemente substituída pela RFC
6241 [3] de junho de 2011, sendo seu principal idealizador
Rob Enns da empresa Juniper Networks. Esta seção apresenta
o material da RFC 6241 de forma a documentar as
características do protocolo numa visão abrangente, mas
sucinta, ideal para o entendimento de suas funcionalidades e
vantagens sobre as brechas identificadas no original SNMP.
A. Proposta
A proposta da RFC 6241 [3] pode ser resumida como a
comunicação dos dispositivos da rede por meio de uma
interface de programação de aplicação (API, Application
Programming Interface) fundamentada no mecanismo de
gerenciamento do protocolo NETCONF, meio pelo qual os
dados de configuração podem ser definidos, obtidos,
manipulados e renovados com níveis adequados de segurança
e empregando uma linguagem formal de definição de dados
descritos de forma hierárquica, textual e padronizada
universalmente.
A Figura 2 apresenta a comunicação realizada por meio de
uma sessão já estabelecida e as mensagens do protocolo e
dados de configuração trocados entre o cliente no dispositivo e
o servidor na aplicação realizados por meio de chamadas de
procedimento remoto ou RPC (Remote Procedure Call)
codificadas em XML (Extensible Markup Language).
As principais vantagens da estruturação em XML são [7]
escalabilidade, formato hierárquico de armazenamento de
dados, alto grau de estruturação e facilidade de transmissão
em rede. Consagrada no mercado de integração, esta
linguagem é capaz de descrever de forma textual dados
complexos, [4] conferindo flexibilidade à definição das
estruturas de dados, campo para adoção de diversas APIs e
kits de ferramentas livres disponíveis no mercado, clareza na
leitura e facilidade no transporte sobre seguros canais
existentes. Os métodos desenvolvidos para as operações do
protocolo NETCONF são documentados em um identificador
de recursos conhecido como URI (Universal Resource
Identifier) das classes de URN (Universal Resource Name) do
XML [15]. O repositório específico na Internet ou
“namespace”,
neste
caso,
é
denominado
urn:ietf:params:dxml:ns:netconf:base:1.0, onde são mantidos
os parâmetros definidos pelo IETF para o NETCONF.
Vantagens sob o ponto de vista de independência quanto ao
protocolo de transporte são alcançadas com o modelo de
comunicação baseado em RPC com chamadas e respostas às
chamadas (<rpc> e <rpc-reply> correspondente).
O protocolo NETCONF [3] transporta a configuração do
equipamento e não seu modelo de dados. Este tem que existir
e ser de conhecimento do próprio dispositivo, que o anuncia
junto com suas capacidades (do original capabilities) –
detalhes das operações suportadas e restrições do modelo –
durante a fase inicial de intercâmbio entre cliente e servidor no
início de uma sessão NETCONF.
Por meio da URI [14] são anunciados os mecanismos
disponíveis para o determinado recurso ou caso de uso
envolvido na sessão. O exemplo seguinte [14] indica que são
passíveis de alteração os dados de um recurso em produção,
condição anunciada dentro de uma tag capability que, por sua
vez, contém uma URI com a designação :writable-running
(sendo o termo “running” uma referência ao sistema em
execução, em oposição ao termo “candidate” que é empregado
como a nova configuração candidata a substituir a versão atual
do sistema).
<capability>
urn:ietf:params:netconf:capability:writable-running:1.0
</capability>
Resumindo, a informação necessária para manter o
dispositivo no estado de execução ideal é o foco do protocolo,
orientado a conexão segura onde os dados e operações são
codificados em XML e as capacidades dos dispositivos devem
ser anunciadas no estabelecimento de uma sessão NETCONF
persistente.
B. Camadas
Figura 2: Paradigma do NETCONF
São quatro as camadas em que o NETCONF é
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
conceitualmente dividido em níveis que vão do mais baixo ao
mais alto: transporte seguro, mensagens, operações e
conteúdo, propriamente dito, como apresentado na Figura 3.
Figura 3: Camadas Conceituais
1) Camada de Transporte Seguro
O NETCONF pode ser transportado por qualquer protocolo
de transporte que atenda aos seguintes requisitos:
a) Apresente mecanismo para indicar o tipo de
sessão (cliente ou servidor)
b) Sendo o NETCONF orientado a conexão:
mantenha conexão persistente entre os pares,
execute a entrega sequenciada de dados e libere
automaticamente os recursos na desconexão
c) Garanta a autenticação, integridade dos dados e
sua confidencialidade.
Ainda segundo a RFC 6241 [3], implementações do
NETCONF devem suportar o mapeamento para o protocolo
SSH (Secure Shell) e a lista de discussões [15] mantida no
fórum do IETF indica ser este o protocolo de transporte mais
amplamente adotado nas soluções atuais. O estabelecimento
de sessões SSH para o transporte de dados NETCONF em
canal seguro como um subsistema SSH é definido pela RFC
6242 de junho de 2011 [19].
Também são fornecidos pelo IETF [4] mecanismos de
transporte baseados em SOAP (Simple Object Access
Protocol) e BEEP (Blocks Extensible Exchange Protocol).
SOAP é um protocolo de transporte independente que traz
como principal funcionalidade o mecanismo de descoberta de
serviços, abordado nesta seção na subseção D, que trata de
integração. BEEP sendo um protocolo peer-to-peer agrega
vantagem no suporte a muitos dispositivos conectados
serialmente. A segurança do SOAP é provida via HTTPS
(Hyper Text Transfer Protocol Secure), enquanto que no
BEEP é suportada por SASL (Simple Authentication and
Security Layer).
2) Camada de Mensagens
Originalmente denominada RPC na RFC 4741 [17], esta
camada passou a ser indicada como Mensagem na nova RFC
6241 [3] ampliando sua representação como camada para
fornecer mecanismo de enquadramento simples e
independente da camada de transporte para RPCs codificadas
e, também, notificações. Estas sendo documentadas
especificamente pela RFC 5717 [18], onde são apresentados
os mecanismos necessários para bloqueio de dados do sistema
em produção alvos de mudanças.
Nesta camada ocorre o envio de mensagens RPC pelo
cliente [6] ao servidor, por meio da conexão segura para, por
153
exemplo, solicitar informação ou realizar alguma mudança na
configuração. O servidor [6] responde às solicitações enviando
o resultado de volta ao cliente pelo mesmo caminho.
3) Camada de Operações
As diversas operações disponíveis para os trabalhos de
recuperação de informações e gerenciamento de configuração
são definidas nesta camada [6]. Elas são invocadas como
métodos RPC codificados em XML [4].
A descrição formal da sintaxe e da codificação XML das
operações do protocolo encontra-se no módulo YANG (Yet
Another Next Generation) da RFC 6241 [3]. Esta é uma
inovação em relação à RFC original [17] que previa um
esquema XML, agora substituído por uma linguagem
específica para modelagem dos dados de configuração e de
estado manipulados pelo protocolo NETCONF denominada
YANG, estabelecida pela RFC 6020 [20].
YANG é usada para definir [14] a sintaxe a semântica tanto
na camada de conteúdo quanto dos dados no banco de dados
de configuração do NETCONF mantido e consultado pelo
servidor.
Existem conceitualmente [14] três tipos de bancos de dados:
· Running (configuração atual do dispositivo e
sempre presente);
· Candidate (base mantida pelas operações do tipo
<edit-config> e presente caso a capacidade seja
suportada pelo servidor, apenas afetará a base
Running após a realização de uma operação
<commit>) e
· Startup (representação a configuração que será
usada na próxima inicialização do dispositivo e
também depende da capacidade do servidor para
estar presente).
Além das nove operações básicas, o conjunto de operações
comporta também a definição de capacidades [7] que permite
obter escalabilidade destas operações primitivas. A Tabela I
apresenta a relação de operações básicas e respectivas
descrições e a Tabela II indica as operações ampliadas pelas
capacidades disponíveis.
TABELA I
OPERAÇÕES BÁSICAS DO NETCONF
OPERAÇÃO
get
get-config
edit-config
copy-config
delete-config
lock
unlock
close-session
kill-session
DESCRIÇÃO
Recupera dados e/ou estatísticas da
configuração atual
Recupera dados da configuração atual
Modifica os dados de configuração
Copia os dados de configuração
Apaga os dados de configuração
Bloqueia os dados de configuração para que
somente possam ser alterados na sessão atual
Libera os dados de configuração para alteração
por qualquer outra sessão
Finaliza esta sessão
Finaliza outra sessão
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
154
TABELA II
OPERAÇÕES AMPLIADAS DO NETCONF
OPERAÇÃO
commit
CAPACIDADE
:candidate
discard-changes
:candidate
validate
:validate
DESCRIÇÃO
Substitui todo o conteúdo da base de
dados atuais <running/> pelo da base
de dados candidatos <candidate/>
Elimina todas as mudanças da base
de dados candidatos <candidate/>
tornando-a igual em conteúdo à base
de dados atuais<running/>
Valida todo o conteúdo da base de
dados de configuração
4) Camada de Conteúdo.
Camada de mais alto nível relacionada aos dados de
configuração e de notificação. Apesar de sua especificação
estar fora do escopo da documentação do NETCONF [3], são
esperados esforços na padronização dos modelos de dados
suportados. O uso da linguagem YANG [20] para a
modelagem da camada de conteúdo é uma iniciativa voltada
nesta direção.
A definição completa dos dados [20] enviados entre cliente
e servidor NETCONF é fruto da modelagem e organização
hierárquica dos dados, passíveis de divisão em módulos e
submódulos, condicionados semanticamente para a realização
das operações suportadas pelos dispositivos.
A próxima seção deste trabalho aborda a organização e a
comunicação entre agentes e gerentes NETCONF na qual o
papel do modelo de dados é de alta importância.
C. Arquitetura
Identificadas as quatro camadas desde transporte seguro até
conteúdo que são responsáveis pela comunicação e realização
das operações solicitadas entre clientes e servidores, nesta
seção avalia a estrutura interna dessas duas pontas.
A arquitetura considera como agente cada cliente instalado
ou disponível nos dispositivos gerenciáveis da rede e gerente o
servidor que gerencia tais dispositivos enviando mensagens de
monitoração ou configuração através da rede.
Mensagens recebidas [5] devem ser desencapsuladas do
envelope SOAP, usado na comunicação entre aplicativos via
RPC na Internet por meio de HTTP (Hiper Text Transfer
Protocol), e seu conteúdo processado por um interpretador
XML no módulo de encapsulamento e desencapsulamento de
mensagens.
Notificações são resultantes de eventos [21] interessantes
para o gerenciamento do dispositivo na rede como: mudança
na configuração, falha, mudança no estado, ultrapassagem de
um limite pré-estabelecido ou mensagem recebida pelo
sistema. Portanto, notificações podem ter origem direta ou
indireta a partir de mensagens dirigidas ao agente NETCONF.
O módulo de notificação [5] conecta-se aos dispositivos para
monitorar seu status, funcionando como um mecanismo de
relatório de eventos que envia mensagens ao servidor por sua
própria iniciativa.
Casos de mudanças são tratados pelo processador de
operações [5] que recupera e modifica, segundo a instrução, os
dados contidos no repositório de objetos do dispositivo. Neste
ponto podem ser empregados mecanismos de filtragem
“subtree” ou “xpath” para a busca por parâmetros a porções
específicas da árvore hierárquica de objetos e atributos dentro
da base de dados, delimitando o alcance das operações
envolvidas.
Observamos ainda no diagrama da Figura 3 a interação com
a base de dados local que [5] armazena as três versões, como
mencionado anteriormente: dados em produção (running),
dados candidatos (candidate) a substituir a versão em
produção e dados de inicialização (startup) representando o
estado inicial dos dados do dispositivo.
2) Gerente NETCONF
As funções componentes do gerente NETCONF [5] são
três: interface com usuário, processador principal e banco de
dados XML, detalhados apresentados na Figura 5.
1) Agente NETCONF
O papel do agente NETCONF [5] é fundamental no
funcionamento e desempenho do sistema e comporta três
módulos distintos: o de encapsulamento e desencapsulamento
para o processamento de mensagens a serem enviadas ou
recebidas pelo sistema, e os módulos de notificação e de
operação, representados esquematicamente pela Figura 4.
Figura 5: Gerente NETCONF
Figura 4: Agente NETCONF
Na camada de interface do usuário [5] os dois primeiros
recursos de importação de arquivos e seleção de objetos são
voltados para a seleção pelo usuário do módulo e do objeto
alvo de sua necessidade de controle ou monitoração. Então,
poderão ser definidas as operações, parâmetros e as bases de
dados envolvidas no componente de configuração de
parâmetros. A consulta a respostas é o módulo desta primeira
camada para exibição de mensagens.
O processador recebe, analisa e processa comandos da
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
interface do usuário e mensagens dos agentes nos dispositivos.
O analisador e gerador de mensagens é o componente
responsável pelo processamento dos comandos recebidos
convertidos em respectivas mensagens para os agentes nos
dispositivos alvos. Como apresentado na subseção A desta
seção, tais mensagens são encapsuladas em envelopes SOAP e
pacote HTTP e são enviadas após a criptografia com SSL.
Nesta camada também é realizado o envio e recebimento de
mensagens dos objetos gerenciados ou sinalizações geradas
pelos mesmos, que são apresentadas para o usuário na camada
superior.
A terceira e última camada é a de banco de dados [5] onde
são mantidos os registros diários das transações (log) e
armazenados os dados de configuração dos dispositivos da
rede.
D. Integração
NETCONF é capaz de suprir as lacunas do SNMP e CLI
aportando valor no gerenciamento de redes complexas,
empregando operações e notificações padronizadas e bases de
dados apropriadas para manter e gerenciar com segurança os
dados de configuração.
Um sistema de gerenciamento de rede baseado em
NETCONF [8] deverá representar ganhos significativos sob
estes vários aspectos, mas é possível conviver com
dispositivos baseados em CLI e agentes SNMP integrando-os
com recursos NETCONF.
A Figura 6 [8] esquematiza em três níveis uma arquitetura
integrada para sistemas de gerenciamento baseados em
NETCONF.
Figura 6: Arquitetura Integração NETCONF [8]
O gerente NETCONF no nível mais alto é capaz de
gerenciar dispositivos de fornecedores diversos que contém ou
não com recursos específicos (agente NETCONF).
A camada intermediária é a mais importante porque [8]
apresenta gateways para traduzir mensagens e providenciar a
conversão da organização de dados entre o gerente NETCONF
e dispositivos baseados em agentes SNMP ou em CLI.
Os dispositivos gerenciados estão representados no nível
inferior. São apresentadas duas abordagens [8] para agilizar e
facilitar a localização destes dispositivos:
1. Por meio de algoritmos de roteamento
habitualmente empregados nos sistemas de
gerenciamento de rede tradicionais; ou
2. Empregando a tecnologia de web services baseada
155
na arquitetura orientada a serviço (SOA ServiceOriented Architecture).
Nesta segunda abordagem, [8] cada agente é considerado
como um serviço, cabendo ao gerente o papel de investigar
serviços disponíveis e fazer solicitações aos agentes. A
descoberta dos serviços pelo gerente é possibilitada pela
publicação de arquivos WSDL (Web Services Description
Language) com informações de cada agente por meio de um
centro de registro UDDI (Universal Description, Discovery
and Integration), que gerencia informações e metadados do
catálogo de serviços. A descoberta de um agente pelo gerente
envolve, portanto, a pesquisa e obtenção de informações
contidas no respectivo arquivo WSDL publicado por aquele
serviço como, por exemplo, o tipo de agente e seu endereço
IP. A partir deste ponto, o gerente passa a interagir com o
agente por meio do modelo de conexão SOAP.
Figura 7: Aplicação Web Services NETCONF
A ilustração da Figura 7 destaca os serviços web dispostos
nas suas funções, as operações entre eles e a tecnologia
aplicada.
As funções dos gateways entre agentes SNMP e CLI e o
gerente NETCONF, ilustrados na camada intermediária da
Figura 6 e necessários para o estabelecimento da arquitetura
cliente servidor em ambientes de rede heterogêneos, são
apresentadas a seguir.
1) Gateway NETCONF/SNMP
São
duas
as
principais
tarefas
do
gateway
NETCONF/SNMP: conversão dos modelos de dados e
mapeamento de mensagens.
Como apresentado na seção II o SNMP adota a estruturação
de dados de objetos em MIB, enquanto que o NETCONF
emprega organização em módulos YANG codificados em
XML. A conversão de dados entre os dois modelos envolve
quatro passos [8]:
1. Análise léxica;
2. Análise sintática;
3. Atividades de conversão: importação da
declaração, tradução dos tipos de dados, tradução
de cláusulas macro e mudança na estrutura; e
4. Geração OID (Object Identifier).
A partir das análises léxica e sintática preliminares é obtida
a correspondência entre as funções ou operações e gerada uma
árvore gramatical que servirá de base para a terceira e [8] mais
importante etapa da conversão. Este passo é iniciado com a
importação da declaração SNMP produzindo duas saídas: uma
declaração abreviada de namespace e a localização do
esquema correspondente. A tradução de tipos de dados tem
sido proposta junto ao IETF desde 2008 (a terceira versão é de
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
156
2010) [26] de MIBs para XSD (XML Schema Definition) de
forma a garantir uniformidade, interoperabilidade e a
possibilidade de reutilização de MIBs antigas. Finalmente, são
gerados os OIDs, identificadores usados para localizar os nós
no mapeamento das mensagens entre NETCONF e SNMP.
A linguagem YANG recentemente publicada para a
modelagem dos dados da camada de conteúdo do NETCONF
[20] mantém compatibilidade com o SMIv2 (Structure of
Management Information version 2). Portanto, módulos MIB
baseados em SMIv2 podem ser automaticamente traduzidos
em módulos YANG para acesso exclusivo de leitura.
2) Gateway NETCONF/CLI
Neste gateway é estabelecida a tradução para cada objeto
gerenciado, que resulta [8] em dois arquivos: o primeiro
guarda o mapeamento dos comandos específicos próprios para
pás operações NETCONF e o outro armazena a organização
dos dados em XML. Estes arquivos [8] devem ser
inicializados logo antes do gateway ser iniciado, podendo,
caso necessário, serem acrescentados novos arquivos pelo
usuário durante o processo.
Também é apresentada uma solução [4] considerada ideal
por não envolver mecanismo de tradução, em que é previsto
upgrade software com a instalação de um agente NETCONF
no dispositivo SNMP para sua integração na rede NETCONF.
V. DESAFIOS DO NETCONF
Nesta seção são explorados os desafios e direções apontadas
por pesquisadores para o sucesso das novas propostas
representadas pelo NETCONF.
A. Disseminação
O primeiro desafio do NETCONF é a disseminação de seu
uso no cenário atual de dispositivos de redes baseados em CLI
e agentes SNMP encontra-se amplamente difundido.
As alternativas de integração de recursos NETCONF por
meio de gateways ou via instalação de agente NETCONF em
dispositivo baseado em SNMP apresentadas na seção IV
representam o caminho de adoção gradual da nova arquitetura
necessário para viabilizar benefícios e investimentos ao longo
do tempo.
Grandes fabricantes como Cisco [22], Juniper [23] e
Huawei [24] divulgam a incorporação em seus sistemas de
recursos que garantem a interoperabilidade necessária. Seus
profissionais participam nas pesquisas, elaboração de RFCs,
publicação de artigos científicos, instituição de patentes [25],
contribuindo, enfim, no estabelecimento do novo protocolo
NETCONF. Rob Ennes, principal autor das especificações do
NETCONF é funcionário da empresa Juniper.
B. Controle de Acesso
Além do emprego de protocolos de transporte seguros,
como o SSH, são recomendados [6] mecanismos baseados em
perfis para o controle eficiente do acesso e proteção dos dados
envolvidos nas operações de gerenciamento.
Dentre as políticas disponíveis para incorporação no
NETCONF são indicadas o RBAC (Role-based Access
Control) e o RuBAC (Rule-based Access Control). Sendo a
diferença fundamental entre eles o emprego de atribuições
(roles) aos clientes ou a aplicação de regras (rules) aos grupos
de usuários.
Uma role é definida [6] como um conjunto de permissões
aos recursos do sistema apropriados ao papel envolvido no
trabalho do cliente usuário do sistema de gerenciamento de
rede. O RBAC estabelece autorizações de acesso aos objetos
por meio de papéis (roles), em vez de especificar todos os
direitos dos usuários, a eles serão atribuídas as roles
necessárias para o desempenho de sua função.
Regras pré-determinadas são usadas para permitir acesso a
sistemas e informações pelo RuBAC, que [6] intercepta cada
solicitação de acesso e compara os direitos do usuário em
relação às regras, liberando ou não o acesso. Regras podem ser
estabelecidas sobre qualquer atributo do sistema relacionado
aos usuários, como: domínio, host, protocolo, rede ou
endereços IP.
Existem diversos mecanismos para controle de acesso e eles
podem ser combinados. Por exemplo, [6] uma combinação
poderia ser feita com RuBAC e RBAC, onde a role seria vista
como mais um dos atributos na configuração de regras.
Portanto, a recomendação é a de que seja incorporada a
combinação de métodos para garantir tanto flexibilidade
quanto eficiente e rígido controle de acesso para o NETCONF.
A subseção A da seção VI aborda as novidades atuais do
mercado em relação ao tema de segurança.
C. Eficiência de Desempenho
O desafio de alcançar eficiência no desempenho,
considerando redes complexas e grande volume de dados
envolvido, está relacionado a três aspectos [6]:
1) Redução de latência
A conexão TCP é estabelecida no NETCONF antes que os
dados sejam transferidos o que representa ganho de
desempenho comparado ao UDP adotado pelo SNMP. Porém,
[6] cuidados devem ser tomados para evitar freqüentes
liberações e restabelecimentos de conexões.
2) Redução de overhead na rede
O overhead de rede [6] está relacionado à porção de banda
na rede sendo usada para transmissão de mensagens de
controle e, portanto, indisponível para o tráfego de dados dos
usuários. Por sua característica textual estruturada, as
informações codificadas em XML sofrem aumento na
quantidade de dados usados na sua representação.
Funcionalidades adicionais e necessárias para atender os
gaps do SNMP como: conexão via TCP, transporte SSH e o
anúncio de capacidades no início da conexão entre cliente e
servidor [31] resultam em overhead adicional na camada de
transporte.
São recomendados esforços [6] na área da compactação
para reduzir o tamanho das mensagens.
3) Recuperação de Alto Volume de Dados
Assim como o SNMP [6] enfrentou problemas para
executar operações envolvendo a recuperação de alto volume
de dados por conta de limitações do seu modelo de dados, o
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
NETCONF também deve se preocupar em prover melhores
opções para a recuperação dos seus dados, facilitando a
obtenção dos dados pelos clientes. Na próxima subseção D
desta seção será abordada a limitação atual quanto à
indisponibilidade de obtenção exclusiva de dados de estados e
que implica em aumento do tráfego de dados.
D. Operações sobre Estados
Operações exclusivas para recuperação de dados de estados
dos objetos gerenciados não estão disponíveis. As operações
atuais do NETCONF para obtenção de dados dos objetos
gerenciados estão divididas entre a obtenção de dados de
configuração (<get-config>) e de dados tanto de configuração
quanto de estado (<get>).
Por serem os dados de estados [6] informações adicionais
de um sistema capazes de evidenciar o status de
funcionamento da rede, sua obtenção em tempo real é o
principal trabalho do monitoramento da rede. Tal operação na
proposta atual do NETCONF resulta no retorno de quantidade
extra de informação (dados de configuração) e aumento de
utilização da rede desnecessário.
VI. AVANÇOS DO NETCONF
Esta seção descreve os avanços atuais do mercado na área
de segurança, no desenvolvimento de sistemas baseados no
NETCONF e o resultado de estudo comparativo sobre as
eficiências dos protocolos NETCONF e SNMP em operações
de gerenciamento de configuração.
A. Segurança
Como abordado na seção V, há orientação para que
funcionalidades apropriadas na área de segurança sejam
associadas às características básicas do NETCONF orientado a
conexão segura via SSH. Pesquisadores publicaram
recentemente dois trabalhos nesta área: aplicação de XACML
(Extensible Access Control Markup Language) estendido [30]
e modelo NACM (NETCONF Access Control Model) [28].
1) XACML
Em [30], os autores apresentaram um mecanismo de
controle de acesso baseado no XACML da Oasis, aprimorado
para trabalhar com a filtragem de elementos por subtree. Este
trabalho foi realizado com base na ferramenta BUPT-NEP
(Beijing University of Posts and Telecommunications –
NETCONF Experimental Platform).
O XACML [32] comporta esquema baseado em XML para
representação de políticas de direitos e autorizações,
descrevendo [30] a linguagem da política de controle de
acesso e a de solicitação de acesso e resposta. A política é
representada por uma árvore booleana de combinações de
predicados que autoriza um usuário a realizar ações sobre
determinados recursos.
Quatro módulos funcionais compõem a arquitetura do
XACML [30]: PEP (Policy Enforcement Point), PDP (Policy
Decision Point), PAP (Policy Administration Point) e PIP
(Policy Information Point). PEP processa as solicitações de
acesso, realizando a tomada de decisão com a aplicação da
política. PDP avalia a política aplicável e devolve uma decisão
157
de autorização. PIP funciona como a fonte de atributos ou
dados necessários para a avaliação da política. O esquema de
controle de acesso do BUPT-NEP baseado nesta arquitetura é
representado pela Figura 8.
Figura 8 Controle de Acesso BUPT-NEP [30]
O contexto XACML descreve as entradas e saída do PDP,
isolando a linguagem core do XACML do ambiente da
aplicação. A fim de adotar em um sistema NETCONF o
XACML [30] foi necessária a conversão de RPC para o
contexto XACML e a criação de método para avaliação das
chamadas RPC em relação à política XACML. O contexto
XACML integrado ao NETCONF está representado na Figura
9.
Figura 9 Contexto XACML NETCONF [30]
Subtree é o mecanismo especificado para o NETCONF [3]
que permite a uma aplicação fazer seleção por específicas sub
árvores da hierarquia de atributos do objeto gerenciado a
serem incluídas na resposta a operações do tipo <get> ou <getconfig>. O XACML recebeu as definições de novo tipo de
dado (subtreeExpress), novo identificador de atributo
(subtree) e a nova função :subtree-xpath-node-match
permitindo a comparação entre expressões da política
XACML (xpath) com a RPC com filtragem subtree do
NETCONF, retornando o resultado como verdadeiro quando é
localizado nó na política com a mesma identidade do nó
indicado no filtro da chamada NETCONF.
A proposta de expansão do XACML para atender sua
integração ao NETCONF traz como principal vantagem a
agregação de recurso de segurança, controle e política de
acesso [30] flexível e extensível baseados em padrões abertos.
2) NACM
Esforços na definição de um modelo de controle de acesso
apropriado estão sendo feitos pelo IETF resultando na
documentação do NACM [28], atualmente na terceira edição
de proposta draft. Trata-se de um modelo conceitual
concebido para configurar e monitorar os procedimentos de
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
158
controle de acesso necessários para a aplicação de uma
política adequada de controle de acesso pelo operador no
ambiente NETCONF. Regras são configuradas de forma
simples e aplicadas a grupos de usuários. O modelo prevê
novas tags de segurança a serem representadas na linguagem
YANG e que o controle de acesso seja aplicado para todas as
mensagens RPC recebidas pelo servidor, individualmente, em
cada sessão ativa. Exceções apenas para mensagem de
encerramento de sessão (<close-session>) e sessão de
recuperação de falha (recovery session). Sendo a sessão
autorizada para executar a operação RPC solicitada, o
processamento continua. Caso contrário, a solicitação é
rejeitada com uma mensagem de acesso negado. Operações
envolvendo a base de dados de configuração ou de estados
devem receber autorização de acesso também aos respectivos
nós para que sejam realizadas.
Ambos os esforços (XACML e NACM) apontam para o
amadurecimento de novas definições para que o NETCONF
faça frente ao desafio do controle de acesso.
B. Ferramentas
Diversos esforços de implementação de sistemas
NETCONF foram identificados na pesquisa e são descritos
brevemente nesta seção.
1) YUMA
Yuma (YANG-based Unified Modular Automation) é
definido [14] como um kit de ferramentas voltado ao
protocolo NETCONF composto por compilador de módulo
YANG (yangdump), servidor NETCONF (netconfd), cliente
para comunicação entre o servidor NETCONF e servidor
Open SSH, cliente NETCONF (yangcli) e utilitário para
comparação de módulo YANG (yangdiff).
tarefas de gerenciamento em redes complexas pelo Time de
Pesquisas Madynes do LORIA (Lorraine Laboratory of IT
Research and its Applications), foram implementadas [33]
todas as operações do NETCONF no YencaP, incluindo a
seleção de dados de dispositivos suporte por meio de filtragem
usando tanto método subtree quanto xpath. Suporta [6]
criptografia, autenticação e controle de acesso como parte da
arquitetura global de segurança para o NETCONF.
4) Tail-f Systems
Fabricante de soluções comerciais adotadas por grandes
provedores de equipamentos de rede, como o ConfD e o NCS,
Tail-f [34] tem contribuído para o desenvolvimento do
NETCONF e YANG. Aplicativos de gerenciamento podem
ser construídos com ConfD e o NCS é uma aplicação de
gerenciamento para configuração automatizada projetada para
ampliar as funcionalidades de sistemas de suporte à operação e
de monitoramento de elementos.
C. Comparativo de Desempenho na Configuração
Estudo recente de maio de 2011 [31] com foco específico
em operações de configuração de dispositivos envolvendo até
100.000 objetos gerenciados foi realizado para a medição
quantitativa do desempenho dos protocolos NETCONF e
SNMP.
O ambiente para os testes e coleta dos dados esquematizado
na Figura 11, envolveu sistema de gerenciamento e a
simulação de dispositivos de rede.
2) BUPT-NEP
Sistema desenvolvido pela Universidade e o Instituto de
Pesquisa de Pequim composto por três partes [8]: gerente,
agente e grupo de módulos, que trabalham no modo
cliente/servidor, representados na Figura 10.
Figura 11 Ambiente Avaliação Protocolos [31]
Figura 10 Arquitetura BUPT-NEP [8]
O primeiro composto por aplicações cliente NETCONF e
gerente SNMP. O seguinte constituído de servidor comercial
Tail-f ConfD com componentes servidor NETCONF, agente
SNMP e modelo de dados equivalente tanto na versão SNMP
MIB quanto em módulo YANG para uma classe de 100.000
objetos gerenciados. Completando o ambiente, um analisador
de pacotes para realização de medições e cálculos do
desempenho.
O agente e os módulos funcionam como um servidor, sendo
o agente responsável pelo recebimento, análise das mensagens
RPC e na chamada de funções de determinado módulo para a
execução das tarefas. Os módulos computam o resultado,
devolvendo-o para o agente, que o empacota em mensagens
do tipo <rpc-reply> encaminhadas ao gerente. Os módulos são
os blocos funcionais que representam os objetos gerenciados.
3) YencaP
Solução experimental desenvolvida para execução de
As análises obtidas em tal estudo comparativo encontram-se
sumarizadas na Tabela III.
Os resultados apresentados [31] indicam comprovada
superioridade do NETCONF em relação ao SNMP em número
de transações necessárias para operações porque aquele foi
capaz de configurar 100.000 objetos numa única transação,
enquanto que o SNMP necessitou de 2.779 transações para o
mesmo número de objetos. Esta vantagem por si só compensa
a maior utilização de largura de banda pelo NETCONF,
resultante de funcionalidades desejáveis e indisponíveis no
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
SNMP (como, por exemplo, a orientação a conexão sobre
TCP, SSH e XML).
TABELA III
RESULTADO DA CONFIGURAÇÃO POR OBJETOS GERENCIADOS
ASPECTOS
Número de
Pacotes
Número de
Bytes
Tempo de
Operação
Número
de
Transações
OBJETOS
0 – 1.000
10.000 – 100.000
0 – 1.000
10.000 – 100.000
0 – 1.000
10.000 – 100.000
0
1.000
10.000
100.000
SNMP
x
x
x
x
x
39x
x
28x
279x
2.779x
NETCONF
4,1x
7,2x
8x
29x
4,5x
x
x
x
x
x
cada vez mais complexos e inteligentes devem também
adquirir recursos que as tornem mais competentes e ágeis. O
papel expressivo do monitoramento de rede para a garantia de
qualidade com o advento de novos serviços também deverá ser
beneficiado. O NETCONF traduz o ambiente ideal para a
arquitetura de soluções de gerenciamento adequadas a esta
nova geração de redes.
REFERÊNCIAS
[1]
[2]
[3]
VII. CONCLUSÕES
Muito esforço e pesquisa têm sido aplicados na busca por
uma alternativa ao SNMP na gerência das novas redes
impulsionadas pela demanda crescente de serviços conectados.
A indústria de fabricantes se prepara para suportar a migração
gradual ou integral e tem partido dos fornecedores alto
investimento de recursos em pesquisas na área de
gerenciamento de configuração de rede. Novos artigos
publicados sobre o tema são acompanhados de promessas de
aprofundamento em área afim. RFCs complementam e
expandem o conhecimento. Os desafios ainda existem e os
trabalhos apontam na direção da superação.
Acredita-se no NETCONF e na sua adesão pelos
provedores de serviços para a gerência de configuração, área
de sua inquestionável superioridade em relação ao SNMP,
intensamente explorada nesta era de ampliação de redes,
implantação de novas tecnologias, incorporação de
equipamentos e conformidade a regras de comercialização.
Caso recente como a portabilidade de números no Brasil e a
aplicação de mecanismos pouco eficientes na sua implantação
na rede das operadoras de telecomunicação pode ser citado
como representativo da lacuna de tecnologia na área de
configuração.
Analisando os esforços da CISCO [22], Juniper [23] e
Huawei [24] e os produtos comerciais da Tail-F Systems [34]
provendo o acoplamento de conectores NETCONF, SNMP e
CLI é possível concluir que a diversidade do mercado e a
praticidade e relação custo/benefício oferecidas por soluções
SNMP e CLI levarão mais rapidamente à fase de convivência
das tecnologias NETCONF e SNMP do que à substituição
desta última.
Na medida em que evoluções naturais na complexidade das
redes passarem a requerer maior confiabilidade e segurança, as
empresas verão vantagem adicional no NETCONF
aumentando sua popularidade no mercado. Novas tecnologias
como o LTE (Long Term Evolution) na rede móvel de
telecomunicações e o IPv6 (Internet Protocol Version 6) nas
redes IP são os próximos impulsionadores nesta mudança de
percepção em relação a conceitos como prático e simples.
As ferramentas que gerenciam as redes e seus dispositivos
159
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
KUROSE, James F.; ROSS, Keith W.; Redes de computadores e a
Internet: uma abordagem top-down. 5a edição - São Paulo, Brasil:
Addison Wesleyl, 2010, pp. 2–18, 45-50, 553-574.
BANNISTER,Jeffrey; MATHER, PauL; COOPE, Sebastian Coope,
Convergence Technologies for 3G Networks IP, UMTS, EGPRS and
ATM. West Sussex, England: John Wiley & Sons Ltd, 2004, pp 509
ENNS, R. [et al], Network Configuration Protocol (NETCONF).
Request for comments (RFC) 6241: Internet Engineering Task Force
(IETF), 2011. Disponível em http://www.rfc-editor.org/rfc/rfc6241.txt
Co-autores: BJORKLUND, M.; SCHOENWAELDER, J.; BIERMAN,
A.
YU, James; AJARMEH, Imad Al, “An Empirical Study of the
NETCONF Protocol” presented at the Sixth International Conference on
Networking and Services, Cancun, Mexico, March 7-13, 2010, Paper
978-0-7695-3969-0/10.
CHANG, Yanan [et al], “Design and Implementation of NETCONFBased Network Management System” presented at the Second
International Conference on Future Generation Communication and
Network, Hainan Island, China, December 13-15, 2008, Paper 978-07695-3431-2/08.
HUANG, Ji [et al], “Challenges to the New Network Management
Protocol: NETCONF” presented at the IEEE First International
Workshop on Education Technology and Computer Science, March 7-8,
2009, Paper 978-0-7695-3557-9/09.
SHISONG, Xiao. RAN, Jia; JUNYING, Guo, “Research and Implement
on Compatibility and Scalability of Agent of Platform for Network
Management based on NETCONF Protocol” presented at International
Conference on Measuring Technology and Mechatronics Automation,
Changsha, China, March 13, 2010, Paper 978-0-7695-3962-1/10.
WU, Baozhen; CHANG, Yanan, “Integrating SNMP Agents and CLI
with NETCONF-Based Network Management Systems” presented at
3rd IEEE International Conference on Computer Science and
Information Technology (ICCSIT), Chengdu, China, July 9-11, 2010,
Paper 978-1-4244-5540-9/10.
Network Working Group. California, EUA. University of California,
Los Angeles (UCLA) [atualizada em April 7, 1969; acesso em August 7,
2011]. Request for Comments: 1. Disponível em http://www.rfceditor.org/rfc/rfc1.txt.
Internet Systems Consortium (ISC). California, EUA. Internet Systems
Consortium, Inc; c2001-2011 [atualizada em January, 2011; acesso em
August 7, 2011] Internet host count history. Disponível em
http://www.isc.org/solutions/survey/history.
The Internet Engineering Task Force (IETF). California, EUA. Internet
Society. Disponível em http://www.ietf.org/.
Simple Network Management Protocol, RFC 1067. [atualizada em
August, 1988; acesso em August 7, 2011]. Disponível em
http://datatracker.ietf.org/doc/rfc1067/
Introduction and Applicability Statements for Internet-Standard
Management Framework, RFC 3410. [atualizada em December, 2011;
acesso em August 7, 2011]. Disponível em
http://datatracker.ietf.org/doc/rfc3410/
Netconf Central, XML-based Network Configuration Tools Online,
YANG Module Database. Andy Bierman; c2008-2011 [atualizada em
August 9, 2012; acesso em August 10, 2011]. Disponível em
http://www.netconfcentral.org/netconf_docs
A URN Namespace for XML.org, RFC 3120. [atualizada em June,
2001; acesso em August 12, 2011]. Disponível em
http://www.ietf.org/rfc/rfc3120.txt
NETCONF Discussion Archive - Date Index. [atualizada em August,
2001; acesso em August 12, 2011]. Disponível em
http://www.ietf.org/mail-archive/web/netconf/current/maillist.html
160
ANAIS DO CONGRESSO DE INICIAÇÃO CIENTÍFICA DO INATEL - INCITEL 2012
[17] ENNS, R. Network Configuration Protocol (NETCONF). Request for
comments (RFC) 4741. [atualizada em December, 2006; acesso em
August 12, 2011]. Disponível em http://www.rfceditor.org/rfc/rfc4741.txt
[18] LENGVEL, B.; BJORKLUNDM. Partial Lock Remote Procedure Call
(RPC) for NETCONF, RFC 5717. [atualizada em December, 2009;
acesso em August 12, 2011]. Disponível em
http://tools.ietf.org/html/rfc5717
[19] WASSERMAN, M. Using the NETCONF Protocol over Secure Shell
(SSH), RFC 5717. [atualizada em June, 2011; acesso em August 12,
2011]. Disponível em http://www.rfc-editor.org/rfc/rfc6242.txt
[20] BJORKLUND, M. YANG – A Data Modeling Language por The
Network Configuration Protocol (NETCONF), RFC 6020. [atualizada
em October, 2010; acesso em August 14, 2011]. Disponível em
http://www.rfc-editor.org/rfc/rfc6020.txt
[21] CHISHOLM, S.; TREVINO, H. NETCONF Event Notifications.
Request for comments, RFC 5277. [atualizada em July, 2008; acesso em
August 14, 2011]. Disponível em http://www.rfceditor.org/rfc/rfc5277.txt
[22] Network Configuration Protocol. Cisco IOS Network Management
Configuration Guide, Release 12.4T. Cisco Systems, Inc; c2007-2009
[acesso em August 20, 2011]. Disponível em
http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_
cns_netconf_ps6441_TSD_Products_Configuration_Guide_Chapter.htm
l
[23] NETCONF XML Management Protocol. Juniper Networks, Inc; c19992011 [acesso em August 20, 2011] Disponível em
http://www.juniper.net/support/products/netconf/
[24] The Value of Future Data Center Transformation. Huawei Technologies
Co. Ltd.; c1998-2011 [acesso em August 20, 2011]. Disponível em
http://www.huawei.com/ilink/en/about-huawei/publications/huaweiservice/HW_089324?dInID=30530&dInDocName=HW_089288&relate
dID=26497&relatedName=HW_089319
[25] A Method and System for Sending the Events Notices Based on
NETCONF. European Patent Application EP2166699.
FreePatentsOnline.com; c2004-2011. [acesso em August 20, 2011].
Disponível em http://www.freepatentsonline.com/EP2166699.html
[26] Conversion of MIB to XSD for NETCONF, draft-xiao-conversion-dm02. Network Working Group. [atualizada em September 11, 2009;
acesso em August 25, 2011]. Disponível em
http://tools.ietf.org/html/draft-xiao-conversion-dm-02
[27] CHANG, Yanan; CHEN, Limiao; WU, Baozhen, “A NETCONF-based
Distributed Network Management Design Using Web Services and P2P”
presented at the Fifth Annual China Grid Conference, Guangzhou,
China, July 16-18, 2010, Paper 978-0-7695-4106-8/10.
[28] BIERMAN, A; BJORKLUND, M. Network Configuration Protocol
Access Control Model, draft-ietf-netconf-access-control-04. Internet
Engineering Task Force. [atualizada em June 14, 2011; acesso em
August 25, 2011]. Disponível em http://tools.ietf.org/html/draft-ietfnetconf-access-control-04
[29] WUANG, Rui [et al], “The Implementation and Analysis of the
Monitoring Module based on NETCONF” presented at the IEEE 2008
International Symposium on Information Science and Engineering
(ISISE), Shanghai, China, December 20-22, 2008, Paper 978-0-76953494-7/08.
[30] WUANG, Jinjin [et al], “Improvement of XACML Access Control
Mechanism based on NETCONF Subtree Filtering RPC” presented at
the IEEE First 2010 International Conference on Network Infrastructure
and Digital Content (IC-NIDC2010), Beijing, China, September 24-26,
2010, Paper 978-1-4244-6853-9/10.
[31] HEDSTROM, B; WATWE, A; SAKTHIDHARAN, S, “Protocol
Efficiencies of NETCONF versus SNMP for Configuration Management
Functions”, M.S. Thesis, University of Colorado, Colorado, EUA.
[acesso em August 25, 2011]. Disponível em
http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf
[32] Extensible Access Control Markup Language (XACML) Version 3.
OASIS c2010 [atualizada em August 10, 2010; acesso em August 26,
2011]. Disponível em http://docs.oasis-open.org/xacml/3.0/xacml-3.0core-spec-cs-01-en.pdf
[33] CRIDLIG,V; BOURDELLON, J; STATE, R, “YencaP Documentation”,
LORIA-INRIA Lorraine, France. [acesso em August 28, 2011].
Disponível em http://hal.inria.fr/docs/00/04/45/39/PDF/yencapDoc1.1.2.pdf
[34] ConfD Tail-f Systems c2011[acesso em August 30, 2011].
Disponível em http://www.tail-f.com/wordpress/wpcontent/uploads/2010/08/Tail-f-Systems-ConfD-Overview.pdf
[35] MARCONDES, G.A.B., Modelo de Gerenciamento OSI, pp 3-7
(Apostila da disciplina RS117 Gerencia de Rede Operacionais, Curso de
Pós-Graduação em Engenharia e Gestão em Telecomunicações,
INATEL Instituto Nacional de Telecomunicações, MG, Brasil).
Lilian Lyra Villela nasceu no Rio de Janeiro, RJ, em 17 de junho de 1959.
Possui os títulos de Tecnólogo em Processamento de Dados (UNESA, 1991),
Pós-graduação em Gestão de Negócios e Sistemas em Telecomunicações
(UNESA, 2000), Pós-graduação em Gestão e Engenharia de
Telecomunicações (FECAP/INATEL, 2011).
Atuou na área de Comércio Exterior até 1987, voltando-se em seguida para a
área de Informática. Desde 1997 projeta, coordena e desenvolve projetos de
automação de processos em soluções de workflow integradas a portais de
gestão de informação na Diretoria Executiva de Rede da Nova Telefônica
Brasil (Vivo).
Tem interesse em aprofundar seus estudos em nível de mestrado na área TIC,
Tecnologia da Informação e Comunicações, e ampliar suas atividades
profissionais no magistério, compartilhando experiências com novos colegas
da área.
Guilherme Augusto Barucke Marcondes nasceu em Volta Redonda, RJ,
em 19 de setembro de 1968. Possui os títulos de Engenheiro Eletricista com
Ênfase em Eletrônica e Telecomunicações (INATEL, 1991), Especialista em
Administração de Empresas (FEA-USP, 1999), Mestre em Telecomunicações
(INATEL, 2005).
Atua na área de P&D desde 1986, tendo trabalho com desenvolvimento de
hardware e software para diversos segmentos. Desde 1996 é Gerente de
Desenvolvimento de Software do Inatel Competence Center e desde 2010 é
Gerente de Projetos certificado (PMP) pelo PMI. É professor do Inatel desde
2004.