1

Novas Propostas para Protocolos de Streaming

Cesar Henrique Pereira Ribeiro

Escola de Engenharia – Universidade Federal Fluminense (UFF)

Rua Passo da Pátria, 156 – Niterói – RJ – Brazil

cesarhpribeiro@yahoo.com.br

Resumo. Este trabalho tem como objetivo descrever as características principais de alguns protocolos de streaming já consolidados e apresentar novos protocolos que surgem como evolução dos protocolos anteriores, adaptados às novas necessidades de comunicação multimídia como mobilidade e convergência.

1. Introdução Streaming introduz uma nova forma de consumir mídia pela Internet, ele permite que se use um arquivo de mídia enquanto ele está sendo transmitido, não precisando esperar que o arquivo inteiro seja recebido. Os dados transmitidos pela Internet são tocados nos players e depois descartados.

Streaming só é possível graças aos diferentes componentes de software que se comunicam em diversos níveis. Um sistema básico de streaming tem três componentes principais:

• Player: O software que permite aos usuários consumirem os arquivos multimídia;

• Servidores: O software que distribui os conteúdos para os usuários;

• Encoders: O software que converte o conteúdo de áudio e vídeo nos formatos que podem ser distribuídos através de streaming.

Estes componentes devem se comunicar em diferentes níveis. Protocolos, formatos de arquivos e codecs providenciam o framework básico para esta interação:

• Protocolos: Definem as regras básicas de como os dados serão trocados entre os componentes;

• Formatos de arquivos: O modo padronizado em que estes dados são trocados;

• Codecs: Usados para codificar/decodificar os dados contidos dentro dos arquivos.

Este trabalho utiliza como base o trabalho realizado no primeiro semestre de 2006 [1] e tem como objetivo apresentar os novos protocolos de streaming MMTP (Multimedia Multiplexing Transport Protocol) e SCTP (Stream Control Transmission Protocol) fornecendo suas característricas mais importantes e inovadoras em relação aos protocolos de streaming já consolidados.

2

O restante do texto está organizado como se segue. Na seção 2 são descritos os protocolos de streaming já consolidados. A seção 3 detalha algumas os protocolos de streaming MMTP e SCTP. A seção 4 faz uma comparação entre os protocolos detalhados e a conclusão é apresentada na seção 5.

2. Protocolos de Streaming Consolidados 2.1. Real-Time Streaming Protocol (RTSP) O Real Time Streaming Protocol (RTSP) [2] é um protocolo do nível de aplicação desenvolvido pela IETF em 1998 com a RFC 2326 [3] para controle na transferência de streamings de mídia armazenada. O RTSP torna possível a transferência, sob demanda, de dados em tempo real como áudio e vídeo. Ele serve para estabelecer e controlar um único ou vários fluxos sincronizados de mídias contínuas pertencentes a uma apresentação.

As funcionalidades do RTSP permitem que um usuário controle o fluxo de mídia através de comandos de:

• pausa e reinício;

• retrocesso e avanço rápidos;

• reposicionamento da reprodução. O RTSP não define um protocolo de transporte a ser utilizado. De forma análoga ao FTP, o RTSP abre uma conexão de controle paralela às conexões usadas para as transmissões de mídias, por esse motivo o RTSP é chamado de protocolo fora de banda. A banda é considerada como sendo o canal de transmissão da mídia.

A figura 1 ilustra uma sessão RTSP. Cada sessão possui um identificador atribuído pelo servidor. O cliente inicia a sessão RTSP com uma requisição de SETUP ao passo que o servidor a responde com um identificador (requisição RTSP SETUP). O cliente então fornecerá esse identificador para cada requisição que fizer até que feche a sessão com uma requisição TEARDOWN. O início da transmissão da mídia acontece quando o cliente envia uma requisição de RTSP PLAY e é finalizado com uma requisição TEARDOWN.

3

Figura 1. Fluxo de Mensagens RTSP

Segue abaixo um exemplo de troca de mensagens RTSP: C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK

3.2. Real-Time Protocol (RTP) O Real-Time Protocol (RTP) [1] é definido na RFC 1889 [4] e especifica uma estrutura de transporte de dados de áudio e vídeo. O RTP foi projetado para ser uma extensão do protocolo de transporte UDP, como mostrado na figura 2, sendo sua contribuição mais importante a introdução das marcas de tempo e dos números de seqüência, essenciais para o sincronismo, ordenação e identificação de perdas de pacote.

4

Figura 2. RTP na Pilha de Protocolos

O cabeçalho RTP indica o tipo de codificação de áudio ou vídeo em cada pacote, os transmissores podem mudar a codificação durante a conferência. O cabeçalho RTP também contém os números de seqüência e marcas de tempo.

O RTP não fornece nenhum mecanismo para assegurar a entrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidade de serviço. A fim de fornecer QoS para uma aplicação, a Internet deve prover um mecanismo, tal como o RSVP, para que a aplicação possa reservar recursos da rede.

O RTP permite atribuir a cada fonte (por exemplo, uma câmera ou um microfone) o seu próprio fluxo de pacotes RTP independente. Por exemplo, para uma videoconferência entre dois participantes, quatro fluxos RTP poderiam ser abertos: dois fluxos para transmitir o áudio (um em cada direção) e dois fluxos para o vídeo (novamente, um em cada direção). Contudo, algumas técnicas de codificação populares, incluindo MPEG1 e MPEG2, reúnem o áudio e o vídeo num único fluxo durante o processo de codificação. Quando o áudio e o vídeo são reunidos pelo codificador, então apenas um fluxo RTP é gerado em cada direção. Para uma sessão multicast do tipo muitos-para-muitos, todos os transmissores e receptores tipicamente enviam seus fluxos RTP na mesma árvore de multicast com o mesmo endereço de multicast.

A figura 3 ilustra o cabeçalho RTP e fornece uma breve explicação sobre os seus campos.

Figura 3. Cabeçalho RTP

Tipo de Carga

Nº de Seq.

Marca de Tempo

Identificador Sinc. Fonte

Outros Campos

5

• Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado no momento. Se um transmissor muda o tipo de codificação durante uma conferência, o transmissor informa o receptor através deste campo de tipo de carga.

•Tipo de carga 0: PCM mu-law, 64 Kbps

•Tipo de carga 3, GSM, 13 Kbps

•Tipo de carga 7, LPC, 2.4 Kbps

•Tipo de carga 26, Motion JPEG

•Tipo de carga 31. H.261 •Tipo de carga 33, MPEG2 video

• Número de Seqüência (16 bits): O número de seqüência é incrementado de um a cada pacote RTP enviado; pode ser usado para detectar perdas de pacotes e para recuperar a seqüência de pacotes.

• Campo de marca de tempo (32 bits): Reflete o instante de amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada do relógio de amostragem no transmissor.

Como exemplo, para aúdio o relógio de marca de tempo incrementa de um a cada intervalo de amostragem (por exemplo, cada 125 us para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio geram blocos contendo 160 amostras codificadas, então a marca de tempo do RTP aumenta de 160 para cada pacote RTP quando a fonte está ativa. O relógio de marca de tempo continua a aumentar numa taxa constante mesmo quando a fonte está inativa.

• Campo SSRC (identificador de sincronismo fonte) (32 bits): Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter um SSRC distinto.

4. Novos Protocolos de Streaming

4.1. Multimedia Multiplexing Transport Protocol (MMTP) O MMTP [5] é um protocolo projetado para a transferência de dados multimídia em sistemas móveis. Ele faz uso simultâneo de todos os canais de comunicação disponíveis para enviar os dados a taxa requerida. A transmissão no MMTP é controlada através de dois mecanismos. O primeiro é um conjunto de protocolos de controle associado a cada canal de saída. O segundo é um algoritmo que encaminha os pacotes que chegam para o canal de comunicação apropriado.

O objetivo do MMTP é agregar todos os canais de comunicação disponíveis para os dispositivos móveis e fornecer à aplicação um único canal virtual, independente das tecnologias de enlace utilizadas em cada canal individual. O MMTP é um protocolo baseado em taxa que utiliza a largura de banda e a estimativa do atraso nos canais para determinar a largura de banda disponível e realizar o controle de congestionamento. Ele

6

fornece à aplicação as informações necessárias para a adaptação de taxa de envio do conteúdo. A função principal do MMTP é decidir por qual canal transmitir cada pacote.

Ao longo da comunicação, podem ocorrer alterações na disponibilidade de cada canal individual. O MMTP adapta a fração do fluxo enviado para cada canal de acordo com as alterações ocorridas. Ele também é capaz de adicionar ou remover canais caso seja necessário. Se a agregação dos canais não fornecer largura de banda suficiente para a transmissão do fluxo da aplicação, o MMTP descarta os pacotes que ele estima que não chegariam a aplicação e informa a aplicação sobre a falta de recursos.

O uso do MMTP provê cinco benefícios principais:

1 – Maior largura de banda para a aplicação, permitindo melhor qualidade do tráfego multimídia;

2 – Utiliza o canal com menor atraso de propagação para a troca de mensagens de controle;

3 – A largura de banda extra de qualquer canal pode ser utilizada para a retransmissão de pacotes perdidos selecionados, sem afetar o stream principal sendo transmitido;

4 – Com o uso de múltiplos canais o MMTP é menos sensível a flutuação de banda de um canal individual;

5 – O uso de múltiplos canais de dados torna natural o handoff de conexões.

No início da comunicação, o MMTP descobre os canais de comunicação disponíveis e estima o atraso de propagação e a taxa de pacotes de cada um. Para saber se a taxa solicitada pela aplicação está disponível, o protocolo calcula a taxa agregada dos canais. Existem dois casos:

• Largura de banda solicitada > ∑ largura de banda agregada disponível: Neste caso, o MMTP notifica à aplicação que os pacotes serão descartados. A aplicação pode então decidir se aborta a transmissão, modifica a taxa ou continua normalmente.

• Largura de banda solicitada < ∑ largura de banda agregada disponível: Neste caso, o MMTP notifica à aplicação que existe largura de banda suficiente para a transmissão dos dados na taxa solicitada.

Existe um parâmetro denominado “atraso inicial” que informa à aplicação

receptora quanto tempo esperar antes de executar o primeiro pacote. O atraso inicial é escolhido entre o atraso inicial máximo dado pela aplicação e o mínimo atraso inicial calculado pelo protocolo usando os atrasos de propagação dos links ativos. Quanto maior o atraso inicial, mais recursos o protocolo tem para compensar a variação do atraso. A aplicação receptora irá buferizar um número de pacotes proporcional a razão entre o atraso inicial e o período do pacote antes de iniciar a execução.

O atraso inicial é sempre maior ou igual ao maior atraso de propagação entre os canais que estão sendo usados e não depende de que canal é usado para o envio do primeiro pacote. A figura 4 ilustra o comportamento inicial assumindo dois canais e um pacote por frame. O primeiro gráfico mostra o atraso inicial quando o pacote é enviado pelo canal de maior atraso de propagação e o segundo ilustra a situação inversa. Nos dois exemplos, o transmissor recebe o pacote 0 no tempo t e o pacote 1 no tempo t +

7

1/(taxa de pacote). No primeiro gráfico, o primeiro pacote foi enviado pelo canal de maior atraso de propagação, logo a execução pode iniciar assim que o pacote 0 foi recebido, pois sabemos que o pacote 1 já terá chegado após a execução do pacote 0. Se os atrasos de propagação dos dois canais forem muito diferentes, é possível que o pacote 1 chegue antes do pacote 0. Nesta situação, devemos buferizar o pacote 1 e novamente iniciar a execução após o recebimento do pacote 0. No segundo gráfico, o pacote 0 chega primeiro, mas deve haver um retardo na execução até que o pacote 1 chegue, para não haver nenhum gap no final da execução do pacote 0.

Como o MMTP usa estimativas tanto para a largura de banda quanto para o atraso de propagação, é difícil implementar a opção 2, pois o atraso inicial depende diretamente do valor estimado para o atraso de propagação em ambos os canais. Enviar o primeiro pacote no canal com o maior atraso de propagação permite que a execução seja automática.

Figura 4. Comunicação MMTP

O controle de fluxo no MMTP pode ser modelado como um conjunto de protocolos de controle, uma para cada canal, todos servindo a uma fila única. Tokens são gerados para cada canal baseados na estimativa da largura de banda disponível e rotulados com a estimativa dos atrasos de propagação. Pacotes são inseridos na fila à taxa de pacotes da fonte e precisam ser transmitidos por um dos canais disponíveis. Pacotes são transmitidos em um canal se existir um token e se o atraso de propagação garantir que o pacote chegará em tempo. Tokens são usados para cada transmissão em um canal e novos tokens não são gerados em quanto os mais velhos não forem usados.

Quando um pacote chega para ser transmitido pelo MMTP, existem três possibilidades:

1- Não há token disponível: o frame tem que esperar até que um token que possa entregar o frame a tempo seja gerado em um canal. Se nenhum token for gerado antes do tempo de entrega do frame expirar, o frame é descartado;

2- Exatamente um token está disponível: se o canal correspondente puder entregar o frame a tempo, o pacote é enviado. De outra forma, o pacote espera como no caso 1;

8

3- Múltiplos tokens estão disponíveis: se mais de um canal puder entregar o pacote, o canal com maior atraso de propagação é escolhido. Manter o canal com o maior tempo de propagação em uso possibilita a criação de um rápido caminho de resposta. Se nenhum canal puder entregar o pacote a tempo, o frame espera como no caso 1.

Mesmo se nenhum dos canais disponíveis atualmente puder enviar os frames, os frames enfileirados ainda podem ser transmitidos se um canal com o menor tempo de propagação for adicionado ou ocorrer uma diminuição no tempo de propagação em um dos canais disponíveis que permita a entrega em tempo dos pacotes ao destino.

No MMTP o controle de congestionamento é implementado de maneira reativa baseado na estimativa da largura de banda. Tanto o atraso de propagação quanto largura de banda disponível em um canal irão variar de acordo com as mudanças de roteamento e interferências causadas por outros tráfegos ao longo do caminho.

A largura de banda disponível é igual a diferença entre a largura de banda máxima de cada enlace e o uso de cada enlace.

O atraso de propagação é composto por duas partes: o atraso de propagação atual dos bits nas linhas de transmissão somado ao tempo gasto durante o processamento em cada roteador ao longo do caminho. A primeira parte é constante na ausência de mudança das rotas, mas a segunda varia de acordo com as filas nos roteadores ao longo do caminho.

Para evitar congestionamento, o protocolo tenta manter a largura de banda solicitada abaixo da largura de banda disponível em um canal. Isto é feito através da medição da largura de banda disponível e da mudança da taxa de pacotes enviados a uma taxa compatível com a largura de banda disponível. A largura de banda disponível é estimada pela medição do intervalo entre chegadas dos frames nos receptor. Como pacotes são enviados em intervalos regulares em cada canal, o intervalo entre frames deve convergir ao período de frames sendo enviados naquele canal se largura de banda suficiente estiver disponível. Se o intervalo entre frames começar a crescer, em algum lugar do caminho um roteador está funcionando acima da sua capacidade de encaminhamento e está enfileirando os pacotes.

4.2. Stream Control Transmission Protocol (SCTP)

O SCTP é um novo protocolo de transporte, projetado para oferecer serviço confiável e orientado à conexão com desempenho superior ao TCP. Ele foi desenvolvido pelo IETF (Internet Engineering Task Force) SIGTRAN Workgroup e suas especificações estão contidas na RFC 2960 [6].

O SCTP pode ser visto como uma “evolução” do TCP. Qualquer aplicação que utilize o TCP pode utilizar o SCTP com desempenho resultante igual ou melhor que antes. A figura 5 ilustra o SCTP na pilha de protocolos. A arquitetura em camadas permite a troca do TCP pelo SCTP de forma transparente para a camada de aplicação. Todas as portas reservadas pelo IANA ao TCP são automaticamente reservadas ao SCTP.

9

Figura 5. SCTP na Pilha de Protocolos

As principais características que tornam o SCTP o protocolo mais adequado para o transporte de sinalização e de aplicações que requerem confiabilidade e desempenho são:

- Associação

Assim como o TCP, o SCTP provê um serviço de transporte confiável, assegurando que todos os dados serão transportados sem erros. O SCTP é um protocolo orientado a conexão, significando que um relacionamento é criado entre pontos terminais numa sessão SCTP antes que os dados sejam transmitidos. O SCTP usa o conceito de associação, que é mais amplo que a conexão TCP. Este relacionamento é mantido até que toda a transmissão de dados seja concluída com sucesso.

- Múltiplos Fluxos (Multi-Streaming):

Existem diferenças básicas entre a conexão TCP e a associação SCTP. Uma conexão TCP estabelece apenas um único fluxo full-duplex. Uma associação SCTP estabelece um número arbitrário de fluxos simplex. Para simular uma conexão TCP, basta criar um fluxo SCTP em cada direção. Isto permite que os dados sejam divididos em fluxos independentes. A perda de uma mensagem afetará a transmissão apenas do fluxo a que ela está associada.

Quando uma associação é estabelecida, o número de fluxos por direção é negociado entre os pontos terminais. Para cada fluxo, o SCTP associa um SSN (Stream Sequence Number) independente. Estes números são usados pelo receptor para determinar a seqüência correta da entrega. O SCTP realiza o controle da ordenação de pacotes por fluxo. Isto impede que perdas de pacotes em um fluxo afetem os outros fluxos da associação.

- Prioridade

O SCTP permite que se dê prioridade a datagramas que serão enviados à aplicação antes dos outros. Isto deve ser usado para mensagens importantes que devem ser processadas antes das outras, como por exemplo um comando de cancelamento para uma aplicação.

10

- Múltiplos Endereços (Multi-Homing):

Outra característica fundamental é a possibilidade de um ponto terminal ter múltiplos endereços IP. O maior benefício desta propriedade é a possibilidade de se manter uma sessão mesmo com falhas na rede. Em sessões tradicionais, a falha em uma rede local pode isolar o sistema final ou falhas na rede principal podem causar indisponibilidade temporária até que os protocolos de roteamento contornem o problema.

No SCTP um único endereço é escolhido como primário e é usado como destino em comunicações normais. Os dados retransmitidos usam os endereços alternativos. Caso o problema persista, todas as mensagens serão transmitidas pelos endereços alternativos. Na forma atual do protocolo, esta característica é usada apenas para fins de redundância e não para balanceamento de carga. Os pontos terminais SCTP trocam listas de endereços durante o início da associação. Uma única porta é usada por todos os endereços da lista num ponto terminal para uma associação específica

- Orientação a Mensagens

O TCP é orientado a octetos (bytes), o que significa que ele não possui nenhuma forma de reconhecer o início e o fim de mensagens individuais. Desta forma, todo o fluxo de dados é gerenciado da mesma maneira.

O SCTP é orientado a mensagens. Várias mensagens diferentes podem ser enviadas em um único segmento SCTP. Cada mensagem é denominada uma fatia (chunk) em um datagrama SCTP. O número total de fatias depende do tamanho das fatias e da MTU ao longo do caminho. A confirmação é realizada por fatia (mensagem).

Para mostrar a diferença entre as duas abordagens, o exemplo da figura 6 ilustra um cliente realizando a requisição de vários arquivos de um servidor.

A 6 (a) mostra o que acontece quando os três arquivos estão usando a mesma conexão TCP: se o primeiro segmento for perdido, mesmo que o segundo e o terceiro cheguem corretamente ao cliente, não poderão ser entregues para a camada superior, pois os dados devem ser enviados na ordem correta. Isto é conhecido como Head-Of-Line (HOL) blocking problem. A figura 6 (b) mostra o caso em que é aberta uma conexão independente por arquivo, que é finalizada assim que a transmissão do arquivo termina. Esta forma de conexão não é afetada pelo Head-Of-Line (HOL) blocking problem e a perda de um segmento de um arquivo não influencia na entrega dos outros arquivos para a camada superior. De qualquer forma, a comunicação sofre com os atrasos envolvidos no estabelecimento e encerramento das diversas conexões TCP, além dos recursos consumidos por permitir diversas conexões TCP entre os mesmos sistemas finais. Isto impacta o número de clientes que um servidor pode atender simultaneamente.

A figura 6 (c) mostra a forma como o SCTP resolve este problema. Ele usa uma única associação com diferentes fluxos (streams) para diferentes arquivos. Desta forma o servidor pode economizar recursos, tendo apenas uma associação por cliente. Outra vantagem é que não há mais os atrasos envolvidos no estabelecimento das várias conexões TCP. Além disso, como todos os fluxos pertencem à mesma associação, todos eles compartilham os mesmos mecanismos de controle de congestionamento. Com o uso de diversas conexões TCP, nenhuma sabe da existência da outra e agem como se só

11

houvesse a sua conexão na rede. Isto torna o controle de congestionamento menos efetivo.

Figura 6. Comparação da Conexão TCP com a Associação SCTP

Um exemplo do uso do SCTP é utilizar uma única associação para gerenciar e controlar várias ligações telefônicas, mesmo que algumas destas ligações sofram atrasos ou perdas, cada ligação é tratada como um fluxo independente dentro da associação, o que faz com que as outras não sejam afetadas.

- Fragmentação Adaptativa O SCTP fragmenta os pacotes de acordo com a MTU descoberta no caminho. A técnica utilizada está descrita na RFC 1191 - Path MTU Discovery.

- Taxa Adaptativa

O SCTP adapta-se às variações de taxa de transmissão da rede. Ele utiliza os mesmos mecanismos do TCP (partida lenta e controle de congestionamento).

12

A figura 7 ilustra o formato do pacote SCTP.

Figura 7. Formato do Pacote SCTP

A PDU SCTP é composta de um cabeçalho comum e fatias (chunks) de dados ou controle.

- Cabeçalho Comum:

O cabeçalho comum consiste de 12 octetos. Para a identificação de uma associação o SCTP usa o mesmo conceito de porta no TCP e UDP. Para a detecção de erros na transmissão, cada pacote é protegido por um checksum de 32 bits (algoritmo Adler-32) que é mais robusto que a soma de controle de 16 bits do TCP ou UDP. Pacotes com somas de controle inválidas são descartados. O cabeçalho comum também contém um rótulo de verificação (verification tag) de 32 bits. Este é específico da associação e é trocado entre as entidades no começo da associação.

- Fatias (Chunks):

Cada fatia se inicia com um campo de tipo que é usado para distinguir fatias de dados ou controle, seguido por flags específicos e pelo campo de tamanho, necessário já que elas têm tamanho variável. As fatias de dados contém campos adicionais com o número de sequência (Transmission Sequence Number – TSN) e de identificação do stream.

13

A figura 8 ilustra as fatias definidas pelo padrão.

Fatia (Chunk) Definição INIT Enviado para se iniciar a associação entre dois pontos terminais.

INIT ACK Reconhece o recebimento do INIT. O recebimento do INIT ACK estabelece a associação.

SACK Reconhece o recebimento de fatias de dados. COOKIE ECHO Usado exclusivamente durante o processo de iniciação.

COOKIE ACK Reconhece o recebimento do COOKIE ECHO. Ele deve preceder qualquer fatia de dados.

HEARTBEAT Enviado de forma a testar a conectividade de um endereço específico na associação.

HEARTBEAT ACK Enviado para reconhecer o recebimento do HEARTBEAT.

ABORT Indicação para se fechar uma associação. Informa a razão do fim da associação através de seus parâmetros.

ERROR Usado para reportar, através de seus parâmetros, o tipo de erro que possa ter ocorrido.

SHUTDOWN Usado para fechar uma associação. SHUTDOWN ACK Acusa o recebimento do SHUTDOWN. SHUTDOWN COMPLETE Conclui o procedimento de fechamento da associação.

Figura 8. Fatias definidas pelo padrão

14

Fases Principais de uma Associação

Serão descritos a seguir as três principais fases do processo de associação. O ponto terminal que inicia a associação será denominado nó A e o que recebe o pedido de estabelecimento de uma associação será o nó B. Vale lembrar que as fatias de controle ERROR e ABORT podem ser gerados por qualquer nó a qualquer momento durante a associação.

Iniciação:

Figura 9. Início da Associação SCTP

1. O nó A gera um INIT e o envia ao nó B. O nó A inicia o temporizador do INIT.

2. Se o nó B quiser aceitar a associação, ele gera um INIT ACK que inclui um cookie.

3. O nó A recebe o INIT ACK e pára o temporizador do INIT. Ele gera um COOKIE ECHO e o envia ao nó B, iniciando o temporizador do cookie. Dados também podem ser inseridos neste pacote.

15

4. O nó B verifica a validade do cookie. A seguir ele envia um COOKIE ACK ao nó A.

5. O nó A recebe o COOKIE ACK e começa a próxima fase de transmissão de dados.

Transmissão de Dados:

Figura 10. Transmissão de Dados

Durante todo o processo de transmissão, HEARBEAT e HEARTBEAT ACK são trocados entre os nós em intervalos de tempo regulares. Estes testam a conectividade entre os pontos terminais preservando a validade da transmissão de dados.

6. Os nós A e B trocam fatias de dados.

7. Após o recebimento de cada fatia de dados, os pontos terminais retornam SACK para acusar o recebimento.

8. Dados são transmitidos até que um ponto terminal decida por encerrar a associação pelo envio de uma fatia SHUTDOWN

16

Encerramento:

Figura 11. Encerramento da Associação SCTP

O SHUTDOWN pode ser enviado por qualquer um dos nós.

9. O nó A envia um SHUTDOWN e inicia o temporizador.

10. O nó B recebe o SHUTDOWN e envia o SHUTDOWN ACK.

11. Nó A recebe o SHUTDOWN ACK e interrompe o temporizador. Gera então um SHUTDOWN COMPLETE que é enviado ao nó B.

17

5. Comparação entre os Protocolos Os protocolos Multimedia Multiplexing Transport Protocol (MMTP) e Stream Control Transmission Protocol (SCTP) otimizam a comunicação de dados streaming através de técnicas distintas.

O MMTP faz uso simultâneo de todos os canais físicos de comunicação disponíveis, fornecendo para a aplicação um único canal virtual. O aumento do desempenho da comunicação streaming é obtido devido ao aumento da largura de banda disponível para a troca de dados entre o servidor e o cliente.

O SCTP utiliza um único canal físico (mais de um pode ser utilizado, mas apenas para alta disponibilidade e não para balanceamento de carga). A comunicação é dividida em vários fluxos. O aumento da performance vem do fato de cada fluxo ser tratado de forma independente. Assim, a perda de pacotes ou atrasos em um fluxo não afetam a comunicação dos outros fluxos. Como todos os fluxos pertencem à mesma associação SCTP, não há atrasos no estabelecimento das diversas conexões (como ocorre no TCP) e também os controles de fluxo e congestionamento podem ser implementados de forma mais eficiente.

Ambos os protocolos fornecem alta-disponibilidade para a aplicação. O MMTP ao utilizar todos os canais disponíveis permite que o fluxo de dados continue mesmo com falha em um dos canais de comunicação. O SCTP por ser multi-homing permite em um host com múltiplas placas de rede que a comunicação seja encaminhada por enlaces secundários em caso de falha no enlace principal.

A tabela 1 sumariza as características dos protocolos detalhados.

Tabela 1. Comparação entre os Protocolos

Característica MMTP STCP Descarte de Quadros seletivo seletivo Retransmissão de Quadros seletiva seletiva Confiabilidade não-confiável confiável Reconhecimentos ACKs Controle de Congestionamento descarte seletivo Descobre MTU Mínimo não sim Multi-Homing sim sim Comunicação ponto-a-ponto ponto-a-ponto Envio de Pacotes Redundantes não não Protocolo de Transporte MMTP SCTP

Fluxo de Streaming full-duplex uFluxos Simplex Independentes

em Ambas as Direções Qtde. de fontes única Única

18

6. Conclusão A medida que aumenta a demanda e o consumo de dados para streaming, surgem novos desafios como mobilidade, alta-disponibilidade e convergência. Para superar estes desafios, novos protocolos de streaming são desenvolvidos com o objetivo de otimizar a comunicação de dados de acordo com as características do meio-físico e com as necessidades das aplicações utilizadas.

Este trabalho discutiu os protocolos MMTP e SCTP e apresentou suas principais características e inovações.

7. Referências [1] Almeida, Luiz (2006) – “Novas Propostas para Protocolos de Streaming”. Escola de Engenharia – Universidade Federal Fluminense (UFF)

[2] Kurose, James F. and Ross, Ketith W. “Computer Networking – A Top-Down

Approach Featuring the Internet”, second edition- Addisson Wesley.

[3] RFC 2326

[4] RFC 1889

[5] Magalhães, Luiz. Kravets, Robin. (2001). “ MMTP – Multimedia Multiplexing

Transport Protocol”. Workshop on data communication in Latin America and the

Caribbean. (SIGCOMM-LA 2001)

[6] RFC 2960