MOBILIDADE SCTP E HIP MIDDLEWARE MPI E FUEGO
description
Transcript of MOBILIDADE SCTP E HIP MIDDLEWARE MPI E FUEGO
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.