MOBILIDADE SCTP E HIP
MIDDLEWARE MPI E FUEGO
MEng. Néstor Felipe Maya Quintero
Matéria: Computação móvel
Professor: PHD. Markus Endler
Sumário
Introdução
 Middleware MPI

Protocolo SCTP
 Funcionamento básico do MPI


Middleware FUEGO
Mecanismo HIP
 Funcionamento básico do FUEGO

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.
O TCP, para as atividades de mobilidade, pelo fato de não entender as
mudanças do endereço IP, é limitado é precisa de componentes
adicionais que ajudem neste processo.
Em contraste com o protocolo TCP, o HIP é um mecanismo que
eficientemente identifica a mobilidade
Em contrapartida com o protocolo TCP, o protocolo de transporte SCTP
foi especificado para resolver todas as limitações deste protocolo.
Baseados nestes protocolos, este trabalho identifica vários
desenvolvimentos que buscam aproveitar as vantagens fornecidas para
o esquema de mobilidade tal como MPI e FUEGO.
Middleware MPI





Message Passing Interface
Middleware para troca de mensagens.
Usado especialmente em aplicações de
computação paralela.
Projetado para tomar vantagens de
comunicações mais especializadas.
Fornecer um componente de comunicações e
de gerenciamento de processos.
MPI - [ SCTP ]

O MPI foi inicialmente projetado com TCP
 O MPI junto com o protocolo SCTP,
demonstrou notável aumento do desempenho
das aplicações com:



Comunicações sobre canais altamente
congestionados.
Latência e perdas altas.
O SCTP, se encaixou perfeitamente nas
funções do MPI por ser baseado em
mensagens.
SCTP
Streaming Control Transport Protocol,
IETF ano 2000 (RFC 2960)
 Protocolo projetado para suprir as
deficiências e limitações encontradas no
protocolo de transporte TCP.
 Suporte de mobilidade
 Multi-streaming
 O controle é baseado em mensagens

SCTP – [ Limitações do TCP ]

Transporte confiável com uma ordem de seqüências
estrita de transferência de dados.






Algumas aplicações precisam confiabilidade sem
manutenção do número da seqüência.
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.
TCP precisa de mecanismo adicionais para controle
de mobilidade, entre outros.
O escopo limitado dos sockets do TCP não permite a
alta disponibilidade na transferência de dados
(multihomed).
O TCP é relativamente vulnerável a ataques, tal como
o ataque do SYN e denegação do serviço DoS.
SCTP vs TCP e UDP
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 Multihoming
Não
Não
Sim
Bundling
Não
Não
Sim
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)
/
\
\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Funcionamento do MPI
Execução de um processo pode ser
dividida em pequenas partes.
 Estas partes podem ser sub-distribuídas
em outras máquinas.
 O processo pode ser executado em uma
única máquina ou em várias máquinas.
 Os processo são controlados a través de
uma interface de mensagens.

Compsição do MPI

- O comunicador: objeto local que representa o
contexto de uma comunicação entre um conjunto de
processos que podem ser contatados.
 - O MPI_COMM_WORLD: comunicador predefinido
que inclui todos os processos.
 - O Application Buffer: representa o endereço de
memória 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.
Exemplo do MPI
Execução do exemplo MPI
MPL [ MPI ]

Message Progression Layer
 Responsável pela progressão, coincidência e
envio das mensagens.
 Composta por:



Contexto, identifica uma série de processos que
pode se comunicar com cada um dos outros.
Identificador, do processo, denominado de rank.
Tag, identifica o tipo mensagem.
Envelope do MPI
MPI com SCTP
Conformação de grupos no MPI






Composição de todos os pontos com o
MPI_COMM_WORLD
Conformação de subgrupos com MPI_Group_incl.
Criação de um comunicador com MPI_Comm_create.
Determinação de um novo rank para o grupo
MPI_Comm_rank
Canal de comunicações com alguma rotina de
emissão de mensagens do MPI.
Para terminar, são liverados os comunicadores e os
grupos com MPI_Comm_free e MPI_Group_free
respectivamente.
Conformação de grupos no MPI
Middleware FUEGO

Especifica uma serie de serviços para
aplicações móveis sobre contextos móveis.
 As áreas de estudo do projeto se focam em:




Aplicações adaptativas
Serviços de reconfiguração dinâmica
Base de informação distribuída móvel
Mobilidade, multihoming e identificação
criptográfica de um host.
Partes relevantes do FUEGO
Sistemas de eventos distribuídos
 Serviço de transporte de mensagens
 Serviço de presença.
 Gateway FUEGO-SIP.
 Baseado no protocolo HIP.

Host Identity Protocol – HIP





Define uma forma de estabelecer e manter de forma
segura o estado da camada IP.
Determina identificadores e regras de localização para
um endereço IP.
Permite a continuidade das comunicações a través de
mudanças do endereço IP.
Usa identificadores de chaves públicas e privadas
para determinar a identidade de um Host.
Projetado para ser resistente aos ataques de
denegação do serviço (Denial of Service - DoS) e
homem no meio (Man in the middle - MitM)
HIP

Propõe uma alternativa de utilizar endereços
IP como “localizador” (marcas de roteamento)
e “identificadores” (identificador do host).
 Introduz um tipo espaço de nomes que
compreende duas principais representações
da identidade do host que são:


Host Identity (HI): chave pública que representa
diretamente a identidade do host
Host Identity Tag – HIT: Representação operacional
(associação), que servirá para gerir o
estabelecimento do estado ponto a ponto
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
/
/
/
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sistemas de eventos do FUEGO

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.

Eventos do FUEGO

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.
Roteador FUEGO
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

Sistema de mensagens FUEGO
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.

Sistema de mensagens FUEGO
AMME - FUEGO

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.

Serviço de presença - FUEGO
Traduz as notificações para uma
estrutura de dados e filtros de serviços.
 Em cada serviço de presença existem
canais de eventos tais como:

Presença: permite disseminar a informação
de presença e de contexto.
 Mensagens instantâneas.
 Controle de presença: realiza as
subscrições e gerência do serviço.

Exemplo do subcriber - FUEGO
Conclusões
O mecanismo HIP, é uma especificação
eficiente e segura, que pode ser aderida
ás funções de um protocolo de
transporte tal como o UDP e o TCP.
 O Middleware Fuego aproveita todas as
características de mobilidade que o HIP
fornece, criando um esquema de
eventos e mensagens, quando existem
variações no endereçamento IP.

Conclusões

O protocolo SCTP, resolve de maneira similar
ao HIP, os problemas de mobilidade na
camada de transporte. Gera eventos de
associações, permitindo realizar em um
mínimo tempo de handoff a identificação das
variações do endereçamento IP.
 Neste contexto, o Middleware MIP, se
encaixou perfeitamente, por ser um protocolo
orientado a mensagens (eventos), permitindo
diferentes associações em uma conexão.
Bibliografia
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”, draftietf-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.