Prof. Dr. Paulo Sampaio: A Pilha TCP/IP e o Protocolo RTP (Real Time Protocol)

+
A Pilha TCP/IP e o Protocolo RTP (Real Time

Protocol)
Prof. Dr. Paulo Sampaio
e-mail: pnms.funchal@gmail.com
Protocolos de transporte para a comunicação multimídia
+ 2
A função básica de um protocolo de transporte é fornecer

funções e serviços à aplicação utilizando protocolos de baixo
nível e a camada de rede.
Protocolo Protocolo Suporte à

de transporte
multimídia
de transporte
convencional
+ garantia de QoS
Estabelecer e manter uma conexão com

garantia de QoS sobre a rede e fornecer uma
interface para a aplicação.
Paulo N.M. Sampaio

+ 3
- Tópicos abordados :
1. TCP (Lucas e Gabriel)
2. UDP (Alefe e Moacir)
3. ICMP (Herculano e Vitor)
4. RTP/RTCP (Oton e Tiago)
5. RTSP (Valdson e Roberto)
6. Confiabilidade, Orientação à Conexão (Jackson e Jean)
7. Controle de Fluxo (Sliding Window) (Rafael)
Paulo N.M. Sampaio

+ 4
1. Requisitos para protocolos de transporte multimídia
2. Por que protocolos de transporte tradicionais não são adequados para a

comunicação multimídia ?
3. TCP/IP
4. Protocolos de transporte tempo-real
Paulo N.M. Sampaio

+ 5

3. TCP/IP
Paulo N.M. Sampaio

Requisitos para protocolos de transporte multimídia
+ 6
1. Grande capacidade de tratamento (throughput)
2. Suporte a musticast (IP ou algoritmo de roteamento)
3. Especificação e garantia de QoS (interface com a aplicação)
Paulo N.M. Sampaio

+ 7
Capacidade de tratamento (throughput) :
- Informações multimídia necessitam de uma grande largura de banda => O protocolo

de transporte deve ser suficientemente rápido para suportar os requisitos para essa
largura de banda.
- O throughput de um protocolo de transporte deve ser maior que a velocidade de

acesso à rede => Se a largura de banda fornecida pelos pontos de acesso à rede
não for completamente utilizada, o protocolo de transporte pode se tornar um
gargalo para o sistema de comunicação.
Paulo N.M. Sampaio

+ 8
Suporte a musticast :
- O suporte a multicast é normalmente implementado pela camada de rede
=> Os sistemas de transporte multimídia (protocolo de transporte, protocolos de baixo

nível e camada de rede subjacente) utilizam algoritmo multicast baseado em IP ou
assumem a existência de certos algoritmos de roteamento multicast.
Paulo N.M. Sampaio

+ 9
Especificação e garantia de QoS :
- O sistema de transporte deve prover mecanismos para as aplicações para a

especificação e negociação de requisitos de QoS.
- Uma aplicação pode realizar a caracterização de tráfego através da especificação de

parâmetros de QoS ou através da modelagem de tráfego
- Alternativamente, o tráfego pode ser especificado através de perfis do tipo “TV-

quality video” ou “phone-quality audio” => Nesse caso, o protocolo de transporte é
encarregado de traduzir esses perfis em um conjunto de parâmetros de QoS.
- Após a especificação, os parâmetros de QoS são passados diretamente à rede
=> O protocolo da camada de rede (protocolo de reserva) propaga os requisitos de

QoS e reserva os recursos necessários para uma determinada conexão
(multicast).
- Todos os sub-sistemas de um sistema de transporte devem cooperar para a

garantia de QoS, incluindo : pilha de transporte, gerência de recursos (admissão,
alocação de recursos e políticas de escalonamento), controle de acesso à rede, e
gerenciamento de filas.
Paulo N.M. Sampaio
+ 10

3. TCP/IP
Paulo N.M. Sampaio

Por que PT tradicionais não são adequados para a comunicação multimídia ?
+ 11
1. Cópia de dados
2. Multiplexação em camadas
3. Controle de fluxo
4. Controle de erros
5. Posicionamento e controle de manuseio de informação
6. Falta de suporte a QoS
Protocolos de -TCP (Internet) Não suportam

Transporte QoS ou Multicast !!!
- TP4 (OSI)
tradicionais
Paulo N.M. Sampaio

+ 12
Cópia de dados :
- Os protocolos OSI-RM e TCP/IP foram projetados em camadas funcionais de forma

a proporcionar interoperabilidade nesses diferentes níveis => Baixa performance
- Os protocolos em camadas representam um gargalo para a comunicação => Os

dados são processados em cada camada, e em seguida, são copiados para uma
camada superior para o seu processamento => A cópia dos dados implica em uma
latência para a rede.
- A cópia de dados pode ser diminuída ou substituída através de um ponteiro para as

informações entre as camadas.
Mens Seg. Dat. Quad.
Mens
Paulo N.M. Sampaio

+ 13
Multiplexação de camadas :
- A multiplexação pode ser considerada como o mapeamento de um número

de conexões de uma camada superior com apenas uma única conexão de
uma
camada inferior => compartilhamento de recursos de um nível mais baixo
por clientes de um nível superior.
- Multiplexação em várias camadas diminui a performance :
(1) Aumento de complexidade e difícil implementação => baixo

throughput
(2) Tratamento de dados por conexões diferentes => atraso e jitter
(3) Dificuldade para tratar erros em camadas inferiores => atraso para
outras conexões
(4) Diferentes conexões com diferentes requisitos QoS são tratadas da
mesma forma => recursos ociosos (sub-uso) e não satisfação de QoS
- Solução : implementação de diferentes threads para diferentes streams ou

diferentes pilhas de transporte para diferentes streams => pilhas podem
ser implementadas por diferentes processadores para aumentar a
performance.
Paulo N.M. Sampaio
+ 14
Controle de fluxo :
- O mecanismo de controle de fluxo mais comum utiliza uma janela deslizante => Um
número fixo de bytes (janela) é transmitido continuamente através da confirmação
(acknowledgment) do receptor (se o seu buffer não estiver cheio).
- Para a transmissão em alta velocidade essa solução não é adequada :
(1) A janela é pequena, e o transmissor ficará esperando acknowledgment do

receptor a maior parte do tempo => largura de banda ociosa
(2) Em uma velocidade de transmissão alta, o atraso é considerável => A mensagem

recebida pelo transmissor não reflete o status atual da rede e do receptor.
(3) Essa solução não é adequada para transmissão multimídia => Necessidade de
respeitar a taxa intrínsica de dados => a rede suporta completamente ou não
transmite nada.
Paulo N.M. Sampaio

+ 15
Controle de fluxo : (cont’)
- Solução : Utilizar um mecanismo de controle baseado em taxa de transmissão =>
O transmissor, a rede e o receptor “acertam” um taxa de transmissão (natureza da

aplicação), e durante a transmissão :
➢ O transmissor emite as informações nessa taxa;
➢ A rede proporciona certas garantias para esse tráfego, e;
➢ O receptor aloca recursos suficientes para receber e apresentar as informações

na taxa de transmissão especificada.
Paulo N.M. Sampaio

+ 16
Controle de erros :
- TCP e TP4 garante uma transmissão de dados confiável => Quando um

pacote é perdido ou danificado, ele é retransmitido.
- Essa estratégia não é adequada para a transmissão multimídia :
(1) Dados multimídia podem tolerar perdas ou erros
(2) Retransmissão causa mais atraso para os dados
(3) A implementação de uma estratégia de retransmissão é mais complexa (mais

timers e buffers maiores) => protocolo de transporte mais complicado e lento
- Para a comunicação multimídia, a detecção de erros é necessária, e ela deveria ser

gerenciada pela aplicação => A aplicação deve decidir qual informação é importante
ser retransmitida (retransmissão seletiva).
- Uma solução possível é o envio de um código de correção de erros => informação

extra é enviada para permitir a correção do erro no receptor sem necessidade de
retransmissão de informações => consumo de largura de banda adicional.
Paulo N.M. Sampaio

+ 17
Posicionamento e controle de manuseio de informação :
- Todos os protocolos operam através da troca de informações de estado do

protocolo : diretamente no pacote de dados (headers) ou através de pacotes de
controle, ou ambos.
- Vários fatores podem afetar a complexidade de implementação do protocolo e a sua

performance :
(1) A posição do controle de informação dentro de um pacote é fixa ?
(2) A estrutura do pacote é adequada para a implementação do hardware ?

(verificação do checksum), etc.
Paulo N.M. Sampaio

+ 18
Falta de suporte a QoS :
- Para a transmissão em alta velocidade e comunicação multimídia é necessário

garantir QoS e dar suporte a multicast.
➢ Em TCP, não existe a noção de QoS
➢ TP4 permite a negociação de parâmetros de QoS => parâmetros são orientados

à transmissão de dados (texto) e não são adequados à comunicação
multimídia.
Paulo N.M. Sampaio

+ 19

3. TCP/IP
Paulo N.M. Sampaio

TCP/IP
+ 20
1. Introdução
2. Visão geral da arquitectura TCP/IP
3. Protocolos de Transporte TCP e UDP
4. Protocolo ICMP
Paulo N.M. Sampaio

Introdução - Histórico
+ 21
◼ 1969, Defense Advanced Research Projects Agency (DARPA) cria um projeto

de pesquisa para criar uma rede experimental de comutação de pacotes –
ARPANET – que deveria prover:
◼ robustez;
◼ confiabilidade; e
◼ comunicação de dados independente de fornecedores.
◼ 1975, Devido ao grande sucesso, a ARPANET deixa uso experimental e passa

a ter uso operacional; seu desenvolvimento continua e a família de protocolos
TCP/IP começa a ser concebida.
◼ 1979, Internet Control and Configuration Board define o projeto de um protocolo

para interconexão de redes;
◼ 1980, TCP/IP torna-se padrão na ARPANET;
◼ 1983, TCP/IP adotado como padrão militar e a Defence Communication Agency

pede a divisão da ARPANET:
Paulo N.M. Sampaio
Introdução – Histórico (cont´)
+ 22
◼ TCP/IP integrado ao BSD/UNIX (Short for Berkeley Software Design, Inc) e

disponibilizado a baixo custo;
◼ 1985, Nacional Science Foundation (NSF) promove expansão da Internet

para a comunidade científica americana – NSFNET
◼ 1986 ... 1992, NSF disponibiliza acesso para comunidade científica fora
dos Estados Unidos;
◼ 1993 ... 1998, TCP/IP torna-se padrão ‘de fato’ para interconexão de redes
de diferentes tecnologias; rede passa a ser usada para os mais variados
fins;
◼ 1997 ... 2000, Mundo usa massivamente a Internet, articula-se e

implementa-se em alguns países a Internet 2; comunicação em alta
velocidade (155/622 Mbps em grosso, 256, 1024, 2048 Mbps no varejo)
◼ http://www.zakon.org/robert/internet/timeline/
Paulo N.M. Sampaio

Características
+ 23
◼ Padrão de protocolos aberto, não associado a nenhum tipo específico de

hardware (computador) ou sistema operacional;
◼ Independente de hardware específico para acesso ao meio físico de

transmissão (TCP/IP funciona sobre Ethernet, Token-ring, X.25, e
qualquer outro tipo de meio de transmissão);
◼ Esquema de endereçamento comum que permite a identificação única de

um elemento da rede (na rede local, ou no planeta);
◼ Protocolos de alto nível padronizados para disponibilização universal e

consistente de serviços aos usuários.
◼ Documentação ampla acessível na própria rede sob a forma de “Request

for Comments” – RFC’s que não sofrem do rigor imposto aos relatórios
técnicos formais. As RFC’s contêm as últimas versões das
especificações de todos os protocolos TCP/IP padrões;
◼ Interconexão cooperativa de redes, suportando serviços de comunicação

universal (usada em uma rede local ou em uma rede [inter] planetária);
Paulo N.M. Sampaio

Características (cont´)
+ 24
◼ Utilização
de tecnologia adequada às
necessidades locais em cada rede;
◼ Independência de hardware e sistemas
operacionais;
◼ Interconexão de redes se dá por meio de
roteadores.
◼ Protocolos mais importantes:
◼ TCP: Transmission Control Protocol
◼ UDP: User Datagram Protocol
◼ IP: Internet Protocol
Paulo N.M. Sampaio

Visão geral da arquitetura TCP/IP
◼ A arquitetura TCP/IP – Internet é organizada em quatro camadas (ou níveis)

conceituais, construídas sobre uma quinta camada que não faz parte do
modelo – chamada intra-rede – como mostrado abaixo.
25
Paulo N.M. Sampaio
Camada de Transporte
+ 26
◼ A camada de transporte fornece o serviço de comunicação fim-a-fim

(computador-a-computador) confiável. Suas funções compreendem:
◼ Montagem de segmentos para a camada de rede a partir de mensagens

vindas da camada de aplicação (fragmentação);
◼ Montagem de mensagens para a camada de aplicação a partir de

segmentos vindos da camada de rede (desfragmentação);
◼ Transmissão de dados sem conexão e não confiável (protocolo UDP)

ou com conexão e confiável (cria circuito virtual através do protocolo
TCP);
◼ Retransmissão temporizada, sequenciamento de segmentos (max. de

64 KB cada), controle de fluxo;
◼ Armazenamento temporário (“buffering”) na recepção e transmissão;
◼ Identificação de processos origem e destino
Paulo N.M. Sampaio

Camada de Transporte (cont´)
+ 27
◼ Protocolo UDP
◼ Transporte de dados baseado em serviço sem conexão
(“conection less”);
◼ Baixa sobrecarga;
◼ Não confiável;
◼ Sem detecção de erros;
◼ Sem controle de seqüência;
◼ Bom para pequenas quantidades de dados a transmitir;
◼ Bom para aplicações do tipo consulta / resposta;
◼ Bom para aplicações que tem seus próprios mecanismos
de entrega confiável.
Paulo N.M. Sampaio

Datagrama UDP
Campos:
• Source/Destination Port:
porta de origem/destino
(identificam os processos
envolvidos na conexão);
• Message Lenght:
tamanho do segmento;
• Checksun: verificação de
erro;
• Data: início dos dados
28
Paulo N.M. Sampaio
+ 29
Protocolo TCP
◼ Baseado em seqüências de bytes não estruturados (“streams”);
◼ Transporte de dados baseado em serviço com conexão (“virtual circuit”):

◼ Estabelecimento de conexão;
◼ Transferência de dados;
◼ Encerramento de conexão;
◼ Maior sobrecarga;
◼ Confiável;
◼ Com detecção e correção de erros;
◼ Com controle de seqüência;
◼ Necessário para maiores quantidades de dados a transmitir;
◼ Necessário para aplicação do tipo interativa;
◼ Necessário para aplicação que não tem seu próprio mecanismo de entrega confiável.
Paulo N.M. Sampaio

Segmento TCP
30
Paulo N.M. Sampaio
+ 31
◼ Source/Destination Port: porta de origem/destino (identificam os processos

envolvidos na conexão);
◼ Sequence Number: posição do segmento dentro da seqüência de bytes da/para

a aplicação;
◼ Acknowledgment Number: número do próximo byte esperado no destino;
◼ Hlen: tamanho do cabeçalho;
◼ Reserved: reservado;
◼ Code bits
◼ URG: campo Urgent Pointer é válido;
◼ ACK: campo Ack number é válido;
◼ PSH: segmento requer um push;
◼ RST: reset a conexão;
◼ SYN: sincronize números de seqüência;
◼ FIN: origem terminou sua seqüência de bytes
◼ Window: tamanho da janela deslizante (número de segmentos enviados em

seqüência antes de receber reconhecimento);
◼ Checksun: verificação de erro no segmento;
Paulo N.M. Sampaio

+ 32
◼ Urgent Pointer: posição onde os dados urgentes se encontram no segmento;
◼ Options: tamanho (opcional) máximo de segmento (“Maximum Segment Size”);
◼ Padding: preenchimento;
◼ Data: dados do segmento.
Paulo N.M. Sampaio

Encapsulamento de dados TCP/IP
+ 33
Paulo N.M. Sampaio

UDP (User Datagram Protocol)
+ 34
◼ UDP é um protocolo de transporte

◼ comunicação entre processos
◼ UDP usa IP para entregar os datagramas ao host correto
◼ UDP utiliza portas que servem os processos individuais
◼ Consiste de um cabeçalho de 8 bytes
Paulo N.M. Sampaio

Portas
+ 35
◼ TCP/IP utiliza destinos virtuais chamados portas protocolares
◼ As portas são identificadas por números inteiros positivos
◼ Os sistemas operativos têm mecanismos que associam um

processo a uma determinada porta
◼ Portas conhecidas (well-known ports) abaixo de 256, são

reservadas para serviços padrão
Paulo N.M. Sampaio

Portas (cont´)
+ 36
Paulo N.M. Sampaio

Portas (cont´)
+ 37
Port Number Description Port Number Description
1 TCP Port Service Multiplexer 42 Host Name Server (Nameserv)

(TCPMUX)
43 WhoIs
5 Remote Job Entry (RJE) 49 Login Host Protocol (Login)
53 Domain Name System (DNS)
7 ECHO
69 Trivial File Transfer Protocol (TFTP)
18 Message Send Protocol (MSP)
70 Gopher Services
20 FTP – Data 79 Finger
80 HTTP
21 FTP – Control
103 X.400 Standard
22 SSH Remote Login Protocol
108 SNA Gateway Access Server
23 TechNet 109 POP2
110 POP3
25 Simple Mail Transfer Protocol
(SMTP) 115 Simple File Transfer Protocol (SFTP)
29 MSG ICP37Time 118 SQL Services
119 Newsgroup (NNTP)
Paulo N.M. Sampaio

Portas (cont´)
+ 38
Port Number Description
137 NetBIOS Name Service

139 NetBIOS Datagram Service
143 Interim Mail Access Protocol (IMAP)
150 NetBIOS Session Service
156 SQL Server
161 SNMP
179 Border Gateway Protocol (BGP)
190 Gateway Access Control Protocol (GACP)
194 Internet Relay Chat (IRC)
197 Directory Location Service (DLS)
389 Lightweight Directory Access Protocol
(LDAP)
396 Novell Netware over IP
443 HTTPS
444 Simple Network Paging Protocol (SNPP)
445 Microsoft-DS
458 Apple QuickTime
546 DHCP Client
547 DHCP Server
563 SNEWS
569 MSN
1080 Socks
Paulo N.M. Sampaio

UDP
Formato datagrama UDP

◼ Entrega de datagramas
◼ Sem conexão
◼ Não fiável
39
Paulo N.M. Sampaio
TCP (Transmission Control Protocol)
+ 40
◼ TCP é outro protocolo de transporte suportado pelo TCP/IP
◼ Características do TCP:
◼ orientada à conexão
◼ fiável
◼ full-duplex e ponto a ponto
◼ byte-stream
Paulo N.M. Sampaio

Orientado à Conexão
+ 41
◼ Significa que antes de qualquer transferência é necessário

estabelecer uma ligação virtual
◼ Se a conexão não poder ser estabelecida - a aplicação é

notificada
◼ Se a conexão for interrompida - a aplicação é notificada
Paulo N.M. Sampaio

Fiável
+ 42
◼ A transmissão de dados tem que ser confirmada pelo

receptor
◼ Se o emissor não receber a confirmação (num período de

tempo específico) os dados são retransmitidos
Paulo N.M. Sampaio

Byte Stream
+ 43
◼ Stream significa que a conexão é tratada como uma corrente

de bytes
Paulo N.M. Sampaio

Buffering
+ 44
◼ TCP é responsável pelo buffering dos dados e determina

quando está na altura de enviar um segmento
Paulo N.M. Sampaio

Portas do TCP
+ 45
◼ A comunicação entre processos é feita pelas portas (como

no UDP)
◼ As portas UDP não têm qualquer relação com as portas

TCP (espaços de endereços diferentes)
Paulo N.M. Sampaio

Segmentos TCP
+ 46
◼ O grupo de dados que o TCP pede ao IP para entregar chama-

se segmento TCP
◼ MTU de um segmento é 65.535 bytes
◼ Cada um dos segmentos contém:

◼ bytes (dados) da byte-stream
◼ informação de controlo que identifica os dados (cabeçalho 20 bytes)
Paulo N.M. Sampaio

Gerenciamento de conexão TCP
+ 47
◼ Uma conexão é estabelecida entre dois pontos terminais

(sockets)
◼ Por exemplo
18.26.0.32::tcp::123 (emissor) e
18.26.0.34::tcp::9912 (receptor)
◼ A conexão é estabelecida com uma sequencia de 3 eventos

(three-way handshake):
Paulo N.M. Sampaio

Gerenciamento de conexão TCP (cont´)
+ 48
◼ A desconexão de uma sessão é executada da seguinte forma:
◼ O primeiro ACK e o segundo FIN pode estar contendido num só segmento
Paulo N.M. Sampaio

TCP - Confiabilidade
+ 49
◼ TCP oferece transferência de dados confiável, assumindo um

serviço de redes não confiável (IP)
◼ Confiabilidade esta baseada sobre confirmações

(acknowledgements) e timeouts
◼ Fluxo normal:
Paulo N.M. Sampaio

TCP – Confiabilidade (cont´)
+ 50
◼Oemissor retransmite depois de um

período de tempo sem confirmação
Paulo N.M. Sampaio

TCP – Controlo de Fluxo
+ 51
◼ TCP utiliza Protocolos de Janela Deslizante (Sliding

Window) Go-back-n
◼ Transmite múltiplos pacotes antes de receber a confirmação

do primeiro pacote
◼ Permite maior eficiência que um controlo de fluxo stop-and-

go
Paulo N.M. Sampaio

TCP/IP - Sumário
+ 52
◼ IP: network layer protocol

◼ entrega não fiável de datagramas entre hosts.
◼ UDP: transport layer protocol

◼ entrega não fiável de datagramas entre processos.
◼ TCP: transport layer protocol

◼ fiável, entrega de byte-stream entre processos
Paulo N.M. Sampaio

Hmmmmm... TCP or UDP ?
+ 53
◼ E-comércio ?
◼ Servidor de vídeo ?
◼ Transferência de arquivos ?
◼ E-mail ?
◼ Grupos de chat ?
◼ Cirurgia com robô controlado remotamente, através de uma rede ?
Paulo N.M. Sampaio

Protocolo ICMP (Internet Control Message Protocol)
+ 54
◼ ICMP é um protocolo para troca de mensagens de

controle/erro
◼ Os eventos são reportados pelo ICMP
◼ Usado para testar a Internet
◼ ICMP usa o protocolo IP para entregar as mensagens
◼ As mensagens de ICMP são processadas pelo software

IP (e não pelas aplicações finais)
Paulo N.M. Sampaio

Protocolo ICMP (Internet Control Message Protocol) – Cont`
+ 55
◼ 12 tipos de mensagens que são encapsuladas em

pacotes IP
Tipo de mensagem Descripção

Destination unreachable Pacote não pode ser entregue
Time exceeded Campo time to live chegou a 0
Parameter problem Campo de cabeçalho inválido
Source quench Pacote regulador
Redirect Ensinar geografia a um roteador
Echo request Perguntar a uma máquina se ela está activa
Echo reply Sim, estou activa
Timestamp request O mesmo que Echo request, mas com timestamp
Timestamp reply O mesmo que Echo reply, mas com o timestamp
Paulo N.M. Sampaio

Protocolo ICMP (Internet Control Message Protocol) – Cont`
+ 56
◼ Quando uma mensagem ICMP é enviada ocorrem 2

níveis de encapsulamento:
◼ A mensagem ICMP é encapsulada num pacote IP.
◼ O pacote IP é encapsulado num frame antes de ser transmitida
na rede.
Paulo N.M. Sampaio

+ 57

3. TCP/IP
Paulo N.M. Sampaio

+ 58
Protocolos de transporte multimídia :
• XPRESS Transfer Protocol (XTP)

• ST-II
• Reservation Protocol (RSVP)
• Real Time Transport Protocol (RTP)
• Heidelberg Transport Protocol (HeiTP)
• TENET Real-Time Protocol (RCAP, RTIP, RMTP, CMTP e RTCMP)
Paulo N.M. Sampaio

Protocolos de transporte em tempo-real
+ 59
Requisitos para o transporte de dados em tempo-real :
- Sequenciamento
- A ordem dos pacotes deve ser redefinida em tempo real
- A perda deve ser detectada e compensada
- Sincronização
- Inter-mídia : relação temporal entre diferentes mídias durante a apresentação
- Intra-mídia : relação temporal entre amostras da mesma mídia
- Identificação de « payload »
- Depende do esquema de codificação
- Pode ser modificado dinamicamente
- Sinalização dos pacotes

- Indica o início e o final dos pacotes ao receptor
- Auxilia a entrega dos pacotes de forma sincronizada
Paulo N.M. Sampaio

+ 60
Uma visão dos protocolos em tempo-real :
Os protocolos e suas aplicações ...
Descrição de streams : MBone, SDP, SMIL...

descrevem a sessão e o conteúdo
Transporte de mídia : RTP

Envia dados e metadados
Controle de stream : RTSP

Controle remoto da sessão
Reserva de recursos : RSVP, Diffserv

Certifica-se que o canal de comunicação ofereçe garantias
apropriadas …
…ou então transmissão Best-Effort!
Paulo N.M. Sampaio
+ 61




apropriadas …
Paulo N.M. Sampaio

+ 62
Multicast Backbone (Mbone) :
Paulo N.M. Sampaio

Multicast Backbone (Mbone) : (cont’)
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

+ 66
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

+ 69




apropriadas …
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Session Description Protocol (SDP) :
Paulo N.M. Sampaio

+ 72




apropriadas …
Paulo N.M. Sampaio
+ 73
Synchronized Multimedia Integrated Language (SMIL) :
Paulo N.M. Sampaio

+ 74




apropriadas …
Paulo N.M. Sampaio

+ 75
Real Time Transport Protocol (RTP) :
Paulo N.M. Sampaio

+ 76
Application Level =>
Provide an information
required by the application
Integrated Level =>

It is integrated with
the application processing
Paulo N.M. Sampaio

5Protocolos de transporte em tempo-real
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Real Time Transport Control Protocol (RTCP) :
Paulo N.M. Sampaio

Encapsulamento de Video
+ 80
Paulo N.M. Sampaio

+ 81




apropriadas …
Paulo N.M. Sampaio
Real Time Streaming Protocol (RTSP) :
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

+ 87




apropriadas …
Paulo N.M. Sampaio

Reservation Protocol (RSVP) :
Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

Paulo N.M. Sampaio

+ 92



Reserva de recursos : RSVP, Diffserv (IntServ)

apropriadas …
Paulo N.M. Sampaio

+ 93
Integrated Services (IntServ)

◼ The Integrated Services (IntServ) model builds upon Resource
Reservation Protocol (RSVP)
◼ Reservations are made per simplex flow
◼ Applications request reservations for network resources which are

granted or denied based on resource availability
◼ Senders specify the resource requirements via a PATH message that

is routed to the receiver
◼ Receivers reserve the resources with a RESV message that follows

the reverse path
RESV
Sender Receiver
PATH
Paulo N.M. Sampaio

Deploying Quality of Service Technologies (Cisco.com)
+ 94
IntServ – Components
The Integrated Services Model can be divided into two parts – the
Control and Data Planes
Control Plane
Routing Selection Admission Control
Reservation Setup
Reservation Table
Data Plane
Flow Identification Packet Scheduler
Paulo N.M. Sampaio

+ 95
IntServ – Components
◼Control Plane
◼ Route Selection – Identifies the route to follow for the reservation
◼ Reservation Setup – Installs the reservation state along the selected
path
◼ Admission Control – Ensures that resources are available before
allowing a reservation
◼Data Plane
◼ Flow Identification – Identifies the packets that belong to a given
reservation (using the packet’s 5-Tuple)
◼ Packet Scheduling – Enforces the reservations by queuing and
scheduling packets for transmission
Paulo N.M. Sampaio

+ 96
IntServ – Service Models

◼Applications using IntServ can request two basic
service-types:
◼ Guaranteed Service
◼Provides guaranteed bandwidth and queuing delays end-to-end,
similar to a virtual-circuit
◼Applications can expect hard-bounded bandwidth and delay
◼ Controlled-Load Service
◼Provides a Better-than-Best-Effort service, similar to a lightly-loaded
network of the required bandwidth
◼Applications can expect little to zero packet loss, and little to zero
queuing delay
Paulo N.M. Sampaio

+ 97
IntServ – Scaling Issues

◼ IntServ routers need to examine every packet to identify and classify
the microflows using the 5-tuple
◼ IntServ routers must maintain a token-bucket per microflow
◼ Guaranteed Service requires the creation of a queue for each

microflow
◼ Data structures must be created and maintained for each reservation
Paulo N.M. Sampaio

+ 98
Differentiated Services (DiffServ)

◼ The DiffServ Model specifies an approach that offers a service better than Best-Effort
and more scalable than IntServ
◼ Traffic is classified into one of five forwarding classes at the edge of a DiffServ network
◼ Forwarding classes are encoded in the Differentiated Services Codepoint (DSCP) field
of each packet’s IP header
◼ DiffServ routers apply pre-provisioned Per-Hop Behaviors (PHBs) to packets according

to the encoded forwarding class
5 4 3 2 1 5 4 3 2 1
Paulo N.M. Sampaio

+ 99
DiffServ – Compared to IntServ
◼ DiffServ allocates resources to aggregated rather than to individual flows
◼ DiffServ moves the classification, policing, and marking functions to the

boundary nodes – the core simply forwards based on aggregate class
◼ DiffServ defines Per-Hop forwarding behaviors, not end-to-end services
◼ DiffServ guarantees are based on provisioning, not reservations
◼ The DiffServ focus is on individual domains, rather than end-to-end

deployments
Paulo N.M. Sampaio

+
A Pilha TCP/IP e o Protocolo RTP (Real Time

Protocol)
Prof. Dr. Paulo Sampaio
e-mail: pnms.funchal@gmail.com

Prof. Dr. Paulo Sampaio: A Pilha TCP/IP e o Protocolo RTP (Real Time Protocol)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Prof. Dr. Paulo Sampaio: A Pilha TCP/IP e o Protocolo RTP (Real Time Protocol)

Enviado por

Direitos autorais:

Formatos disponíveis

+

A Pilha TCP/IP e o Protocolo RTP (Real Time

A função básica de um protocolo de transporte é fornecer

Protocolo Protocolo Suporte à

Estabelecer e manter uma conexão com

Paulo N.M. Sampaio

1. TCP (Lucas e Gabriel)

2. UDP (Alefe e Moacir)

3. ICMP (Herculano e Vitor)

4. RTP/RTCP (Oton e Tiago)

5. RTSP (Valdson e Roberto)

6. Confiabilidade, Orientação à Conexão (Jackson e Jean)

7. Controle de Fluxo (Sliding Window) (Rafael)

Paulo N.M. Sampaio

1. Requisitos para protocolos de transporte multimídia

2. Por que protocolos de transporte tradicionais não são adequados para a

4. Protocolos de transporte tempo-real

Paulo N.M. Sampaio

1. Requisitos para protocolos de transporte multimídia

2. Por que protocolos de transporte tradicionais não são adequados para a

4. Protocolos de transporte tempo-real

Paulo N.M. Sampaio

1. Grande capacidade de tratamento (throughput)

2. Suporte a musticast (IP ou algoritmo de roteamento)

3. Especificação e garantia de QoS (interface com a aplicação)

Paulo N.M. Sampaio

Capacidade de tratamento (throughput) :

- Informações multimídia necessitam de uma grande largura de banda => O protocolo

- O throughput de um protocolo de transporte deve ser maior que a velocidade de

Paulo N.M. Sampaio

- O suporte a multicast é normalmente implementado pela camada de rede

=> Os sistemas de transporte multimídia (protocolo de transporte, protocolos de baixo

Paulo N.M. Sampaio

Especificação e garantia de QoS :

- O sistema de transporte deve prover mecanismos para as aplicações para a

- Uma aplicação pode realizar a caracterização de tráfego através da especificação de

- Alternativamente, o tráfego pode ser especificado através de perfis do tipo “TV-

- Após a especificação, os parâmetros de QoS são passados diretamente à rede

=> O protocolo da camada de rede (protocolo de reserva) propaga os requisitos de

- Todos os sub-sistemas de um sistema de transporte devem cooperar para a

1. Requisitos para protocolos de transporte multimídia

2. Por que protocolos de transporte tradicionais não são adequados para a

4. Protocolos de transporte tempo-real

Paulo N.M. Sampaio

5. Posicionamento e controle de manuseio de informação

6. Falta de suporte a QoS

Protocolos de -TCP (Internet) Não suportam

Paulo N.M. Sampaio

- Os protocolos OSI-RM e TCP/IP foram projetados em camadas funcionais de forma

- Os protocolos em camadas representam um gargalo para a comunicação => Os

- A cópia de dados pode ser diminuída ou substituída através de um ponteiro para as

Mens Seg. Dat. Quad.

Paulo N.M. Sampaio

- A multiplexação pode ser considerada como o mapeamento de um número

- Multiplexação em várias camadas diminui a performance :

(1) Aumento de complexidade e difícil implementação => baixo

- Solução : implementação de diferentes threads para diferentes streams ou

- Para a transmissão em alta velocidade essa solução não é adequada :

(1) A janela é pequena, e o transmissor ficará esperando acknowledgment do

(2) Em uma velocidade de transmissão alta, o atraso é considerável => A mensagem

Paulo N.M. Sampaio

Controle de fluxo : (cont’)

- Solução : Utilizar um mecanismo de controle baseado em taxa de transmissão =>