Expressões regulares, autômato finito não determinístico e autômato finito determinístico


 

Introdução

 

No desenvolvimento de um programa (http://www.braga.eti.br/ca/) para exibir quaisquer das 256 regras de autômatos celulares (ACs) propostos pelo incrível Stephen Wolfram, em seu volumoso livro “A New Kind of Science” deparou-se com a questão, simples, de como tratar as possíveis combinações de entrada, do referido programa, já que o usuário poderia:

  1. Pedir o AC de uma única regra (x, onde 0 \leq x \geq 255);
  2. Pedir um conjunto de ACs no seguinte formato: x-y, onde x, y \leq 255\,\,e\,\,x < y;
  3. Pedir vários ACs, combinando as duas alternativas anteriores separadas por vírgula (,), em um número finito (e, arbitrário) de vezes.

Este artigo trata das etapas necessárias para que se possa implementar, de forma correta, o tratamento da entrada do programa proposto. Tais etapas são: (a) a construção da expressão regular, (b) a transformação da expressão regular em um autômato finito não determinístico (NFA), (c) a redução do NFA para um autômato finito determinístico (DFA) e, (d) a implementação propriamente dita.

 

Expressão Regular

 

Na literatura de computação, principalmente, os trabalhos de pessoas que lidam com inseguridade como, por exemplo, LANGSEC: Language-theoretic Security recomendam, insistentemente, o uso de linguagens regulares para tratar as entradas de um programa. Nesta direção, se considerado que nos itens de 1 a 3 das especificações acima, as variáveis x e y (diferentes entre si) são números de 0 a 255 pode-se adotar tais números como símbolos, e com as abstrações admissíveis usar a letra (ou símbolo!) n para representá-los e, adicionalmente reconhecer, que dois outros símbolos como pré-requisitos, (, e -), as seguintes combinações de entrada são possíveis:

  • n
  • n, n-n
  • n, n-n, n, …,n, n-n, …
  • n-n, …, n, …,n, n-n, …
  • etc

De tais combinações, depois de um pequeno esforço mental é possível identificar a expressão regular que responde ao desejado:

(n\mid n-n)(,n\mid,n-n)^*

A noção de abstração aplicada à formulação da expressão regular implica que serão deixadas para a implementação, as questões limitantes do uso do símbolo n e da representação infinita do *.

Dada a expressão regular, a próxima etapa é a construção do NFA.

 

Autômato finito não determinístico (NFA)

 

Construir um NFA a partir de uma expressão regular utilizando-se do algoritmo disponível em várias referências é uma tarefa extremamente agradável, muito embora, um pouco trabalhosa. em determinados casos. Entretanto, na Internet existem diversos ambientes para construção do NFA, de forma automática. Um deles é o Regular Expression to NFA. Usando-o, obtemos o NFA exibido na Figura 1.

 

nfa-erca

Figura 1. NFA obtido automaticamente. Fonte: Regular Expression to NFA.

 

Autômato finito determinístico (DFA)

 

O mesmo construtor do NFA, fornece o DFA, imediatamente, conforme visto na Figura 2.

 

dfa-erca

Figura 2. DFA produzido a partir do NFA da Figura 1. Fonte: Regular Expression to NFA.

 

 

Implementação

 

No Capítulo 10, “Patterns, Automata, and Regular Expressions”, do livro de Al Aho e Jeff Ullman, imperdível e disponível na Internet em Foundations of Computer Science, exibe um algoritmo de implementação de um autômato, extremamente simples, como se pode verificar. Foi usado aquele algoritmo para a implementação e, na oportunidade garantindo as restrições sobre a expressão regular lembradas acima.

XML na Infraestrutura da Internet

Jewish law prohibited farmers from harvesting every last item from their fields.
If something was missed in the first pass, they were to leave it for the poor to harvest.
This was called gleaning. Gleaning provides a metaphor for good writing and teaching.
Don’t explain everything in complete detail. Leave something for the reader or student to harvest on their own.
From John Cook => https://plus.google.com/u/0/+JohnCook/posts/4UpWuws59oU

 

Introdução

 

Tenho insistido na ideia da aplicação de Web Semântica na Infraestrutura da Internet. Durante o, ainda em desenvolvimento desta ideia, uma questão parece evidente: o domínio da Infraestrutura da Internet é enorme e inexplorado sob a ótica da Web Semântica! Basta uma olhada na Figura 1, uma representação simplificada e parcial deste domínio, na qual, os principais agentes aparecem com algumas relações básicas. Tais agentes são os produtores das informações, isto é, dados que são produzidos e guardados em repositórios, geralmente, no formato texto com uma estrutura mínima. Há um texto em inglês, Preliminaries essays to research in Semantic Web applied to Internet Infrastructure, disponível em PDF, no qual, entre outras coisas, esclarece como os administradores de Sistemas Autônomos consomem estes dados, através de ferramentas orientadas a este fim. No “Preliminaries essays…”, a localização de alguns dos repositórios está representado em um cenário mais abrangente.

 

VisaoEntrelaçadaIPv6

Figura 1. Representação simplificada e parcial do domínio da Infraestrutura da Internet.

 

Ao procurar fixar o cenário, a maneira de pensar varia do geral para o particular e muitas vezes, também, do particular para o geral. Uma troca, sem limites usando refinamentos sucessivos, tanto no pensamento “top->down” como no “bottom->up”. Neste vai e vem da forma de pensar, o Mapa de Conceito4, exerce um papel fundamental, já que sua característica principal é a facilidade de representar o domínio do problema (ou do conhecimento), visualmente, simplificado e, direto. Existem vários mapas de conceito disponíveis, nos quais incluem os mapas mentais, que também fazem um bom trabalho. Neste texto, usamos o CMaps8 descrito sob o ponto de vista de suas aplicações. A Figura 1 e muitas outras que seguem foram, também produzidas, no CMaps.

Além das preocupações com o tamanho do domínio, a ausência de um vocabulário direto e aplicável ao domínio há outras. Entre estas outras, a linguagem para representar e permitir fácil acesso aos repositórios é um dos aspectos mais importantes. A base para tratar as aplicações de Web Semântica está na eXtensible Markup Language (XML), definida em [6] e é sobre ela que trataremos neste primeiro artigo.

 

A XML e a aplicação na delegação de IPv6

 

Sistemas Autônomos6 na Internet são identificados por um número denominado ASN (Autonomous System Number). Este número é controlado e distribuído pelo IANA (Internet Assigned Numbers Authority). A IANA (http://www.iana.org/about) é um departamento do ICANN (Internet Corporation for Assigned Names and Numbers). A IANA, também controla a distribuição de números IPv4 e IPv6, entre outras funções. O mecanismo de distribuição do IANA é do tipo atacado, isto é, ela distribui os números de AS, IPv4 e IPv6 para os RIR (Regional Internet Register), que por sua vez distribuem para os NIR (National Internet Register) ou diretamente para os interessados, quando não existir um NIR. Os RIRs são em número de cinco, cada um responsável por uma região do mundo (http://www.iana.org/numbers). Os RIRs são: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A IANA está, também, intimamente conectado com o IETF9. ICANN, IANA, IETF, números IPv4, números IPv6, números de ASes, RIRs, NIRs, Empresas, Instituições, Países, Pessoas e muitas outras coisas são parte dos “conceitos” associados ao domínio Infraestrutura da Internet, ou em outras palavras, ao vocabulário do domínio.

Para a aplicação da XML trabalharemos sobre um sub-domínio da representação exibida na Figura 1 (em laranja). Com o CMaps obtemos facilmente a derivação que pode ser vista na Figura 2.

 

DetalheIPv6

Figura 2. Detalhe da destinação de um bloco IPv6.

 

A representação fala por si mesmo. Em resumo, uma Empresa (digamos, um provedor) recebe um bloco de IPv6 sobre o qual estamos interessados. De posse deste bloco, um /32, o provedor planeja e designa sub-blocos a seus clientes e/ou usuários. Partindo da premissa de que a empresa tem muitos clientes, há necessidade de se criar um repositório do recurso (bloco IPv6) recebido, juntamente com as informações a ele associadas. Sobre este repositório uma série de operações conhecidas devem estar disponíveis. Uma abstração deste repositório e suas relações podem ser vistos na Figura 3.

 

RepositorioAbstrato

Figura 3. Representação abstrata de um repositório de registro de designação IPv6 e suas respectivas operações.

 

A abstração indica que o tal repositório pode ser, desde folhas de papel até um local (digital), onde se pode usar processos mais so fisticados, que tenham, por exemplo, um gerenciador de banco de dados relacional (digamos, MySQL). Vamos eliminar as soluções trabalhosas, como as folhas de papel, para procurar alternativas mais apropriadas sob o ponto de vista do acesso ao repositório e proporcionais a expectativa de tamanho deste repositório.

Faremos uma incursão sobre as soluções tradicionais, para depois seguirmos as técnicas que envolvem Web Semântica, nosso objetivo neste texto. Passemos, então, à descrição do contexto do problema desejado, com alguns detalhes importantes descobertos no planejamento.

 

Planejamento da distribuição de um bloco /32

 

Então, o provedor recebeu, do Registro.br, um bloco IPv6, que iremos supor como sendo o bloco dddd:dd00::/32. Depois de ler o artigo “Preparing an IPv6 Address”5 e o RFC 59321, cuidadosamente planejou a sua distribuição. Ele trabalhou tendo em mãos o Guia didático de Endereçamento IPv6. Assim, os números envolvidos tornaram fáceis de encontrar.

Ele dividiu este /32 em 65.536 blocos /48. Em seguida, achou adequado separar os primeiros 32.768 blocos para uso futuro e passou a pensar na segunda metade. Insistente reservou a primeira metade deste conjunto de blocos /48 (16.384), também, para uso futuro e passou a pensar sobre a divisão dos outros 16.384, da segunda metade, para que fosse distribuida a seus Clientes. O provedor calculou que na sequência deste conjunto de /48s, ele teria 1.024 x 16 blocos /48. Chamou cada um destes /48 de Disponibilidades e montou o seguinte esquema de distribuição:

  • Disponibilidade 0: dddd:dd00:c000::/48 a dddd:dd00:c00f::/48
    • dddd:dd00:c000::/48 ) Uso interno
    • dddd:dd00:c001::/48 ) Liberado
    • dddd:dd00:c00f::/48 ) Liberado
  • Disponibilidade 1: dddd:dd00:c010::/48 a dddd:dd00:c01f::/48
    • dddd:dd00:c010::/48 ) Cliente/Localidade 1
    • dddd:dd00:c011::/48 ) Liberado
    • dddd:dd00:c01f::/48 ) Liberado
  • Disponibilidade 2: dddd:dd00:c020::/48 a dddd:dd00:c02f::/48
    • dddd:dd00:c020::/48 ) Cliente/Localidade 2
    • dddd:dd00:c021::/48 ) Liberado
    • dddd:dd00:c02f::/48 ) Liberado
  • Disponibilidade 3: dddd:dd00:c030::/48 a dddd:dd00:c03f::/48
    • dddd:dd00:c030::/48 ) Cliente/Localidade 3
    • dddd:dd00:c031::/48 ) Liberado
    • dddd:dd00:c03f::/48 ) Liberado
  • 

  • Disponibilidades 4 ate 511

  • Disponibilidade 512: dddd:dd00:c2f0::/48 a dddd:dd00:c2 ::/48
    • dddd:dd00:c2f0::/48 ) Cliente/Localidade 512
    • dddd:dd00:c2f1::/48 ) Liberado
    • dddd:dd00:c2 ::/48 ) Liberado
  • 

  • Disponibilidades 513 ate 1022

  • Disponibilidade 1023: dddd:dd00: f0::/48 a dddd:dd00: ::/48
    • dddd:dd00: f0::/48 ) Cliente/Localidade 1023
    • dddd:dd00: f1::/48 ) Liberado
    • dddd:dd00: ::/48 ) Liberado

Quando esta divisão foi feita, o provedor tinha em mente o RFC 61773, não deixando de pensar que um de seus clientes poderia dividir o bloco /48 em /56 ou /60. Indo um pouco mais além fez recomendações para que seus clientes distribuíssem a seus usuarios, blocos /64. Como em cada /48 estão disponveis 65.536 redes /64, ele fez as seguintes recomendacões a seus Clientes:

    
  • Usar o primeiro bloco /64 para Loopback.
  • 

  • Deixar pelo menos 15 redes contíguas ao /64 designado (da mesma forma que o /48, acima).
  • 

  • Avaliar o uso de su fíxos relativamente fáceis de lembrar, para a rede interna (por exemplo: CA5A, FACA, …).

Tudo isto está mostrado gráfi camente na Figura 4, onde P é o prefixo dddd:dd00 e, h, i, j são dígitos hexadecimais dentro dos limites escolhidos. Por outro lado, a base de um planejamento em Infraestrutura da Internet é a topologia. Neste caso usamos a topologia da Figura 2.8 do texto Topologias, Interconexões e Protocolos.

E assim, a divisão do IPv6 deixou de ser um problema. Agora, a questão é identifi car uma maneira de como controlar as informações relacionadas com a designação dos IPv6 aos Clientes. Sem dúvida, qualquer solução envolve um local de armazenamento das informações, isto é, um repositório para os dados. A visão mais abstrata capaz de ilustrar tal ambiente, onde pessoas (usuários) possuem acesso, é a mostrada na Figura 3.

 

DivisaoIPv6

Figura 4. Representando o plano de divisão do bloco /32, graficamente.

 

Construindo o repositório com a XML

 

XML é uma linguagem livre. São poucas as restrições (sintáticas!) sobre ela. Desta forma, o estilo, a experiência e a criatividade individuais determinam a estrutura do repositório. Para este texto, o repositório em XML foi proposto como abaixo, de forma parcial e resumida:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<empresaX>
  <designacao_ipv6>
    <ip prefixo="dddd:dd00::" masc="/32">
      <ip prefixo="dddd:dd00::" masc="/48">
        <designado_para>Livre</designado_para>
      </ip>
      <!-- ... -->
      <ip prefixo="dddd:dd00:8::" masc="/48">
        <ip prefixo="dddd:dd00:8000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <!-- 
            Grupo dos /48 designados 
        -->
        <ip prefixo="dddd:dd00:c001::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c002::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c003::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c010::" masc="/48">      
          <designado_para>Localidade 1</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c010:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 1</comentarios>          
          </ip>
          <ip prefixo="dddd:dd00:c010:0001::" masc="/64">
            <designado_para>Cliente 1</designado_para>
            <fone>37-xxxx-xxxx</fone>
            <responsavel_t>Fulano de Tal</responsavel_t>
            <email>nome AT SPAMFREE exemplo DOT com DOT br</email>
            <comentarios>Cliente do Provedor</comentarios>          
          </ip>
          <!-- ... -->
          <ip prefixo="dddd:dd00:c010:CA5A:" masc="/64">
            <designado_para>Rede Local</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Utilizado na rede local</comentarios>   
          </ip>
          <!-- ... -->
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c020::" masc="/48">      
          <designado_para>Localidade 2</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c020:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 2</comentarios> 
          </ip>
          <!-- ... -->
        </ip>
      </ip>
    </ip>
  </designacao_ipv6>
</empresaX>

Pode-se concluir que o repositório tende-se a tornar muito grande. Entretanto, a partir da escolha inicial da estrutura (ou conjunto de marcadores), da XML, o processo é repetitivo, o que facilita o trabalho. As linguagens de programação (qualquer uma e em especial JavaScript) estão preparadas para trabalhar de maneira trivial sobre repositórios XML, o que facilitaria em muito as operações desejadas (Figura 3). Da mesma forma, os navegadores, imediatamente, representam de forma estruturada um arquivo XML, como pode ser visto na Figura 5.

 

XMLnoChrome

Figura 5. Repositório XML exibido no Chrome.

 

Não se pode esquecer que a W3C possui um recurso para validar um texto XML, bastante útil, que pode ser usado em Markup Validation Service.

Por outro lado, um banco de dados (repositório) XML possui uma organização hierárquica, como mostra a Figura 6.

 

XML-hierarquia

Figura 6. Organização hierárquica de um repositório XML.

 

A eficiência sobre um repositório com tais características depende não somente da hierarquia (ou arranjo dos marcadores) mas, também, do sistema de gerenciamento (programa) do repositório. Durante a etapa de programação, eventualmente, a hierarquia poderá ser aperfeiçoada.

 

Aperfeiçoando as ideias e, o projeto

 

Suponhamos que a ideia de um repositório XML para controlar as designações de IPv6 de um provedor tenha sido um sucesso. A notícia se espalha e um habilidoso programador, digamos, o Pedro Paulo (nosso programador fictício preferido…) resolve desenvolver um repositório para:

  • Atender a vários provedores e,
  • Controlar IPv6 e IPv4

Em uma primeira tentativa, a organização do repositório poderia ter a seguinte organização

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP>
    <empresaX>
        <blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <cliente id="201311281745">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaX>
    
    <empresaY>
        <blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <cliente id="201311281754">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaY>
</repositorioIP>

 

Este segundo modelo altera a hierarquia do primeiro. O componente mais importante do repositório é o marcador <cliente>, mas exige-se que os blocos delegados de IPv6 e IPv4 estejam presentes, mas dando liberdade em relação à presença dos marcadores debaixo do marcador mais importante. Uma visão mas agradável é a do navegador, mostrada na Figura 7, logo abaixo.

 

XML-RepositorioPedroPaulo

Figura 7. O novo repositório exibido no Chrome.

 

Ou, mais agradável ainda, a visão gráfica da hierarquia mostrada na Figura 8.

 

XML-hierarquia-PedroPaulo

Figura 8. Visão gráfica da hierarquia do segundo modelo (Pedro Paulo).

 

Embora imediado é oportuno observar, que a Figura 8 representa uma árvore (estrutura de dados). Navegar nesta árvore é um processo eficiente. Por exemplo, se procuramos pelas informações da Empresa 1, basta seguir os ramos abaixo dela, ignorando o restante dos nós à sua direita. Ou seja, qualquer operação a ser feita sobre o repositório (indicadas pela Figura 3) é estritamente localizada, portanto, muitíssimo eficiente.

Há, contudo, uma questão importunando ao Pedro Paulo. Os nomes dos marcadores de cada empresa / provedor são os mesmos e isto pode causar problemas de consistência ou de conflitos. Se o repositório fosse controlado à mão (por um ser humano), certamente poderíamos trocar um marcador, sem perceber, já que eles são idênticos. Mesmo desenvolvendo procedimentos para manipular automaticamente o repositório, a inconsistência prevalecerá. A linguagem XML possui na sua especificação, um mecanismo importante para garantir a consistência dos marcadores. É a técnica denominada espaço de nomes (do inglês, namespaces). Falaremos sobre ela em seguida, mas uma ótima introdução ao conceito pode ser visto em XML Namespaces.

 

Espaço de nomes em XML

 

O objetivo do espaço de nomes em XML é eliminar conflitos entre marcadores ou, em outras palavras, estabelecer a unicidade dos marcadores. Isto é feito através do atributo xmlns que distinguirá os prefixos a serem usados nos marcadores. O formato deste atributo é, xmlns:prefixo=”URI” colocado(s) no marcador inicial (raiz). URI (Uniform Resource Identifier) é uma cadeia de caracteres que identifica um Recurso da Internet. A URL (Uniform Resource Locator), usualmente usado por nós é um caso particular da URI. Na XML, a URI é simplesmente a caracterização da unicidade e não transporta nenhuma informação adicional.

Nos artigos seguintes veremos um papel mais preponderante do espaço de nomes. Por hora, o segundo modelo do repositório proposto e, a Figura 9, ilustram como ele se transforma, ao usar espaço de nomes, que comparando com a Figura 7 torna-se o entendimento imediatamente intuitivo.

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP 
    xmlns:x="http://ws.org.br/empresa/X"
    xmlns:y="http://ws.org.br/empresa/Y">
    
    <x:empresa>
        <x:blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <x:blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <x:cliente id="201311281745">
            <x:nome></x:nome>
            <x:responsaveltecnico></x:responsaveltecnico>
            <x:fonenoc></x:fonenoc>
            <x:endereco>
                <x:logradouro></x:logradouro>
                <x:numero></x:numero>
                <x:complemento></x:complemento>
                <x:bairro></x:bairro>
                <x:cep></x:cep>
                <x:cidade></x:cidade>
                <x:estado></x:estado>
            </x:endereco>
            <x:ipv6designado></x:ipv6designado>
            <x:ipv4designado></x:ipv4designado>
            <x:observacoes></x:observacoes>
        </x:cliente>  
    
    </x:empresa>
    
    <y:empresa>
        <y:blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <y:blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <y:cliente id="201311281754">
            <y:nome></y:nome>
            <y:responsaveltecnico></y:responsaveltecnico>
            <y:fonenoc></y:fonenoc>
            <y:endereco>
                <y:logradouro></y:logradouro>
                <y:numero></y:numero>
                <y:complemento></y:complemento>
                <y:bairro></y:bairro>
                <y:cep></y:cep>
                <y:cidade></y:cidade>
                <y:estado></y:estado>
            </y:endereco>
            <y:ipv6designado></y:ipv6designado>
            <y:ipv4designado></y:ipv4designado>
            <y:observacoes></y:observacoes>
        </y:cliente>  
    
    </y:empresa>
</repositorioIP>

 

Olhando um pouco mais atentamente a XML acima, surge uma questão sobre a qual vale a pena pensar: será que o atributo id, incluído nos marcadores <cliente> faz sentido diante da presença do espaço de nomes?

 

XML-NS-RepositorioPedroPaulo

Figura 9. O segundo modelo, com a unicidade dos marcadores garantida pelo espaço de nomes, visto pelo Chrome.

 

Considerações finais

 

Nada foi dito no artigo sobre as técnicas de programação para manipular repositórios em XML. Foge do escopo do texto, que se preocupou em mostrar algumas facilidades para planejar o uso dos recursos de numeração (IPv6 / IPv4) e a alternativa de estrutura-los em um repositório usando XML. A XML é uma linguagem orientada, principalmente, ao entendimento computador-computador (ou melhor, programa-programa), muito embora ela seja acessível a humanos. Dada à sua forma livre de expressão, presta-se a inúmeras aplicações úteis, como a do exemplo, documentar a distribuição de IPv6.

Sob o ponto de vista da Web Semântica, a XML é muito restrita para a necessária expressividade semântica, apesar de ser a base para as alternativas que serão abordadas nos próximos textos.

 

Referências

  1. S. Kawamura amd M. Kawashima. A Recommendation for IPv6 Address Text Representation. RFC5952. December 2008. Disponível em: http://www.rfc-editor.org/rfc/rfc5952.txt. Acessado em 02/10/2013.
  2. IHMC. Cmap tools. http://ftp.ihmc.us/. Acessado em 02/10/2013.
  3. T. Narten and G. Huston ant L. Roberts. IPv6 Address Assignment to End Sites, March 2011. RFC6117.
  4. Joseph D. Novak and D. Bob Gowin. Learning how to learn. Cambridge University Press, Cambridge, UK, 1 edition, 1984.
  5. SurfNet. Preparing an IPv6 Address Plan. Disponível em: https://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf. Acessado em: 02/10/2013.
  6. BRAY, T. et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C, 26 November 2008. Disponivel em: http://www.w3.org/TR/REC-xml/. Acesso em: 22 maio 2013.
  7. BRAGA, J. Sistemas Autonomos, Empresas Autônomas. Infraestrutura da Internet, 03 mar. 2006. Disponivel em: http://ii.blog.br/2006/03/03/sistemas-autonomos-empresas-autonomas/. Acesso em: 22 maio 2013.
  8. CAÑAS, A. J. et al. A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support. The Institute for Human and Machine Cognition. Pensacola, FL: The Chief of Naval Education and Training. 2003. p. 108.
  9. BRAGA, J. A ISOC, o IETF e a infraestrutura da Internet. Infraestrutura da Internet, 03 Janeiro 2013. Disponivel em: http://ii.blog.br/2013/01/03/a-isoc-o-ietf-e-a-infraestrutura-da-infraestrutura-da-internet/. Acesso em: 22 maio 2013.

Semantic Web x Internet Infrasctruture

CMapProject1

English:

 

I wrote some preliminary ideas about a project of medium / long-term application of Semantic Web Infrastructure on the Internet named Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

The text is available in PDF (English): here.

Other useful information about the IETF is here.

I’m looking for researchers interested in this area. E-mail to: juliao SPAM FREE AT braga eti DOT DOT br.

Português:

 

Escrevi algumas ideias preliminares sobre um projeto de médio / longo prazos de Web Semântica aplicada a Infraestrutura da Internet, com o nome Preliminaries essays to research in Semantic Web applied to Internet Infrastructure.

O texto, em pdf está disponível (em inglês) aqui

Outras informações úteis sobre o IETF encontra-se em aqui.

Tenho grande interesse em contatos com pesquisadores interessados nesta área. E-mail para juliao AT SPAM FREE braga DOT eti DOT br.

 

Topologias, Interconexões e Protocolos

Introdução

 

Desde que iniciei com este blogue, no final de 2005, muitos amigos e leitores encaminham-me, sistematicamente, sugestões e críticas, construtivas, de vários tipos. Alguns dizem que os textos estão muito longos e pedem para que os segmente, outros indicam falhas ou conteúdo que geram dúvidas, principalmente de interpretação, por não estarem suficientemente claros. Outros insistem para que os textos sejam transformados em livro. Há uns três anos atrás pensei, seriamente, nesta possibilidade. Portanto, recentemente decidi que isto seria feito. Na realidade, pensei em dois livros. Um com a exposição dos textos do blogue, refinados e organizados em forma e conteúdo adequados, a preservar a tese de conhecimento auxiliar àqueles que precisam de uma referência imediata e simples.

capaLivro-1

Entretanto, durante um ano “quase” sabático que me dei, refleti e imaginei a possibilidade de escrever o segundo livro, no qual a simplicidade do conhecimento e experiências que acumulei ao longo dos muitos anos de trabalho pudessem ser expostos a partir de uma topologia que fosse capaz de exibir a aplicação de problemas de interconexões e de decisões sobre quais protocolos usar, principalmente, orientados aos pequenos e médios provedores.

Desde então, comecei a me preparar para este segundo livro, já que a decisão sobre o primeiro livro estava tomada e em andamento, com a ajuda do Deivison Moraes, o qual participou, remotamente, de diversas experiências necessárias à consolidação do conhecimento envolvido. Para o segundo livro, escolhi uma arquitetura, que a princípio parece complexa (mas, não é), contendo tudo aquilo necessário para que o administrador de um pequeno e médio provedor deve conhecer, para construir uma infraestrutura da Internet melhor. Ao dizer isto estou fazendo apologia à estrutura e missão do IETF, que pode ser adaptada do RFC3935: “É uma comunidade internacional de pessoas interessadas em cumprir a missão de produzir, com alta qualidade e relevância técnica, documentos de engenharia, que influenciam a maneira como as pessoas projetam, usam e gerenciam a Internet, de tal maneira, que ela possa funcionar cada vez melhor.”

capa

O título escolhido, para o segundo livro, “Topologias, Interconexões e Protocolos” insiste no fato de que estas três palavras evidenciam questões inter-relacionadas que exigem decisões corretas e seguras, de implementação. A arquitetura (no sentido de uma topologia ou de diversas topologias) é o planejamento ou projeto, com base nas disponibilidade de recursos e facilidades disponíveis, no cenário em que se insere. As Interconexões exigem ou são exigidas na escolha dos Protocolos. Protocolos dependem de Interconexões e são tratados, pelo livro, em um sentido mais amplo, ao adotar componentes necessários ao funcionamento da Infraestrutura da Internet, local ou não. Observações anotadas e retiradas das listas do IETF (de grupos de trabalhos ou independentes), das listas dos RIRs (Regional Internet Registers), de listas internacionais independentes, das listas brasileiras (GTER, a peculiar, finada prematuramente, GT-AS, entre outras), dos cursos de IPv6 do Nic.br e outros (como o recente curso para ASes), tudo, foi usado para compor a proposta do livro. Adicionalmente, uma extensa referência bibliográfica coletada e lidas por mim, ao longo dos anos (artigos, livros, RFCs e equivalentes) expande a estrutura fundamental, do conhecimento exigido e exposto. O que faltava era ajustar tudo isto de forma simples, atento ao ponto de vista de Alfred North Whitehead: “Seek simplicity, but distrust it”.

Abaixo seguem extratos dos dois primeiros capítulos do livro (Introdução e Topologias), que orienta o sobre como será o conteúdo dos capítulos restantes. Vamos esperar para uma avaliação dos autores.



 

Topologias, Interconexões e Protocolos

 

1. Introdução

 

A Infraestrutura da Internet está, sistematicamente, em movimento. Há poucos anos atrás, a perspectiva da escassez do IPv4 trouxe o IPv6 para resolver o problema. Foi um impacto radical, em particular, sobre a mente dos administradores da Infraestrutura da Internet. Assim, antes da chegada do IPv6 e durante muitos anos, a Internet era representada nos textos, de forma abstrata, como se fosse um nuvem, em variações diversas, semelhante à Figura 1.1.

 

InternetAntiga
Figura 1.1. Representação abstrata da Internet.

 

Com a chegada do IPv6, até podemos representar a Internet como a Figura 1.1, desde que fique claro que a Internet, na realidade é composta de dois ambientes bem definidos: o ambiente IPv4 e o ambiente IPv6. Uma possível representação desta nova abstração é a Figura 1.2.

 

InternetNova
Figura 1.2. Nova representação abstrata da Internet.

 

Neste livro, por razões didáticas iremos preferir uma representação mais apropriada para escapar das imagens confusas, ao associarmos topologias, interconexões e protocolos. A Figura 1.3 exibe a nossa proposta, onde o fundo branco servirá para desenhar os modelos propostos.

 

Topologia-01
Figura 1.3. A representação abstrata da Internet, para efeitos deste livro.

 

Se a Internet está envolvida, qualquer roteador colocado na área branca da Figura 1.3, que esteja conectado a outro roteador de um Sistema Autônomo (AS) tornará, imediatamente, membro da Internet, juntamente com toda a sua rede interna de usuários e/ou computadores. Portanto, o espaço em branco é outra abstração, que estamos usando, para facilitar a exploração didática dos conceitos abordados.

O livro está estruturado em quatro capítulos básicos: Introdução, Topologias, Interconexões e Protocolos. Completam o livro, um considerável glossário, seguido de uma Referência Bibliográfica bastante completa e de índices (analítico, remissivo e figuras), além de Anexos abordando equipamentos, roteadores, ferramentas e servidores essenciais à Infraestrutura da Internet. Os anexos sobre outros roteadores que não aqueles usados no capítulo de Protocolos, adicionam alternativas de usá-los, por alguma razão específica do leitor.

 

2. Topologias

 

2.1 Tráfego, trânsito e transporte

 

Topologia é o recurso inicial, que um administrador da Infraestrutura da Internet tem disponível, para planejar e desenvolver o projeto de uma ou mais interconexão e os respectivos protocolos necessários. Geralmente, usamos um processo de modelagem (ou desenho) de uma topologia, usando a técnica de refinamentos sucessivos para chegarmos ao modelo final esperado, ou melhor, o modelo ótimo. Por outro lado, a apresentação das diversas topologias neste texto, nos dá a impressão de que foi imediato, o desenvolvimento do projeto. Não foi! Levou-se um bom tempo para chegar à etapa descrita, inicialmente, neste capítulo e, outras mudanças virão na sequência. Na prática percebe-se de que a oportunidade de usar a técnica de refinamentos sucessivos é fundamental e fortemente recomendada, pois ela permite o entendimento completo do problema, etapa por etapa. Em cada refinamento, ou cada etapa, a utilização de ferramentas de simulação representaram uma decisão de projeto extremamente eficaz, mas reconhecidamente trabalhosa. Várias outras ferramentas foram utilizadas, sobre as quais comentamos nos Anexos.

 

2.2 Topologia da Localidade 1

 

O exemplo escolhido para ilustrar as questões que encontramos em nosso dia a dia, envolvendo topologia, interconexões e protocolos foi o de uma empresa, que possui filiais em seis localidades remotas e principais, além de quatro outras localidades “secundárias”, mas também remotas. O objetivo da empresa é atender suas demandas de tráfego de dados dentro de cada localidade e entre todas as localidades. Como qualquer empresa, custo é um componente importante e a máxima é minimizá-lo.

A Localidade 1 possui uma característica importante: nela estão os recursos necessários para administrar toda a infraestrutura de tráfego de dados. Por recursos entende-se pessoal, equipamentos, software, ferramentas e tudo mais necessário para atender a este objetivo. A Figura 2.1 exibe a topologia da Localidade 1, a qual passamos a descrever.

 

Topologia-02
Figura 2.1. Topologia da Localidade 1.

 

Na topologia da Figura 2.1, vemos a rede interna (azul claro) e o seu roteador de borda identificado pelo número 1. Este roteador tem três conexões. A conexão em verde, com o roteador T11 é a oferta de tráfego de dados para a Internet. Dizemos, então, que T11 pertence a um provedor que oferece trânsito. Reforçando, tráfego de dados para a Internet, chamamos de trânsito. Esta conexão de trânsito, entre 1 e T11 é direta, no sentido de que existe um meio físico conectando os dois roteadores. Há, entretanto, uma curiosidade neste trânsito: ele é assíncrono, isto é, as velocidade de subida e descida, do tráfego de dados, são diferentes. Verde é a cor que usaremos para identificar conexão assíncrona. O fornecedor de trânsito para a Localidade 1, somente oferece trânsito para a Internet IPv4. Foi necessário conseguir um trânsito IPv6 usando um túnel (“tunnelbroker”), com a Hurricane Electric (HE), que oferece tal facilidade, sem custo. A conexão com a HE não é direta e, portanto, exige interconexão com a Internet, em IPv4. Embora a HE não exija, a empresa usou seu ASN para fazer um empareamento (“peering”) com o HE1 (roteador da HE que atende ao trânsito IPv6 para a empresa, na Localidade 1. Como a empresa precisa de trânsito IPv6, em todas as localidades, a equipe técnica resolveu solicitar um empareamento com o Team Cymru (TCY), com o objetivo de receber os blocos IPv6 que não são anunciados na Internet, informação muito útil para os administradores da empresa, ao eliminar um considerável esforço extra de gerenciamento. O TCY estabelece o empareamento através de ASNs privativos, o que indica que não é necessário possuir um ASN para o empareamento com eles.

O trânsito assíncrono com T11 é uma aDSL. Os fornecedores de aDSL no Brasil, não possuem o hábito de estabelecer empareamento em seus roteadores com os clientes.

Não estamos interessados em avaliar o mérito do significado de um trânsito assíncrono. A escolha foi feita partindo das premissas: baixíssimo custo e interesse técnico.

Há diferenças entre o tráfego de dado estabelecido com o Team Cymru e com a HE. O primeiro é somente tráfego de dados (em uma única direção) e o segundo é trânsito! Tráfego de dados como o do Team Cymru, é dito tráfego de empareamento (ou tráfego de “peering”), ou mais simplesmente, tráfego (quando não há custos envolvidos, como é o caso). A conexão com o Team Cymru não é direta, razão pela qual usamos a cor vermelha.

Já é possível perceber, que não estamos interessados em questões de implementação ou outros detalhes de cada fornecedor de tráfego. Isto acontecerá nos Capítulos 3 e 4. Por hora, nossa preocupação são as topologias. Claro é, entretanto, que os envolvidos na topologia possuem um conhecimento técnico anterior. Até o final do livro, isto será transmitido para aqueles que ainda não detêm tal conhecimento.

A importância da Localidade 1, para a equipe técnica está caracterizada pelo retângulo, no desenho.

 

2.2 Topologia da Localidade 2

 

A Figura 2.2, apresenta a topologia da Localidade 2.

 

Topologia-031

Figura 2.2. Topologia das Localidades 1 e 2.

 

A topologia da Localidade 2 mostra uma conexão de trânsito em T21 (via fibra ótica), agora síncrona. T21 é um AS, o que implica em um trânsito com empareamento entre os roteadores 2 e T21. Este empareamento com T21 recebe a tabela completa de rotas disponível da Internet e, o roteador 1, não faz nenhuma restrição do que chega até ele, nesta tabela, exceto a rotas padrões (ou, “default”) e seus blocos anunciados. Também, trânsito IPv6 não é oferecido por T21 e, portanto, suprido pela HE (HE2). Como temos agora, IPv4 e IPv6 sendo oferecidos foi conveniente fazer dois empareamentos com o TCY, para receber os blocos IPv4 e IPv6, não anunciados (chamado de “bogon”, em ambos os casos). O TCY exige dois empareamentos (para segurança adicional da conexão), para cada tipo de “bogon”: dois para o IPv4 e dois para o IPv6. Então, o roteador 2 tem quatro empareamentos com o TCY (no roteador 1, são dois empareamentos).

A novidade na Localidade 2 é a conexão com um dos Pontos de Troca de Tráfego (PTTs) brasileiros. Nesta Localidade temos o PTT1, com uma conexão de tráfego, parecida com a do Team Cymru e por isto, conexões a PTTs são chamadas simplesmente de tráfego (ou tráfego de empareamento). Ao PTT1, está conectado o T22, com o qual a empresa resolveu fazer um acordo bilateral dentro do PTT1, para seu trânsito redundante na Localidade 2, à Internet. Há entretanto, uma conexão de trânsito, entre o T21 e o T22 indicando que o trânsito da empresa na Localidade 2 é feita, na realidade, somente pelo T22. Este aparente excesso será analisado detalhadamente no Capítulo 3 (Interconexões). A conexão do roteador 2 com o PTT1 é direta (local, para sermos mais precisos).

 

2.3 Topologia da Localidade 3

 

Nossa abordagem agora será sobre a Figura 2.3, que expõe a topologia da Localidade 3.

 

Topologia-043

Figura 2.3. Topologias das Localidades 1, 2 e 3.

 

A Localidade 3 tem trânsito IPv6 e IPv4, diretamente de T31. O fornecedor T31 recebe trânsito IPv6 de T32 do qual, também. recebe trânsito IPv4 e transporte até o PTT4. O T31 recebe trânsito IPv4 de T33, o qual fornece transporte até o PTT2. Nesta topologia, o roteador 3 possui um empareamento em pilha dupla (IPv4 + IPv6) com seu único fornecedor de trânsito, o T31. O TCY é usado, com quatro empareamentos para receber os “bogons” IPv4 e IPv6. É do nosso conhecimento, que T31 possui trânsitos com bandas diferentes, de T32 e T33. O conexão de 3 com T31 é local, o que favorece, no empareamento, somente o recebimento da rota padrão, sem necessidade de tabelas de roteamento.

Vamos à topologia da Localidade 4, mostrada na Figura 2.4.

 

2.4 Topologia da Localidade 4

 

 

Topologia-052

Figura 2.4. Topologias das localidades 1, 2, 3 e 4.

 

A topologia para a Localidade 4 é parecida com a da Localidade 3, exceto pelo fato de possuir trânsito somente com um fornecedor, o T41, que por sua vez, também possui uma única conexão de trânsito, com o T411. Um pouco mais elaborada, a topologia mostra que o roteador 2 recebe trânsito IPv6, através de uma conexão com o PTT2, em um acordo bilateral com um fornecedor por lá conectado. Com podemos observar, o PTT2 é também, uma conexão da Localidade 3 mas, que não recebe trânsito IPv6, por lá. O Team Cymru está, também, empareado nesta localidade (TCY).

O desenho ilustra que o tráfego do roteador 4 ao PTT2 é invisível aos fornecedores de trânsito. Bem como o trânsito IPv6.

A topologia da Localidade 5 é discutida no tópico abaixo.

 

2.5 Topologia da Localidade 5

 

A Figura 2.5 exibe a topologia da penúltima localidade.

Topologia-062

Figura 2.5.

 

Sem redundância, o T51 fornece trânsito para a empresa, através de T52. Como T52 não é uma conexão direta, é a localidade com a pior deficiência na segurança de tráfego para a Internet, muito embora isto não aconteça nos trânsitos construídos por T52. Um novo PTT, o PTT1 está acessível aproveitando a oportunidade de transporte que T52 oferece para T51.

 

2.6 Topologia da Localidade 6

 

A Figura 2.6 mostra uma topologia preliminar da Localidade 6.

 

Topologia-072

Figura 2.6.

 

É a única em que o trânsito não é direto com o roteador de borda da Internet. Mas, isto não representa uma insegurança para a conexão, porque o roteador T61 está em uma rede diretamente conectada. Além do mais, o T61 está diretamente conectado a diversos trânsitos redundantes. Embora um dos trânsitos de T61 ofereçam IPv6, não foi possível, ainda, usar esta facilidade. Por esta razão, o trânsito IPv6 é feito via túnel, com a HE (HE6). Via T61, conseguiu-se acesso a um outro PTT, o PTT5. A troca de tráfego multilateral no PTT1 é muito interessante para a Localidade 6. Insistentemente, o TCY é usado, também.

A Localidade 6 possui uma característica especial, no contexto da empresa, que é o controle sobre atividades de quatro outras localidades próximas, mas remotas. Esta relação está exibida na Figura 2.7. O trânsito de Internet para estas localidades é feito pela Localidade 6. Por outro lado, a Localidade 6 possui uma série de outros recursos especialmente úteis para atender a sua demanda remota.

 

Topologia-07.12

Figura 2.7. Topologias de todas as localidades e a extensão da Localidade 6.

 

 

2.9 A arquitetura final

 

Cada localidade da empresa está acessível através da Internet. Logo, a empresa ESTÁ na Internet, pois ela usa seus ASNs, em cada localidade, para que isto aconteça (exceto a Localidade 1). A Figura 2.8 ilustra bem este fato.

O pessoal de administração da rede da empresa, presentes, em sua quase totalidade, na Localidade 1, gerencia todos os recursos, principalmente usando o IPv6.

 

Topologia-Final4

Figura 2.8. Visão final da topologia global da empresa.

 

Mas, há algumas pequenas dificuldades, a maioria delas identificadas quando toda a arquitetura (o conjunto das seis topologias) se tornou operacional. Como não eram problemas graves foi prudente esperar algum tempo para iniciar um processo de otimização e refinamento granular da arquitetura. O que foi feito estará descrito nos Capítulos 3 e 4, deste livro.

 

2.10 ASNs, IPv4 e IPv6 usados neste documento

 

O RFC5398 indica os seguintes números para identificar ASNs privativos:

64496 - 64511 e 65536 - 65551

 

O RFC5735 (página 5), apresenta o quadro reproduzido abaixo, os IPv4 indicados para uso específico:

 

Address Block       Present Use                Reference
------------------------------------------------------------------
0.0.0.0/8           "This" Network             RFC 1122, Section 3.2.1.3
10.0.0.0/8          Private-Use Networks       RFC 1918
127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
169.254.0.0/16      Link Local                 RFC 3927
172.16.0.0/12       Private-Use Networks       RFC 1918
192.0.0.0/24        IETF Protocol Assignments  RFC 5736
192.0.2.0/24        TEST-NET-1                 RFC 5737
192.88.99.0/24      6to4 Relay Anycast         RFC 3068
192.168.0.0/16      Private-Use Networks       RFC 1918
198.18.0.0/15       Network Interconnect
                    Device Benchmark Testing   RFC 2544
198.51.100.0/24     TEST-NET-2                 RFC 5737
203.0.113.0/24      TEST-NET-3                 RFC 5737
224.0.0.0/4         Multicast                  RFC 3171
240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
                                               RFC 922, Section 7

 

O RFC3849 recomenda o uso do bloco IPv6

2001:DB8::/32

em documentos. Contudo, há em andamento, no IETF um Internet-Draft (I-D) propondo disponibilizar o bloco DDDD:D000::/20, para documentação (draft-moreiras-v6ops-rfc3849bis-00.txt). Embora o I-D esteja em fase de obtenção do consenso no IETF usaremos endereçamento IPv6 retirado deste bloco.

Arbitrariamente, vamos supor que a empresa abordada possua o AS64500 e tenha recebido, associados a este ASN, do Registro.br, os blocos 10.1.0.0/20 e DDDD:D000::/32. Suponha, também, que esta empresa obteve um outro ASN (AS65536), sem nenhum bloco IPv6 ou IPv4. Para efeito didático, o conteúdo deste livro abstrai-se das restrições privativas dos números escolhidos, isto é, a noção de uso privado não será considerado, nestes casos.



 

Agradecimentos

 

Foram muitas as pessoas que me deram suporte para o desenvolvimento deste trabalho. De várias maneiras, direta e indiretamente. Isto inclui meus inúmeros clientes, velhos amigos e novos amigos. A eles, meus agradecimentos. Em particular, gostaria de nomear algumas pessoas que colocaram recursos físicos, materiais, experiências incomuns e incentivos, permitindo incondicionalmente, que a topologia pudesse ser testada e simulada de forma integral, sistemática e intensivamente, em suas diversas etapas, mesmo sem conhecimento do objetivo final. São elas, em ordem alfabética: Éder Zagui (IBL Telecom, Guaratinguetá, SP), Fabrício Mota Camargo (MutumNet, Mutum, MG), José Marconi de Almeida (Cooperabaeté, Abaeté, MG), Luciano Inácio (Jupiter Telecom, Imperatriz, MA), Luciano Rampanelli (Comodoro, MT), Marcelo Micucci (BM Promoções, Belém, PA), Marcos Paulo Fernandes (Heliodora Online, Heliodora, MG), Samyr Bechelane (Netcetera, Betim, BH).



CategoriasBogon, eBGP, iBGP, IPv4, MPTCP, PTT, RPKI, TCP/IP

Um Guia para modelar ontologias usando OWL-DL (GOL)

“…A atmosfera moral é magnífica para batráquios.
Não imaginas como andam propícios os tempos a todas as mediocridades. Estamos no período hilariante dos grandes homens-pulhas, dos Pachecos empavesados e dos Acácios triunfantes…”

Euclides da Cunha, em 1909, numa carta ao seu cunhado.

 

Apresentação

 

Web Ontology Language (OWL), (Hitzler, et al., 2009) é uma linguagem para Semantic Web, desenvolvida pelo World Wide Web Consortium (W3C) e está descrita formalmente por (Patel-Schneider, et al., 2004). A OWL é uma extensão da linguagem RDF Schema, (Hayes, 2004), com significativos recursos adicionais de expressividade, no aspecto da representação do conhecimento, objetivo da ontologia e usa a XML. Em relação à expressividade do conhecimento a OWL é classificada em OWL Full, OWL-DL e OWL Lite. A OWL Full é usada quando se deseja o máximo de expressividade e liberdade sintática, em relação à RDF Schema, mas que, na mesma proporção de seu poder, incorpora o fato de ser indecidível. A OWL-DL, menos poderosa do que a OWL Full, consegue compor recursos de expressividade satisfatórios, sem perder a completude e decidibilidade computacionais. Finalmente, a OWL Lite é uma linguagem com poder de expressividade extremamente pobre, muito embora seja de compreensão simples e é fácil de implementar em procedimentos automáticos. Neste contexto, a OWL-DL é a linguagem preferida para modelar ontologias.

Modelar, ou construir modelos que representem um domínio de interesse é um processo complicado e muitas vezes difícil. Isto se torna uma tarefa monumental e a recomendação é que seja um trabalho incremental (baseado em refinamentos sucessivos) e, sobretudo, que se siga um roteiro sistemático, o qual somente uma metodologia efetivamente consistente poderia satisfazer. Existem muitas propostas de metodologias e, a maioria delas é derivada de outras metodologias conhecidas, liderando com vantagens as áreas de desenvolvimento de software e de projetos em geral.

EagleOwl

O presente trabalho propõe um guia para o desenvolvimento de ontologias em OWL-DL, ao qual se dá o nome de GOL. Adicionalmente o trabalho segue o OpenStand descrito em (OpenStand, 2013) e, em seus princípios (OpenStand, 2012). Para estabelecer a proposta do GOL será desenvolvida uma abordagem orientada ao domínio de conhecimento associado à Infraestrutura da Internet.

O GOL responde às questões subjacentes à Figura 1, a qual exibe dois ambientes:

  • Seleção de ferramentas e técnicas para trabalhar na modelagem de ontologias.
  • Seleção e modificação de metodologias para o projeto, implementação e teste de ontologias.

 

guidetoModelOntology

Figura 1. As escolhas de um guia para modelar ontologias (GOL).

 

Os ambientes são derivados de metodologias conhecidas no desenvolvimento de sistemas e programas, como já foi dito acima, coincidindo o primeiro ambiente com o tópico Requirements and Analysis, e, o segundo ambiente associa-se ao tópico Design, Implement and Test, ambos baseados no Unified Process (UP), de (Jacobson, et al., 1999). Esta relação está bem caraterizada em uma das metodologias analisadas para o GOL, chamada Unified Process for ONtology (UPON), descrita por (Nicola, et al., 2009).

Após as avaliações sobre os recursos disponíveis nos dois ambientes, o trabalho propõe o GOL, conforme a Figura 2 com as escolhas possíveis entre as alternativas estudadas.

Por outro lado, o GOL, ao indicar uma metodologia, atenta para o fato de que ela seja versátil, o suficiente, e capaz de permitir mudanças, a critério das habilidades e perfis de grupos e pessoas envolvidas no desenvolvimento de ontologias sem, contudo descaracterizar o resultado final que se espera quando é usada a OWL-DL.

 

guidetoModelOntology-final

Figura 2. A estrutura final (enxuta), do EOWL.

 

Para validar o GOL, um projeto envolvendo um subdomínio do imenso domínio de conhecimento agregado à Infraestrutura da Internet. A escolha recai sobre os recursos de numeração, cuja atribuição / distribuição é feita pelo IANA. Propositalmente, a escolha origina um estudo para aplicação da Web Semântica, na direção de tornar os administradores de recursos da Internet, confortáveis diante de suas responsabilidades.

 

Bibliografia

 

  • Fernández López M. Overview of Methodologies For Building Ontologies [Conference] // Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) / ed. Benjamins V. R. [et al.]. – Stockholm, Sweden : [s.n.], August 2, 1999.
  • Hayes, P., 2004. RDF Semantics. [Online] Available at: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
    [Acesso em 18 maio 2013].
  • Hitzler, P., Krötzsch, M., Parsia, B. & Patel-Schneider, P. F., 2009. OWL 2 Web Ontology Language Primer. [Online] Available at: http://www.w3.org/TR/2009/REC-owl2-primer-20091027/ [Acesso em 19 maio 2013].
  • IANA, 2013. Autonomous System (AS) Numbers. [Online] Available at: http://www.iana.org/assignments/as-numbers/as-numbers.xml [Acesso em 17 maio 2013].
  • Jacobson, I., Booch, G. & Rumbaugh, J., 1999. The Unified Software Develop-. s.l.:Addison Wesley, USA.
  • Nicola, A. D., Missikoff, M. & Navigli, R., 2009. A Software Engineering Approach to Ontology Building. Information Systems, 34(2), Elsevier, pp. 258-275.
  • OpenStand, 2012. Principles. [Online] Available at: http://open-stand.org/principles/ [Acesso em 17 maio 2013].
  • OpenStand, 2013. About. [Online] Available at: http://open-stand.org/about-us/ [Acesso em 2013].
  • Patel-Schneider, P. F., Hayes, P. & Horrocks, I., 2004. OWL Web Ontology Language Semantics and Abstract Syntax. [Online] Available at: http://www.w3.org/TR/2004/REC-owl-semantics-20040210.

IETF => D-58: Como participar dos encontros do IETF

Atualizado em 10/11/2013 17:20.

 

Introdução

 

Atualmente os encontros do IETF tem sido em número de três, por ano, geralmente realizados nos seguintes locais, do mundo: América do Norte, Europa e Ásia. A Tabela 1 exibe os encontros do IETF já programados.

Encontro
Ano
Mês
Local
IETF 89 2014 Março Londres
IETF 90 2014 Julho Toronto
IETF 91 2014 Novembro Honolulu
IETF 92 2015 Março Dalas
IETF 93 2015 Julho Praga
IETF 94 2015 Novembro Yokohama
IETF 95 2016 Abril Europa
IETF 96 2016 Julho América do Norte
IETF 97 2016 Novembro Ásia

Tabela 1. Próximos encontros do IETF
Fonte: IETF Upcoming IETF Meetings.

 

Maneiras de participar

 

Pode-se participar dos encontros do IETF, presencialmente ou remotamente. A participação presencial implica em arcar com todas as despesas de viagem e estada, incluindo a taxa de registro no evento (Figura 2). A Internet Society oferece algumas bolsas para a participação presencial. A participação remota é gratuita e completa, no sentido de participação efetiva, apenas exigindo o uso de ferramentas apropriadas. Presencial, remota ou como bolsista, o IETF oferece um conjunto de facilidades para quem participa pela primeira vez. A melhor maneira de enxergar tais alternativas é acessar a página do evento. A Figura 1 exibe a programação parcial do IETF 86, que irá acontecer em março de 2013. Os anais e resultados completos das reuniões passadas possuem suas próprias páginas disponíveis em Past Meetings.

 

ProgramacaoIETF86

Figura 1. Visão parcial da programação do IETF 86. Fonte: IETF 86 – Orlando, FL, USA.

 

Na Figura 2, estão anotados em vermelho, os pontos importantes. Em particular, a ênfase dada aos participantes de primeira vez (New Attendees), os quais são chamados a compor uma série de eventos preliminares (um dia antes do encontro), com o objetivo de indicar o funcionamento do encontro do IETF, para que a oportunidade seja proveitosa e maximizada. Uma referência importante e exclarecedora é The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force, com sua tradução em português, aqui.

 

Participação presencial

 

Em Register aparecem as instruções e regras para a inscrição, conforme mostra a Figura 2, seguindo do respectivo formulário. Estão visíveis, os valores das taxas de inscrição, que variam de acordo com datas. Atenção ao fato de que estudantes são favorecidos por uma taxa de inscrição bem mais em conta.

 

Participação remota

 

Cada encontro possui uma completa facilidade para participação remota e estão disponíveis, para o IETF 86, em Remote Participation at IETF 88. A informação é extensiva, no sentido de que tudo é muito bem documentado. As facilidades passivas (audio e vídeo) são complementadas pelas facilidades ativas (Jabber/XMPP Groupchat, WebEx e Meetecho), com os respectivos tutoriais referenciados. São facilidades que atendem, na plenitude, o participante remoto, inclusive, com mobilidade. No máximo exige uma pequena preparação antecipada. A organização dos recursos remotos está bem estruturada e orientada pela Agenda.

 

Bolsas

 

A ISOC (Internet Society) oferece diversas bolsas voltadas à participação em suas atividades, uma delas para apoiar diretamente a presença em encontros do IETF (The Internet Society Fellowship to the Internet Engineering Task Force (IETF) Programme). A participação em outros programas de bolsas agregam valor ao pedido de bolsa para participação no IETF.

A bolsa para participação nos encontros do IETF são de dois tipos: primeira participação (em um dos eventos do ano) e retorno (a um evento no próximo ano). Não há limite de idade e inclui:

  • Passagens, acomodação (no hotel do evento), taxas de inscrição e entrada para o evento social do encontro;
  • Disponibilidade de um mentor, que ajudará o bolsista a se preparar para participar na área de interesse, facilitar o relacionamento com outros participantes e garantir a movimentação no encontro, durante toda a semana de duração;
  • Uma ajuda financeira para despesas diversas (~ US$400.00);
  • Certificado de participação.

O critério de seleção é bastante competitivo (mais de 200 candidatos para, aproximadamente 10 bolsas). Os requisitos para a qualificação (Selection Criteria for Fellowships to the IETF) são, resumidamente, os seguintes:

  • Ser membro da Internet Society;
  • Possuir grau universitário em ciência da computação, tecnologia da informação, ou equivalente, ou ainda, demonstrar experiência relevante nestas áreas;
  • Ser membro de uma organização com atividades associadas a redes, instituição de ensino, pesquisa e participante de programas de mestrado e doutorado com objetivos afins;
  • Possuir completa noção da influência do IETF no seu contexto de interesse ou demonstrar a importância de áreas do IETF sobre seu trabalho atual;
  • Demonstrar uma forte razão para participar de encontros do IETF relatando a influência dos trabalhos do IETF sobre seu próprio trabalho, estudo ou pesquisa, quando retornar a seu país;
  • Apresentar um plano para compartilhar a experiência e conhecimento adquiridos no encontro do IETF, com outras pessoas na sua área ou região locais;
  • Residir em um país em desenvolvimento e que tenha baixa frequência de participação no IETF;
  • Necessitar de apoio para participar de um encontro do IETF e mesmo que não tenha sido selecionado em tentativa anteriores;
  • Seguir um ou mais Grupos de Trabalho (WGs) do IETF.

O inglês é a língua oficial do IETF. Ouvir, escrever e falar com razoável fluência é um requisito essencial. Por outro lado, a sistemática participação em atividades promovidas por instituições locais, responsáveis por aplicações de recomendações ou de gerenciar recursos de rede de dados (LACNIC, NI.br, etc.) é fortemente positiva na seleção.

 


Nota 1: O IETF apoia diversas outras formas de participação, identificadas como IETF and OIS Programmes que, além das bolsas incluem: reguladores, mentores e participação no Centro de Engajamento Remoto (IETF Remote Engagement Hub). Acompanhe as atividades, resumidas, do IETF e da ISOC em http://ietf.protocolos.net.br.


 

Participantes dos encontros do IETF

 

Os anais de todos os encontros, exceto do IETF 5 encontram-se em Past Meetings

A primeira participação de brasileiros, em encontros do IETF aconteceu no IETF 36, realizado entre os dias 24 e 28 de junho de 1996 em Montreal, Quebec, CA.

 

Ano
Participantes
Brasileiros
1986
95
0
1987
280
0
1988
308
0
1989
589
0
1990
1025
0
1991
1107
0
1992
1840
0
1993
1767
0
1994
2574
0
1995
2607
0
1996
4314
2
1997
4526
5
1998
6005
3
1999
5794
1
Ano
Participantes
Brasileiros
2000
6585
2
2001
5739
1
2002
5111
3
2003
4216
5
2004
4161
3
2005
3823
6
2006
3766
7
2007
3496
7
2008
3451
8
2009
3814
16
2010
4006
24
2011
3627
17
2012
4249
20
2013
4171
32

Tabela 1. Participação presencial geral e de brasileiros nas reuniões anuais do IETF.
Fonte: IETF Past Meetings.


Nota 2: Foram realizados 88 encontros desde 1986 até 2013. A partir de 1991, as reuniões anuais passaram a ser em número de 3. Em cada um dos anos de 1986, 1987, 1989 e 1990 ocorreram 4 encontros. Em 1988, foram 3 encontros. Os anais do IETF 5, em 1987 não foram encontrados, até o momento. Muito embora seja cedo para afirmar, houve um aumento na participação dos brasileiros em 2013, ano em que houve diversas iniciativas de divulgar o IETF, no Brasil e na América Latina (foi criada a lista IETF-LAC – ietf-lac@lacnog.org – pelo Lacnic). Para o próximo ano poderemos ter certeza se esta tendência será mantida, pois várias outras iniciativas estão em andamento, como o Livro do IETF – em português e espanhol, promovido pelo CGI.br -, e as provocações de reuniões complementares do IETF, não oficiais, associadas aos eventos da América Latina.


 

IETF-Atendees1

Figura 3. Participação presencial anual, nos encontros do IETF. Fonte: IETF Past Meetings.

 

 

Uma das principais conclusões após a análise do gráfico da Figura 3 é o fato de que a participação brasileira ser muito pequena (embora, crescente em 2013). Também, de imediato, observa-se um declínio na participação global nas reuniões do IETF, embora com pequeno avanço em 2012. Estas avaliações nos levam a desejar um debate no sentido melhorar as duas participações, global e brasileira. Este debate poderia, por exemplo, partir de uma proposta para diminuir para dois encontros anuais e acrescentar dois eventos anuais por região do planeta digamos, no domínio dos RIRs, que antecederiam em três meses, a cada um dos dois encontros do IETF. Naturalmente, tal proposta deverá conter argumentos suficientes para ser exposta aos participantes de encontros do IETF, que decidiriam por sua viabilidade e interesse nas mudanças. Os encontros regionais, promovidos por instituições relevantes – por exemplo, o LACNIC, quando se tratar da América Latina – iriam encontrar respaldo, também, para o aumento dos recursos de bolsas oferecendo oportunidades para candidatos avaliados regionalmente, que seguindo as regras já estabelecidas sejam qualificados para os encontros centrais.

O movimento das inscrições no IETF 86, por país e pelos RIRs, está disponível em tempo real na página RIR and Country Participation in IETF 86, IPv6 (preferencialmente) e IPv4, com base no IETF Meeting Registration System. Complementarmente, o levantamento das participações nos encontros que ocorreram a partir dos dois últimos do ano de 2008 até o ano de 2012, encontra-se disponível em RIR and Country Participation in IETF, com base nas informações contidas em Past Meetings, possíveis de se obter automaticamente. Estatísticas de atividades relacionadas com a participação em trabalhos podem ser encontradas em Document Statistics (What’s Going on in the IETF?), que embora muito importantes, fogem do escopo inicial deste texto, uma vez que ele se concentra nas inscrições presenciais dos encontros do IETF. Além do mais, sendo o IETF uma organização que depende do trabalho voluntário e, portanto, extremamente importante, também, não foi considerado. As considerações sobre o que não mereceu atenção, no presente texto devem, naturalmente, chamar atenção especial do autor ou de terceiros, em futuras observações. As informações coletadas estão disponíveis em base de dados MySQL e podem ser solicitadas, por quem as solicitar ou podem ser obtidas nas páginas referenciadas, construídas para facilitar esse trabalho.

 

Artigos Relacionados

 

CategoriasIETF, ISOC, TCP/IP Tags:,

IETF => D-75: O comitê de nomeação

 

Introdução

 

Para quem atua na infraestrutura da Internet pela primeira vez e até mesmo depois de anos de experiência consegue compreender parte do funcionamento e da estrutura do IETF. Mas não consegue entender como funciona o IETF, na prática. A principal dificuldade é não imaginar, de imediato, que o IETF NÃO é uma instituição ou organização privada. A dificuldade aumenta um pouco mais, quando se percebe que o IETF não tem endereço fixo ou um representante central para onde flui o que lhe diz respeito. Piora um pouco quando percebe-se que o IETF é um grupo de pessoas que participam de suas atividades, independentemente, sem influências de qualquer entidade organizada (pública ou privada). Este grupo de pessoas tem uma instituição que preserva esta independência, abrigando suas atividades, sem exercer nenhuma influência: a ISOC. Mas, as pessoas chaves que coordenam seus interesses e ajuda no entendimento sereno de todos os participantes estão ligadas ao IESG. Estas pessoas são os Presidentes das áreas (8) e os responsáveis pelos WGs. Tais responsáveis (pelas áreas e pelos WGs) não possuem nenhuma influência sobre o IETF (isto é, sobre o grande grupo). São abnegados e experientes profissionais, que encaminham para que tudo dê certo no objetivo final de definir os comportamentos adequados para a Internet. Em outras palavras, para a criação de normas, recomendações e práticas, que por serem efetivas e eficazes, se tornam padrões.

Quando uma proposta é considerada pronta, pelo grupo, ela é encaminhada a um outro grupo chamado IESG, que seguindo regras pré-estabelecidas, conduz a avaliação técnica da proposta. O IESG também possui pessoas que coordenam, sem influência pessoal, o prosseguimento sob as normas estabelecidas.

Com um olhar mais técnico e cuidadoso, o IAB, outro grupo intimamente ligado ao IETF e ao IESG, também, sob o guarda chuva da ISOC, refina os trabalhos do IETF, encaminhados através do IESG, de forma que se garanta a sua aplicabilidade ou viabilidade de divulgação (através das RFCs).. O IAB possui diversas pessoas que dão suporte às suas atividades e responsabilidades.

Por fim, para que as reuniões do IETF possam funcionar adequadamente, os recursos sejam disponibilizados sem problemas e, no geral, liberar as pessoas (os grupos que formam IETF, IESG e IAB), de preocupações de natureza administrativa e financeira, existe o IAOC. O IAOC, por seu lado possui pessoas que cuidam de seus afazeres adequadamente, e também, seguindo regras bem definidas.

A nomeação dos dirigentes do IESG, IAB e IAOC, incluindo os impedimentos são de responsabilidade de um outro grupo denominado Comitê de Nomeações (Nominating Committee), ou como é mais conhecido, NomCom, cuja descrição é feita a seguir.

 


Nota 1: Alguns e-mails trocados com S. Moonesamy, da República do Maurício, ISOC Fellow ajudaram na compreensão mais refinada do IETF.

Nota 2: D-75, significa que faltam 75 dias para o início do IETF 86.


 

O NomCom

 

O NomCom está apresentado em IETF NomCom, no sítio do IETF. O NomCom foi criado com o objetivo de analisar cada cargo disponível no IESG, IAB, e IAOC, e providenciar seu preenchimento, em datas de nomeções normais ou por impedimento. A estrutura funcional do NomCom possui os seguintes componentes: um Presidente (chair), sem direito a voto, 10 voluntários com direito a voto, 2-3 elementos de ligação (liaison) e um conselheiro (advisor). As obrigações de cada um, suas respectivas funções bem como as regras para se candidatar ao preenchimento das vagas disponíveis são definidas pela RFC37771. A RFC3777 possui quatro atualizações, que substituem alguns de seus itens, aperfeiçoando o processo. São elas: a RFC50782, a RFC56333, a RFC56804, e a RFC56806

NomCom

O Presidente do NomCom é nomeado pelo Presidente da ISOC. Os candidatos voluntários (10) são escolhidos através de um complexo mecanismo randômico, como caracterizado pela RFC37975, a partir de indicações dos próprios interessados. Há algumas poucas restrições para que uma pessoa se candidate como voluntário, na pressuposição de que ele tenha uma experiência mínima no IETF. Os elementos de ligações são indicados pelo IESG, pelo IAB e, eventualmente, pelo Conselho de Curadores (Board of Trustees) da ISOC. O conselheiro é o Presidente da gestão anterior.

Assim, o NomCom exerce um papel muito importante, na organização do caos!

 


Observações: O IETF utiliza-se dos elementos de ligações (liaisons) em diversas atividades, principalmente, naquelas que se relacionam com outras organizações responsáveis por padrões. Nestes casos, o NomCom, não é acionado, mas sim o IAB, que coordena todas as atividades que os envolvem. As regras e normas associadas são definidas pela RFC4052 e a referência inicial pode ser vista em Liaisons. A lista dos atuais participantes está apresentada em Liaison Managers e os documentos que estabelecem as iniciativas formais, em Liaison Statements.


 

Artigos Relacionados

 

 

Referências

 

  1. RFC3777. IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin [ June 2004 ] (TXT = 76395) (Obsoletes RFC2727) (Updated-By RFC5078, RFC5633, RFC5680) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: gen, WG: nomcom).

  2. RFC5078. IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins [ October 2007 ] (TXT = 19870) (Updates RFC3777) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP).

  3. RFC5633. Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins [ August 2009 ] (TXT = 11117) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

  4. RFC5680. The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins [ October 2009 ] (TXT = 14296) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

  5. RFC3797. Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd [ June 2004 ] (TXT = 39883) (Obsoletes RFC2777) (Status: INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP).

  6. RFC6859. Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba [ January 2013 ] (TXT = 5619) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (Stream: IETF, WG: NON WORKING GROUP).

CategoriasIAB, IAOC, IESG, IETF, ISOC, liaison, TCP/IP Tags:
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 29 outros seguidores