sistemas multimÍdia - joinville.udesc.br osi 3/44. sistemas multimídia ... •operação plug and...

Sistemas Multimídia 2011/2

UDESC

SISTEMAS MULTIMÍDIA

Prof. Claudinei Dias

Capítulo 4 – Redes IP e o Transporte

de Dados Multimídia

http://www.udesc.br/


UDESCEmenta Cap. 4

• 4. Redes IP e o Transporte de Dados Multimídia

– A arquitetura Internet;

– Protocolo IP e a multimídia;

– Requisitos para protocolos de transporte;

– Protocolo TCP;

– Protocolo UDP.

2/44



UDESCArquitetura TCP/IP

• Nível de Aplicação

• Oferece ao usuário acesso aos serviços da internet– Web (HTML/HTTP)

– Correio Eletrônico (SMTP/POP)

– Conexão Remota (Telnet)

– Transferência de arquivos (FTP)

– Real-Time Transport Protocol (RTP)

– Multimedia Messaging Service (MMS)

7. Aplicação

6. Apresentação

5. Sessão

4. Transporte

3. Rede

2. Enlace

1. Física

Modelo OSI

3/44



UDESC

• Nível de Transporte

• Transmission Control Protocol(TCP)– Multiplexação e Demultiplexação (Portas)– Fornece comunicação confiável– Sequenciamento de Pacotes– Controle de fluxo e congestionamento

• User Datagram Protocol (UDP)– Multiplexação e Demultiplexação (Portas)

– Serviço sem confiabilidade

7. Aplicação

6. Apresentação

5. Sessão

4. Transporte

3. Rede

2. Enlace

1. Física

Modelo OSI

Arquitetura TCP/IP

4/44



UDESC

• Nível de Rede

• Internet Protocol (IP)– Serviço de comunicação sem

conexão, baseado em comutação de pacotes

• Mecanismo de roteamento de mensagens– Encaminha os datagramas do nó

fonte para o nó destino

– Utiliza protocolos de roteamentoque atualizam as tabelas de roteamento nos nós intermediários (roteadores)

7. Aplicação

6. Apresentação

5. Sessão

4. Transporte

3. Rede

2. Enlace

1. Física

Modelo OSI

Arquitetura TCP/IP

5/44



UDESC

• Nível de Enlace e Físico

• Não são definidos padrões específicos na arquitetura da internet

• Objetivo é acomodar diversos tipos de redes existentes

– Possibilidade de usar padrões de redes locais ou protocolos personalizados

7. Aplicação

6. Apresentação

5. Sessão

4. Transporte

3. Rede

2. Enlace

1. Física

Modelo OSI

Arquitetura TCP/IP

6/44



UDESCProtocolo IP e Multimídia

• IPv4

– Amplamente usado nas redes atuais

– Endereços de rede de 32-bits

– IPv4 Multicast

• Extensão do IPv4 para suportar multicast

• IPv6

– Evolução do IPv4, introduz novas características

– Endereços de rede de 128-bits

7/44

Vídeo Warriors Of The Net - http://www.youtube.com/watch?v=tFKVFWfC2nk&feature=related



UDESCProtocolo IP e Multimídia

• Protocolo IP oferece serviço de “melhor esforço”

• Problema?

– Não garante vazão, atraso, variação de atraso e taxa de perda de pacotes

– Não garante qualidade de apresentação de áudio e vídeo

– No caso de sobrecarga da rede, pacotes podem ser descartados

• Geralmente ocorre nas filas dos roteadores

8/44



UDESCIP Multicast

• Suportado no IPv4 (extensão)

• Permite o envio de datagramas IP para um conjunto de máquinas

– Grupo multicast é identificado por um endereço IP

• Existe uma distinção dos pacotes unicast e multicast

– Roteador distingue os tipos de pacotes olhando no formato do endereço de destino

– Pacotes Multicast: 4 primeiros bits do endereço IP tem o valor “1110” (classe D), demais bits identificam o grupo multicast

9/44



UDESCIPv6

• Proposto em 1992 pelo Internet Engineering Task Force– Motivação: espaço de endereçamento disponível no IPv4 terminaria

no início do século 21

• Projetado para melhorar o IPv4– Aumento do espaço de endereçamento

– Autenticação

– Criptografia

– Extensões para fluxos de dados multimídia

• Compatibilidade com o IPv4– Uma das metas principais do projeto IPv6

– Hosts e roteadores IPv6 são capazes de co-existir com hosts IPv4

• Migração gradativa

10/44



UDESCIPv6 - Características

• IPv6 se baseia nos principais paradigmas do IPv4

– Sem conexão, sem controle de erro e de fluxo na camada de rede

– Oferece serviço de “melhor esforço”

• Suporte a bilhões de hosts

– Expansão do espaço de endereçamento (128 bits)

– Mais níveis de hierarquia

11/44




• Permissão de multicast

– Campo scope no endereçamento limita o seus domínio de validade

• Redução da tabela de roteamento e melhoria no roteamento

– Inclusão de hosts móveis

• Extensibilidade através do uso dos cabeçalhos de extensão

12/44




• Identificação dos pacotes de um mesmo fluxo (campo flow)

• Fluxo é uma sequencia de pacotes enviados por um host para um endereço unicast ou multicast

• Todos os roteadores podem identificar os pacotes de um fluxo e tratá-los de modo específico

– Exemplo: priorizar pacotes de áudio sobre pacotes de transferência de arquivos

13/44



UDESCIPv6 – Novas Características

• Simplificação do cabeçalho do protocolo

– Diminuição do tempo de processamento na análise dos cabeçalhos

• Garantia de mais segurança

– Autenticação e criptografia

• Recursos para mobilidade em redes IP

• Operação plug and play

– Habilidade dos nós se auto configurarem ao serem ligados na rede

• Novo tipo de endereço: anycast

– Identifica um grupo de nós

– O pacote enviado será entregue a um destes nós do grupo

14/44



UDESCRequisitos para Protocolos de Transporte Multimídia

• Quais são os requisitos básicos para um protocolo de transporte, visando Sistemas Multimídia?

– Abstrair as funções e serviços oferecidos pelos níveis de enlace e físico

– Alta vazão

– Suporte multicast

15/44




• Alta Vazão

• Dados multimídia necessitam de grande largura de banda– Vídeo de qualidade compactado necessita de 1,4 à 8 Mbps (ou mais)

• Requisitos de vazão do ponto de vista da aplicação?– Todos os dados passam pela pilha de transporte.

– Qual(is) seria(m) o(s) requisito(s)?

• Protocolo de transporte deve ser rápido o suficiente para suportar os requisitos de grande largura de banda

– Aplicações podem envolver vários fluxos de dado.

– Qual(is) seria(m) o(s) requisito(s)?

• Velocidade do protocolo de transporte deve ser maior que a largura de banda agregada dos fluxos

16/44




• Alta Vazão

• Requisitos do ponto de vista do sistema de comunicação?

– Vazão de um protocolo de transporte deve ser maior ou próxima a velocidade de acesso a rede

– Senão a largura de banda fornecida pelos pontos de acesso a rede não poderiam ser inteiramente usados• Protocolo de transporte seria o gargalo no sistema de

comunicação

17/44




• Multicast

• Muitas aplicações multimídia exigem multicast

– Sistema de transporte deve fornecer capacidades multicast

• Multicast é implementado na camada de rede

– Muitos sistemas de transporte multimídia usam o algoritmo IP multicast

– Ou assumem a existência de certos algoritmos de roteamento multicast

18/44



UDESCProtocolo TCP

• Projetado para comunicação de dados confiável em redes de baixa largura de banda e altas taxas de erro

• Problema?– Não é otimizado para operações de alta velocidade

– Não fornece suporte a multicast

– Não atende todos os requisitos para comunicações de vários tipos de aplicações multimídia

• TCP possui aspectos indesejáveis para multimídia.

• Quais?– Controle de erro

– Controle de fluxo e de congestionamento

– Não suporte a multicast

19/44



UDESCProtocolo TCP: Controle de Erro

Porta Origem Porta Destino

Número da Seqüencia

Número do Acknowledge

JanelaTam.Cab. Res. Code Bits

Checksum Urgência

Opções Padding

Dados

...

20/44



UDESCProtocolo TCP: Controle de Erro

• Quando um nó transmite um segmento, ele:

– Coloca uma cópia do segmento em uma fila de retransmissão e dispara um temporizador

– Caso o reconhecimento do segmento é recebido, o segmento é retirado desta fila

– Caso o reconhecimento não ocorra antes do temporizadorexpirar, o segmento é retransmitido

21/44



UDESCCenários de Retransmissão

Host A Host B

PerdaXti

meo

ut

Ack Perdido

22/44



UDESCCenários de Retransmissão

Host A Host BSe

q=9

2 t

imeo

ut

Seq

=10

0 t

imeo

ut

Timeout prematuro,Ack acumulativo

23/44



UDESCControle de Erro e Multimídia

• Retransmissão não é ideal para várias aplicações multimídia

• Porque?– Protocolo fica complicado e lento

• Implementação de estratégias de retransmissão necessitam de temporizadores e buffers maiores

– Retransmissão causa atrasos para os dados subsequentes

• Mais dados sem utilidade no receptor

– Dados multimídia toleram alguns erros ou perdas

• Aplicável somente em aplicações baseadas em servidor para aumentar a qualidade– Requer tempos de bufferização maiores

24/44



UDESCControle de Erro e Multimídia

• Em várias aplicações multimídia somente a detecção de erros é suficiente– Quando acontecer um erro, a aplicação deveria ser notificada

– Aplicação decide se a retransmissão é necessária

• Retransmissão Seletiva: pacotes perdidos são retransmitidos

• Alternativa: usar codificação Forward Error Correction (FEC)– Não necessita de retransmissão quando erros são detectados

– Envio de informações extras para permitir a correção de erros no receptor

– Problema?

• Consumo adicional de banda

25/44



UDESCRecuperação de Perdas de Pacotes

• Paridade bidimensional

– Paridade tanto da linha como da coluna

– Erro em um único bit pode ser corrigido

101011

111100

011101

001010

Sem erros

101011

110100

011101

001010

Correção do erro de bit

26/44



UDESCRecuperação de Perdas de Pacotes

• Intercalar fluxos de alta e baixa qualidade

– Vantagem?

• Na perda de pacotes, a informação de baixa qualidade é apresentada

– Desvantagem?

• Mau uso da largura de banda

• Perdas em rajada não são bem tratadas

• Como resolver esses problema?

27/44



UDESCEntrelaçamento de Pacotes

• Não tem redundância, mas causa atraso na apresentação

– Exemplo: dividir audio de 20 ms em pacotes de 5 ms, e entrelaçados

28/44



UDESCEntrelaçamento

Vantagem? Reduz perda em rajada

29/44



UDESCProtocolo TCP: Controle de Fluxo

Porta Origem Porta Destino

Número da Seqüencia

Número do Acknowledge

JanelaTam.Cab. Res. Code Bits

Checksum Urgência

Opções Padding

Dados

...

30/44




• Mecanismo usado pelo receptor para determinar o volume de dados que o transmissor envia

– Janela deslizante

• Receptor envia, junto com o acknowledge, o número de bytes que ele ainda pode receber

– Considera-se o último pacote recebido com sucesso

31/44




• Tamanho típico da janela é 64 Kb

• Muito grande para redes lentas– Rede de 64 Kbps leva 8s para transmitir 64kbytes

– Atraso de ida-e-volta normal é muito menor que 8s

– Transmissor receberá um reconhecimento antes de acabar o envio dos bits de uma janela

• Muito pequeno para rede rápidas– Transmissor aguardará muito para receber a permissão de transmissão

– Largura de banda não é inteiramente utilizada

– Transmissor enviará 64 Kbytes em 50 ms na velocidade de 10 Mbps

– Em WAN o atraso ida-e-volta é normalmente muito maior que 50 ms

32/44



UDESCProtocolo TCP: Controle de Congestionamento

• “Excessivo número de fontes enviando uma grande quantidade de dados mais rápido do que a rede pode manipular”

• Conseqüências?

– Pacotes perdidos (overflow dos buffers nos roteadores)

– Grandes atrasos (enfileiramento nos buffers dos roteadores)

• Um grande problema de rede!

33/44




Host A Host BAlgoritmo de Partida Lenta

• Incremento exponencial no tamanho dajanela• Janela aumenta enquanto não houverperda ou o treshold for alcançado• Perda = timeout ou 3 ACKs duplicados

34/44




• Fase de prevenção de congestionamento

– Inicia quando o tamanho da janela ultrapassa o threshold

– A partir daí, a janela cresce linearmente

• Na ocorrência de um timeout

– Valor do threshold é modificado para a metade do valor da janela de congestionamento atual

– Janela de congestionamento atual = número de segmentos permitidos para transmitir quando ocorreu a perda

– Partida lenta é reiniciada

35/44



UDESCPrevenção de Congestionamento

36/44



UDESCProtocolo TCP e Multimídia

• Controle de erros e retransmissão

– Não é interessante para várias aplicações multimídia

• Controle de congestionamento e de fluxo

– Requer que a aplicação se adapte a situação da rede

– Também não é interessante para várias aplicações multimídia• Requer que a rede suporte a taxa de apresentação (+sobrecargas

do protocolo)

• Multicasting

– Não suportado

37/44



UDESCProtocolo UDP

• Não oferece meios que permitam uma transferência confiável de dados

• Não tem controle da taxa de transmissão entre os nós

• Não implementa mecanismos de reconhecimento, de seqüencialização, nem de controle de fluxo das mensagens

38/44



UDESCProtocolo UDP

• Datagramas podem ser perdidos, duplicados, ou entregues fora de ordem ao sistema de destino

• Aplicação assume toda a responsabilidade pelo controle de erros

• Serve para transportar uma mensagem de uma estação para outra, utilizando o IP para enviar e receber estes datagramas

39/44



UDESCProtocolo UDP

• É um protocolo simples – Latência menor

• Usa mais eficientemente a banda da rede– Cabeçalho por segmento é menor

– Sem controle de congestionamento e de fluxo: permite usar a banda de maneira mais eficiente

– Pode provocar taxa de perdas altas e perdas

• Muito usado para aplicações multimídia de streaming– Tolerantes a perda

– Sensíveis a taxa

• Transferência confiável sobre UDP– Adicionar confiabilidade na camada de aplicação

– Recobrimento de erro específico de aplicação

40/44



UDESCProtocolo UDP e Multimídia

• Serviço orientado datagrama simples sem confiabilidade

– Melhor para aplicações multimídia (nem todas!)

• Aplicações podem rodar no topo do UDP com funções adicionais integradas nas aplicações

– Delegando-se às estações o recobrimento das dificuldades que a rede tem quanto a garantias de serviço• Técnicas de bufferização

• Protocolos de transporte melhores adaptados (RTP)

41/44



UDESCProtocolos Application Level Framing (ALF)

• Inclusão de estratégias de controle de fluxo ou retransmissão na aplicação

• Para suportar a interoperabilidade

– Protocolos ALF são definidos pela especificação dos formatos da unidade de dados de protocolo

– Protocolos ALF não definem algoritmos para controle de fluxo e retransmissão• Estes são baseados nos requisitos das aplicações

• RTP é um bom exemplo de projeto de protocolo baseado no ALF

42/44



UDESCBibliografia

• WILLRICH, R. Sistemas Multimídia Distribuídos. Apostila do curso de Especialização em Redes de Computadores, UFSC, agosto, 2004.

• KERLOW, I. V. Art of 3D computer animation and effects , The - 4th ed / c2009

• VELHO, L. Anais do SIBGRPI 96 : IX Simpósio Brasileiro de Computação Gráfica e Processamento de Imagens - 1 ed. / 1996

• AGNEW, P. W.; KELLERMAN, A. S. Distributed Multimedia: Technologies, Applications, andOpportunities in the Digital Information Industry. A Guide for Users and Providers. AddisonWesley, 1996.

• ENGLAND, E.; FINNEY, A.; FINNEY, A. Managing Multimedia. Addison Wesley, 1996.

• GIBSON, J. D.; BERGER, T.; LINDBERGH, D. Digital Compression for Multimedia: Principles andStandards. Morgan Koufman, 1998.

• FLUCKIGER, F. Understanding Networked Multimedia: applications and technology. Prentice Hall, 1995.

• STEINMETZ, R, NAHRSTEDT, R. Multimedia: computing, communications & applications. Prentice Hall, 1995.

43/44



UDESC

SISTEMAS MULTIMÍDIA

Prof. Claudinei Dias

Capítulo 4 – Redes IP e o Transporte

de Dados Multimídia


sistemas multimÍdia - joinville.udesc.br osi 3/44. sistemas multimídia ... •operação plug and...

Documents