Integração de Serviços na - inf.pucrs.brfldotti/redes/aulas/IS-2-fundoClaro.pdf · n bit T: alto throughput n bit R: maior confiabilidade y “dicas” para os algoritmos de roteamento

1

Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Redes de Computadores

Fernando Luís Dotti

Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Integração de Serviços naInternet

porFernando Luís Dotti

[email protected] www.inf.pucrs.br/~fldottiPrograma de Pós-Graduação

em Ciência da ComputaçãoPUC-RS

2

Redes de Computadores 3

Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Sumário

z Integração de Serviçosy Terminologia, Aplicações, Requisitos

z Abordagens para suporte a integração de serviçosy B-ISDN: ATMy IETF: Integrated Services Architecture

z Arquitetura tradicional da Internet - Problemasz Arquitetura expandida da Internet

y Iniciativasy Protocolos de suporte a qualidade

n RTP/RTCP; RSVPy Protocolos de suporte a sessões com dados contínuos

n SIP; RTSP


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Integração de Serviços

z Terminologiay serviço: serviço de comunicação - telefonia, tv, rádio, fax,

dados (e-mail, ftp, …)y integração de serviços: utilização de mesma infra-estrutura

para suportar vários tipos de serviços de comunicaçãoy multimídia: várias mídias

n e.g.: texto + figuras; figuras + áudio; áudio + vídeo; 2vídeos; ...

3


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Terminologiay mídia discreta: independente do tempoy mídia contínua: tempo faz parte da semântica da sua

apresentaçãon e.g.: vídeo: seqüência de quadros com ordem e duração

definiday tempo real

n existem requisitos temporais quanto ao tráfego de dados.e.g.: vazão, atraso, variação do atraso

n sua não observação pode significar falha da aplicação


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Terminologiay tráfego tempo-real pode ou não ser multimídia, e.g.:

n controle de usina nuclear (sinais lidos de sensores)n controle de produção - fábricasn sistemas de controle de tráfego

4


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Terminologiay tráfego multimídia pode ou não ser tempo real, e.g.:

n páginas WWW (texto+figuras+áudio+animações+…) -primeiro traz informação como dado qualquer, depois exibe

n download de filme, música


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Terminologiay tráfego multimídia e tempo real

n reprodução durante tráfego: requisitos temporais comrelação ao tráfego

n comunicação unidirecional: transmissão de rádion comunicação interativa: conferência de áudio/vídeo

n também chamados serviços diferenciados

5


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Aplicações básicasy mídia sob demanda

n e.g.: servidores de áudio / vídeon dados volumosos, equipamento terminal simples, resposta

rápida ao usuário (início da mídia) >> reprodução dos dadosenquanto o tráfego dos dados acontece

n requisitos: largura de banda e baixa variância de atrason atraso não é crítico

Servidor de Mídia


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Aplicações básicasy difusão de mídia

n e.g.: serviços análogos a TV e rádion requisitos semelhantes a mídia sob demandan emprego de transmissão multicast (Mbone - Multicast

Backbone)n 1 ---> muitos

Fonte Geradora

6


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Aplicações básicasy interativas: conferências

n atraso deve ser baixoy conferências de áudio / telefonia

n não exige muita largura de bandan 56 a 64 Kbps sem compressão

y conferências de vídeon largura de banda considerável


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Áreas de aplicaçãoy difusão: tv, rádioy telefoniay mail multimídiay hipermídiay trabalho cooperativo suportado por computador (CSCW)

n editoração conjunta de documentos; reuniões a distância; ensino adistância; etc.

y comércio eletrônico

7


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Caracterização / requisitosTráfego Vazão média dos dados Tolerância a

erros

Atraso máximo e

variação de atraso

Texto Rajada Poucos bps até algunsmbps

Não tolerável Não constituemproblemas

Imagem

gráfica

Rajada Pode chegar a dezenas dembps

Compromete aimagem final

Não constituemproblemas

Áudio Tráfego contínuo com taxaconstante. Introduzindosilêncio: tráfego em rajadas. Seutilizar técnicas decompactação e compressão:tráfego com taxa variável.

Depende da qualidade dosinal, da compactação oucompressão utilizada.CD: 44.100 samples/seg (taxade amostragem), 16 bits cadað 705,6 Kbps – monoð 1.411 Mbps – stereoCompactado com MPEG96 a 128 Kbps

Pode ser alta,não causandoproblemas

Crítico em aplicaçõesque exigemcomunicação interativa

Vídeo Tráfego contínuo com taxaconstante. Introduzido técnicasde compactação e compressãose caracteriza por um tráfegocom taxas variáveis

Varia com a qualidade dosinal e os algoritmos decompactação, codificaçãoe compressão utilizados.XGA: 1024 x 768, 24 bits/pixel25 frames/segð 472MbpsCompactado com MPEG3 a 10 Mbps dependendo daqualidade escolhida

Tolerável Crítico em aplicaçõesque exigemcomunicação interativa

MPEG - Motion Picture Experts Group


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Garantia de qualidadey reserva de recursos no caminho dos dados

8


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


z Abordagens para suportey Integrated Services Digital Networks

n Broadband-ISDN: ATMy IETF (Internet Engineering Task Force)

n Integrated Services Architecture


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

ATM

z Nível de rede orientado a conexão:n estabelece um caminho para os dadosn tráfego segue sempre mesmo caminhon reserva de recursos pode acontecer junto com o

estabelecimento do caminhon >> protocolo de sinalização serve para abertura

de conexão e reserva de recursossimultaneamente

9


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

n células do mesmo “canal virtual” são “chaveadas”conforme o caminho estabelecido e reservadopara a conexão

ATM

EqTerm

SWITCH

SWITCH SWITCH

SWITCH SWITCH

SWITCH

SWITCH

EqTerm


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

z Possibilita especificar níveis dey largura de banday atrasoy variação do atraso

ATM

10


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

y ATM resolve ?n Todas redes teriam que ser ATM:

n Realidade

ATM

ATM

ATM ATMATMATM

EqTerm EqTerm

Satelite

Ethernet Token-ringATMFDDI

EqTerm EqTerm


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

y ATM resolve ?n Aplicações tem que ser portadas para ATMn Não é apropriada para aplicações 1 -> muitos,

como difusão

n >> ATM é parte da solução

ATM

11


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Internet: inter-redesz define arquitetura independente de tecnologia de

transmissãoz protocolo de rede (IP) isola características das

camadas inferiores


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

ATM

12


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Protocolo IP:y chave da interoperabilidade da Internety simplesy não orientado a conexão


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Protocolo IP:y o roteamento de cada pacote é calculado

independentementey pacotes pertencentes ao mesmo fluxo podem ser roteados

por caminhos diferentes

13


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z IPv4: Service Type ou TOS: Type of servicen Precedência (3 bits): 0 a 7

n indica importância do datagraman informação de controle sobre dados (ex.: controle de congestionamento)

n bit D: indica baixo atrason bit T: alto throughputn bit R: maior confiabilidade

y “dicas” para os algoritmos de roteamenton escolha dos links físicos disponíveis

y a rede não garante o tipo de serviço pedidoy raramente suportado


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z como “reservar” recursos para dar garantias dequalidade?

EqTerm

R

R R

R R

R

R

EqTerm

14


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Razões do TCP:y protocolo IP

n pacotes podem seguir por diferentes caminhos: nãogarante ordenação dos pacotes

n roteadores podem estar congestionados e descartarpacotes: não garante entrega dos pacotes


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Problemas de TCPy garante chegada baseado em retransmissões - atrasoy aplicações tempo real normalmente toleram melhor a falta de

dados do que seu atraso excessivon retransmissões perdem sentidon introduzem overhead

15


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Internet

z Problemas de TCPy ordena os dados, mas não preserva a relação temporal entre

fonte e destinoy aplicações tempo real normalmente podem lidar com dados

desordenadosn ordenação dos dados perde sentido

z novos requisitos aos protocolos de transporte


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Alguns Esforços na Internet

z IETF - Internet Engineering Task Forcey Grupo Int-serv:

concepção da arquitetura Internet para suporte a integração de serviços

y Grupo RSVP: Resource Reservationconcepção de um esquema para reserva de recursos na internet

y Grupo IETF MMUSIC: Multiparty Multimidia Session Controldesenvolvimento do SIP - protocolo para controle de sessões multiponto(conferências) - serve para telefonia na internet

16


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Arquitetura estendida da InternetSuporte a Integração de Serviços


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Restante da Apresentação

z IPv6 - contribuição para qualidadez Reserva de recursos: RSVPz Protocolos de transporte para tempo real: RTPz Protocolos voltados a aplicações:

RTSP e SIP

17


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

IPv6


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

IPv6IPv6

z Resolver problemas existentes no IPv4y espaço de endereçamentoy tamanho das tabelas de roteamentoy segurança

z Adequar as novas tecnologia de redesz Tratar voz e vídeo - maior importância ao tipo de serviço

18


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

IPv6

z Qualidade: flow labelsy usado para distinguir pacotes que devem receber o mesmo tratamentoy todos pacotes tem mesmo destino e devem conter as mesmas opções para os

roteadores no caminhon cabeçalho hop-by-hop (até agora tamanho do pacote)n cabeçalho de extensão de roteamento

y ao receber um pacote com flow especificado, roteador pode consultar tabelade flows e saber o caminho por onde enviar o pacoten “caching”


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

Qualidade no IPv6

z flow labelsy estabelecer o identificador do flow e determinar seu tempo de validade é

responsabilidade de outros protocolos, e não do IPv6

n ex.: Resource reSerVation Protocolo (RSVP)

19


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP -Resource reSerVation Protocol


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Reserva de recursos - razõesy Serviço best-effort

n não garante entrega dos dadosn não garante ordenação dos dadosn não garante valores de vazão e latência

y aplicações com tráfego tempo realn algumas podem usar este serviço

n reordenando dados (uso de RTP)n aceitando algumas perdas

n outras aplicações precisam mais que isto

20


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Reserva de recursos - razõesy outras aplicações precisam mais que serviço best-effort

n para atingir garantias >> necessário reservar recursos darede para cada aplicação

n RSVP:n suporta um serviço de reservan define como aplicações podem pedir e liberar reservas


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Sem reserva: compartilhamento igualitárioy alocação de 10 Mbit/s para vídeoy 10 Mbit/s para a transferência de arquivoy resultado: vídeo prejudicado, arquivo poderia ter pequeno atraso

a mais

EqTerm EqTerm

Rede 20 Mbit/s

EqTerm EqTermTransferencia de arquivotemporária de 13 Mbit/s

Vídeo em tempo real a 12 Mbit/s

21


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Roteadores

y poderiam fazer a reserva de recursos apropriada para o casoy no entanto eles não sabem qual é a reserva necessária para cada

fluxo

z Com RSVPy Aplicações pré-informam suas necessidades

n Vídeo informa necessidade de 12 Mbit/sn Roteadores limitam pico de tráfego de transferência de arquivo a

8 Mbit/sy rede pode negar a reserva (recursos ñ disp)


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Funcionamento do protocoloy noções básicas: fluxos e reservas

n fluxo é uma conjunto de pacotes carregando dadoscontínuos de uma mesma mídia

n datagramas pertencentes a um mesmo fluxo devem ter omesmo tipo de tratamento

n fluxos são identificados por combinações de endereçosfonte e destino e do flow label de cabeçalho IPv6

22


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP


n reservas são feitas para fluxosn RSVP identifica a qualidade de serviço que um fluxo

necessitan flowspecn campo “opaco” - o protocolo RSVP não processan hosts e roteadores analisam o flowspec e verificam se podem

suportar a reserva

n fluxos unicast e multicast são suportadosn mesmo serviço


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP


n reservas são iniciadas pelos receptoresn ao contrário da maioria de protocolos de reservan melhor tratamento de fluxos multicastn como o receptor sabe do fluxo para poder reservar ?

espera-se que seja resolvido pela aplicação:• anúncio prévio de fluxo• anúncio periódico durante o tempo de vida do fluxo• ambos• (anúncios não necessitam reserva de recursos)

23


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Funcionamento do protocolon como saber o caminho descrito pelo fluxo ?

n Cliente de difusão de vídeo sabe a fonte da difusão mas não sabe ocaminho descrito pelo fluxo ?

n caminho de ida pode ser diferente do caminho de voltan caminho pode variar

EqTerm EqTerm

Rede

Rede

RedeRede


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Funcionamento do protocoloy mensagens Path

n geradas pelo originador do fluxo para o mesmo endereçodestino do fluxo

n trafegam na mesma direção do fluxo de dados e descrevemmesmo caminho

EqTerm EqTerm

Rede

Rede

RedeRede

24


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP


n ao passar pelos roteadoresn grava na mensagem os roteadores do caminhon identifica o fluxo para o roteadorn “avisa” a possibilidade de reservan cada roteador olha na mensagem e guarda o roteador anterior para

aquele fluxo:• se roteador pedir reserva do fluxo, sabe o anterior do caminho

para mandar a reserva adiante (em direção à fonte)


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP


n função básica: “gravar” o caminhon podem servir também para descrever o fluxo para seus

receptoresn se descrição for complexa: realizar separado

senão (apenas alguns bytes são suficientes):• mensagens path podem ser usadas

25


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Funcionamento do protocoloy mensagens Reservation

n mandada no caminho obtido via mensagem pathn pede para reservar recursos para um fluxo

EqTerm EqTerm

Rede

Rede

RedeRede

DATA

PATH

RESV

DestinoFonte DATA

PATH

RESV

DATA

PATH

RESV


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Redes dinâmicas

y falhas nos roteadoresn soft-state

n recursos são mantidos enquanto pedidos de reserva forem mandadosregularmente

n fonte sempre manda path messagesn se rede mudar: e.g. link fica ativo / inativo

mensagens path subsequentes atualizam caminhon reservas passam a acontecer no caminho novon antigas reservas caem por não confirmação

26


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Cenários multicast

y RSVP voltado a cenários com muitos destinatáriosn serviços de difusão: rádio, tvn conferênciasn escalabilidade ?

n Habilidade para suportar número grande de usuários


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Cenários multicasty baseia-se em suporte existente para formar grupos

n IGMP, MOSPF, Mrouters, etc.y “merge” de reservas

n realizados pelos roteadores no caminhon só precisa reservar o necessário para chegar à porção já

reservada da “multicast tree”n com aumento do número de participantes, diminui a

possibilidade de que entrada de mais um afete o fonte

27


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Cenários multicasty “merge” de reservas

Ramo não reservado

Ramo reservado

Merge de reservas

Modificação eventual


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Cenários multicasty “merge” de reservas

n depende do roteadorn normalmente combina os melhores valores de vazão,

atraso, e variância de atraso e pede reserva para oanterior

Ramo não reservado

Ramo reservado

Merge de reservas

28


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz E conferências ?


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


29


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti



Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Estilos de Reservas

y Fixed Filter: para um fluxo particulary Shared Explicit: reserva para vários fluxos especificados - os

fluxos compartilham os recursos reservadosy Wildcard Filter: reserva recursos para um tipo de fluxo, todos

fluxos deste tipo compartilham os recursos

30


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Estilos de Reservas

y Exemplos:n conferências de áudio: normalmente nem todos falam ao

mesmo tempo - não há necessidade de reserva fixa paracada fluxo.n Shared Explicit ou Wildcard Filter podem ser usadas


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Impossibilidade de Reserva

y várias razões de erro:n admission failure

n limite de atraso não pode ser garantidon largura de banda requisitada não existen serviço conflitante (?)n serviço não suportado (?)n especificação de fluxo erradan período máximo de “refresh” muito pequeno

31


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy trafegam sobre IPy IP next header = 46y pode ser sobre UDP (mais usado se IPv4)


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

ReservedChecksum

VersionFlags

RSVP type

Message IdentifierFragment Offset

Body of RSVP Message

IP Header

Msg Length

Reserved

More Fragments

32


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy versão = 2y flags - extensõesy tipo:

n 1 path,n 2 reservation,n 3 error para path messagen 4 error para reservation messagen 5 path teardownn 6 reservation teardown


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy últimos 3 campos: para fragmentação da mensagemy message identifier: = para cada fragmento da originaly restante do corpo da mensagem: conjunto de objetos

n cada objeto tem mesmo formato básico

33


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy objetos tem mesmo formato básico

ClassNum

Object Contents

Object Length ClassType


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy objetos:

n 0 nulln 1 sessionn 3 rsvp_hopn 4 integrityn 5 time_valuesn 6 error_specn 7 scopen 8 style

34


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

z Mensagens do protocoloy objetos:

n 9 flowspecn 10 filter_specn 11 sender_templaten 12 sender_tspecn 13 adspecn 14 policy_datan 20 tag


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVPz Mensagens do protocolo

y Path messages:n destinationn previous hopn frequencia de refreshn flown outros opcionais

35


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


y Reservation requestsn podem ser complicadosn session: endereço destinon rsvp_hop: último sistema a manipular o pedido de reservan time_values: frequencia de refreshn style: tipo da reservan flowspec: especificação do fluxo


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti


y Errosn Path error

n sessionn sender_templaten error_spec

n Reservation errorn sessionn stylen flowspecn filter_specn error_spec

36


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RSVP

Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Real Time Protocol(RTP)

37


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Lembrando ...y Protocolo TCP:

n entrega garantida com retransmissões perde o sentidon entrega ordenada, porém sem preservar a relação temporal

da fontey novos requisitos a protocolos de transporte para tráfego tempo

real


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTPz Aplication layer framing (ALF)

y D.D.Clark e D.L.Tennenhouse. Sigcomm, IEEEy propõe a troca de protocolos como TCP por um framework que

aplicações podem utilizar diretamentey reduz overhead de processamento:

n camadas de protocolos normalmente utilizam comunicaçãoentre processos (IPC)

n aplicações podem diretamente utilizar chamadas de bibliotecas(ALF) - melhor performance

38


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z RTPy uma parte do application layer framing (ALF)y não especifica de fato um protocolo completoy define

n regras básicasn operaçõesn formato de mensagens

y aplicações específicas partem destas definições e adicionam,formando um protocolo


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

RTPUDP

IPREDE

X

IPC

Chamada alibs

•Protocolos de controle:

• usina nuclear;

• produção - chão de fábrica;

• sistemas de tráfego;

• ...

•Dados multimídia:

• áudio;

• vídeo;

• combinações

•........

39


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z RTPy exemplo

n formatos de codificação MPEG, JPEG, H.621n RTP é um framework viável a todos

RTPUDP

IPREDE

MPEG JPEGH.621

IPC

Chamada alibs


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Relação temporal das mensagensy rede não preserva esta relaçãoy reconstrução:

n timestampsn fonte marca mensagem com timestamp relativon receptor pode reproduzir dados no mesmo tempo relativon quase toda aplicação tempo real necessita timestamps - faz

parte do RTPn aplicações com requisitos mais sofisticados devem modelar

isto como parte da sua comunicação

40


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Operação Multicasty RTP é voltado a conferênciasy muitos participantes - multicasty participantes de uma conferência pertencem a um grupo

multicast


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Translators e Mixersy além de originadores e receptores:

translators e mixersn não são obrigatóriosn residem no caminho dos dadosn processam pacotes RTP

41


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Translatorsy traduzem de um formato de dados para outroy exemplo:

n transformar qualidade dos dados de forma a transmitir porcanais de baixa largura de banda

y mais simples que mixersy economia de recursosy usuários com rede de acesso “estreita” podem se tornar

participantes


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Mixersy combinam múltiplos streams de dados em um, preservando a

informaçãoy particularmente efetivo para áudio

n combinação dos dados enquanto tráfego na rede tem quasemesmo efeito para o ouvido humano que reproduçãosimultânea de várias fontes de áudio

y economia de recursosy usuários com rede de acesso “estreita” podem se tornar

participantes

42


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Tráfego RTPy freqüentemente usado sobre UDP mas pode ser com outros

protocolos de transportey tráfego RTP não tem porta específica - várias aplicações podem

usar RTPy porta 5004 é uma porta default reservada para RTP se a

aplicação não tiver outra porta disponívely sempre uso de porta pary valor da porta + 1 = porta para tráfego RTCP associado


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy mesmo formato para todas mensagensy header compacto- baixo overhead

n aplicações tempo real (multimídia) tendem a ser volumosasn acréscimo de cabeçalho pode ser significativo

43


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato dasmensagens

TimestampSequence Number

VersionPadding

ExtensionContributor Count

Payload typeMarker

Synchronization Source Identifier(first) Contributing Source Identifier

(last) Contributing Source Identifier...

Application Data

UDP Header

IP Header


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy versão: corrente é 2y padding: informa se houve enchimento - se ligado o último byte

de dados informa quantos bytes de enchimento foramadicionados (completar múltiplos de 4 bytes)

y extension: ligado se existe um cabeçalho de extensão - aindanão foram definidos

44


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy contributor count

n diz quantos identificadores de fonte a mensagem temn máximo de 15 fontesn se mixer tem que combinar mais fontes, somente 15 serão

identificadasy marker

n disponível para aplicações sinalizarem o que desejarn normalmente usado para identificar limites nos seus dados


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy payload type

n 0 a 15: áudion O: PCMUn 1: 1016n 2: G721n 3: GSMn 4: unassignedn 5: DVI4 (8KHz)n 6: DVI4 (16 KHz)n ...

45


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy payload type

n 16 a 22: unassigned áudio;n 23 a 33: vídeo

n ...

n 34 a 71: unassigned vídeon 72 a 76: reservadon 77 a 95: unassignedn 96 a 127 dynamic


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Formato das mensagensy Synchronization source identifier (SSRC)

n identifica o original enviador da mensagemn i.e., o sistema que definiu o timestamp e número de

seqüência dos dadosn tomado randomicamente pelos enviadoresn resolução de conflito de identificadoresn translators preservam esta informaçaon mixers:

n coloca seu identificador como o SSRCn fontes originais tornam-se Contributing source (CSRC)

46


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTP

z Controley necessidade de reportsy funções em um protocolo separado:

Real Time Control Protocol (RTCP)y RTP: só dados


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Tipos de mensagensy 200: Sender Reporty 201: Receiver Reporty 202: Source Descriptiony 203: Byey 204: Application Specific

47


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Sender Reporty enviados periodicamente por fontes de dadosy outros participantes sabem o que deveriam ter recebido deste

fontey versão: 2y paddingy número de blocos de receptoresy tamanho do pacote em bytes


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Sender Reporty SSRC identifier do enviadory NTP timestamp

n tempo absoluton segundo Network Time Protocoln nro de segundos desde 1/1/1900

y RTP timestamp: permite ordenação dos reports em relação aospacotes de dados do RTP

48


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Sender Reporty número de pacotes enviados por este originadory número de bytes enviados por este originadory próximos blocos: receiver blocks

n originador informa não só sobre dados transmitidosn informa também sobre dados RTP que recebeu


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z receiver blocksn um bloco para cada fonte remotan fração de pacotes daquela fonte que foram perdidos - desde

o último reportn número total de pacotes perdidosn maior número de seqüência de pacote recebido da fonten interarrival jitter: estimativa da variação do atraso da

chegada de pacotes.n Jitter 0: chegada regularn jitter alto: chegada muito irregular

49


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z receiver blocksn dois últimos campos do bloco: referentes ao último sender

report da fonte referente ao blocon 2 bytes do meio do NTP timestampn tempo decorrido desde aquele report e a geração deste pacote


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

z RTCPSenderReport

SSRC of SenderLengthPtype 200 RcvCntV

NTP Timestamp

Senders Packet CountRTP Timestamp

Senders Byte CountSSRC of first source

Extended Highest Sequence Number Received

Time of Last Sender ReportInterarrival Jitter

Time since Last Sender Report

Cumulative Packets Lost% Lost

SSRC of last source





.......

Application Specific Information

50


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Receiver Reporty quando entidade não é fonte, deve mandar reports sobre os

dados recebidosy receiver reports: um conjunto de receiver blocks


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

z RTCPReceiverReport SSRC of Sender

LengthPtype 201 RcvCntV

SSRC of first source





SSRC of last source





.......

Application Specific Information

51


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Source Description Packety enviadores mandam informação sobre si mesmoy conjunto de identificadores de fontes e itens descrevendo cada

umy cada item tem um código de tipo e tamanho associado


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Source Description Packety tipos de itens

n CNAME: nome único, não ambiguon NAME: nome do usárion EMAILn PHONEn LOC: localização geográfican TOOL: aplicação gerando os dadosn NOTEn PRIV: extensões

52


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

z RTCPsourcedescriptionpacket

SSRC or CSRC of first SourceLengthPtype 202 SrcCntV

SDES Items

SSRC or CSRC of second Source

SDES Items

SSRC or CSRC of last Source

SDES Items


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Bye Messagey anuncia a saída de uma fontey outros participantes poderiam notar a saída sem esta

mensagem, mas com ela o processo torna-se mais rápidoy importante para mixers

53


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

z RTCPbyemessage

SSRC of first SourceLengthPtype 203 SrcCntV

SSRC of second Source

Reason for leaving

SSRC of last SourceR Length


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Outros aspectosy Mensagens específicas de aplicações: tipo 204

n aplicações podem experimentar novas mensagensn se uma mensagem vier a ser útil, pode ser incorporada ao

RTCP como um tipo oficialy mensagens RTCP podem ser combinadas em datagramas

UDP - compound packetn estatísticas devem ser tão frequentes quanto possível

54


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Operação Multicast: reportsy reports para o grupo multicasty todos participantes sabem a qualidade percebida pelos outros

(problema é só comigo ou com todo mundo ?)y monitoração de qualidade pode ser feita facilmente - basta

juntar-se ao grupo multicast e receber reports de todosparticipantes


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Operação Multicast: reportsy sem cuidado: reports podem tomar faixa considerável da

largura de banda disponívely regras:

n manter limites de tráfego RTCP constante, independente donúmero de fontes envolvidosn como pacotes são multicast, todos participantes sabem o número de

outros participantes enviando reportsn se número de participantes aumenta, freqüência de reports baixan cooperação entre as entidades

55


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTCP

z Operação Multicast: reportsy regras:

n aleatoriedade na geração de reportsn com geração de reports em intervalos fixos (calculados segundo

mesmos algoritmos), enviadores poderiam sincronizarn poderia haver picos de carga na reden cada enviador randomiza o intervalo calculado (de 0.5 a 1.5 x o

intervalo calculado)n obtém distribuição no tempo dos reports


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTSP -Real Time Streaming Protocol

56


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTSP

z Suporte a gravação e recuperação de mídias contínuas

ClienteServidor Áudio

Servidor Vídeo

HTTP GET

Servidor Web

s.d.

PLAY -2

OK

OK

SETUP-1

SETUP-1PLAY -2


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

RTSPMétodo Direção Objeto RequerimentoDESCRIBE C → S Apr, Str Recomendado

ANNOUNCE C → S, S → C Apr, Str OpcionalGET_PARAMETER C → S, S → C Apr, Str Opcional

OPTIONS C → S, S → C Apr, Str RequeridoPAUSE C → S Apr, Str Recomendado

PLAY C → S Apr, Str RequeridoRECORD C → S Apr, Str OpcionalREDIRECT S → C Apr, Str Opcional

SETUP C → S Str RequeridoSET_PARAMETER C → S, S → C Apr, Str Opcional

TEARDOWN C → S Apr, Str Requerido

57


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

SIP -Session Initiation Protocol


Fac

uld

ade

de

Info

rmát

ica

- P

UC

RS

Fern

ando

Luí

s D

otti

SIP

z Protocolo de sinalização paray estabelecer, modificar, terminar chamadas

INVITE [email protected]: [email protected]: [email protected]: [email protected]

ls

[email protected]

anything.com

200 OK

exemplo.br

Servidor de nomes

tune

ks

B

B@

ks

INVITE

200 OK

ACKACK

Documents

Integração de Serviços na - inf.pucrs.brfldotti/redes/aulas/IS-2-fundoClaro.pdf · n bit T: alto throughput n bit R: maior confiabilidade y “dicas” para os algoritmos de roteamento