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

5

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,.

6

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

7

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).

8

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.

9

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.

10

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

11

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.

12

Figura 2. Código fonte Hello definido para MPI

Figura 3. Exemplo do MPI do código fonte Hello

2.3. MPL

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

13

recebida 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

14

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

15

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

16

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

17

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

18

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.

19

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.

20

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

21

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.

22

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.

23

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

24

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

25

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.

26

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.