When knowledge is involved,
it is best to bring the Internet to the user,
instead of taking the user to Internet.

Uma dificuldade na Infraestrutura da Internet

Em tudo o que tem sido escrito sobre BGP neste blogue há sempre uma observação persistente: BGP é complexo. Na realidade, a complexidade do BGP está na sua abrangência e sua perspectiva de mudar constantemente. Mas, há outro componente importante quando se deseja implementar o BGP em roteadores de borda: a topologia.

Vamos a um exemplo. Recentemente, um Provedor consultou-me sobre uma topologia com três (3) trânsitos: dois com uma operadora A e um terceiro com a operadora B. A topologia parecia ser a mostrada na Figura 1, abaixo.

Este texto não propõe a implementação da topologia acima, com o BGP. Ele trata de outro assunto, correlato. Entretanto, vou dar algumas dicas sobre a implementação. Até aquele momento, nunca tinha passado por experiência semelhante. Ao entrar no roteador do Provedor foi curioso observar o fato de que a operadora A recomendou que se estabelecesse dois empareamentos com cada um de seus enlaces de trânsito: um com a tabela de roteamento completa e outro com tabela de roteamento parcial. Incluindo o empareamento da Operadora B haviam cinco sessões BGP ativas. O roteador estava em produção e alguns comportamentos ruins eram incompreensíveis. A primeira visão da implementação, sempre segue o instinto (da suposta experiência): (a) a Operadora A entende mais do que qualquer um e, (b) um ajuste nos filtros poderia resolver o comportamento ruim (abstraindo-se do fato do BGP ser complexo). Duas premissas completamente equivocadas. Revendo a presunção inicial, observou-se que, na realidade havia uma novidade na topologia: dois trânsitos com a mesma operadora. Google, eis a saída! Nesta hora é que você vê como o Google cansa!!! Depois de algum tempo, a luz no final do túnel veio com a RFC2270¹. Esta RFC, de 1998 é um pouco confusa, pois trata de topologias bem mais simples sem as variações possíveis do futuro atual. Por exemplo, a topologia poderia não ser a da Figura 1, exatamente. Em outras palavras, o trânsito poderia estar vindo através de um único roteador da Operadora A, ou chegando em uma única porta do roteador do Provedor. Ou ainda, alguma outra variação do tema. No Google, eficaz sintáticamente, infelizmente não consegue interpretar a semântica, ainda. Quem propõe a solução para implementar BGP em uma topologia destas é o primeiro autor da RFC2270, J. Stewart. No romance do BGP, escrito por ele², Capítulo 3 há uma completa descrição de todos os comportamentos do BGP em casos como estes, incluindo balanceamento. Em particular, a Fig. 3.2, na página 78, Stewart explica em detalhes um multi-homed com uma mesma operadora, de forma didática!

Mas o erro mais grave da dúvida produzida pela topologia da Figura 1 é que, ao lidarmos com o BGP associado a uma topologia qualquer, não é por hábito fazer um projeto, minimamente cuidadoso, que permita o entendimento do comportamento esperado. Em outras palavras, não se pensa sobre o problema. Isto tem acontecido sistematicamente com os pequenos e médios provedores. Por outro lado, observa-se que a falta de pensar e/ou a falta de projeto são recorrentes, mesmo tendo do seu lado as grandes operadoras brasileiras. A Operadora A da Figura 1 é uma enorme de uma operadora. Por outro lado, o Google demorou demais em ajudar a encontrar uma saída.

Uma dificuldade em outras áreas de projetos

Há alguns meses atrás fiquei dependendo de uma informação relacionada com seguradoras que estariam dispostas a segurar riscos fortuitos. Suponha que você tenha um projeto cujo objetivo é a realização de um evento em uma determinada localidade. Um evento de grande porte, com um orçamento considerável. Imagine que na véspera do evento aconteça (digamos, uns 3 dias antes), uma tempestade de enormes proporções, que arrase a cidade e cause danos materiais irreversíveis (neste exemplo, não há perdas de vida, felizmente), causando uma perda total do evento. Qual seguradora seria capaz de segurar a perspectiva de uma perda destas? Procurei, procurei, googlei, telefonei, mandei e-mails e não consegui uma resposta. Finalmente entrei no Linkedin e coloquei uma pergunta relacionada, em um grupo de projetos. Houve um debate muito interessante, até que alguém passou o nome de uma seguradora que bancou um risco semelhante, na cidade de New Orleans e acabou pagando o prejuízo causado a um projeto semelhante que iria acontecer por lá. Desta forma, a dúvida e a ausência do seguro foram resolvidas.

Para uma equipe de projetos, a indisponibilidade de competências para descrever, detalhar ou desenvolver partes do projeto (ou mesmo o projeto completo) é a principal motivação para recorrer a opiniões especializadas.

Perdas de tempo em projetos

No primeiro exemplo, do BGP e topologias, o problema maior é a falta de pensar, com certa antecedência sobre a implementação de um trânsito com a Internet. Mas, esta questão, com a maturidade será resolvida e em breve teremos projetos sendo desenvolvidos para preparar devidamente os roteadores de borda ou até mesmo as redes internas que estão se tornando, também, complexas. Mesmo que sejam pequenos Sistemas Autônomos. Neste momento, o administrador (ou preposto) de um Sistema Autônomo passa a ser um gerente de projetos.

No segundo exemplo, a questão de segurar perdas fortuitas foi resolvida por um membro de um projeto completamente dissociado do meu projeto. Por acaso expor a dúvida em um grupo de alto nível do Linkedin foi um sucesso, embora a iniciativa tenha demorado um pouco para ser tomada.

Geralmente, dentro de uma mesma empresa, obter informações úteis ou fundamentais para projetos não levam muito tempo, porque há sempre disponível o chamado “golden book”, que vai acumulando informações úteis a cada término de um projeto. Entretanto, intergrupos desconexos de projetos, isto não acontece. Um provedor, dificilmente troca informações com outros Provedores. Não por considerarem as informações preciosas ou de valor competitivo, mas por falta de oportunidades ou de local adequado para fazê-los. Geralmente, as informações são trocadas quando alguém, em uma lista de e-mail ou fórum apropriados provoca a questão. Não é, portanto, usual alguém colocar em algum fórum ou lista, por livre e espontânea vontade: “o problema do multi-homed para um mesmo operador de trânsito resolve-se assim e assado…”. Da mesma forma, porque um membro ou gerente de projeto iria divulgar o nome de uma seguradora de riscos fortuitos, se não há um ambiente apropriado para fazê-lo?

Objetos de Projeto Estendidos

Se houvesse um ambiente apropriado, seguro, confiável e com um mecanismo de pesquisa mais “inteligente”, do que os disponíveis atualmente, a cooperação fluiria espontâneamente. Por várias razões, algumas relacionadas abaixo:

• Pelo natural espírito de cooperação do ser humano, interessado e consciente.
• Pela garantia de autoria da informação.
• Pela perspectiva de auxiliar no crescimento de um repositório de sabedoria útil para projetos, em geral, do qual todos se beneficiarão.
• Pela rapidez de acesso à informação.
• Pela possibilidade de manter informações pessoais e privativas.
• Pela garantia de intervir no ambiente garantindo a qualidade da informação.
• Pela existência de mecanismos de pesquisa semântica, mais próximos do pensamento humano.

A disponibilidade de informações (textos, gráficos, imagens, videos, etc.), tratadas neste documento são armazenadas no que se convencionou chamar Objetos de Projeto Estendido (OPE). Existem dois tipos de OPEs: público e privado. Um OPE é público se ele pode ser compartilhado com terceiros. Um OPE é privado se ele não puder ser compartilhado com terceiros. Os OPEs são agrupados (ou armazenados) em um ambiente chamado de ROPE (Repositório de Objetos de Projeto Estendidos). Existem inúmeros ROPEs, cada um deles hospedados no computador do usuário interessado (o “dono” do ROPE). Um ROPE, possui uma interface humano-computador que, de forma independente classifica, pesquisa e visualiza os OPEs armazenados, além de permitir operações de criação/inclusão e demais atividades necessárias ao tratamento de um OPE isoladamente ou em conjunto. OPEs podem ser enviados ou recebidos de um Sistema de Gerenciamento de Projetos (SGP), através de uma interface apropriada que funcionaria da forma representada na Figura 2.

Se o SGP possuir as facilidades adequadas, os recursos de WEB Semântica serão utilizados, mais apropriadamente, ontologias⁷ e as propostas da W3C relacionadas com a OWL (Web Ontologoy Language)⁶. Em futuro próximo, outro artigo abordará este tema, em detalhes, oportunidade em que será mostrado que ontologias podem ser transformadas em XML e vice-versa, aperfeiçoando a proposta da Figura 2. Uma ótima e rápida leitura pode ser encontrada no artigo da Scientific American⁸ e com maior profundidade, um texto clássico e completo em [9].

Cada OPE possui uma medida de aceitação, denominada assimetria e pode sofrer alterações por terceiros, no sentido de aprovar, reprovar ou identificar a relevância. Assimetria é uma medida de qualidade de um OPE. Por outro lado, o conteúdo de um OPE pode, também, sofrer alterações. Neste caso, o repositório manterá um histórico de tais alterações, desde o OPE original até o atual, incluindo cada uma das contribuições efetivamente aceitas, aprovadas ou reprovadas, e relacionadas com o OPE. A técnica usada para que este procedimento ocorra adequadamente é a procedência de dados, a qual garante que um OPE conterá a descrição de “como”, “quando”, “onde”, “porque” os dados foram obtidos e “quem” os obteve. Cada um dos componentes históricos de uma OPE, caracterizado pela procedência de dados, também tem o sua respectiva assimetria associada, que representa uma medida de aprovação/reprovação e relevância da nova alteração OPE. Por outro lado, a informação oferecida em um OPE pode ou não ter um valor financeiro para que ela se torne visível.

A contribuição da procedência de dados foi obtida da interessante experiência sobre imagens, proposta por Braga⁴. A noção de assimetria tem sido experimentada e abordada neste blogue em diversas oportunidades, como medida representativa de distorções sociais, de pessoas, entre outras.

Caracterizando o tratamento do ROPE

A Figura 3 é um esboço preliminar de um diagrama (que parece, mas não é uma diagrama de caso de uso!), caracterizando os pontos mais importantes. Na sequência uma abordagem, também preliminar, sobre o escopo do sistema. A formalização definitiva dependerá de alguns componentes ainda pendentes no âmbito acadêmico em que o autor está atualmente engajado.

Os desafios de pesquisa avaliados a partir da abstração exposta na Figura 3, são:

1. A medida de assimetria e as intervenções históricas (procedência) sobre um OPE exigem autenticação do usuário, a qual irá configurar sua validação. Também, a assimetria poderá indicar a permanência ou não de um OPE no repositório distribuído ou no repositório local, sem que haja intervenção humana direta, com base em critérios pré-definidos.
2. O ROPE deverá estar disponível na Internet, da forma descrita em (c). A disponibilidade de um ROPE é ativa ou passiva. Uma disponibilidade é ativa, se o ROPE está hospedado em um IP público (IPv4 e/ou IPv6), e a disponibilidade é passiva se o IPv4 e/ou IPv6, no qual ele se hospeda é privado (não está visível na Internet). IPv6 é a alternativa preferencial.
3. Não pode haver um sistema central, característica do paradigma cliente/servidor. Apesar de este paradigma criar uma imensa facilidade para o usuário, uma vez que o acesso poderia ser feito por qualquer navegador (cliente da WEB), ele traria um componente de custo que poderia inviabilizar sua implementação ou mesmo exigir um patrocínio, para garantir servidores e seus respectivos sistemas de segurança associados. Além do mais, tal alternativa afrontaria o princípio do domínio local.
4. Os mecanismos de pesquisa e acesso ao ROPE que é, na verdade, uma base de conhecimento deve seguir as recomendações propostas nos padrões W3C e em técnicas derivadas.
5. A quebra do paradigma cliente/servidor exige um mecanismo que permita que os ROPEs sejam distribuídos, isto é, sejam hospedados nas máquinas de cada usuário interessado. Tal predisposição leva às seguintes preocupações:
   1. Fácil implementação e uso de linguagem universal independente do sistema operacional utilizado pelo usuário. Preferencialmente em código objeto com versão bem definida onde, o sistema operacional é uma completa abstração.
   2. Cada ROPE deve ter uma identificação única sempre associada a seu usuário. Está identificação será um número de 32 bits permitindo até 4.294.967.296 repositórios diferentes. Tal identificação pode ser obtida através de qualquer repositório ativo (sempre o mais próximo do usuário, preferencialmente).
   3. Disponibilidade de mecanismo que permita atualização do(s) procedimento(s) associado(s) à operação local do ROPE. Por exemplo, o código objeto dito em (i).
   4. Atualização do repositório de OPE, em tempo real, que não poderá usar qualquer SGBD (Sistema de Gerenciamento de Base de Dados). O uso de um SGDB implicaria em complexidade adicional à implementação. Tal imposição leva à criação de representações de arquivos (incorporando XML, RDF, …) sob uma estrutura de diretórios locais, em texto ou outro formato, bem como qualquer outro tipo de informação (como por exemplo, aquelas necessárias ao mecanismo de autenticação).
   5. O projeto deve prever a ubiquidade, e usar recursos pervasivos.
   6. As propriedades ubíquas e pervasivas implicam na necessidade de mecanismo de cooperação entre os ROPEs disponíveis. A propriedade pervasiva somente poderá ocorrer em ROPEs ativos. Neste caso, o proprietário do ROPE pode autorizar ou não, terceiros usarem seu repositório para atender tal demanda.
   7. Por fim, um ROPE deve ser autônomo, com todas as facilidades e demandas disponíveis localmente.
6. Mecanismos de criptografia adequados e transparentes aos usuários para garantir a segurança a todos os requisitos exigidos.
7. O OPE deve ser caracterizado, também, pela sua aplicação às recomendações do PMBOK⁵, suas seções e capítulos. Consequentemente, deverá atualizar as características recomendadas pelas novas versões de padronizações propostas pelo PMI. Na hipótese de ocorrerem mudanças fundamentais na estrutura do PMBOK de referência, o OPE deverá manter histórico referencial.
8. Os ROPEs devem ser identificados com garantia de autonomia. O mecanismo de cooperação (item d, subitem v), deve propagar tais informações para outros repositórios. A princípio, o mecanismo de propagação seguirá um esquema conhecido por empareamento (peering). Em outras palavras, um repositório OPE tem um ou mais empareados (peers).
9. Cada empareado age ativamente (e de forma autônoma), no sentido de atualizar seus ROPEs, das seguintes maneiras:
   1. Cada ROPE está disposto a receber e enviar atualizações de um ou mais empareados, quando seu hospedeiro for ativo (item b);
   2. Um ROPE busca e envia atualizações em um ou mais empareados, previamente conhecidos, quando seu hospedeiro for passivo (item b).
10. ROPEs empareados possuem um protocolo de relacionamento que permita a troca segura de informações. Tal protocolo é caracterizado por um autômato finito e seguirá os exemplos mais eficazes e simples, disponíveis na literatura.
11. Um ROPE empareado que tenha sofrido uma alteração comunica-se com todos os seus empareados conhecidos com o objetivo de atualizá-los.
12. Um OPE pode ter um custo associado à informação que ele está disponibilizando. Baseado na descrição objetiva do conteúdo do OPE pode-se decidir pelo pagamento com regras bem estabelecidas, inclusive uso de cartões de crédito. Neste caso, um mecanismo de pagamento deverá estar disponível para acesso imediato via o próprio OPE. A previsão de mecanismos de segurança descritas no item (e) torna factível esta proposição.

Vale lembrar, que o BGP é uma implementação que quebra o paradigma cliente/servidor (o que não é uma novidade), e usa a Internet para criar os ambientes de redes autônomas. Aliás, melhor seria afirmar que as implementações de BGP constroem a Internet.

Ademais, não é uma proposta de um sistema de relacionamento. Os ROPEs não possuem a identificação de seus proprietários, muito embora os OPEs e seus históricos, sim. Neste último caso, se o autor do OPE ou histórico, assim o desejar. Isto não configura o anonimato pois só se pode criar ou alterar um OPE se existir um proprietário de ROPE bem identificado.

Com referência à metodologia há fortes indícios que levam às recomendações propostas por Eeles e Crips³.

Observações finais

O trabalho deve ser desenvolvido em três etapas, a saber:

1. Definição do problema: é a etapa em que o refinamento do texto acima irá acontecer, com a especificação do mecanismo de bases de dados distribuídas, as relações ubíqua e pervasiva. Formalização do esquema de mensagens e o autômato finito das conexões dos repositórios entre si. Adicionalmente, a especificação do modelo da base da dados do ROPE, através de uma metalinguagem.
2. A descrição geral do sistema e suas relações com o PMBOK: etapa que irá descrever todo o sistema, com os detalhes das especificações e os componentes teóricos envolvidos. Os mecanismos de arbitragem das medidas de aceitação (assimetrias). Os tipos de OPEs possíveis e seus formatos relacionados com a estrutura do PMBOK. A proposta da linguagem de programação com base em comparações específicas.
3. A evolução: propostas de estudos e pesquisas que possam viabilizar a implementação, testes de protótipos e fortalecimento de fragilidades a serem identificadas. Esta etapa está fora do escopo da proposta de trabalho inicial, que representam os itens (1) e (2), acima.

Referências

1. RFC2270, Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart, T. Bates, R. Chandra, E. Chen [ January 1998 ] (TXT = 12063) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr)
2. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
3. Peter Eeles e Peter Cripps. (2012, Second Printing). The process of software architecting. Addison-Wesley.
4. Juliana Cristina Braga. Procedência de Dados: Teoria e Aplicações ao Processamento de Imagens. 2004. 110 f. Tese de Doutorado do Curso de Pós-Graduação em Computação Aplicada. INPE, São José dos Campos, 2007.
5. PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK), 4a. edição, 2008
6. W3C. OWL Web Ontology Language Guide. W3C Recommendation 10 February 2004. Disponível em: http://www.w3.org/TR/owl-guide/. Acessado em 16/12/2012.
7. NOY, N.; MCGUINNESS, D. Ontology development 101: A guide to creating your first ontology, 2001. Disponivel em: http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What is an ontology and why we need it.htm. Acessado em 20/12/2012.
8. BERNERS-LEE, T. I. M.; HENDLER, J.; LASSILA, O. R. A. The Semantic Web will enable machines to. Scientific American, n. May, p. 1-4, 2001. Disponível em http://www-sop.inria.fr/acacia/cours/essi2006/Scientific%20American_%20Feature%20Article_%20The%20Semantic%20Web_%20May%202001.pdf
9. TRUSZKOWSKI, W.; BREITMANN, K. K.; CASANOVA, M. A. Semantic Web: Concepts, Technologies and Applications. [S.l.] Springer-Verlag, 2007.

Na sequência: Máquinas de estado finito: Parte Prática: MEF do BGP