Monografia - PUC-Rio

NESTOR FELIPE MAYA QUINTERO
MIDDLEWARE PARA OS PROTOCOLOS SCTP E HIP
Introdução à computação móvel
Professor: PHD. Markus Endler
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO – PUC
CENTRO DE ESTUDOS DAS TELECOMUNICAÇÕES – CETUC
DOUTORADO EM ENGENHARIA ELÉTRICA
RIO DE JANEIRO
2007.2

ÍNDICE
1. Introdução ................................................................................................... 5
2. Middleware MPI .......................................................................................... 6
2.1. SCTP ................................................................................................... 6
2.1.1. Limitações do TCP........................................................................ 6
2.1.2. SCTP vs TCP................................................................................ 8
2.1.3. Cabeçalho SCTP ........................................................................ 10
2.2. Funcionamento do MPI ...................................................................... 11
2.3. MPL.................................................................................................... 12
2.4. Conformação de grupos no MPI ........................................................ 14
3. Middleware FUEGO .................................................................................. 15
3.1. Host Identity Protocol – HIP ............................................................... 15
3.1.1. Estados do HIP........................................................................... 16
3.1.2. Cabeçalho HIP............................................................................ 16
3.1.3. Arquitetura do HIP ...................................................................... 17
3.1.4. Troca básica do HIP ................................................................... 19
3.1.5. Mobilidade e Multihoming HIP .................................................... 19
3.2. Sistema de eventos............................................................................ 20
3.3. Sistema de mensagens...................................................................... 21
3.4. Serviço de presença .......................................................................... 23
4. Conclusões ............................................................................................... 25
5. Bibliografía ................................................................................................ 26

LISTA DE FIGURAS
Figura 1. Cabeçalho SCTP............................................................................ 10
Figura 2. Código fonte Hello definido para MPI ............................................. 12
Figura 3. Exemplo do MPI do código fonte Hello........................................... 12
Figura 4. Envelope do MPI ............................................................................ 13
Figura 5. Mapeamento do MPI ...................................................................... 13
Figura 6. Conformação de grupos no MPI..................................................... 14
Figura 7. Cabeçalho HIP ............................................................................... 16
Figura 8. Arquitetura de rede com HIP .......................................................... 18
Figura 9. Troca básica do HIP ....................................................................... 19
Figura 10. Sistema de mensagens .............................................................. 22
Figura 11. Componentes do serviço de presença........................................ 23
Figura 12. Exemplo de uma subscrição....................................................... 24

LISTA DE TABELAS
Tabela 1. Comparação do SCTP com TCP e UDP ...................................... 8
Tabela 2. Tipos de Chunk........................................................................... 11
Tabela 3. Estados do HIP........................................................................... 16
Tabela 4. Tipos de pacotes HIP.................................................................. 17

1. Introdução
O middleware para computação móvel, na maioria das vezes depende das
capacidades dos protocolos de transporte e das camadas mais baixas da
arquitetura de rede. Embora o protocolo mais conhecido para realizar o
transporte dos dados seja o TCP [1], será demonstrado que, para as atividades
onde há mobilidade, ele é limitado e precisa de componentes que o ajudem
neste processo.
Em contraste com o protocolo TCP, o HIP, localizado entre as camadas de
rede (com o protocolo IP) e de transporte (com o protocolo TCP), entra como
um mecanismo que identifica a mobilidade com eficiência, permitindo
determinar mudanças do endereço IP, persistindo nas comunicações sem
interromper a conexão.
Em contrapartida com o protocolo TCP, o protocolo de transporte SCTP foi
especificado para resolver todas as limitações deste protocolo, tais como:
mobilidade, múltiplas conexões associadas a um mesmo socket, dentre outras.
Baseado nestes mecanismos e em novos protocolos, este trabalho identifica
várias abordagens que visam aproveitar as vantagens fornecidas para o
esquema de mobilidade. Inicialmente, a especificação do mecanismo HIP e
protocolo SCTP serão descritas. Em seguida, serão especificados os
Middleware Fuego e MIP, descrevendo seus funcionamentos e as
características básicas de mobilidade que eles implementam para diferentes,
aplicações, utilizando os protocolos anteriormente citados,.
5

2. Middleware MPI
A especificação do MPI (Message Passing Interface) define um middleware
para troca de mensagens, usado especialmente em aplicações de computação
paralela. As funções do middleware MPI foram projetadas para tomar
vantagens de comunicações mais especializadas, para fornecer um
componente de gerenciamento de processos. O padrão MPI especifica a
criação dinâmica de processos, desde o início, execução e término. para
ambientes de memória distribuída, máquinas paralelas, NOWs (network of
workstations) e redes heterogêneas. Este padrão é utilizado sobretudo em
grades computacionais, fornecendo grande eficiência às aplicações paralelas,
possibilitando o escalonamento dinâmico de processos, a fim de obter maior
eficiência na execução das aplicações.
O MPI, junto com o protocolo de transporte SCTP, demonstrou notável
aumento no desempenho das aplicações que realizam comunicações sobre
canais altamente congestionados (com valores de latência e de taxa de perdas
de pacotes elevados). Ainda que, a princípio, o protocolo TCP fosse utilizado
como o protocolo de transporte padrão do MPI, o SCTP se adequou melhor às
suas funções por ser baseado em mensagens.
2.1. SCTP
Streaming Control Transport Protocol (SCTP), é um protocolo projetado para
suprir as deficiências e limitações encontradas no protocolo de transporte TCP.
Tais limitações, juntamente com algumas comparações analíticas, serão
determinadas a seguir.
2.1.1. Limitações do TCP
6

Atualmente o protocolo TCP (RFC793) é amplamente utilizado para diferentes
tipos de serviços que necessitam de transporte confiável dos dados em redes
IP. No entanto, um número crescente de aplicações mostrou que o TCP é
bastante limitado, por este motivo, determinadas aplicações optaram por
incorporar novos algoritmos para obter confiabilidade de forma mais flexível,
utilizando o protocolo UDP (RFC768). As limitações mais comuns do TCP são:
• O TCP fornece transporte confiável com uma ordem estrita de
transferência de dados. Algumas aplicações precisam de confiabilidade,
sem manutenção do número da seqüência,.enquanto que outras podem
ser satisfeitas com uma ordem parcial. Em ambos os casos, o bloqueio
causado por esta política do TCP, causa um atraso desnecessário.
• A natureza stream-oriented do TCP é, na maioria das vezes, um
inconveniente. As aplicações devem adicionar seu próprio registro de
marcas para delinear suas próprias mensagens, e deve fazer
explícitamente o uso desta facilidade para assegurar que a mensagem
seja transferida em um tempo razoável.
• O escopo limitado dos sockets do TCP complica a tarefa de fornecer alta
disponibilidade na transferência de dados para aplicações que utilizam
hosts “multihomed”.
• O TCP é relativamente vulnerável a ataques, tal como o ataque do SYN
para denegação do serviço DoS.
Em contraste, o SCTP (Stream Control Transport Protocol) evoluiu a partir de
um protocolo de sinalização telefônico desenvolvido para redes IP. Em Outubro
de 2000 ele foi padronizado pela IETF (RFC 2960), sendo suportado por
diversas variantes do Unix (kernel de Linux 2.6).
7

2.1.2. SCTP vs TCP
O termo multi-streaming refere-se à capacidade do SCTP em transmitir vários
fluxos de mensagens independentes, paralelamente, como por exemplo, a
transmissão simultânea de duas imagens sobre uma aplicação HTTP. Pensar
em multi-streaming é semelhante a construir várias conexões TCP em uma
única associação SCTP. De um lado, o TCP assegura uma ordem correta dos
bytes em um fluxo contínuo, aplicando números de seqüências em cada pacote
enviado. Por outro lado, o SCTP pode aplicar diferentes números de
seqüências nos pacotes enviados sem precisar de uma ordem restrita. Não
obstante, o ordenamento das mensagens e a confiabilidade do transporte são
opcionais no SCTP. Uma comparação entre os protocolos de transporte TCP,
UDP [2] e SCTP, pode ser vista na tabela 1.
Função TCP UDP SCTP
Orientado a Conexão Sim Não Sim
Transporte Confiável Sim Não Sim
Preserva um Limite de Mensagens Não Sim Sim
Entrega Ordenada Sim Não Sim
Entrega Desordenada Não Sim Sim
Checksum de Dados Sim Sim Sim
Path MTU Sim Não Sim
Controle de Congestionamento Sim Não Sim
Múltiplos streams Não Não Sim
Suporte Multi-homing Não Não Sim
Bundling Não Não Sim
Tabela 1. Comparação do SCTP com TCP e UDP
Outra característica marcante do protocolo SCTP é o suporte a múltiplos
endereços IP em uma mesma “conexão” permitindo redundância de caminhos
em caso de falhas na rede. Essa característica é conhecida como multihoming.
O protocolo SCTP é orientado a conexão, estabelecendo uma associação entre
o tx e o rx com um número arbitrário de fluxos simplex de transmissão e
recepção.
8

Diferentemente do TCP, que é orientado a octetos, o SCTP é um protocolo
orientado a mensagens. Nesse esquema, as informações transmitidas em uma
comunicação são transportadas em blocos de dados (chunks), que podem ser
de usuários (dados da aplicação) ou de controle do protocolo. Mensagens de
usuários e de controle podem estar contidas em um mesmo pacote SCTP. Os
blocos de controle desempenham diversas tarefas necessárias à operação do
protocolo, como o reconhecimento de mensagens proveniente de usuários e o
estabelecimento de associações. Esse último procedimento é realizado pela
troca de quatro mensagens de controle entre cliente e servidor, conhecido
como four-way handshake. O fato de utilizar um esquema de mensagens de
controle garante ao SCTP uma maior flexibilidade para complementações em
sua estrutura operacional. Em contrapartida, o TCP possui suas funções de
controle embutidas em uma estrutura de segmento, o que embora traga
benefícios de eficiência computacional de processamento, inibe muitas
tentativas de adaptação e evolução do protocolo.
O protocolo SCTP é rate adaptive, o que garante adaptação dinâmica às
variações e problemas que ocorrem na rede. Devido à eficiência comprovada
em anos de operação, os algoritmos de controle de congestionamento do TCP
foram aproveitados no SCTP, com pequenas variações.
Quanto à mobilidade, o MSCTP (Mobile Stream Control Transmission
Protocol), é uma extensão que define o uso do SCTP em conjunto com
mecanismos de configuração dinâmica de endereços IP numa associação. A
idéia é explorar a característica de multihoming do SCTP, juntamente com
mecanismos de configuração dinâmica de endereços, o que permite operações
de handover em ambientes que necessitam de mobilidade, garantindo assim
“mobilidade de terminal” no nível de transporte.
9

2.1.3. Cabeçalho SCTP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 1. Cabeçalho SCTP
O cabeçalho do SCTP, como ilustrado na figura 1, está composto pelos
seguintes campos: o campo U de um bit que determina se os pacotes podem
chegar com número de seqüência desordenada. O campo B determina o
primeiro fragmento da mensagem. O campo E determina o último fragmento da
mensagem. O campo Stream Identifier determina o identificador da associação
do usuário. O campo Payload Protocol Identifier é um dado que pode ser
fornecido pelo usuário para uma aplicação específica. O campo TSN
(Transmission Sequence Number) define a seqüência dos fragmentos
transmitidos. O campo Type determina o tipo do pacote, que pode ser dados ou
eventos, especificado na tabela 2.
Valor Tipo de Chunk
0 Dados
1 INIT Inicio da associação
3 INIT ACK
4 Selective ACK – SACK
5 HEARTBEAT
6 ABORT
7 SHUTDOWN
8 SHUTDOWN ACK
10

9 ERROR
10 COOKIE ECHO – estado do coockie
11 COOKIE ACK
12 ECNE - Notificação explicita do congestionamento
13 CWR – redimensiona o tamanho da Janela de congestionamento
14 SHUTDOWN COMPLETE
15-254 Reservado pela IETF
Tabela 2. Tipos de Chunk
2.2. Funcionamento do MPI
No MPI, a execução de um processo pode ser dividida em pequenas partes
que são distribuídas que são distribuídas entre múltiplas estações para o
balanceamento da carga de processamento. Os resultados obtidos pelas
outras máquinas são enviados a um receptor que os coleta e, em seguida, os
agrupa para fornecer o resultado esperado. O processo pode ser executado em
uma única máquina ou em várias máquinas. Todo o processo recebe uma
identificação única, denominada de Rank. Essa identificação é contínua e é
representada por um número inteiro, começando de zero até N-1, onde N é o
número de processos.
O MPI é composto por grupos representados por um conjunto ordenado de N
processos. Todo e qualquer grupo é associado a um comunicador, muitas
vezes pré-definido como "MPI_COMM_WORLD".
- O comunicador é um objeto local que representa o contexto de uma
comunicação entre um conjunto de processos que podem ser contatados.
- O MPI_COMM_WORLD é o comunicador pré-definido que inclui todos os
processos definidos pelo usuário numa aplicação MPI.
- O Application Buffer representa o endereço de memória, gerenciado pela
aplicação, que armazena um dado que o processo necessita enviar ou receber.
- O System Buffer é um endereço de memória reservado pelo sistema para
armazenar mensagens.
Um exemplo de programação do MPI de um simples “hello world” pode ser
visto na figura 2, cujo resultado de execução pode ser visto na figura 3.
11

2.3. MPL
Figura 2. Código fonte Hello definido para MPI
Figura 3. Exemplo do MPI do código fonte Hello
O MPI utiliza uma variedade de rotinas para passar mensagens entre
processos, tal como o Message progression Layer (MPL), responsável pela
progressão, coincidência e envio das mensagens. Esta rotina é composta por
funções como o Matching, que verifica a coincidência das mensagens. Está
conformado sobre parâmetros de: contexto, rank e tag. Uma chamada
12

ecebida realiza uma correspondência dos valores no envelope da mensagem
com cada um destes parâmetros, visualizados na figura 4 [6].
Figura 4. Envelope do MPI
- O contexto identifica uma série de processos que pode se comunicar com
cada um dos outros.
- O Identificador do processo, denominado de rank.
- O tag, que identifica o tipo mensagem.
Uma relação do protocolo SCTP com cada um dos parâmetros da
especificação MPI, pode ser vista na figura 5 [7]. Significa que em uma
conexão de um para muitos, um socket SCTP é associado aos diferentes
pontos com identificadores únicos, que são traduzidos no MPI como rank. O
contexto e o rank são utilizados no envelope da mensagem, através de tags
necessários para as funções Matching.
Figura 5. Mapeamento do MPI
13

2.4. Conformação de grupos no MPI
Uma conformação típica de grupos no MPI está ilustrada na figura 6,
juntamente com uma série de funções, tais como:
1. Composição de todos os pontos com o MPI_COMM_WORLD
2. Conformação de subgrupos com MPI_Group_incl.
3. Criação de um comunicador com MPI_Comm_create.
4. Determinação de um novo rank para o grupo MPI_Comm_rank
5. Canal de comunicações com alguma rotina de emissão de
mensagens do MPI.
6. Ao término da execução, são liberados os comunicadores e os
grupos através das chamadas “MPI_Comm_free” e
“MPI_Group_free”, respectivamente.
Figura 6. Conformação de grupos no MPI
14

3. Middleware FUEGO
O Middleware FUEGO especifica uma serie de serviços para aplicações
móveis sobre contextos móveis [10]. As áreas de estudo do projeto se focam
em aplicações adaptativas, serviços de reconfiguração dinâmica, sistema de
informação distribuída móvel, mobilidade, multihoming e identificação
criptográfica de um host. As partes mais relevantes do Middleware FUEGO se
resumem em sistemas de eventos distribuídos, serviço de transporte de
mensagens, serviço de presença e o gateway FUEGO-SIP. O middleware
FUEGO é baseado no protocolo HIP, que será o primeiro tema a ser
apresentado neste segmento.
3.1. Host Identity Protocol – HIP
O HIP define uma forma de estabelecer e manter, de maneira segura, o estado
da camada IP. Especifica identificadores e regras de localização para um
endereço IP, permitindo a continuidade das comunicações, mesmo quando
este é alterado. Usa identificadores de chaves públicas e privadas para
determinar a identidade de um Host para uma autenticação mútua entre os
pontos. O protocolo é projetado para ser resistente aos ataques de negação de
serviço (Denial of Service - DoS) e homem no meio (Man in the middle - MitM),
permite proteção à integridade dos dados aplicando o ESP (Encapsulated
Security Payload) e criptografia para outras camadas, tal como TCP e UDP.
A arquitetura do HIP propõe uma alternativa à utilização de endereços IP, como
“localizador” (marcas de roteamento) e “identificadores” (identificador do host).
Compreende duas principais representações da identidade do host: o
identificador do host (HI) e uma etiqueta para a identidade do host (Host
Identity Tag - HIT). O HI é uma chave pública que representa diretamente a
identidade do host. O HIT é uma representação operacional, tem um tamanho
de 128 bits utilizado no cabeçalho do HIP para indexar o estado
15

correspondente no host final, o que servirá para gerenciar o estabelecimento
dos estados, ponto a ponto.
3.1.1. Estados do HIP
O protocolo HIP tem poucos estados. Os estados iniciais são o Initiator e o
Responder [8], utilizados no começo da conexão quando a associação é
estabelecida. Não obstante, outros estados podem ser livremente
especificados por implementações particulares. Os estados mais comuns
podem ser vistos na tabela 3.
Estado Descrição do estado
UNASSOCIATED Estado inicial da máquina
I1-SENT Inicio de troca básica
I2-SENT Espera para completar a troca básica
R2-SENT Espera para completar a troca básica
ESTABLISHED Associação HIP estabelecida
CLOSING Fechar associação HIP
CLOSED Associação HIP fechada
E-FAILED Falha na troca básica
Tabela 3. Estados do HIP
3.1.2. Cabeçalho HIP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Host Identity Tag (HIT) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ HIP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 7. Cabeçalho HIP
16

O cabeçalho HIP, visto na figura 6, é logicamente uma extensão do cabeçalho
IP. O campo Next Header não esta documentado na RFC, mas depende dos
processos do IPv6, que será futuramente documentado quando for definida a
sua utilidade. Por enquanto, este campo não indica nada para o protocolo HIP.
O campo Header Length contém o tamanho do cabeçalho HIP. O campo
Packet Type determina o tipo do pacote HIP, especificados na tabela a seguir:
Tipo de pacote Nome do pacote
1 I1 - Pacote Iniciador
2 R1 - Pacote Responder
3 I2 - Segundo pacote iniciador
4 R2 - Segundo pacote Responder
16 UPDATE - Pacote atualizador
17 NOTIFY - Pacote notificador
18 CLOSE - Pacote que fecha associação
19 CLOSE_ACK - Pacote que fecha o ACK
Tabela 4. Tipos de pacotes HIP
O campo VER refere-se à versão do protocolo HIP, necessário para determinar
incompatibilidades de versões. O campo RES, esta reservado para usos
futuros. Os campos 0 e 1 do cabeçalho, são campos reservados para
compatibilidade potencial com o protocolo SHIM6 [I-D.ietf-shim6-proto]. O
campo Parameters, representa os parâmetros usados para com a chave
pública associada com o HIT emitida junto com informação relativa à
seguridade mais outro tipo de informação.
3.1.3. Arquitetura do HIP
Na atualidade, a internet usa dois espaços de nomes (namespace) globais:
Nomes de domínio e Endereços IP [11]. O espaço de nomes representa
identificadores simbólicos para uma série de endereços IP. Nesse sentido,
estes espaços de nomes têm dois usos: o primeiro uso refere-se à localização
topológica em pontos de aderência de uma rede, tal como o endereçamento
17

para uma localização específica em uma topologia de rede. O segundo uso
refere-se aos identificadores de interfaces rede.
Em contraste, o HIP adiciona uma subcamada entre a camada de rede e de
transporte [8]. Introduz um novo espaço de nomes criptografado e o conceito
do HI, como pode ser visto na arquitetura de rede da figura 7.
Figura 8. Arquitetura de rede com HIP
No HIP, a camada de transporte é modificada para que as conexões sejam
identificadas utilizando a fonte e o destino do HI.
Basicamente, o HI é uma chave pública que serve como identificador do ponto
destino. Cada host tem pelo menos um HI designado que é armazenado em
diretórios, tal como no DNS, para permitir que o host possa ser contatado pelos
demais. Um host pode ter vários HIs e este pode também gerar HIs anônimos
para estabelecer conexões com outros hosts. O principal propósito de um HI
anônimo é fornecer proteção da privacidade do host quando o host não permite
utilizar HIs públicos.
O HIT (Host Identity Tag), variante do HI, tem um tamanho fixo de cifragem que
contém 128 bits, o que o torna vantajoso para realizar uma codificação mais
fácil com um formato consistente. O HIT identifica a chave pública que pode
validar a autenticidade do pacote.
18

3.1.4. Troca básica do HIP
O protocolo HIP realiza uma sinalização entre as comunicações dos pontos
finais com o principal propósito de autenticação fim a fim e criar segurança IP
(IPSec) com o ESP (Encapsulating Security Payload) [4]. A troca básica do
HIP começa com a primeira mensagem denominada como I1, enviado pelo
INITIATOR com seu próprio HIT e o HIT do RESPONDER. O RESPONDER
envia uma resposta com a mensagem R1, que contem os HIs do INITIATOR e
um desafio que consiste em um enigma que deve ser resolvido. O propósito
deste desafio é fazer o protocolo resistente ao ataque DoS [5]. O INITIATOR
resolve o desafio e envia a mensagem I2 com seus próprios HITs junto com a
solução do enigma para realizar a autenticação com a resposta R2 do
RESPONDER. Esta troca básica, descrita anteriormente, pode ser vista na
figura 8.
Figura 9. Troca básica do HIP
3.1.5. Mobilidade e Multihoming HIP
O HIP utiliza um par de chaves publica/privada, ao invés do endereço IP, com
uma identificação do host. Não obstante, cada host deve conhecer pelo menos
um endereço IP no qual o ponto pode ser alcançado, durante a troca básica do
HIP. Em conseqüência a tal desacoplamento, uma nova solução de mobilidade
e multihoming na camada de rede foram atribuídas.
19

A mobilidade na camada de rede no HIP define um parâmetro genérico
denominado LOCATOR, utilizado nas mensagens do HIP. Este parâmetro
permite que um host HIP notifique a alternância de endereços que um ponto
pode alcançar. O parâmetro LOCATOR pode ser endereços IP.
Quando um host se move para outro endereço, um evento de mobilidade é
notificado ao ponto conectado, enviando uma mensagem de tipo UPDATE que
contém o parâmetro LOCATOR. Este pacote UPDATE é confirmado com um
ACK no ponto de destino. Para confiabilidade em presença de pacotes
perdidos, o pacote UPDATE é retransmitido, como definido nas especificações
do HIP. O ponto de destino pode autenticar o conteúdo do pacote UPDATE,
baseado nas chaves do pacote.
Uma configuração operacional relatada é um host de tipo multihoming, que
significa que um host possui simultaneamente múltiplos LOCATORS, o que em
conseqüência, converge em um caso de mobilidade. Por usar o parâmetro
LOCATOR, um host pode informar ao ponto de destino os LOCATORS
adicionais, determinando como pode ser alcançado e definir um determinado
LOCATOR como preferido [3].
3.2. Sistema de eventos
O sistema de eventos do Middleware FUEGO baseia-se em três entidades:
• Subscribers: Recebe as notificações baseado em filtros
• Publishers: Publica as notificações.
• Fuego Router: Encaminha as notificações aos clientes.
O roteador pode se dividir em duas partes: servidor de acesso e núcleo de
roteamento. O roteador baseia-se em um algoritmo de roteamento
fundamentado em distribuição sobre canais de eventos. Desde o ponto de vista
do cliente, o objeto básico é a sessão que representa uma subscrição. Um
20

canal é um tipo de objeto e pode determinar a estrutura de um evento. O
subspcritor utiliza um listener específico que determina de onde estão vindo as
notificações e para aonde devem ser enviadas.
Um servidor de eventos pode ser estendido usando componentes, tais como:
• EventServer: Funcionalidade de acesso ao servidor.
• StartServer: Reinicia o sistema
• IRoutingEngine: Interface para o motor de roteamento.
• IMobilityEngine: Interface para o motor de mobilidade.
A implementação da interface IMobilityEngine fornece o núcleo do sistema de
eventos publish/subscribe e esta baseado em canais de eventos ou roteadores
salto a salto.
O núcleo do roteador é responsável por:
• Processamento do serviço lógico
• Armazenagem dos filtros
• Coincidência das notificações
• Operações de gerenciamento
• Fornecer uma interface de usuário para o roteador
3.3. Sistema de mensagens
O sistema de mensagens para uma série de serviços que suporta
comunicações de mensagens ou RPC (Remote Procedure Call), é constituído
por três componentes:
• Serviço de mensagens: fornece uma interface padrão à aplicação e
conecta os componentes.
• O protocolo AMME: responsável por gerenciar as conexões de rede
enviando e recebendo mensagens.
• Sistema Xebu: fornece formatos de serialização para mensagens SOAP.
21

O principal sistema de mensagens é denominado de AMME, e esta dividido em
uma camada de mobilidade compartilhada e um protocolo independente de
transferência, denominado Meep e MOP. O Meep é baseado no protocolo de
troca extensível de blocos BEEP (Blocks Extensible Exchange). O MOP o
protocolo é baseado em HTTP. As partes do sistema de mensagens podem ser
vistas na figura 9.
Figura 10. Sistema de mensagens
A API XAS, pertencente ao modulo Xebu, processa todas as mensagens que
utilizam a linguagem XML, e conseqüentemente origina uma seqüência de
eventos. O serviço de mensagens se compõe da subcamada Axis e Lye. O
Axis é uma interface que apresenta um serviço de mensagens que permite ao
servidor a comunicação com as subcamadas do mecanismo.
O AMME é um protocolo de mensagens projetado para ambientes móveis. Este
protocolo esta dividido em duas camadas:
• Camada de mobilidade: Fornece uma conexão persistente produzindo o
envio de eventos quando o cliente esta se deslocando.
• Camada de transferência: Fornece um canal de comunicações full-
duplex.
22

O sistema de mensagens permite utilizar uma grande variedade de formatos
textuais, como XML e formatos binários, como o Xebu. O sistema de
mensagens baseado no Xebu, permite converter as mensagens no formato
SOAP que tem associado uma interface de implementação XAS.
3.4. Serviço de presença
O serviço de presença e o serviço de mensagens instantâneo são simples
protótipos da implementação de um serviço de notificação para conectividade e
mobilidade. O protótipo esta implementado em J2ME (Java 2 Micro Edition) e
utiliza a interface do MIDP (Mobile Information Device Profile). Mediante o
componente de descoberta de presença junto com o serviço de mensagens
instantâneo, o modelo de sensibilidade ponto a ponto, depende do sistema de
notificações, o que permite operar sem um servidor dedicado. O serviço de
presença está implementado por componentes que podem ser vistos na figura
10.
Figura 11. Componentes do serviço de presença
23

Em cada serviço de presença existem canais de eventos tais como:
• O canal de eventos relacionado à presença, o qual permite disseminar a
informação de presença e de contexto.
• O canal relacionado a mensagens instantâneas.
• Canal de controle de presença, o qual realiza as subscrições e gerência
do serviço.
A função subscriptor refere-se ao estado onde o usuário solicita receber
atualizações do contexto de outro usuário. Um exemplo de subscrição, que
apresenta um cenário simples, pode ser visto na figura 11. Neste exemplo, o
elemento “consumer” realiza um pedido de subscrição para os elementos
“producer 1 e 2”. O elemento producer 1 permite realizar a subscrição,
enquanto que o elemento producer 2 não.
Figura 12. Exemplo de uma subscrição
24

4. Conclusões
O mecanismo HIP, é uma especificação eficiente e segura complementares ao
endereço IP, que identifica um host com chaves públicas e privadas, permitindo
a mobilidade no esquema de multihoming quando existem mudanças no
endereçamento IP, sem perder as conexões TCP de uma aplicação. Em
contraste com este mecanismo, o Middleware Fuego, aproveita todas as
características de mobilidade que este mecanismo fornece, criando um
esquema de eventos e mensagens, quando existem variações no
endereçamento IP, com a finalidade de apoiar mobilidade na computação
distribuída desde a camada de aplicação.
O protocolo SCTP, é um protocolo de transporte, que resolve os problemas de
mobilidade quando acontecem mudanças de endereçamento IP. Gera eventos
de notificações, permitindo realizar em um mínimo tempo de handoff a
identificação das variações do endereçamento IP. Neste sentido, o Middleware
MIP, se encaixou perfeitamente, por ser um protocolo orientado a mensagens
(eventos), permitindo diferentes associações em uma conexão.
25

5. Bibliografía
1. DARPA. “RFC793 Transmission Control Protocol TCP”. Internet
Engineering Task Force,1981.
2. J. POSTEL. “RFC768 User Datagram Protocol UPD”, Internet Engineering
Task Force. 1980.
3. R. MOSKOWITZ, P. NIKANDER. “Host Identity Protocol”, draft-ietf-hip-
base-10. 2007.
4. STEPHEN KENT, RANDALL ATKINSON. “RFC 2406: IP Encapsulating
Security Payload (ESP)”. Internet Engineering Task Force, 1998.
5. THOMAS AURA, PEKKA NIKANDER. “DOS resistant authentication with
client puzzles”. In 8th International Workshop on Security Protocols, pages
170–177, 2001.
6. HUMAIRA KAMAL, BRAD PENOFF, “SCTP versus TCP for MPI”, SC, 2005.
7. HUMAIRA KAMAL, BRAD PENOFF. “Using SCTP to hide latency in MPI
programs”. HCW 2006 and IPDPS 2006, 2006.
8. R. MOSKOWITZ, P. NIKANDER. “rfc4423 Host Identity Protocol (HIP)
Architecture”, Internet Engineering Task Force, 2006.
9. Márcia C. Cera, Nicolas Maillard, “Escalonamento Dinâmico de
Processos MPI”, ERAD2006, 2006.
10. SASU TARKOMA, JAAKKO KANGASHARJU. “Documentation of Fuego
Service Set Implementation”. Helsinki Institute for Information Technology.
2006.
11. LARS EGGERT, JULIEN LAGANIER, “HIP Resolution and Rendezvous
Mechanisms”. Workshop on HIP and Related Architectures. 2006.
26