MOBILIDADE SCTP E HIPMIDDLEWARE MPI E FUEGO

MEng. Néstor Felipe Maya Quintero

Matéria: Computação móvelProfessor: PHD. Markus Endler

Sumário

IntroduçãoMiddleware MPI

Protocolo SCTPFuncionamento básico do MPI

Middleware FUEGOMecanismo HIPFuncionamento 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 mobilidadeMulti-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 UDPFunçã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 mensagensServiç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 filtrosPublishers: 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ógicoArmazenagem dos filtrosCoincidência das notificaçõesOperações de gerenciamentoFornecer 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”, 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.