Página Inicial

Introdução

Histórico e Motivação

Arquitetura DTN

Registros Administrativos e Opções de Entrega

Protocolo Bundle

Segurança

Cenário Determinístico & Exemplos

Cenário Estocástico & Exemplos

Aplicações

Perspectivas e Considerações Finais

Perguntas & Respostas

Referências

Glossário


DTN – Delay and Disruption Tolerant Networks (Redes Tolerantes a Atrasos e Interrupções)



Histórico e Motivação

O Departamento de Correios nos EUA, com um histórico em torno de 230 anos, desenvolveu um sistema notável de serviço oferecendo o que para muitos parece como uma forma simples e direta de entrega de correio. Além das categorias básicas de primeira-classe, prioridade, correio expresso, postagem parcelada e matéria impressa encadernada (“bound printed matter”), um grande número de opções são disponíveis de acordo com as necessidades do cliente.

Apesar do sistema de serviços ser familiar e ter uma longa história, analisando cruamente, os serviços postais são atrativos por causa de seu caráter granular e intuitivo: a escolha de prioridades baixa, ordinária e alta de entrega; notificações de estado da encomenda, entrega ao recipiente (recibo de retorno) e rota do correio (histórico). É importante ressaltar a necessidade de alguma forma de armazenamento, o que se chama de persistência, e transferência da responsabilidade de entregar a informação, transferência de custódia, a cada salto na rota.

Algo diretamente inspirado no sistema de correios é o correio eletrônico (e-mail) que possui as características de nomeação flexível, operação assíncrona baseada em mensagens e relatório de erros dentro da banda de transmissão. Correio eletrônico não atende as expectativas das redes em questão pois não tem roteamento dinâmico, definido fragilmente pela semântica de entrega, e falta de uma interface de aplicação consistente. Temos um avanço em relação a utilidade os relatórios de erro enviados pelos servidores de email, mas o usuário típico tem pouco controle direto para corrigir o problema.

_________________________________________________________________________________

No advento, desenvolvimento de sistemas de satélite e telefonia móvel, começaram a surgir dificuldades que traziam problemas de compatibilidade com as redes até então com as redes exóticas. Veio então as chamadas abordagens reparo-de-link (link-repair), uma classe de tentativas de abordagem usando TCP/IP para ligações problemáticas, que pareciam mais como reinventando o que TCP/IP já propunha solucionar. Elas tentam “enganar” os outros protocolos em acreditar que estão operando sobre uma infraestrutura operacional estável. As técnicas reparo-de-link têm como objetivo a confiabilidade fim-a-fim, a garantia do modelo de “tudo-ou-nada” (fate-sharing) [8] da Internet, e geralmente requerem o uso de IP em todos sistemas conectados. Também outra abordagem para tentar tratar redes exóticas foi usar agentes de proxy especiais para atar elas aos cantos da Internet, permitindo um acesso delas, e para elas a Internet. Tratou-se de uma solução plausível, mas não forneceu uma forma geral para usar as ligações criadas para trânsito de dados.

Dada a estrutura complexa da Internet desde que ficou famosa, métodos de reparo-de-link sozinhos não foram suficientes, e proxies específicas a cada caso de rede (ad-hoc) são indesejáveis. A formulação de DTN foi influenciada pelas propriedades de interoperabilidade da arquitetura clássica da Internet, a semântica robusta e assíncrona de entrega de correio eletrônico, e um subconjunto de classes de serviços do Sistema Postal Americano.

A principal técnica utilizada para tratar os atrasos e as desconexões foram a comutação de mensagens e o armazenamento persistente de dados. Assim, as DTNs se caracterizam por armazenar e encaminhar (store-and-forward) mensagens. Posteriormente, um grupo Internet Research Task Force (IRTF) estabeleceu um arquitetura para DTN que fosse compatível com a técnica já utilizada e com qualquer tipo de (sub)rede, a solução foi uma camada de agregação (bundle layer) abaixo da camada de aplicação e acima da camada de transporte. Atualmente, existem diversos protocolos de roteamento para DTNs classificados de acordo com grau de informação disponível sobre a rede.

O grupo Jet Propulsion Laboratory (JPL) [2][7] ainda na década de 90 desenvolvendo um projeto sobre internet interplanetária (IPN). Eles tinham como objetivo definir uma arquitetura de redes que permitisse comunicação entre a internet existente na terra com uma interplanetária.

Como o IRTF já entendia que as soluções aplicadas a IPN poderiam ser aplicadas a algumas redes terrestres, em 2002, eles criaram um grupo de pesquisa em DTN (Delay Network Research Group, DTNRG) para tratar o conceito de DTN em ambientes terrestres.

Em 2007, o RFC 4838 mantido pelo IETF (Internet Engineering Task Force) definiu a arquitetura DTN, descrevendo como um conjunto de nós armazenam e encaminham mensagens em ambiente com grandes atrasos e frequentes desconexões. No mesmo ano, o RFC 5050 definiu as especificações do protocolo bundle (de agregação).

_________________________________________________________________________________

Até seu desenvolvimento mais recente, foram abordadas algumas alternativas às DTNs que possuem características próprias:

  • Proxies de Desempenho (PEP, Performance Enhancing Proxies), agentes, que ativamente modificando a sequência de dados fim-a-fim, “enganam” estações destinatárias baseadas em TCP/IP operar mais eficientemente em caminhos envolvendo conexões de desempenho pobre ou incomum, sendo desencorajado pela IETF devido sua fragilidade, aumentando significamente a complexidade dos sistemas para atender as demandas de confiabilidade e segurança;

  • Boosters de Protocolo, semelhante às PEPs mas trabalham a nível de protocolo;

  • Outras proxies na camada de aplicação, que contém mapeamento especializado (análogo a DHCP) e tradução de protocolos, cuja a desvantagem é a especificidade, pois as proxies correspondem a um dos dois comportamentos: elas respondem a um conjunto especializado de comandos específico a rede especial, ou agem como barramentos de dados brutos, então nenhuma recurso geral de roteamento entre proxies é utilizado atualmente, ou seja se roteamento dinâmico é realizado entre proxies é específico ao tipo das proxies em questão.




DEL/UFRJ

Rio de Janeiro, 2018