Arquitetura recursiva entre redes - Recursive Internetwork Architecture
A Recursive InterNetwork Architecture (RINA) é uma nova arquitetura de rede de computadores proposta como uma alternativa à arquitetura do atual pacote de protocolos da Internet . Os princípios fundamentais do RINA são que a rede de computadores é apenas comunicação entre processos ou IPC, e que a disposição em camadas deve ser feita com base no escopo / escala, com um único conjunto recorrente de protocolos, ao invés de baseada na função, com protocolos especializados. As instâncias de protocolo em uma camada fazem interface com as instâncias de protocolo em camadas superiores e inferiores por meio de novos conceitos e entidades que efetivamente reificam as funções de rede atualmente específicas para protocolos como BGP , OSPF e ARP . Desta forma, o RINA afirma oferecer suporte a recursos como mobilidade, multihoming e qualidade de serviço sem a necessidade de protocolos especializados adicionais como RTP e UDP , bem como permitir uma administração de rede simplificada sem a necessidade de conceitos como sistemas autônomos e NAT .
Fundo
Os princípios por trás do RINA foram apresentados pela primeira vez por John Day em seu livro de 2008, Patterns in Network Architecture: A return to Fundamentals . Este trabalho é um recomeço, levando em consideração as lições aprendidas nos 35 anos de existência do TCP / IP , bem como as lições do fracasso do OSI e as lições de outras tecnologias de rede das últimas décadas, como CYCLADES. , DECnet e Sistemas de Rede Xerox .
O ponto de partida para uma arquitetura de rede radicalmente nova e diferente como o RINA é uma tentativa de resolver ou uma resposta aos seguintes problemas que não parecem ter soluções práticas ou sem compromisso com as arquiteturas de rede atuais, especialmente o pacote de protocolo da Internet e seu funcional camadas conforme representado na Figura 1:
- Complexidade de transmissão: a separação de IP e TCP resulta em ineficiência, com a descoberta de MTU realizada para evitar a fragmentação de IP sendo o sintoma mais claro.
- Desempenho: o próprio TCP carrega uma sobrecarga bastante alta com seu handshake, que também causa vulnerabilidades como inundações de SYN . Além disso, o TCP depende do descarte de pacotes para se auto-estrangular e evitar congestionamentos, o que significa que seu controle de congestionamento é puramente reativo, não proativo ou preventivo. Isso interage mal com grandes buffers, levando a bufferbloat .
- Multihoming : o endereço IP e o número da porta são de nível muito baixo para identificar um aplicativo em duas redes diferentes. O DNS não resolve isso porque os nomes de host devem resolver para uma única combinação de endereço IP e número de porta, tornando-os aliases em vez de identidades. Nem o LISP , porque i) ele ainda usa o localizador, que é um endereço IP, para roteamento, e ii) é baseado em uma falsa distinção, em que todas as entidades em um escopo são localizadas por seus identificadores para começar; além disso, também apresenta seus próprios problemas de escalabilidade.
- Mobilidade: o endereço IP e o número da porta também são de nível muito baixo para identificar um aplicativo conforme ele se move entre as redes, resultando em complicações para dispositivos móveis, como smartphones. Embora seja uma solução, o Mobile IP, na realidade, transfere o problema inteiramente para o endereço Care-of e introduz um túnel de IP, com complexidade de atendimento.
- Gerenciamento: a mesma natureza de baixo nível do endereço IP incentiva vários endereços ou até mesmo intervalos de endereços a serem alocados para hosts únicos, pressionando a alocação e acelerando o esgotamento. O NAT apenas atrasa o esgotamento e potencialmente introduz ainda mais problemas. Ao mesmo tempo, as camadas funcionais da arquitetura do pacote de protocolos da Internet deixam espaço para apenas dois escopos, complicando a subdivisão da administração da Internet e exigindo a noção artificial de sistemas autônomos. OSPF e IS-IS têm relativamente poucos problemas, mas não escalam bem, forçando o uso de BGP para redes maiores e roteamento entre domínios.
- Segurança: a própria natureza do espaço de endereço IP resulta em segurança frágil, uma vez que não há uma política configurável verdadeira para adicionar ou remover endereços IP além de impedir fisicamente o anexo. TLS e IPSec fornecem soluções, mas com complexidade associada. Firewalls e listas negras são vulneráveis à opressão e, portanto, não são escaláveis. "[...] a experiência tem mostrado que é difícil adicionar segurança a um conjunto de protocolos, a menos que esteja embutido na arquitetura desde o início."
Embora esses problemas sejam muito mais visíveis hoje, houve precedentes e casos quase desde o início da ARPANET , o ambiente no qual o pacote de protocolos da Internet foi projetado:
1972: Multihoming não suportado pela ARPANET
Em 1972, a Tinker Air Force Base queria conexões com dois IMPs diferentes para redundância. Os projetistas da ARPANET perceberam que não podiam oferecer suporte a esse recurso porque os endereços de host eram os endereços do número da porta IMP ao qual o host estava conectado (emprestado da telefonia). Para a ARPANET, duas interfaces do mesmo host tinham endereços diferentes; em outras palavras, o endereço era de nível muito baixo para identificar um host.
1978: TCP dividido a partir de IP
As versões iniciais do TCP executavam as funções de controle de erro e fluxo (TCP atual) e de retransmissão e multiplexação (IP) no mesmo protocolo. Em 1978, o TCP foi separado do IP, embora as duas camadas tivessem o mesmo escopo. Em 1987, a comunidade de rede estava bem ciente dos problemas de fragmentação de IP, a ponto de considerá-la prejudicial. No entanto, não foi entendido como um sintoma de que o TCP e o IP eram interdependentes.
1981: resultados fundamentais do Watson ignorados
Richard Watson em 1981 forneceu uma teoria fundamental de transporte confiável em que o gerenciamento de conexão requer apenas temporizadores limitados por um pequeno fator do Tempo de Vida Máximo do Pacote (MPL). Com base nessa teoria, Watson et al. desenvolveu o protocolo Delta-t que permite que o estado de uma conexão seja determinado simplesmente limitando três temporizadores, sem handshaking. Por outro lado, o TCP usa handshaking explícito, bem como gerenciamento mais limitado baseado em temporizador do estado da conexão.
1983: camada de rede perdida
No início de 1972, o Grupo de Trabalho de Rede Internacional (INWG) foi criado para reunir a comunidade nascente de pesquisa de rede. Uma das primeiras tarefas que realizou foi votar um protocolo de transporte de rede internacional, que foi aprovado em 1976. Notavelmente, a opção selecionada, assim como todas as outras candidatas, tinha uma arquitetura composta por três camadas de escopo crescente: enlace de dados (para lidar com diferentes tipos de mídia física), rede (para lidar com diferentes tipos de redes) e internetwork (para lidar com uma rede de redes), cada camada com seu próprio espaço de endereço. Quando o TCP / IP foi introduzido, ele era executado na camada de internetwork no topo do NCP . Mas quando o NCP foi desligado, o TCP / IP assumiu a função de rede e a camada de internetwork foi perdida. Isso explica a necessidade de sistemas autônomos e NAT hoje, para particionar e reutilizar intervalos do espaço de endereço IP para facilitar a administração.
1983: Primeira oportunidade de corrigir o endereçamento perdida
A necessidade de um endereço de nível superior ao endereço IP foi bem compreendida desde meados da década de 1970. No entanto, os nomes dos aplicativos não foram introduzidos e o DNS foi projetado e implantado, continuando a usar portas conhecidas para identificar os aplicativos. O advento da web e do HTTP criou a necessidade de nomes de aplicativos, levando a URLs. URLs, entretanto, amarram cada instância de aplicativo a uma interface física de um computador e uma conexão de transporte específica, já que a URL contém o nome DNS de uma interface IP e o número da porta TCP, espalhando os problemas de multihoming e mobilidade para os aplicativos.
1986: O colapso do congestionamento pega a Internet de surpresa
Embora o problema de controle de congestionamento em redes de datagrama fosse conhecido desde os anos 1970 e início dos anos 80, o colapso do congestionamento em 1986 pegou a Internet de surpresa. O que é pior, o controle de congestionamento adotado - o esquema de prevenção de congestionamento Ethernet , com algumas modificações - foi colocado no TCP.
1988: O gerenciamento de rede dá um passo para trás
Em 1988, o IAB recomendou o uso de SNMP como o protocolo de gerenciamento de rede inicial para a Internet para posterior transição para a abordagem orientada a objetos do CMIP . O SNMP foi um retrocesso no gerenciamento de rede, justificado como uma medida temporária enquanto as abordagens mais sofisticadas exigidas eram implementadas, mas a transição nunca aconteceu.
1992: Segunda oportunidade para corrigir o endereçamento perdida
Em 1992, o IAB produziu uma série de recomendações para resolver os problemas de dimensionamento da Internet baseada em IPv4 : consumo de espaço de endereço e explosão de informações de roteamento. Três opções foram propostas: introduzir CIDR para mitigar o problema; projetar a próxima versão do IP (IPv7) com base no CLNP ; ou continue a pesquisa sobre nomenclatura, endereçamento e roteamento. CLNP era um protocolo baseado em OSI que endereçava nós em vez de interfaces, resolvendo o antigo problema de multihoming que datava da ARPANET e permitindo uma melhor agregação de informações de roteamento. O CIDR foi introduzido, mas o IETF não aceitava um IPv7 baseado em CLNP. O IAB reconsiderou sua decisão e o processo de IPng foi iniciado, culminando com o IPv6 . Uma das regras do IPng era não alterar a semântica do endereço IP, que continua a nomear a interface, perpetuando o problema de multihoming.
Visão geral
O RINA é o resultado de um esforço para desenvolver princípios gerais em redes de computadores que se aplicam a todas as situações. RINA é a arquitetura específica, implementação, plataforma de teste e, em última instância, implantação do modelo informalmente conhecido como modelo IPC, embora também trate de conceitos e resultados que se aplicam a qualquer aplicativo distribuído, não apenas à rede.
A entidade básica do RINA é o Processo de Solicitação Distribuída ou DAP, que freqüentemente corresponde a um processo em um host. Dois ou mais DAPs constituem um Distributed Application Facility ou DAF, conforme ilustrado na Figura 3. Esses DAPs se comunicam usando o Common Distributed Application Protocol ou CDAP, trocando dados estruturados na forma de objetos. Esses objetos são estruturados em um Resource Information Base ou RIB, que fornece um esquema de nomenclatura e uma organização lógica para eles. O CDAP fornece seis operações básicas em objetos DAPs remotos: criar, excluir, ler, gravar, iniciar e parar.
Para trocar informações, os DAPs precisam de um recurso subjacente que forneça serviços de comunicação a eles. Este recurso é outro DAF, denominado Distributed IPC Facility ou DIF, cuja tarefa é fornecer e gerenciar serviços IPC em um determinado escopo. Os DAPs de um DIF são chamados de processos IPC ou IPCPs. Eles têm a mesma estrutura DAP genérica mostrada na Figura 3, além de algumas tarefas específicas para fornecer e gerenciar IPC. Essas tarefas, conforme mostrado na Figura 4, podem ser divididas em três categorias: transferência de dados, controle de transferência de dados e gerenciamento de camadas. As categorias são ordenadas por complexidade crescente e frequência decrescente, com a transferência de dados sendo a mais simples e frequente, o gerenciamento de camadas sendo a mais complexa e menos frequente e o controle de transferência de dados intermediário.
Os DIFs, sendo DAFs, por sua vez usam outros DIFs subjacentes, indo até o DIF da camada física que controla os fios e os conectores. É daí que vem a recursão do RINA. Conforme mostrado na Figura 4, as redes RINA são geralmente estruturadas em DIFs de escopo crescente. A Figura 5 mostra um exemplo de como a Web poderia ser estruturada com RINA: a camada mais alta é a mais próxima dos aplicativos, correspondendo a e-mail ou sites; as camadas mais baixas agregam e multiplexam o tráfego das camadas mais altas, correspondendo aos backbones do ISP . DIFs de vários provedores (como a Internet pública ou outros) flutuam no topo das camadas do ISP. Neste modelo, três tipos de sistemas são distinguidos: hosts, que contêm DAPs; roteadores internos, internos a uma camada; e roteadores de fronteira, nas bordas de uma camada, onde os pacotes sobem ou descem uma camada.
Um DIF permite que um DAP aloque fluxos para um ou mais DAPs, apenas fornecendo os nomes dos DAPs desejados e os parâmetros de QoS desejados, como limites na perda de dados e latência, entrega ordenada ou fora de ordem, confiabilidade e assim para frente. Os DAPs podem não confiar no DIF que estão usando e, portanto, podem proteger seus dados antes de gravá-los no fluxo por meio de um módulo de proteção SDU , por exemplo, criptografando-os. Todas as camadas RINA têm a mesma estrutura e componentes e fornecem as mesmas funções; eles diferem apenas em suas configurações ou políticas. Isso reflete a separação de mecanismo e política em sistemas operacionais.
Resumindo, o RINA mantém os conceitos de PDU e SDU, mas em vez de camadas por função, camadas por escopo. Em vez de considerar que escalas diferentes têm características e atributos diferentes, considera que toda comunicação tem fundamentalmente o mesmo comportamento, apenas com parâmetros diferentes. Assim, o RINA é uma tentativa de conceituar e parametrizar todos os aspectos da comunicação, eliminando assim a necessidade de protocolos e conceitos específicos e reutilizando o máximo possível de teoria.
Nomenclatura, endereçamento, roteamento, mobilidade e multihoming
Conforme explicado acima, o endereço IP é um identificador de nível muito baixo no qual basear o multihoming e a mobilidade com eficiência, além de exigir que as tabelas de roteamento sejam maiores do que o necessário. A literatura RINA segue a teoria geral de Jerry Saltzer sobre endereçamento e nomenclatura. De acordo com Saltzer, quatro elementos precisam ser identificados: aplicativos, nós, pontos de conexão e caminhos. Um aplicativo pode ser executado em um ou mais nós e deve ser capaz de se mover de um nó para outro sem perder sua identidade na rede. Um nó pode ser conectado a um par de pontos de conexão e deve ser capaz de se mover entre eles sem perder sua identidade na rede. Um diretório mapeia o nome de um aplicativo para um endereço de nó e as rotas são sequências de endereços de nó e pontos de conexão. Esses pontos são ilustrados na Figura 6.
Saltzer tirou seu modelo dos sistemas operacionais, mas os autores do RINA concluíram que ele não poderia ser aplicado de forma limpa a internetworks, que podem ter mais de um caminho entre o mesmo par de nós (muito menos redes inteiras). A solução deles é modelar rotas como sequências de nós: a cada salto, o respectivo nó escolhe o ponto de conexão mais apropriado para encaminhar o pacote ao próximo nó. Portanto, o RINA roteia em um processo de duas etapas: primeiro, a rota como uma sequência de endereços de nó é calculada e, em seguida, para cada salto, um ponto de conexão apropriado é selecionado. Estas são as etapas para gerar a tabela de encaminhamento: o encaminhamento ainda é realizado com uma única consulta. Além disso, a última etapa pode ser executada com mais frequência para explorar o multihoming para balanceamento de carga.
Com esta estrutura de nomenclatura, mobilidade e hospedagem múltipla são inerentemente suportadas se os nomes tiverem propriedades cuidadosamente escolhidas:
- os nomes dos aplicativos são independentes do local para permitir que um aplicativo se mova;
- os endereços dos nós são dependentes da localização, mas independentes da rota; e
- os pontos de fixação são, por natureza, dependentes da rota.
Aplicar este esquema de nomenclatura ao RINA com suas camadas recursivas permite a conclusão de que mapear nomes de aplicativos para endereços de nós é análogo ao mapeamento de endereços de nós para pontos de fixação. Simplificando, em qualquer camada, os nós na camada acima podem ser vistos como aplicativos, enquanto os nós na camada abaixo podem ser vistos como pontos de fixação.
Projeto de protocolo
O conjunto de protocolos da Internet também geralmente determina que os protocolos sejam projetados isoladamente, sem levar em consideração se os aspectos foram duplicados em outros protocolos e, portanto, se eles podem ser transformados em uma política. O RINA tenta evitar isso aplicando a separação de mecanismo e política em sistemas operacionais ao projeto de protocolo. Cada DIF usa políticas diferentes para fornecer diferentes classes de qualidade de serviço e se adaptar às características da mídia física, se o DIF for de baixo nível, ou dos aplicativos, se o DIF for de alto nível.
O RINA usa a teoria do protocolo Delta-T desenvolvido por Richard Watson em 1981. A pesquisa de Watson sugere que as condições suficientes para uma transferência confiável devem limitar três temporizadores. Delta-T é um exemplo de como isso deve funcionar: ele não tem uma configuração de conexão ou desmontagem. A mesma pesquisa também observa que o TCP já usa esses temporizadores em sua operação, tornando o Delta-T comparativamente mais simples. A pesquisa do Watson também sugere que a sincronização e a alocação de portas devem ser funções distintas, a alocação de portas sendo parte do gerenciamento de camadas e a sincronização sendo parte da transferência de dados.
Segurança
Para acomodar a segurança, o RINA requer que cada DIF / DAF especifique uma política de segurança, cujas funções são mostradas na Figura 7. Isso permite proteger não apenas os aplicativos, mas os backbones e as próprias estruturas de comutação. Uma rede pública é simplesmente um caso especial em que a política de segurança não faz nada. Isso pode apresentar sobrecarga para redes menores, mas é melhor escalonado com redes maiores porque as camadas não precisam coordenar seus mecanismos de segurança: estima-se que a Internet atual requer cerca de 5 vezes mais entidades de segurança distintas do que o RINA. Entre outras coisas, a política de segurança também pode especificar um mecanismo de autenticação; isso torna firewalls e listas negras obsoletos porque um DAP ou IPCP que não pode se juntar a um DAF ou DIF não pode transmitir ou receber. Os DIFs também não expõem seus endereços IPCP a camadas superiores, evitando uma ampla classe de ataques man-in-the-middle.
O design do protocolo Delta-T em si, com sua ênfase na simplicidade, também é um fator. Por exemplo, como o protocolo não tem handshake, ele não tem mensagens de controle correspondentes que possam ser forjadas ou estados que possam ser mal utilizados, como em uma inundação de SYN. O mecanismo de sincronização também torna o comportamento aberrante mais correlacionado com as tentativas de intrusão, tornando os ataques muito mais fáceis de detectar.
Pesquisar projetos
Desde a publicação do livro PNA em 2008 a 2014, muito trabalho de pesquisa e desenvolvimento do RINA foi feito. Um grupo informal conhecido como Sociedade Pouzin , em homenagem a Louis Pouzin , coordena vários esforços internacionais.
Equipe de pesquisa da BU
A equipe de pesquisa do RINA na Universidade de Boston é liderada pelos professores Abraham Matta, John Day e Lou Chitkushev, e recebeu uma série de bolsas da National Science Foundation e EC para continuar investigando os fundamentos do RINA, desenvolver um protótipo de código aberto implementação sobre UDP / IP para Java e experimentá-la no topo da infraestrutura GENI. BU também é membro da Pouzin Society e um colaborador ativo dos projetos FP7 IRATI e PRISTINE. Além disso, BU incorporou conceitos e teoria do RINA em seus cursos de rede de computadores.
FP7 IRATI
IRATI é um projeto financiado pelo FP7 com 5 parceiros: i2CAT, Nextworks, iMinds, Interoute e Boston University. Ele produziu uma implementação RINA de código aberto para o sistema operacional Linux no topo da Ethernet .
FP7 PRISTINE
PRISTINE é um projeto financiado pelo FP7 com 15 parceiros: WIT-TSSG, i2CAT, Nextworks, Telefónica I + D, Thales, Nexedi, B-ISDN, Atos, Universidade de Oslo, Juniper Networks, Universidade de Brno, IMT-TSP, CREATE- NET, iMinds e UPC. Seu objetivo principal é explorar os aspectos de programação do RINA para implementar políticas inovadoras para controle de congestionamento, alocação de recursos, roteamento, segurança e gerenciamento de rede.
GÉANT3 + Vencedor do Open Call IRINA
IRINA foi financiada pelo open call GÉANT3 +, e é um projeto com quatro parceiros: iMinds, WIT-TSSG, i2CAT e Nextworks. O objetivo principal do IRINA é estudar o uso da Arquitetura InterNetwork Recursiva (RINA) como base da próxima geração de arquiteturas de rede NREN e GÉANT. IRINA baseia-se no protótipo IRATI e irá comparar o RINA com o estado da arte da rede atual e a arquitetura de ardósia limpa relevante sob pesquisa; realizar um estudo de caso de uso de como o RINA poderia ser melhor usado nos cenários de NREN; e apresentar um ensaio de laboratório do estudo.
Veja também
Referências
links externos
- Site da Sociedade Pouzin: http://pouzinsociety.org
- Página RINA Education no site da IRATI, disponível online em http://irati.eu/education/
- Repositório de documentos RINA administrado pelo TSSG, disponível online em http://rina.tssg.org
- Tutorial RINA na conferência IEEE Globecom 2014, disponível online em http://www.slideshare.net/irati-project/rina-tutorial-ieee-globecom-2014
