Instead of trying to impress the reader with what I know,
I try to explain why the things I’ve learned impress me.
Donald Knuth, aqui

 

Introdução

 

Este é o terceiro da série (imagino, longa) de artigos necessários para consolidar as ideias do projeto sobre Objetos de Projeto Estendido (OPE)¹. Na sequência do primeiro artigo foi apresentada a MEF (Máquina de Estado Finito) do BGP¹. O modelo da MEF foi construído com base na descrição fundamental, isto é, a RFC4271⁴.

Um dos mais importantes componentes dos artigos são os modelos. Via de regra abstratos e produzidos por imagens ou figuras, eles são acompanhados de uma descrição para que se desfaça algumas confusões mentais. A noção de modelos, tal qual se imagina é descrita, a seguir.

 

Modelos

 

Modelos tem sido explorados por muitos pesquisadores e autores. Particularmente, por Scott E. Page^{5, 6 e 7}, em seus inúmeros textos além dos citados. Por exemplo, em seu curso Model Thinking. Professor Scott⁵ chama a atenção para fatos interessantes, sobre modelos:

• Quando mais você conhece o contexto, mais seu modelo se aproxima da realidade.
• Modelos devem ser aperfeiçoados, isto é, refinados de forma sistemática.
• Nenhum modelo é perfeito. O modelo da MEF do BGP se aproxima mais da realidade quando damos nomes aos arcos com o objetivo de descrever, compreender e garantir sua consistência.
• Muitas vezes, principalmente em sistema com razoável complexidade, precisamos de vários modelos para descrevê-lo. É o caso do BGP. A MEF não modela o BGP como um todo, mas sim uma parte dele que é o automato finito para que a conexão seja estabelecida. A figura e a respectiva descrição² representam, por outro lado, uma parte da MEF do BGP. Está faltando o comportamento do autômato finitoo (ou MEF), no que diz respeito às mensagem recebidas, que está disponível no livro do Stewart⁸.
• Sistemas como a MEF do BGP tendem a permitir a construção de modelos bem representativos do seu comportamento. Em sistema mais complexos isto só será possível com um conglomerado (ou nuvem) de modelos. O próprio BGP é um sistema muito complicado, como já foi dito. A MEF é um componente, simples, do BGP. Para entender o BGP, como um todo, precisamos de vários modelos. Até mesmo vários modelos de autômatos finitos. por exemplo, para que o BGP funcione, os pares precisam estar conectados. A conexão é feita em TCP. A modelagem de uma conexão TCP exige um outro autômato finito. Veremos isto mais à frente.
• Há três equívocos comuns cometidos por pessoas, sobre modelos:
  1. Pessoas acreditam piamente em modelos.
  2. Algumas pessoas desacreditam os modelos, por razões políticas.
  3. Pessoas confundem modelos com o que foi produzido por eles. Algo como considerar o BGP como sendo a MEF. Ou, mais simplesmente, como diz Scott, a árvore com a madeira.

Dependendo das ferramentas utilizadas, modelos podem ser complicados para entendermos. É o caso de modelos mais formais onde matemática e física são utilizadas. O próprio Scott⁶, exibe um formalismo para modelar o comportamento de redes, em geral, com aplicações na Internet, na sociologia, nas finanças e em muitas outras áreas do conhecimento. O formalismo matemático apresentado pelo Professor Scott é necessário para manter o rigor da modelagem e permitir a verificação do desempenho de um modelo usando ferramentas computacionais. As dificuldades podem ser vistas no que o eminente físico Richard Freynman disse para Leonard Mlodinow, [9, página 54]: …eu jamais deveria pensar que compreendi um trabalho de física se tudo o que fiz foi ler a prova de outra pessoa. A única maneira de realmente entender uma teoria, afirmou, é refazer a prova por conta própria – quem sabe você não acaba refutando a teroria? … No mesmo parágrafo, Mlodinow lembra, também, que um professor de Harvard, especializado em probabilidade e estatística disse, a propósito de dificuldades de pessoas e bons matemáticos não conseguirem identificar o erro em algo aparentemente óbvio: …Nosso crérebro não foi muito bem projetado para resover problemas de probabilidade. …

 

O problema de Monty Hall

 

Leonard Mlodinow, faz as citações acima no capítulo 3 do seu incrível livro, páginas 50-68: Encontrando o caminho em meio a um espaço de possibilidades. É a abordagem sobre um programa de televisão apresentado por Monty Hall (nos períodos de 1963-1976 e 1981-1991), uma famosa colunista chamada Marilyn vos Savant (maior QI já registrado no planeta, segundo o Guiness), o brilhante matemático Paul Erdös e uma imensa parcela do povo americano.

Se você ouvir o Scott E. Page falar sobre o problema das três portas de Monty Hall, e em seguida responder a um questionário, este poderá ser apenas uma tentativa. Isto porque, naquele momento você não está acostumado com a Lei do Espaço Amostral, lembrada inicialmente por Gerolamo Cardano, no século XVI. Vejamos o problema, as consequências para Marilyn e sua coluna “Ask Marylin”, Paul Erdös, um pedaço do povo americano e você, ao assistir a aula de Scott.

Com pequenas modificações, ao invés de portas, teremos três caixas de chapéus idênticas e indevassáveis (digamos, chapéus de inglesas abastadas). Elas são grandes o suficiente para caber, em uma delas, o roteador dos seus sonhos (valor em torno de $50,000.00). Nas outras duas caixas serão colocadas “switches” usados, que não necessariamente funcionam, cujo preço de novos está em torno de R$50,00, cada um (“hubs”, talvez). Como a Figura 1, que segue.

 

 

Se olharmos as caixas com visão de raios X teremos algo parecido com a Figura 2. Esta é a visão do apresentador, que sabe qual caixa contem roteador e quais as duas que contem os equipamentos usados. Este é um fato importante que qualifica o apresentador para interferir no processo da escolha feita pelo competidor (ou você).

 

 

O esquema é o seguinte: Você escolhe uma caixa. O apresentador irá então interferir no processo, abrindo uma das caixas que contem um equipamento usado. A seguir ele lhe pergunta se você quer trocar ou não a sua escolha original. O que você deve fazer? Permanecer na caixa escolhida ou trocar de caixa (só tem mais uma para a troca). Em outras palavras, você tem duas caixas a escolher, o que significa que você tem 50% de ganhar o roteador. O que fazer? Continuar na escolha original ou trocar?

Fizeram a mesma pergunta no “AskMarilyn”. Marilyn afirmou em sua coluna que o melhor seria mudar a escolha! Marilyn recebeu cerca de 10.000 cartas reagindo contra sua posição de trocar a caixa original. Também, quase 1.000 matemáticos, aparentemente irados, com a posição de Marilyn. Paul Erdös, em particular, foi agressivo: “Impossível!”, afirmou ele. Foi tão brutal, o impacto que Marilyn parou de discutir o tema. Até que ficou provado que Marilyn estava correta. Paul Erdös só se convenceu depois de avaliar uma simulação feita por computador que mostrou a resposta correta de Marilyn, e admitiu estar errado. Na realidade, quando você tinha de escolher, inicialmente, uma das três caixas, sua chance de coincidir com a caixa do roteador era de 1/3. Mas, quando o apresentador interferiu no processo que era aleatório ele alterou o estado da probabilidade. Melhor dizendo, você sabe que uma das caixas (ela foi aberta!), portanto tem de escolher 2 entre três (2/3!). Dobrou a probabilidade de acertar! Então, troque, pois sua escolha inicial foi com a chance de 1/3! Leonard Mlodinow é perfeito na descrição do problema, no capítulo 3 de seu livro. O modelo (Oops, figura?) exibido na Figura 3 nos dá a noção precisa de nossas escolhas em cada uma das alternativas.

 

 

 

Modelando uma conexão BGP

 

Quando estabelecemos uma rede interna, usando o TCP/IP, ou em outras palavras, usando IPv6 ou IPv4 (hoje estamos preferindo o IPv6), nosso cenário é como o da Figura 4. É necessário que nossa LAN (rede local) tenha um “gateway” que seja capaz de receber pacotes em IPv6 de algum equipamento de origem e os encaminhe de volta para a LAN, na direção do destino, na mesma LAN. Este modelo não é único, pois neste caso, o “gateway” pode ser um simples “switch”. Estamos colocando um “gateway”, no modelo, porque estamos enxergando a Internet, na qual deseja-se ardorosamente conectar. Tanto que a exibimos no modelo.

 

 

Quando da decisão de se conectar à Internet, o primeiro passo é encontrar um operador de trânsito que seja membro da Internet. Em outras palavra, procurar por um operador de trânsito que seja um Sistema Autônomo (AS). Por ser um AS, o operador de trânsito poderá nos fornecer os IPv6 que precisamos para estabelecer nossas conexões à Internet. Nosso modelo ficará um pouco mais complexo, visto na Figura 5. Agora temos IPv6 para atender nossas expectativas e nosso “gateway” passa a ser um roteador, quem sabe o que ganhamos do Monty Hall… Para os equipamentos que estão na rede local, a rota “default”, isto é, a direção de pacotes que contem IPv6 que não são nossos, é o IPv6v, colocado na LAN de nosso roteador. Já pacotes com IPv6 desconhecidos do roteador serão encaminhados para a sua rota “default”, que é o IPv6a.

 

 

O modelo da Figura 5 não está legal. Falta a ele capturar diversas informações importantes, que podemos enumerar:

1. A LAN, passou a ser uma rede do operador de trânsito. Na realidade, embora a LAN não pertença ao operador de trânsito, os IPv6 pertencem a ele, partindo do pressuposto de que são IPv6 válidos.
2. A LAN é cliente comercial do operador de trânsito. O operador de trânsito é um AS.
3. O cliente comercial não é um Sistema Autônomo. É parte de um Sistema Autônomo.
4. A conexão TCP estabelece um tráfego de pacotes para, e da Internet usando um protocolo que não é o BGP. Quem usa o BGP é o operador de trânsito.
5. O cliente comercial é uma rede que está na Internet, via o operador de trânsito.

Como estamos usando um modelo gráfico e estático, muitas informações complementares devem ser descritivas. Porém, à medida que padronizarmos o modelo gráfico, menos descrições complementares serão necessárias. Padronizar, neste caso, envolve um cenário mais universal, no sentido de que a grande maioria dos envolvidos concordam com o que está sendo desenhado. Já existem propostas para isto. Os diagramas da UML (Unified Modeling Language), iniciativa da OMG (Object Management Group) é uma proposta de unificação de padrões, que não cobre somente a engenharia de software.

 

 

A Figura 6 é uma proposta de modelo com um significativo refinamento ao da Figura 5. Ele nos traz muito mais informações do que o frágil modelo da Figura 5. Eis os pontos importantes exibidos no novo modelo, os quais dizemos que fazem parte do escopo do modelo:

1. A Internet que ele está exibindo é a Internet IPv6. Hoje temos duas Internet. A outra é a Internet IPv4.
2. O operador de trânsito em questão é um Sistema Autônomo. Ele possui um número de AS, no modelo representado por n, ou ASn.
3. A Internet é um conjunto de ASes (nuvens em verde), incluindo o operador de trânsito.
4. Está claro agora, que o cliente do operador de trânsito tem acesso à Internet, e que é membro da rede do operador de trânsito, pois ele não é um AS.

Há, também, coisas que o modelo não nos informa (são partes do que chamamos de não escopo), a saber:

1. Não nos fala nada sobre a Internet IPv4. Fica apenas o registro da Internet IPv6.
2. O modelo não identifica qualquer acordo entre o cliente e seu operador de trânsito.

O próximo modelo, finaliza nosso refinamento desta etapa, pressupondo de que o cliente passa a ser um AS. Está na figura 7, a seguir.

 

 

O comentários importantes sobre o modelo da Figura 7, são os seguintes:

1. Retiramos a ideia de operador de trânsito. Temos agora, somente os ASes que, na realidade, fornecem tráfego através da Internet ou não. Tráfego é trânsito, ou transporte, ou “peering”, ou todos eles. Estas noções podem ser vistas em [10].
2. As duas Internet estão transparentes. O ex-cliente, agora ASj é dono de seus próprios IPs. Como, geralmente, um AS tem IPv6 e IPv4, ele pode se conectar à Internet IPv6 e/ou IPv4, através de várias técnicas, uma das quais é a pilha dupla, que o modelo subentende.
3. A ideia mais importante mostrada no modelo é a Conexão TCP. Antes de ser AS, o cliente tinha, também, uma conexão TCP. Agora, sendo AS, ele ativou o protocolo BGP, que só se viabiliza, se os “pares” tiverem uma conexão TCP, entre si.

 

Modelando o BGP

 

Na seção anterior, os modelos foram construídos para conexões BGP e não para o BGP propriamente dito. Já está claro que para uma conexão BGP funcionar, dois componentes são importantes: uma conexão TCP e a MEF do BGP. A MEF do BGP já é nossa conhecida. Sobre conexão TCP, muito pouco foi dito, até agora. A questão importante sobre conexão TCP é de que ela é estabelecida, usando-se soquetes. Um exemplo prático pode ser visto aqui no blogue³, onde soquetes foram usados para estabelecer uma conexão de telnet sob a ótica do paradigma cliente-servidor. Entretanto, já sabemos, também, que ao falarmos de BGP, a característica cliente-servidor desaparece. O mesmo acontece com a conexão TCP que dá suporte, ou que viabiliza o BGP. Isto nos leva a pensar da forma correta de que uma conexão TCP é estabelecida atrávés de um autômato finito ou MEF, também.

Falaremos sobre a MEF de uma conexão TCP em outro momento, mas podemos modelar o BGP conforme a Figura 8, que segue.

 

 

Eis as informações que nos interessam sobre o modelo acima:

1. Os empareamentos são: ASi com ASj e ASj com ASk.
2. O pré-requisito para iniciar uma conexão TCP é a existência de ligações físicas (camada L1), entre os empareados. Não interessa a extensão destas ligações.
3. A MEF do TCP inicia o processo em entendimento entre os pares. Uma vez estabelecida a conexão TCP, o estado IDLE da MEF do BGP é acionado.
4. A MEF do TCP mantêm a conexão TCP. Se ela cair, a conexão BGP cai e o processo começa novamente por ela, que no momento adequado aciona novamente o estado IDLE do BGP.
5. Cada empareamento age de maneira independente. Se cair a conexão de um, o outro continua.
6. Observa-se que, cada dia que passa, as conexões de camada física estão se tornando mais estáveis, apesar do preço cada vez mais baixo. Provavelmente, consequência da competição que está aumentando e a necessidade das operadoras (ou ASes) se tornarem mais eficientes. Um visível sintoma é o fato do Nic.br (no Brasil) já admitir que um AS possa ter somente uma conexão.

 

Conclusões

 

A MEFTCP é o mais importante para a proposta de OEP¹. Da mesma forma que a MEFBGP, a qual ficará completa quando for analisado o mecanismo de mensagens do BGP.

A noção sobre modelos é apenas um princípio de como se pode tratar questões ligadas a implementação de BGP. O tratamento deve ser semelhante a um projeto. Os processos são as diversas etapas que seguem aquelas recomendadas a um projeto normal. Há requisitos, escopo e a implementação propriamente dita. Provedores de Internet, principalmente os pequenos sofrem na mão de grandes operadores. Se as propostas referente a um esquema mais profissional de implementação de projetos, quando se tratar de BGP, os ganhos serão enormes e podem, inclusive, admitir à ANATEL a criação de um mecanismo adequado para ela administrar sua função de vigilante das normas legais. Um exemplo é o uso de algo parecido com um Termo de Abertura do Projeto (TAP), criado especificamente para este fim. Sobre este assunto, isto é, a aplicação de metodologias e/ou técnicas de projetos sobre implementações de BGP, incluindo análise de topologias e outros protocolos associados (iBGP, OSPF, entre outros), oportunamente serão tratadas aqui neste blogue.

 

Referências

 

1. Julião Braga. (Agosto 2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 05/09/2012.
2. Julião Braga. (Agosto 2012). Máquinas de estado finito: Parte Prática: MEF do BGP. Disponível em: https://juliaobraga.wordpress.com/category/projetos/gerenciamento-de-projetos/. Acessado em 05/09/2012.
3. Julião Braga. (Março 2012). Soquetes: PHP, IPv6 e ‘inseguridade. Disponível em: https://juliaobraga.wordpress.com/2012/03/04/soquetes-em-php-ipv6/. Acessado em 05/09/2012.
4. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 05/09/2012.
5. Scott E. Page. Prologue The Card Catalogue. Disponível em: http://www.cscs.umich.edu/~spage/ONLINECOURSE/R1Page.pdf. Acessado em 09/09/2012.
6. Scott E. Page, Lecture 23 Networks. July 28, 2006. Disponível em: http://www.cscs.umich.edu/~spage/teaching_files/modeling_lectures/MODEL5/M29networknotes.pdf. Acessado em 09/09/2012.
7. Scott E. Page, The Difference: How the power of diversity creates better groups, firms, schools, and societies. Aug 11, 2008. Disponível em: http://pt.scribd.com/doc/82442356/Scott-E-Page. 424 p. Acessado em 09/09/2012.
8. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
9. Leonard Mlodinow (1954). O andar do bêbado: como o acaso determina nossas vidas. Rio de Janeiro: Zahar, 2009. Tradução de Diego Alfaro.
10. Julião Braga. (Março 2010). Tráfego, trânsito, transporte e peering (uma proposta de definição). Disponível em: https://juliaobraga.wordpress.com/2010/03/09/trafego-transito-transporte-e-peering/. Acessado em 10/09/2012.