Protocolos e Linguagens de Modelagem e Especificação e da Gerência IETF

Protocolos e Linguagens de Modelagem e Especificação e da Gerência IETF

• Introdução• Linguagens de Modelagem e Especificação de Gerência

IETF– ASN.1– SMI (Structured Management Information) do SNMP– YANG

• Protocolo SNMP (v1, v2c e v3)• MIB-II• MIB-OTN• Protocolo NETCONF• YANG

2 Sumário

• Monitoração de rede

– Monitoração é o processo de obter informação acerca das configurações e estado dos vários elementos de um sistema computacional e preparar essa informação para consumo do sistema de Gerência.

– A preparação da informação pode compreender a geração de relatórios para o administrador do sistema, coletar dados pertinentes de um conjunto de dados brutos ou a compactação de um conjunto muito grande de informação para que essa possa ser interpretada por humanos.

3 Introdução

• O tratamento adequado dessa informação pode facilitar muito as tarefas de Gerência, podendo a informação ser dividida em grupos lógicos relevantes, como:– Informação de estado

• informação acerca do estado de funcionamento de um dispositivo. Um dispositivo pode estar ligado e funcionar corretamente, pode estar ligado mas com falhas de funcionamento ou estar desligado. Essas informações têm um impacto importante numa primeira análise durante as tarefas de Gerência;

– Informação das configurações• A informação sobre as configurações consiste em todos os

atributos de um dispositivo manipuláveis pelo administrador. A monitoração dessa informação pode indicar se um atributo tem um valor válido, se é a causa para a degradação do desempenho do sistema ou mesmo responsável pela falha do mesmo;

4 Introdução

– Estatísticas de desempenho e utilização• Essas informações são normalmente importantes para a gestão

de recursos de um sistema. Aqui estão contempladas informações como o número de utilizadores ou sessões ativas, bem como, informações acerca da latência ou da taxa de transferência;

– Informação de erros• A informação de erros pode indicar falhas ou a operação

incorreta de um dispositivo. Essa informação pode incluir códigos de erro ou o número de erros ocorridos num intervalo de tempo;

– Informação da topologia• Normalmente a topologia de uma rede já é conhecida quando se

inicia o processo de monitoração. No entanto, conhecer no tempo adequado alterações da topologia pode ser vital para o bom funcionamento do sistema ou redução do seu tempo de inatividade ou mau funcionamento.

5 Introdução

• As aplicações de monitoração normalmente seguem uma estrutura de funcionamento idêntica à representada na figura abaixo:

6 Introdução

• Coleta de dados – Consiste na Coleta de dados brutos dos dispositivos ou

aplicações que constituem o sistema.• Pré Processamento

– Esse processamento é feito em tempo real à medida que os dados são coletados e serve para verificar a integridade da informação, para eliminar dados redundantes ou desnecessários e para efetuar as conversões necessárias entre os tipos de dados coletados e os tipos de dados do repositório

• Repositório de dados– Armazenamento com vistas a manter a persistência dos dados

para análise e posterior geração de relatórios. Essa persistência é necessária e permite verificar a evolução dos dados ao longo do tempo e análises de desempenho difíceis de fazer em tempo real.

7 Introdução

• Pós processamento– Para gerar os relatórios é necessário processar os dados

armazenados; a qualidade da informação de um sistema de gestão é extremamente dependente dos algoritmos utilizados para processar os dados nessa fase.

• Relatório– Os relatórios são uma mera apresentação ao administrador

dos resultados do pós-processamento.

8 Introdução

• A coleta de dados de monitoração pode ser dividida em dois modos, monitoração passiva e monitoração ativa:

• Monitoração passiva– A monitoração passiva é feita através das informações

coletadas pelo funcionamento normal do sistema. Não implica nenhum esforço adicional para o sistema, a não ser o envio da informação para o gerente.

– A monitoração passiva utiliza logs, configurações, MIBs, sniffers de redes, entre outros, para produzir informação. O uso de notificações também é considerado monitoração passiva

9 Introdução

• Monitoração ativa:– A monitoração ativa interfere com a carga de trabalho

(workload) do sistema. Implica pedidos explícitos para determinar a informação sobre o sistema. Por exemplo, para medir a latência de um servidor web uma aplicação pode periodicamente consultar um site para analisar a latência ou uptime.

– Outros exemplos são a utilização de ferramentas como o ping ou o traceroute, bastante utilizados em monitoração

10 Introdução

• Sistema de gestão de redes

11 Introdução

• Dispositivos gerenciados contêm objetos gerenciados (MO).

• O conjunto de objetos é armazenado em uma base de informação de gerenciamento (MIB).

• A MIB é descrita em um modelo de informação

• Gerente e agentes se comunicam usando o protocolo de gerência.

• Modelo Gerente/Agente

12 Introdução

• ASN.1 : Abstract Syntax Notation One.

• É uma linguagem para definição de padrões:– Notação formal usada para transmissão de dados pelos

protocolos de telecomunicações.– Independente da linguagem de implementação, aplicação e

representação física dos dados.– Com a ASN.1 o projetista de um protocolo não precisa se

preocupar com a forma com que os dados são transmitidos, e sim com a forma que deve descrever as estruturas de dados, sendo que essa facilita a definição de estruturas de dados bastante complexas.

13 ASN.1

• Recomendações padronizadoras para ASN.1.ISO 8824-1 | ITU-T X.680: Specification of basic notation,ISO 8824-2 | ITU-T X.681: Information object specification,ISO 8824-3 | ITU-T X.682: Constraint specification,ISO 8824-4 | ITU-T X.683: Parameterization of ASN.1 specifications.

• Lista dos padrões comumente usados que são programados no ASN.1:– X.400 (Mensagens eletrônicas)– X.500 (Serviços de diretório)– X.200 (Comunicações de rede)– Solicitação de comentários (RFCs) 2251-2256 (Lightweight

Directory Access Protocol ou LDAP)– Muitas outras RFCs.

14 ASN.1

• Define:– O que é "Tipo".– O que é um "módulo" e qual deve ser sua aparência.– O que é um INTEIRO.– O que é um BOOLEANO.– O que é um "tipo estruturado".– Qual o significado de determinadas palavras-chave (por

exemplo, INÍCIO, FIM, IMPORTAR, EXPORTAR, EXTERNO e assim por diante).

– Como colocar um tipo entre "tags" para que possa ser devidamente codificado.

15 ASN.1

• A notação provê tipos de dados pré-definidos como:– integers (INTEGER),– booleans (BOOLEAN),– character strings (IA5String, UniversalString...),– bit strings (BIT STRING),– etc.,

• Prevê a construção de tipos como:– structures (SEQUENCE),– lists (SEQUENCE OF),– choice between types (CHOICE),– etc.

16 ASN.1

• BER (Basic Encoding Rules):– BER é um conjunto de regras para codificação de dados do

ASN.1 para um fluxo de octetos que pode ser transmitido por um link de comunicações.

– Define• Métodos para codificação de valores ASN.1.• Regras para decisão de quando usar um determinado método.• Formato de octetos específicos nos dados.

• O ASN.1 é como uma “linguagem de programação” (por exemplo C), enquanto o BER é como um compilador para essa linguagem.

17 ASN.1

• Codificação TLV– Ideia: dados transmitidos são auto identificáveis

• T: tipo de dado, um dos tipos definidos do ASN.1• L: tamanho dos dados em bytes• V: valor dos dados, codificados de acordo com o padrão ASN.1

18 ASN.1

• Codificação TLV: Exemplo

19 ASN.1

• Uso do ASN.1 para representar a informação hypotética de um indivíduo: personnel record:– Estrutura do personnelrecord com um valor particular:

20 ASN.1 Exemplos

21 ASN.1 Exemplos

– Os dados de John necessitam ser transmitidos e com isso surge a necessidade de representa-lo em uma sintaxe de transferência. De posse de um tipo ASN.1 definido (como no exemplo anterior) deve-se atribuir valores para que sejam conduzidos de um dispositivo a outro. Nesse caso usa-se a BER. Os dados de John são formalmente gravados em notação de dados padrão como segue:

22 ASN.1 Exemplos

• A descrição do ASN.1 demonstra qual a aparência de um registro pessoal. Mas, mais importante que isso, descreve como os dados do aplicativo devem ser formatados para que se tornem dados ASN.1 antes de dar lugar à codificação.

• Depois disso, o aplicativo mapeia os dados pessoais em uma estrutura de registro pessoal (formato de dados ASN.1), e aplica o BER (Basic Encoding Rules) aos dados ASN.1. Essa é a aparência que deverá ter (com exceção de que os nomes deverão ser convertidos para ASCII):

23 ASN.1

• Quando tudo estiver concluído, o que realmente será transmitido (ou, mais especificamente, o que torna-se a parte dos dados para o pacote na próxima camada) é:

24 ASN.1

• SMI (Structure of Management Information – Estrutura de Informação de gerenciamento).

• Linguagem de definição de dados.– Define os tipos de dados, um modelo de objetos e regras para

escrever e revisar informações de gerenciamento.– Objetos da MIB são especificados nessa linguagem de

definição de dados.– É necessária para assegurar que a sintaxe e a semântica dos

dados de gerenciamento de rede sejam bem definidos e não apresentem ambiguidade.

• A SMI é baseada no ASN.1, porém acrescentou tantos tipos de dados novos que deve ser considerada uma linguagem de definição por direito próprio.

25 SMI

• Tipos de dados básicos da SMI:

26 SMI

James F. Kurose, Keith W. Ross 3º Edição

• A construção OBJECT-TYPE é utilizada para especificar o tipo de dado, o status e a semântica de um objeto gerenciado.

• Há mais de 10.000 objetos definidosem diversas RFCs na internet.

27 SMI

Especifica o tipo de dado básico associado ao objeto

Especifica se o MO pode ser lido, escrito, criado ou ter seu valor incluído em uma notificação

Indica se a definição do objeto é atual e válida, obsoleta ou depreciada.

Definição textual e legível do objeto

• Exemplo: Retirado da MIB do desafio Padtec CampusParty 2012.

28 SMI

• A Construção MODULE-IDENTITY permite que objetos relacionados entre si sejam agrupados, dentro de um “módulo”.

• A construção MODULE-IDENTITY contém cláusulas para documentar informações de contato do autor do módulo, a data da última atualização, um histórico de revisões e uma descrição textual do módulo.

29 SMI

• Como exemplo considere a identificação do módulo da MIB desafio Padtec Campus Party 2012.

30 SMI

Anilton

O povo vai reclamar que o exemplo fala de um concorrente.

RAFAEL

Coloquei uma MIB que achei na internet mas não ajuda com a exemplificação do Módulo pois deixa muitos campos em aberto e com poucas informações relevantes.

• MODULE-COMPLIANCE define o conjunto de objetos gerenciados dentro de um módulo que um agente deve implementar.

31 SMI

• AGENT-CAPABILITIES especifica as capacidades dos agentes relativas às definições de notificação de objetos e de eventos.

32 SMI

33 SMI

• YANG é uma linguagem de modelagem de dados para o protocolo NETCONF, que permite a descrição da hierarquia dos nós de dados e restrições existentes entre eles.

• YANG define o modelo de dados, bem como a forma de manipular esses dados através das operações presentes no protocolo NETCONF.

• Proposta que surgiu do grupo de trabalho conhecido como Netmod Standard Working Group(Netmod WG).– Netmod WG escolheu definir sua própria linguagem,

objetivando ter total controle da sua evolução e maior aderência e foco em gestão de configuração.

34 YANG

• O NETCONF permite o acesso às capacidades nativas dos dispositivos existentes numa rede, definindo métodos para a manipulação dos repositórios de dados de configuração, resgatar dados operacionais e invocar operações especificas.

• Conceitualmente YANG pode ser comparada a SMI, a linguagem usada no framework SNMP para modelagem de MIBs, mostrando-se como uma linguagem de modelagem de dados onde os dados encontram-se distribuídos e acessíveis por meio de um protocolo.

• Os módulos YANG organizam hierarquicamente os dados em árvore onde cada nó é definido pelo seu nome e o seu respectivo valor ou um conjunto de nós descendentes

• YANG será abordada com mais detalhes posteriormente.

35 YANG

• Protocolos de gerência:– CMIP (Common Management Information Protocol)

• Proposto pela ISO no início dos anos 90• Controle (complexo) de redes complexas• Muito presente em redes de telefonia

– SNMP• SNMPv1

– Criado pela IETF em 1988– Simplicidade;

• SNMPv2– RFC1442 Structure of Management Information for Version

2 of SNMP– RFC1448 Protocol Operations for Version 2 of SNMP

• SNMPv3– 1998– Principal característica: Segurança

36 SNMP

• Histórico do Simple Network Management Protocol (SNMP):

– No inicio de 1988, o Internet Architecture Board (IAB), órgão criado com a função de "legislar" sobre os padrões da Internet, declarou ser urgente a necessidade de um modelo padrão de gerência aplicável, em caráter imediato, ao parque computacional instalado na comunidade Internet.

– A ordem foi estabelecer um modelo simples, de fácil implementação e aberto, possibilitando adoção imediata pelos mais diversos fabricantes.

– Existia também a intenção de compatibilizar o modelo de gerência Internet com a proposta de gerencia OSI.

37 SNMP

– Atendendo a demanda do IAB, o Internet Engineering Task Force (IETF) desenvolveu o conjunto de conceitos e protocolos necessários a implementação da atividade de gerencia de redes na Internet.

• Fortemente baseada na arquitetura genérica de gerência baseada no modelo OSI.

• Foi inspirada também no padrão Simple Gateway Management Protocol (SGMP).

– No começo da década de 90 o IAB, percebendo a complexidade e a lentidão com que se desenvolvia o padrão de gerencia OSI, decidiu que não era mais possível esperar pela integração dos padrões.

– Aproveitando os esforços feitos desde 1988, decidiu finalizar a formalização de sua iniciativa própria de gerenciamento, denominada SNMP, e torna-la o padrão de gerencia Internet até que a gerencia OSI pudesse ser implementada

38 SNMP

• O SNMP é um protocolo de gerência definido a nível de aplicação:

39 SNMP

• Operações do Protocolo SNMPExistem duas operações básicas (SET e GET) e suas derivações (GET-NEXT, TRAP).– A operação SET é utilizada para alterar o valor da variável: o gerente

solicita que o agente faça uma alteração no valor da variável;

– A operação GET é utilizada para ler o valor da variável: o gerente solicita que o agente obtenha o valor da variável;

40 SNMP

– A operação de GET-NEXT é utilizada para ler o valor da próxima variável: o gerente fornece o nome de uma variável e o agente obtém o valor e o nome da próxima variável; também é utilizado para obter valores e nomes de variáveis de uma tabela de tamanho desconhecido;

– A operação TRAP é utilizada para comunicar um evento: o agente comunica ao gerente o acontecimento de um evento, previamente determinado.

41 SNMP

– São sete tipos básicos de trap determinados:– coldStart: a entidade que a envia foi reinicializada, indicando que a

configuração do agente ou a implementação pode ter sido alterada;

– warmStart: a entidade que a envia foi reinicializada, porém a configuração do agente e a implementação não foram alteradas;

– linkDown: o enlace de comunicação foi interrompido;

– linkUp: o enlace de comunicação foi estabelecido;

– authenticationFailure: o agente recebeu uma mensagem SNMP do gerente que não foi autenticada;

– egpNeighborLoss: um par EGP parou;

– enterpriseSpecific: indica a ocorrência de uma operação TRAP não básica.

42 SNMP

• Mensagem no Protocolo SNMP– Uma mensagem SNMP deve definir o servidor do qual vai se

obter ou alterar os atributos dos objetos, e que será o responsável pela conversão das operações requisitadas em operações sobre a MIB.

– Após verificar os campos de uma mensagem o servidor deve utilizar as estruturas internas disponíveis para interpretar a mensagem e enviar a resposta da operação ao cliente que a solicitou.

• As mensagens no protocolo SNMP não possuem campos fixos e por isso são construídas de trás para frente.

43 SNMP

• A mensagem possui três partes principais:– version,

• contem a versão do SNMP. Tanto o gerente como o agente devem utilizar a mesma versão. Mensagens contendo versões diferentes são descartadas.

– community,• identifica a comunidade. É utilizada para permitir acesso do

gerente as MIBs

– SNMP PDU• é a parte dos dados, possui PDU (Protocol Data Units) que são

constituídas ou por um pedido ou por uma resposta a um pedido.

44 SNMP

• Mensagem SNMP

45 SNMP

• Existem cinco tipos de PDUs:– GetRequest,– GetNextRequest,– GetResponse, – SetRequest– Trap.

• Com dois formatos distintos:

46 SNMP

• O SNMPv1 se valia da arquitetura Agente/Gerente/MIB para designar os papeis de gerência em uma rede, adotando uma versão simplificada do modelo OSI de gerência.

• Requisito de simplicidade:– Rápida difusão no mercado;– O Agente deveria ser um elemento bastante simples e de fácil

implementação.– A MIB foi concebida com o conceito simplificado de Objetos

Gerenciáveis baseados em tipos de dados tais como: Bits, Inteiros, Strings e composições de dados do tipo Registro.

• Modelo simplificado de MIB não orientado a objetos.– Objetos foram organizados em uma estrutura de

armazenamento, Structured Management Information (SMI) do tipo árvore, facilitando a identificação de cada um deles.

47 SNMPv1

• Arquitetura geral do SNMP

48 SNMPv1

• Em 1992 surgiram discussões relevantes para que o protocolo de gerenciamento pudesse atender as necessidades de operação da internet.

• Foram introduzidos: – Contador de 64 bits (Counter64 – que permitiu o aumento da

capacidade de representação de alguns fenômenos mais frequentes);

– Primitiva Get_Bulk ( que permitiu a requisição de todo um grupo de objetos da SMI através de uma única operação);

– Troca de informação entre gerentes (gerente trocando dados com outro gerente)

– E um pequeno aumento da segurança de acesso aos dados de um agente (SNMP 2c)

49 SNMPv2

• Em 1997, através das RFCs 2271 a 2275, a versão 3 do SNMP foi proposta para resolver o problema de segurança das versões anteriores. – Com uma visão moderna, o IETF remodelou o SNMP para

suportar uma arquitetura modular, capaz de abrigar os novos e velhos requisitos de funcionamento;

– Coexistência das três versões em um único ambiente de gerência;

– Técnicas de autenticação e criptografia foram colocadas a disposição para garantir a segurança da comunicação entre agentes e gerentes.

50 SNMPv3

• Arquitetura básica SNMPv3:

51 SNMPv3

• A arquitetura básica de uma entidade SNMP v3 é composta por 9 elementos funcionais, divididos em duas camadas:– Motor SNMP : camada responsável por abrigar as entidades

que operam as primitivas de gerência. Dentro dessa camada se encontram os seguintes elementos:

• Dispatcher: elemento que cuida do despacho de PDUs entre os elementos da camada de Aplicação e entidades remotas. Proporciona suporte as diferentes versões de PDU (SNMP v1, v2 e v3) encaminhando cada um deles para o seu respectivo decodificador.

• Message Processing Subsystem: responsável pela codificação e decodificação de PDUs, observando as versões utilizadas. Possui submódulos que respondem por versões especificas de PDUs de um protocolo de gerencia.

52 SNMPv3

• Security Subsystem: sistema responsável pelo fornecimento de serviços de segurança, tais como autenticação e criptografia. Cada submódulo desse elemento representa um modelo de segurança em especial, que pode ser exigido na troca de dados entre duas entidades de gerencia;

• Access Control Subsystem: geralmente implementado apenas nos agentes e proxies, proporciona mecanismos de verificação de permissões de acesso a MIB ou de envio de notificações;

53 SNMPv3

– Aplicações SNMP : camada responsável por abrigar as aplicações que efetivam a gerência de redes através de funções de gerência que serão traduzidas em primitivas requisitadas a camada Engine SNMP. Os elementos contidos aqui são:

• Command Generator: esse elemento inicia as funções de gerência requisitando o envio de PDUs tais como: Get, GetNext, etc.;

• Command Responder: elemento que responde a uma função de gerencia iniciada por outra entidade. A resposta e feita através da função GetResponse;

• Notification Generator: elemento responsável por gerar eventos de notificação, configurados por outra aplicação. Um de seus trabalhos é determinar para quem mandar as notificações e qual a versão de PDU usar;

54 SNMPv3

• Notification Receiver: recebe as notificações e gera respostas quando essas são exigidas;

• Proxy Forwarder: reencaminha mensagens SNMP, fazendo a ligação entre aplicações que não se comunicam diretamente.

55 SNMPv3

• Controle de acesso a MIB:– Prevê a criação de visões (conjunto de objetos gerenciáveis),

estabelecendo contextos de gerenciamento onde cada grupo de usuários recebe direitos específicos de acesso.

• As mudanças exigiram a criação de novas MIBs. Dentre elas:– SNMP-TARGET-MIB : abriga as informações relacionadas com

a identificação e o endereçamento de hosts que receberão informações de gerenciamento.

– SNMP-NOTIFICATION-MIB : abriga as informações sobre a configuração das notificações que serão geradas, seus parâmetros de operação, seu relacionamento com os hosts alvo, filtros aplicáveis e etc.

– SNMP-PROXY-MIB :contem informações sobre a configuração de reencaminhamento de informações de gerencia (Proxy).

56 SNMPv3

• Multi Router Traffic Grapher – MRTG– Gráficos diários, semanais, mensais e anuais:

57 Ferramentas SNMP

• Cactihttp://www.cacti.net/Gráficos sobre número de usuários, processos, tempo de resposta, uso de memória e carga média do sistema.

58 Ferramentas SNMP

• Nagios: http://www.nagios.org/

59 Ferramentas SNMP

• Pandora:• http://pandorafms.com/

60 Ferramentas SNMP

• Base de Informação de Gerenciamento (Management Information Base - MIB).

• Banco virtual de informações que guarda objetos gerenciados, cujos valores, coletivamente refletem o ‘estado’ atual da rede.

• Os objetos gerenciados podem ser especificados utilizando a construção OBJECT-TYPE da SMI discutida anteriormente e agrupados em módulos MIB utilizando a construção MODULE-IDENTITY.

61 MIB

• Um objeto gerenciado é a visão abstrata de um recurso real do sistema. Assim, todos os recursos da rede que devem ser gerenciados são modelados, e as estruturas dos dados resultantes são os objetos gerenciados.

• Os objetos gerenciados podem ter permissões para serem lidos ou alterados, sendo que cada leitura representará o estado real do recurso e, cada alteração também será refletida no próprio recurso.

• Dessa forma, a MIB é o conjunto dos objetos gerenciados que procura abranger todas as informações necessárias para a gerência da rede.

62 MIB

• A RFC - Request For Comment 1066 apresentou a primeira versão da MIB, a MIB I.

• Esse padrão explicou e definiu a base de informação necessária para monitorar e controlar redes baseadas na pilha de protocolos TCP/IP.

• A evolução aconteceu com a RFC 1213 que propôs uma segunda MIB, a MIB II, para uso baseado na pilha de protocolos TCP/IP.

• Basicamente são definidos três tipos de MIBs: MIB II, MIB experimental, MIB privada.

63 MIB

– A MIB II, que é considerada uma evolução da MIB I, fornece informações gerais de gerenciamento sobre um determinado equipamento gerenciado. Através das MIB II pode-se obter informações como: número de pacotes transmitidos, estado da interface, entre outras.

– A MIB experimental é aquela em que seus componentes (objetos) estão em fase de desenvolvimento e teste, em geral, eles fornecem características mais específicas sobre a tecnologia dos meios de transmissão e equipamentos empregados.

– MIB privada é aquela em que seus componentes fornecem informações específicas dos equipamentos gerenciados, como configuração, colisões e também é possível reinicializar, desabilitar uma ou mais portas de um roteador.

64 MIB

• Estrutura– A árvore hierárquica abaixo foi definida pela ISO, representa a

estrutura lógica da MIB, mostra o identificador e o nome de cada objeto.

65 MIB

• O nó raiz da árvore não possui rótulo mas possui pelo menos três subníveis.– O nó 0 que é administrado pela Consultative Committe for

International Telegraph and Telephone – CCITT (Hoje ITU)

66 MIB

• O nó 1 que é administrado pela International Organization for Standartization - ISO;

• O nó 2 que é administrado em conjunto pela CCITT e pela ISO.

67 MIB

• Sob o nó ISO fica o nó que pode ser utilizado por outras instituições:

68 MIB

O org (3), abaixo dele fica o dod (6) que pertence ao departamento de defesa dos EUA.

O departamento de defesa dos EUA alocou um sub-nó para a comunidade internet, que é administrado pela International Activities Board - IAB

e abaixo deste nó tem-se, entre outros, os nós: management, experimental, private.

• Sob o nó management ficam as informações de gerenciamento:

69 MIB

• É sob este nó que está o nó da MIB II.

• Sob o nó experimental estão as MIBs experimentais.

• Sob o nó private fica o nó enterprises e sob este nó ficam os nós das indústrias de equipamentos.

• Como exemplo de um objeto citaremos o ipInReceives do grupo IP:

70 MIB

• Organização• Abaixo da subárvore MIB II estão os objetos usados para

obter informações específicas dos dispositivos da rede.• Esses objetos estão divididos em 10 grupos, que estão

presentes na tabela abaixo.

71 MIB-II

• A planificação do nó da MIB II:

72 MIB II• Grupos da MIB II em

uma pilha de protocolos :

• Alguns dos objetos pertencentes aos grupos da MIB II são:

• Grupo System (1.3.6.1.2.1.1)

– sysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade. Pode incluir o nome e a versão do hardware, sistema operacional e o programa de rede.

– sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares de segundos) desde a última reinicialização do gerenciamento do sistema na rede.

– sysContact (1.3.6.1.2.1.1.4): Texto de identificação do gerente da máquina gerenciada e como contatá-lo.

73 MIB II

• Grupo Interfaces (1.3.6.1.2.1.2)– ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede (não

importando seu atual estado) presentes neste sistema.– ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface.– ifInOctets (1.3.6.1.2.1.2.2.1.10): Número total de octetos

recebidos pela interface.

• Grupo IP (1.3.6.1.2.1.4)– ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um

gateway.– ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas

recebidos pelas interfaces, incluindo os recebidos com erro.– ipInHdrErrors (1.3.6.1.2.1.4.4): Número de datagramas que

foram recebidos e descartados devido a erros no cabeçalho IP.

74 MIB II

• Grupo ICMP (1.3.6.1.2.1.5)– icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens

ICMP recebidas por esta entidade. Incluindo aquelas com erros.

– icmpOutMsgs (1.3.6.1.2.1.5.14): Número total de mensagens ICMP enviadas por esta entidade. Incluindo aquelas com erros.

• Grupo TCP (1.3.6.1.2.1.6)– tcpMaxConn(1.3.6.2.1.6.4): Número máximo de conexões TCP

que esta entidade pode suportar.– tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP que

estão como estabelecidas ou a espera de fechamento.– tcpRetransSegs (1.3.6.2.1.6.12): Número total de segmentos

retransmitidos.

75 MIB II

• Grupo UDP (1.3.6.1.2.1.7)– udpInDatagrams (1.3.6.1.2.1.7.1): Número total de datagramas

UDP entregues aos usuários UDP.– udpNoPorts (1.3.6.1.2.1.7.2): Número total de datagramas

UDP recebidos para os quais não existia aplicação na referida porta.

– udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do usuário UDP local.

• Grupo SNMP (1.3.6.1.2.1.11)– snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens

recebidas pela entidade SNMP.– snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens

enviadas pela entidade SNMP.– snmpInTotalReqVars (1.3.6.1.2.1.11.13): Número total de

objetos da MIB que foram resgatados pela entidade SNMP.

76 MIB II

• Exemplo operação SNMP sobre a MIB II:

ID do obejto + ID da instância

Objetos folha (.0)ex.: GET sysDescr.0GET 1.3.6.1.2.1.1.1.0

Objetos como campo de uma tabelas (.chave)ex.: GET ipRouteNextHop .143.54.1.0GET 1.3.6.1.2.1.5.7.143.54.1.0

77 MIB II

MIB OTN

RFC 3591

78

• A MIB OTN IETF é apresentada na RFC 3591 lançada no ano de 2003.

• A RFC 3591 define a porção da MIB para uso com o Protocolo SNMP.

• Define os Objetos para o gerenciamento de interfaces ópticas associadas com sistemas Wavelength Division Multiplexing (WDM) ou caracterizados pelo the Optical Transport Network (OTN) de acordo com a arquitetura definida na recomendação da ITU-T G.872.

• O módulo MIB definido neste memorando pode ser usado para performance monitoring e/ou configuração de cada interface óptica.

79 MIB OTN 3591

• Os objetos ópticos serão gerenciados utilizando a MIB II ifTable e a ifStackTable.

• Tabelas adicionais para suporte ao monitoramento do status de uma camada especifica e para o monitoramento dos dados de desempenho.

• Nessas tabelas, algumas entradas são requeridas para sistemas OTN. – Configuration (Config) table, – Current Performance Monitoring (PM) table, – Interval PM table

• Estas tabelas serão ligadas ao ifTable usando o ifIndex que está associado a essa camada.

80 Overview

• As camadas OTN gerenciadas na ifTable usam ifEntries para correlaciona-las com as camadas apresentadas:

81 Camadas

RFC 3591

• Há implementações que amplificadores operam em grupos de canais ópticos separadamente (por exemplo, C, e canais de banda L) antes de finalmente de multiplexa-los e transporta-los através de uma camada física.

• Para sistemas DWDM é importante ter a habilidade de modelar os grupos (OChGroup Layer).

• Opcional.

82 OChGroup Layer

• Objetos da ifTable:– ifIndex : índice da interface

– ifDescr : Optical Transport Network (OTN) Optical Transmission Section (OTS)/Optical Multiplex Section (OMS) / Optical Transport Network (OTN) Optical Channel Group (OChGroup) / Optical Transport Network (OTN) Optical Channel (OCh)

– ifType : opticalTransport (196) / opticalChannelGroup(219) / opticalChannel(195)

– ifSpeed: Largura de banda real da interface em bits por segundo.

– ifPhysAddress: No OTS/OMS uma string de tamanho zero que indica que nenhum endereço específico é associado com a interface. No OChGroup indica a faixa da banda (ex: 1350-1650). Já no OCh indica a comprimento de onda da portadora (ex: 1550)

83Uso do ifTable para OTN OTS/OMS, OChGroup e OCh Layer

• Objetos da ifTable (continuação):– ifAdminStatus: Designa o status administrativo na interface.– ifOperStatus: Estado operacional da interface:

lowerLayerDown(7), notPresent(6), down(2).

– ifLastChange: O valor do sysUpTime na última mudança no ifOperStatus.

– ifName: prove meios para referenciar uma ou mais tabelas de empresas específicas.

– ifLinkUpDownTrapEnable: Valor padrão é o habilitado enabled(1). Atributo de somente leitura

– ifHighSpeed: Atual banda da interface em Mega-bits por segundo.

– ifConnectorPresent: Definido como true(1) para as camadas OTS/OMS e false(2) para OChGroup e OCh.

– ifAlias: Nome de Alias para a interface atribuído pelo gerente da rede.

84Uso do ifTable para OTN OTS/OMS, OChGroup e OCh Layer

• Uso do ifStackTable e ifInvStackTable para associar as interfaces de entradas opticalTransport e opticalChannel ilustradas na figura 5 da RFC 3591:

85 Uso do ifStackTable

Este exemplo assume uma interface OTN com ifIndex “i” carregando duas interfaces och multiplexadas com valores de ifIndex j e k.

• A RFC 3591 apresenta ainda a terminologia associada com as camadas ópticas, suas condições de erro e os parâmetros de performace monitoring.– Exemplo de terminologia de camada óptica:

– Exemplo de terminologia de parâmetros de performance monitoring

86 Terminologia de rede óptica

• Exemplo de terminologia dos erros associados:

87 Terminologia de rede óptica

• Uma terminação ODUk pode ser aprovisionada para suportar até 6 níveis de TCM.

• Cada campo TCM contém os seguintes subcampos:– Trail Trace Identifier (TTI)– Bit Interleaved Parity 8 (BIP8)– Backward Defect Indication (BDI)– Backward Error Indication (BEI)– Bits de status indicando a presença do overhead de TCM,

entrada AlignmentError, ou um sinal de manutenção (STAT). • A inserção desses subcampos é controlada pelos:

– optIfODUkTSourceMode ou otnODUkTsinkMode• A detecção e a ação correspondente são controlados por:

– optIfODUkTTimDetMode– optIfODUkTTimActEnabled

88Tandem Connection Monitoring (TCM)

• A conexão TCM é usada para monitorar a qualidade de uma conexão fim a fim ou algum segmento:

89 Exemplo TCM

TCM1 é usado para a conexão fim a fim de A1 a A2

TCM2 é usado para o segmento B1-B2 e novamente em B3-B4

Os TCM3-TCM6 não são usados neste exemplo

• Os objetos gerenciados estão organizados nos seguintes grupos de tabelas

– optIfOTMn group: lida com a estrutura de informação OTM de uma interface óptica.

optIfOTMnTable

– optIfPerfMon group: lida com os intervalos de tempo decorridos de 15 minutos e 24 horas, bem como o número de intervalos de 15 minutos para todas as camadas. for all layers.

optIfPerfMonIntervalTable

90 Estrutura da MIB OTN

• Diversos grupos para lidar com a configuração e a performance monitoring de cada camada:

– optIfOTSn groups– optIfOTSn groups– optIfOMSn groups– optIfOChGroup groups– optIfOCh groups– optIfOTUk groups– optIfODUk groups– optIfODUkT groups

91 Estrutura da MIB OTN

Tabelas da optIfODUk groupsoptIfODUkConfigTableoptIfODUkTtpConfigTableoptIfODUkPositionSeqTableoptIfODUkNimConfigTableoptIfGCC12ConfigTable

• Frustrando as expectativas a 3591 não aborda os objetos de cross conexão:

92 E quanto a cross conexão?

93 O optIfOTSn groupsTabelas da optIfOTSn groups

optIfOTSnConfigTableoptIfOTSnSinkCurrentTableoptIfOTSnSinkIntervalTableoptIfOTSnSinkCurDayTableoptIfOTSnSinkPrevDayTableoptIfOTSnSrcCurrentTableoptIfOTSnSrcIntervalTableoptIfOTSnSrcCurDayTableoptIfOTSnSrcPrevDayTable

optIfOTSnConfigTableEx: objeto definido:

94 optIfOTSnConfigTable


...

...


...


• É possível traduzir informações da MIB 874.1 para a 3591?– Teoricamente sim, pois a 3591 é baseada nas recomendações

da ITU-T:

– A recíproca é verdadeira no que se refere que ao desenvolvimento da 874.1 prover uma abordagem genérica para adoção de protocolos específicos de gerenciamento tais como CMISE, CORBA, e SNMP.

98 Relação MIB OTN 874.1 e 3591

• Há perdas no mapeamento 874.1 <-> 3591?– Existem parâmetros na 3591 que não encontram

correspondentes na 874.1:– Existem parâmetros na 874.1 que não encontram

correspondentes na 3591:

99 Relação MIB OTN 874.1 e 3591

NETCONF e YANG

100

• Motivação• Abordagens Atuais• Novos Requisitos de Gestão de Configuração• NETCONF

– Visão Geral– Arquitetura– Exemplos– Ferramentas

• YANG– Visão Geral– Arquitetura– Exemplos– Ferramentas

101 NETCONF YANG

Fonte: Material desenvolvido na Cooperação UFES/UECE no projeto do junto à Padtec

• “O contínuo crescimento das redes de telecomunicações e de dados em termos de tamanho e funções de serviço resulta em uma maior complexidade do processo de gerenciamento de redes”.

• “A gestão da configuração de um grande número de dispositivos de rede continua a ser um problema prático muito importante ”.

• Configurações de dispositivos e os mecanismos para recuperar e modificá‑las são em grande parte algo específico de cada fornecedor, e as interfaces de configuração mais amplamente usadas hoje são interfaces proprietárias de linha de comando (CLIs), tornando-se oneroso atingir um elevado nível de eficiência e confiabilidade através da automação.

102 Motivação e Background

• Com base na aceitação da indústria, é bastante claro que o Simple Network Management Protocol (SNMP) é provavelmente o mais bem sucedido, uma vez que quase todos os fornecedores dão suporte ao SNMP em seus equipamentos de rede.

103 Abordagens atuais

• A abordagem “The Network is the Record”– Trabalho intensivo– Cara– Sujeito a erros– Amplamente implantado


• Abordagem “Generate Everything”– Todas as configurações são feitas (e validadas) no banco de

dados de configuração em toda a rede e os dispositivos não são trocados manualmente.


106Novos Requisitos de Gestão de Configuração

• A crescente complexidade das redes modernas expôs várias questões graves relacionadas ao uso de SNMP:– SNMP não suporta a recuperação da configuração completa

de um dispositivo.– SNMP sofre de um desempenho ruim para transferência de

dados em massa, mesmo para tarefas simples como a recuperação de uma tabela de roteamento.

– SNMP sofre a falta de mecanismos de consulta e agregação que reduzem a eficiência e a escalabilidade do protocolo.

107 E quanto ao SNMP?

– A Interface de programação SNMP é muito baixo nível e consome bastante tempo do desenvolvedor; programação / scripting SNMP é inconveniente para o uso prático.

– Ferramentas de desenvolvimento com base em SNMP são caras.

– SNMP não emprega os mecanismos de segurança padrão;– As Traps SNMP não fornecem descrição detalhada de um

evento, e operações GET geralmente são obrigados a recolher informações adicionais para descrever o evento.

108 E quanto ao SNMP?

NETCONF

Network Configuration Protocol

109

• Network Configuration Protocol NETCONF– Netconf é considerado um grande passo em direção aos

sistemas automatizados de gerenciamento de rede baseados em XML.

– É um protocolo de gerência que define as operações para o gerenciamento de dispositivos de rede onde os dados de configuração podem ser carregados, recuperados e manipulados como um todo ou parcialmente.

– O protocolo Netconf é baseado em XML-RPC para a comunicação entre o gerente e o agente.

110 NETCONF

• Solicitações e respostas do protocolo concentram-se em manipulação de configuração, como obter a configuração atual, atualizar, criar ou excluir todos ou parte dele.

• As configurações são representadas em um documento XML que contém dois tipo de dados:

– dados de configuração - gravável, e que descrevem os parâmetros de configuração do agente netconf.

– dados do estado - somente leitura e que descrevem os dados operacionais, tais como contadores ou estatísticas.

111 NETCONF

• Modelo de desenvolvimento– NETCONF habilita a inclusão de dispositivos servidores

NETCONF– Aplicações de gerenciamento incluem o cliente NETCONF– Command Line Interfaces (CLIs) podem ser encapsuladas em

um cliente NETCONF

112 NETCONF

• Arquitetura:– A arquitetura NETCONF foi concebida visando distinguir entre

dados de configuração e dados de estado de um dispositivo.– O NETCONF estabelece uma clara distinção entre

configurações de execução, inicialização e temporárias.– Apresenta o conceito de datastore, uma espécie de repositório

de dados que contém todas as informações de configuração de um dispositivo. Sua arquitetura propõe o uso de três diferentes datastory:

• Running.• Candidate.• Startup.

113 NETCONF

• Running: contém as configurações atualmente ativas no dispositivo.

• Candidate: contém configurações temporárias e/ou voláteis, as quais podem ser manipuladas sem afetar as configurações atuais do dispositivo.

• Startup: contém as configurações iniciais do dispositivo usadas sempre que o mesmo é inicializado.

114 NETCONF

• NETCONF utiliza uma arquitetura em camadas para a transmissão de mensagens, a fim de fornecer uma separação clara entre a gestão de dados (conteúdo) e o protocolo subjacente usado para transportar os dados.

– Segurança é provida pela camada de transporte– A camada de operação provê as primitivas para a aquisição de

configuração.

115 NETCONF Camadas

• Content: Camada de Conteúdo, responsável pela configuração de dados do dispositivo.

• Operation: Camada de Operações, contendo todas as operações invocadas como métodos RPC, codificadas em tags XML como <get-config> e <edit-config>.

• RPC: Camada de Chamada de Procedimento Remoto, responsável por um mecanismo de enquadramento independente do modelo de transporte, também codificado em XML por meio das tags <rpc> e <rpc-reply>.

• Transport: Camada de transporte, define o protocolo de transmissão entre o agente e o gerente NETCONF, exemplos: SSH, SOAP, e BEEP.

116 NETCONF

• SNMP não tem o conceito de gerenciamento de sessões, deixando os dispositivos abertos a quaisquer solicitações SNMP para modificar um configuração enquanto eles carregam as credenciais corretas.

• Uma configuração bloqueada por uma sessão Netconf não pode ser bloqueada ou alterada por quaisquer outras sessões. Este recurso é muito importante para garantir a consistência de configuração, especialmente entre os vários dispositivos.

117 Características - NETCONF

• Netconf fornece um desempenho significativamente melhor em termos de número de operações e utilização de pacotes em relação ao SNMP quando recupera vários objetos de uma só vez.


Retrieving large number of objects

• Recuperar um único objeto de dados requer mais largura de banda em Netconf do que em SNMP, isso é devido à natureza detalhada de documentos XML, além da sobrecarga associada com o estabelecimento e que encerramento de sessões de transporte TCP.


Retrieving a single data Object

• Camada de transporte– Quanto ao mecanismo de transporte, a IETF sugere três

opções:• Secure Shell (SSH, RFC4742), • Simple Object Access Protocol (SOAP, RFC4743) e • Blocks Extensible Exchange Protocol (BEEP, RFC4744).

• Entretanto, em termos práticos o NETCONF pode fazer uso de vários outros protocolos seguros orientados a conexão – Para isso é exigido que uma conexão persistente de longa duração

seja mantida, estabelecendo-se assim a ideia de uma sessão.– A RFC 4741 impõe a utilização do SSH, pelo que dois peers de

NETCONF que pretendam comunicar fazem-no primeiramente em SSH e só depois, caso pretendam, explicitam a intenção de utilizar outro protocolo no processo de troca de capacidades durante a negociação da sessão de NETCONF.

120 NETCONF Camada de Transporte

• Uma vez estabelecida uma sessão segura, os interlocutores NETCONF enviam uma mensagem hello que serve de anúncio de suas capacidades e definição do identificador de sessão, o qual é gerado pelo servidor NETCONF.

• Exemplo de mensagem de hello enviada por um agente NETCONF.

121 NETCONF Camada de Transporte

• Camada RPC– Seguindo um modelo de comunicação interprocessos baseado

em RPC as operações NETCONF são construídas em cima de dois elementos XML:

• <rpc>: usado para executar requisições.• <rpc-reply>: usado para fornecer respostas.

– Após o estabelecimento da sessão NETCONF, os interlocutores iniciam a troca de mensagens por meio dos elementos <rpc> e <rpc-reply>.

– A cada nova requisição o cliente envia uma mensagem <rpc> contendo um identificador de mensagem, chamado message-id, gerado por ele mesmo e anexado como atributo. Esse atributo é obrigatório e deve também ser usado pelo servidor NETCONF nas mensagens <rpc-reply> .

122 NETCONF Camada RPC

• Mensagem rpc:

• Mensagem rpc-reply:


• Falhas na RPC podem ser indicadas por uma ou mais elementos <rpc-error/> no elemento <rpc-reply/>


• Estrutura básica do elemento rpc-reply


• As operações básicas são definidas em elementos XML:<get> : Retorna (em todo ou parte deles) dados de estado e configuração;<get-config> : Retorna (em todo ou parte deles) dados de configurações do tipo running ou candidate;<edit-config> : Carrega (em todo ou parte deles) para edição os dados de configurações do tipo running ou candidate;<copy-config> : Copia dados de configuração sobre uma especificada configuração running ou candidate;

126 NETCONF Camada de Operação

<delete-config>: remove uma configuração candidate;<lock>: bloqueia uma configuração atual contra qualquer edição ou copiar para as operações de configuração originado de outra sessão ou acesso externo;<unlock>: desbloqueia uma configuração;<close-session>: encerra a sessão Netconf encerrando as operações em andamanto;<kill-session>: encerrar a sessão Netconf sem concluir qualquer operação em andamento.

127 NETCONF Camada de Operação

• Parâmetros utilizados pelas operações– source: Especifica a configuração de origem dos dados, Ex.:

candidate; – target: Especifica a configuração a editar, Ex.: startup; – filter: permite indicar um filtro para selecionar apenas parte

dos dados de configuração ou de estado– default-operation: Define o tipo de manipulação a efetuar pela

operação edit-config sobre uma configuração.• merge: as configurações do campo config são adicionadas na

configuração target; • replace: as configurações em config sobrepõem-se às da

configuração target; • none: as configurações em config são ignoradas até que seja

utilizado o atributo operation a indicar uma operação diferente;

128 NETCONF

– test-option: Este parâmetro pode ser especificado se for anunciada a capacidade :validate e toma um dos seguintes valores:

• test-then-set: Inicialmente é feita a validação de config, caso não se verifiquem erros as alterações são aplicadas;

• set: As alterações são aplicadas sem validação das configurações;

• test-only: Apenas é feita a validação de config sem aplicar as configurações;

129 NETCONF

– error-option: a política de tratamento de erros, com os seguintes valores possíveis:

• stop-on-error: Assim que houver um erro a edição das configurações é abortada. Essa é a opção por omissão;

• continue-on-error: A aplicação das alterações continua mesmo em caso de erro. É gerada uma resposta conforme os erros ocorridos;

• rollback-on-error: Em caso de erro as alterações são abortadas e as configurações são restauradas até ao estado do inicio da alteração. Essa opção é disponibilizada pela capacidade “:rollback-on-error”;

130 NETCONF

– config: Especifica as alterações a fazer, tem que estar de acordo com o modelo de dados e namespace do target;

– session-id: Identificador da sessão a terminar; – stream: Identificador de um fluxo de eventos. São conjuntos de

notificações que respeitam um dado critério. Na omissão deste parâmetro, são enviadas notificações da stream por omissão que normalmente inclui todas as notificações de um agente;

– start time: subscreve notificações a partir de um instante temporal. Faz parte da funcionalidade de replay da capacidade :notification;

– stop time: também faz parte da funcionalidade de replay e deve ser utilizado em conjugação com o parâmetro anterior para definir o intervalo de tempo de que se quer receber notificações;

– persist-id: valor identificador de um commit, só é válido mediante a capacidade :confirmed-commit.

131 NETCONF

• Com o objetivo de lidar com grandes configurações, o protocolo prevê que para as operações de recuperação e edição possam ser utilizados mecanismos de filtragem– Isso permite aos clientes obter apenas um subconjunto de uma

dada configuração por meio de elementos do tipo <filter> – Exemplo do uso do elemento <filter> durante a edição de uma

configuração:

132 NETCONF

• A Camada de Conteúdo da arquitetura NETCONF inclui o modelo de gestão de dados que é completamente independente do protocolo

• Os fabricantes e pesquisadores logo identificaram a necessidade de um modelo de dados padronizado para lidar com informações de configuração, tratando assim da difícil tarefa de gerenciar os dados de diferentes dispositivos fabricados por diferentes provedores.

• Para isso surgiram várias alternativas de modelagem XML, destacando-se dentre elas a linguagem YANG.

133 NETCONF Camada de Conteúdo

• Yuma: http://www.netconfcentral.org/yuma/• EnSuite: http://ensuite.sourceforge.net/index.html

134 Ferramentas NETCONF

YANG

135

• O YANG Internet Draft define YANG como uma linguagem de modelagem de dados usada para descrever a configurações e dados do estado em Netconf.

• O padrão Netconf não define tal linguagem para sua camada de conteúdo.

• O netmod working group charter2 explica por que uma linguagem de nível mais alto do que XML é necessário.

136 YANG

• Propósito:– YANG é uma linguagem de modelagem de dados capaz

de modelar dados de configuração, dados de estado, operações e notificações. Sua definições podem ser mapeadas diretamente em conteúdo XML.

• YANG vs. YIN:– YANG usa uma sintaxe SMIng like compacta tendo a

legibilidade de como alta prioridade. YIN é a versão XML do YANG.

• YANG vs. XSD ou RELAX NG:– YANG pode ser traduzida para XML Schema (XSD) e

RELAX NG - existem ferramentas para isso.

137 YANG

138 YANG vs. XSD vs. RELAX NG

Análise de linguagens de modelagem usadas com NETCONF: XML Schema,

Relax NG and YANG

139

Data Modeling for NETCONF-Based Network

Management: XML Schema or YANG.

140 YANG – Modules e submodules

Module: “A self-contained collection of YANG

definitions.”

Submodule: “A partial module definition which contributes

derived types, groupings, data nodes, RPCs, and notifications

to a module.”

141 YANG Exemplo:

142 Built-in Data Types

O Sistema de tipos de dados é

maior que do SMIng,

acomodando requisitos XML e

XSD.

143 YANG Exemplo

• Leaf contem um valor, sem filhos, uma instância.

• Leaf-list contem um valor, sem filhos, muitas instâncias.

• Container não contem valor, guarda filhos relacionados, não tem

instância.• List

Não tem valor, guarda filhos relacionados, tem muitas instâncias, tem uma proprieddade chave.

144 Leafs, Leaf-lists, Container, Lists

145 Exemplo: leaf and leaf-list

146 Exemplo: container

147 Exemplo: list

• Augment Pode ser usada para inserir nós em uma hierarquia existente.

• Must Pode ser usada para expressar restrições em formato Xpath,

as quais precisam ser satisfeitas para uma configuração válida.• When

Pode ser usada quando uma dada condição precisa se satisfeita e é expressa em XPath.

148 Augment, Must, When

149 Exemplo: augment and presence

150 Exemplo: augment & must

151 Exemplo: augment &when

152 Exemplo

UML

XSD

YANG

153 Exemplo de XML

• Pyang Open source YANG validator and translator written in Python.

• Yangdump Closed source YANG validator and translator written in C.

• Smidump Open source SMI to YANG translator written in C.

• Emacs Open source YANG editing mode for the emacs editor.

154 Ferramentas YANG

Documents

Protocolos e Linguagens de Modelagem e Especificação e da Gerência IETF