Protocolos Referência: Slides extraídos do material dos professores Jim Kurose e Keith Ross relativos ao livro Redes de Computadores e a Internet – Uma.

Apresentação em tema: "Protocolos Referência: Slides extraídos do material dos professores Jim Kurose e Keith Ross relativos ao livro Redes de Computadores e a Internet – Uma."— Transcrição da apresentação:

1 Protocolos Referência: Slides extraídos do material dos professores Jim Kurose e Keith Ross relativos ao livro Redes de Computadores e a Internet – Uma abordagem top- down, segunda e terceira edições Alterações nos slides, incluindo sequenciamento, textos, figuras e novos slides, foram realizadas conforme necessidade

2 Real Time Streaming Protocol: RTSP HTTP Projetistas do HTTP tinham mídias fixas em mente: HTML, imagens, applets, etc. HTTP não pretende tratar mídia contínua armazenada (isto é, aúdio, vídeo, apresentações SMIL, etc.) RTSP: RFC 2326 Protocolo de aplicação do tipo cliente-servidor. Permite ao usuário controlar apresentações de mídia contínua: voltar ao início, avançar, pausa, continuar, seleção de trilha, etc… O que ele não faz: não define como o aúdio e o vídeo é encapsulado para transmissão sobre a rede não restringe como a mídia contínua é transportada: pode usar UDP ou TCP não especifica como o receptor armazena o aúdio e o vídeo RealNetworks Servidor e transdutor usam RTSP para enviar informações de controle de um para o outro

3 RTSP: controle fora da banda FTP usa um canal de controle fora-da-banda: Um arquivo é transferido sobre um canal. Informação de controle (mudanças de diretório, remoção de arquivos, trocas de nomes, etc.) é enviada sobre uma conexão TCP separada. Os canais dentro-da- bandae fora-da- bandausam diferentes números de portas. Mensagens RTSP também são enviadas fora-da-banda: As mensagens de controle RTSP usam diferentes números de portas em relação ao fluxo de dados de mídia contínua, e, portanto, são enviados fora-da-banda. O fluxo de dados de mídia contínua cuja estrutura de pacotes não é definida pelo RTSP, é considerada dentro- da-banda. Se as mensagens do RTSP usassem os mesmos números de portas do fluxo de mídia contínua, então as mensagens RTSP seriam consideradas como intercaladas com o fluxo de mídia contínua.

4 Iniciação do RTSP e controles de entrega Cliente obtém uma descrição da apresentação multimídia, que pode consistir de vários fluxos de dados. O browser chama o transdutor de mídia (aplicação auxiliar) com base no tipo de conteúdo da descrição da apresentação. A descrição da apresentação inclui referências aos fluxos de mídia usando o método rtsp:// Transdutor envia o comando RTSP SETUP; servidor envia a resposta RTSP SETUP. Transdutor envia o comando RTSP PLAY; servidor envia a resposta RTSP PLAY. O servidor de mídia descarrega o fluxo de mídia. Transdutor envia o comando RTSP PAUSE; o servidor envia a resposta RTSP PAUSE. Transdutor envia o comando RTSP TEARDOWN; servidor envia a resposta RTSP TEARDOWN. HTTP GET SETUP PLAY media stream PAUSE TEARDOWN media player Web server media server Web browser clientserver presentation desc. Transdutor de mídia Servidor de mídia cliente servidor descr. apresent. fluxo de mídia

5 Sessão RTSP Cada sessão RTSP tem um identificador de sessão, que é escolhido pelo servidor. O cliente inicia a sessão com o comando SETUP, e o servidor responde ao comando com um identificador. O cliente repete o identificador de sessão em cada comando, até que o cliente encera a sessão com o comando TEARDOWN. O número de porta do RTSP é 554. RTSP pode ser usado sobre UDP ou TCP. Cada mensagem RTSP pode ser enviada numa conexão TCP separada.

6 Real-Time Protocol (RTP) RTP especifica uma estrutura de pacotes que transportam dados de aúdio e vídeo: RFC 1889. pacote RTP oferece identificação do tipo de conteúdo numeração da seqüência de pacotes marcas de tempo RTP roda nos sistemas terminais. os pacotes RTP são encapsulados em segmentos UDP Interoperabilidade: se duas aplicações diferentes de telefonia IP usam RTP, então elas podem ser capazes de trabalhar juntas

7 RTP roda em cima do UDP As bibliotecas do RTP fornecem uma interface de camada de transporte que extende o UDP: número de portas, endereços IP verificação de erros dentro dos segmentos identificação do tipo de conteúdo numeração da seqüência de pacotes marcas de tempo Aplicação Enlace Física camada de transporte

8 RTP: Exemplo Considere enviar 64 kbps de voz codificada em PCM sobre RTP. A aplicação reúne dados codificados em blocos, por exemplo, a cada 20 ms = 160 bytes por bloco. O bloco de aúdio, junto com o cabeçalho RTP forma o pacote RTP, que é encapsulado num segmento UDP. O cabeçalho RTP indica o tipo de codificação de aúdio 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.

9 Fluxos RTP RTP permite atribuir a cada fonte (por exemplo, uma câmara 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 aúdio (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 aúdio e o vídeo num único fluxo durante o processo de codificação. Quando o aúdio e o vídeo são reunidos pelo codificador, então apenas um fluxo RTP é gerado em cada direção.

10 Cabeçalho RTP 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. Tipo de Carga Número de Seqüência Marca de tempo Identificador sincronismo fonte campos de miscelânias Cabeçalho RTP

11 Campo de marca de tempo (32 bytes). 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. Cabeçalho RTP (2)

12 Real-Time Control Protocol (RTCP) Trabalha em conjunto com o RTP. Cada participante de uma sessão RTP transmite periodicamente pacotes de controle RTCP para todos os outros participantes. Cada pacote RTCP contém relatórios do transmissor e/ou do receptor que são úteis para a aplicação. As estatísticas incluem o número de pacotes enviados, número de pacotes perdidos, variação de atraso entre chegadas, etc. Esta informação de realimentação para a aplicação pode ser usada para controle do desempenho e para fins de diagnóstico. O transmissor pode mudar suas transmissões com base nestas informações de realimentação.

13 RTCP - Continuação - Os pacotes RTP e RTCP são distintos um dos outros pelo uso de números de portas diferentes. - Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o número de participantes da conferência aumenta.

14 Pacotes RTCP Pacotes de relatório do receptor: fração de pacotes perdidos, último número de seqüência, variância média do atraso entre chegadas. Pacotes de relatório do transmissor: SSRC do fluxo RTP, o tempo corrente, o número de pacotes enviados e o número de bytes enviados. Pacotes de descrição da fonte: endereço de e-mail do transmissor, o nome do transmissor, o SSRC do fluxo RTP associado. Esses pacotes fornecem um mapeamento entre o SSRC e o nome do usuário ou do host.

15 Sincronização de Fluxos RTCP pode ser usado para sincronizar diferentes fluxos de mídia numa sessão RTP. Considere uma aplicação de videoconferência para a qual cada transmissor gera um fluxo RTP para aúdio e um para vídeo. As marcas de tempo nestes pacotes são vinculadas aos relógios de amostragem de vídeo e de aúdio, mas não são vinculadas a um relógio de tempo real (isto é, a um relógio de parede). Cada pacote relatório-do- transmissor RTCP contém para o último pacote gerado no fluxo RTP associado, a marca de tempo do pacote RTP e o instante de tempo real no qual o pacote foi criado. Desta forma o pacote RTCP relatório-do- transmissor associa o relógio de amostragem com o relógio de tempo real. Receptores podem usar esta associação para sincronizar a reprodução de aúdio e de vídeo.

16 Controle de Banda do RTCP O RTCP procura limitar seu tráfego a 5% da banda passante da sessão. Por exemplo, suponha que existe um transmissor enviando vídeo com uma taxa de 2 Mbps. Então o RTCP procura limitar seu tráfego a 100 Kbps. O protocolo dá 75% desta taxa, ou 75 kbps, para os receptores; ele dá os 25% restantes da taxa, isto é, 25 kbps, para o transmissor. Os 75 kbps dedicados aos receptores são divididos de forma igual entre todos os receptores. Assim, se existem R receptores, cada receptor consegue enviar tráfego RTCP a uma taxa de 75/R kbps e o transmissor envia tráfego RTCP a uma taxa de 25 kbps. Um participante (um transmissor ou receptor) determina o período de transmissão de pacotes RTCP dinamicamente calculando o tamanho médio do pacote (durante toda a sessão) e dividindo o tamanho médio do pacote RTCP pela sua taxa alocada.

17 Recuperação de perdas de pacotes (1) Perdas: pacote nunca chega ou chega depois do seu tempo de reprodução programado correção de erro de envio (FEC): esquema simples para cada grupo de n blocos cria um bloco redundante realizando uma operação OU exclusivo entre os n blocos originais envia os n+1 blocos, aumentando a banda passante por um fator de 1/n. pode reconstruir os n blocos originais se houver no máximo um bloco perdido nos n+1 blocos enviados Atraso de reprodução precisa ser definido para receber todos os n+1 pacotes Compromisso: aumentar n, menor disperdício de banda aumentar n, maior atraso de reprodução aumentar n, maior a probabilidade que dois ou mais blocos sejam perdidos

18 2o, esquema FEC enviar um fluxo de menor qualidade como carona envia fluxo de aúdio de menor resolução como a informação redundante por exemplo, um fluxo PCM nominal a 64 kbps e um fluxo GSM redun- dante a 13 kbps. Transmissor cria pacote tomando o bloco n do fluxo nominal e anexando a ele o bloco (n-1) do fluxo redun- dante Sempre que ocorre perda não-consecutiva, o receptor pode esconder a perda. Apenas dois pacotes precisam ser recebidos antes do início da reprodução Pode também anexar os blocos (n-1) e (n-2) do fluxo de baixa qualidade Recuperação de perdas de pacotes (2) Fluxo original Redundância Perda de Pacote Fluxo reconstruído

19 Intercalação blocos são quebrados em unidades menores por exemplo, 4 blocos de 5 ms cada intercalar os blocos como mostrado no diagrama pacote agora contém unidades menores de diferentes blocos Remontar os blocos no receptor Se o pacote é perdido, ainda resta mais de cada bloco Recuperação de perdas de pacotes (3) Fluxo original Fluxo intercalado Perda de pacote Fluxo reconstruído

20 Recuperação pelo receptor de fluxos de aúdio danificados produzir uma substituição para um pacote perdido que seja similar ao pacote original pode produzir bons resultados para baixas taxas de perdas e pacotes pequenos (4-40 ms) estratégia mais simples: repetição estratégia mais complexa: interpolação Recuperação de perdas de pacotes (4)

21 H.323 - Visão Geral (1) Base para conferência de aúdio e de vídeo através de redes IP. Objetiva comunicação de tempo real (ao invés de por demanda) Recomendação quarda- chuva do ITU-T. Escopo largo: equipamentos isolados (ex., telefones Web) aplicações em PCs conferências ponto-a- ponto e multiponto A especificação H.323 inclui: Como os equipamentos terminais fazem e recebem chamadas. Como os equipamentos terminais negociam codificações comuns de aúdio e vídeo. Como os blocos de aúdio e vídeo são encapsulados e enviados para a rede. Como o aúdio e o vídeo são sincronizados entre si. Como os equipamentos terminais se comunicam com seus respectivos gatekeepers. Como os telefones IP e os telefones PSTN/ISDN convencionais se comunicam.

22 Chamadas telefônicas Chamadas de vídeo Conferências Quadros brancos Todos os terminais suportando H.323 Telefone "Ethernet" MS Netmeeting NetSpeak WebPhone H.323 - Visão Geral (2)

23 H.323SS7, Inband H.323 - Visão Geral (3)

24 Terminais H.323 Devem Suportar: G.711 - padrão do ITU para compressão de voz RTP - protocolo para encapsular blocos de dados de mídia em pacotes H.245 - Protocolo de controle fora-da-banda para controlar a mídia entre os terminais H.323. Q.931 - Um protocolo de sinalização para estabelecer e encerrar chamadas. RAS (Registration/Admission/S tatus) protocolo de canal - Protocolo para comunicação com o gatekeeper (se um gatekeeper está presente)

25 Terminal H.323

26 Codificação H.323 Aúdio: Terminais H.323 devem suportar o padrão G.711 para compressão de voz e transmissão a 56/64 kbps. H.323 está considerando exigir a codificação G.723 = G.723.1, que opera a 5.3/6.3 kbps. Opcionais: G.722, G.728, G.729 Vídeo Capacidade de vídeo para um terminal H.323 são opcionais. Qualquer terminal H.323 com capacidade de vídeo deve suportar o formato QCIF H.261 (176x144 pixels). O suporte a outros esquemas da recomendação H.261 é opcional: CIF, 4CIF e 16CIF. H.261 é usado com canais de comunicação cuja taxa de transmissão é múltipla de 64 kbps.

27 Gerando fluxo de pacotes de aúdio no H.323 Fonte de Aúdio Codificação: ex., G.711 ou G.723.1 encapsulamento de pacote RTP porta UDP Internet ou Gatekeeper

28 Canal de Controle H.245 O fluxo H.323 pode conter múltiplos canais para diferentes tipos de mídia. Um canal de controle H.245 por sessão H.323. O canal de controle H.245 é um canal confiável (TCP) que transporta mensagens de controle. Principais tarefas: Abrir e fechar canais de mídia. Troca de informações de capacidades: antes de enviar dados os terminais devem concordar sobre o algoritmo de codificação Nota: H.245 para conferência multimídia é análogo ao RTSP para mídia contínua armazenada

29 Fluxos de Informação

30 Gatekeeper 1/2 O gatekeeper é opcional. Pode oferecer aos terminais: translação de endereços para endereços IP gerenciamento de banda-passante: pode limitar o total de banda-passante consumida pelas conferências de tempo real Opcionalmente, as chamadas H.323 podem ser roteadas através do gatekeeper. Conveniente para bilhetagem. Protocolo RAS (sobre TCP) para comunicação entre terminal-gatekeeper. terminais H.323 Gatekeeper Rote ador Internet LAN = Zona RAS

31 Gatekeeper 2/2 Terminal H.323 deve se registrar com o gatekeeper na sua zona. Quando a aplicação H.323 é chamada no terminal, o terminal usa o RAS para enviar seu endereço IP e apelido (alias) fornecido pelo usuário ao gatekeeper. Se o gatekeeper está presente numa zona, cada terminal da zona deve contacta-lo para pedir permissão para realizar uma chamada. Uma vez que ele obtém a permissão, o terminal pode enviar ao gatekeeper um endereço de e-mail, um nome de referência (alias) ou uma extensão de telefone. O gatekeeper translada o nome de referência num endereço IP. Se necessário, o gatekeeper poderá consultar outros gatekeepers em outras zonas para resolver um endereço IP. O processo varia entre os fornecedores.

32 Gateway Terminais H.323 Gatekeeper Router Internet LAN = Zona RAS Gateway PSTN Ponte entre a zona IP e as redes PSTN (ou ISDN). Terminais se comunicam com gateways usando H.245 e Q.931

33 SIP Session Initiation Protocol Desenvolvido pelo IETF Visão de longo prazo do SIP Todas chamadas telefônicas e chamadas de videoconferência ocorrem sobre a Internet Pessoas são identificadas por nomes ou endereços de e-mail, em vez de números telefônicos. Você pode alcançar o usuário chamado, não importa onde ele esteja, não importa o dispositivo IP que ele esteja usando atualmente. SIP

34 SIP: Serviços Serviços Estabelecendo uma chamada Provê mecanismos para o chamador deixar o usuário chamado saber que ele deseja estabelecer uma chamada Provê mecanismos de modo que o chamador e o chamado possam concordar com o tipo de mídia e codificação. Provê mecanismos para terminar a chamada. Determina o endereço IP do usuário chamado. Mapeia o identificador mnemônico para o endereço IP atual Gerenciamento de chamada Adiciona novos fluxos de mídia durante a chamada Troca a codificação durante a chamada Convida outros Transfere e retém chamadas SIP (2)

35 Estabelecendo uma chamada para um endereço IP conhecido A mensagem 200 OK de Bob indica seu número de porta, endereço IP e codificação preferida (GSM) Mensagens SIP podem ser enviadas sobre TCP ou UDP; aqui são enviadas sobre RTP/UDP. O número de porta padrão do SIP é 5060. A mensagem INVITE do SIP de Alice indica seu número de porta e endereço IP. Indica a codificação que Alice prefere receber (PCM lei-m) SIP (3)

36 Estabelecendo chamada Negociação do codec: Suponha que Bob não tenha o codificador do PCM para lei m Bob responderá então com 606 Not Acceptable Reply e listará os codificadores que ele pode usar Alice pode então enviar uma nova mensagem INVITE, anunciando um codificador apropriado Rejeitando a chamada: Bob pode rejeitar com respostas ocupado, ausente, pagamento exigido, proibido A mídia pode ser enviada sobre RTP ou algum outro protocolo SIP (4)

37 Exemplo de mensagem SIP Ex. de mensagem: INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: sip:alice@hereway.com To: sip:bob@domain.com Call-ID: a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: 885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 Notas: Sintaxe de mensagem HTTP sdp = protocolo de descrição de sessão ID de chamada (Call-ID) é único para cada chamada. Aqui não sabemos o endereço IP de Bob. Servidores SIP intermediários serão necessários Alice envia e recebe mensagens SIP usando o número 5060 de porta padrão do SIP Alice especifica através de cabeçalho que o cliente SIP envia e recebe mensagens SIP sobre UDP SIP (5)

38 Tradução do nome e localização do usuário O chamador quer chamar o usuário de destino, mas tem somente o nome do usuário ou o endereço de e-mail Precisa obter o endereço IP do hospedeiro atual do usuário chamado, sendo que: Usuário move-se livremente Pode usar protocolo DHCP Usuário possui diferentes dispositivos IP (PC, PDA, dispositivo de carro, etc) Resultado pode ser baseado em: Hora do dia (trabalho, casa) Status do chamado (chamadas enviadas para correio-de-voz quando o chamado já está falando com alguém) Serviços fornecidos pelos servidores SIP: Servidor de registro SIP Servidor proxy SIP SIP (6)

39 REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 Registro SIP Quando Bob inicia o cliente SIP, o cliente envia a mensagem SIP REGISTER ao servidor de registro de Bob (função similar necessária para mensagens instantâneas) Mensagem de registro: SIP (7)

40 Proxy SIP Alice envia a mensagem invite para o seu servidor proxy Contém endereço sip:bob@domain.com Proxy responsável por rotear mensagens SIP para o usuário chamado Possivelmente através de múltiplos proxies. O usuário chamado envia a resposta de volta através do mesmo conjunto de proxies. Proxy retorna a mensagem de resposta SIP para Alice Contém o endereço IP de Bob Nota: proxy é análogo ao servidor DNS local SIP (8)

41 Exemplo Usuário chamado jim@umass.edu que estabelece uma chamada para keith@upenn.edu (1) Jim envia mensagem INVITE para o proxy SIP umass SIP. (2) Proxy encaminha a requisição para o servidor de registro upenn. (3) servidor upenn retorna resposta, indicando que ele deveria tentar keith@eurecom.fr (4) proxy umass envia INVITE para registro eurecom. (5) registro eurecom encaminha INVITE para 197.87.54.21, que está rodando o cliente SIP de keith. (6-8) resposta SIP enviada de volta (9) mídia enviada diretamente entre clientes. Nota: também há mensagens ACK SIP, que não são mostradas. SIP (9)

42 H.323 é outro protocolo de sinalização para tempo real, interativo H.323 é um conjunto de protocolos completos e verticalmente integrados para conferência multimídia: sinalização, registro, controle de admissão, transporte e codecs. SIP é um componente monolítico. Funciona com RTP, mas não o obriga. Pode ser combinado com outros protocolos e serviços. H.323 foi desenvolvido pela ITU (telefonia). SIP foi desenvolvido pela IETF: muitos de seus conceitos vêm do HTTP. O SIP é parecido com a Web, visto que H.323 é parecido com a telefonia. SIP usa o princípio de KISS (keep it simple stupid). Comparação com H.323

43 IP Multicast : o que é? RFC 1112 IP multicasting is the transmission of an IP datagram to a host group, a set of zero or more hosts identified by a single IP destination

44 IP Multicast : o que é? Grupo multicast (endereço IP classe D) Vinculação dinâmica de fontes e receptores Duplicação de fluxos na camada de rede

45 Multicast versus Unicast Links Streams Unicast

46 Multicast versus Unicast Links Streams Multicast

47 Vantagens com Multicast Escalabilidade: sem duplicação de fluxos Redução de congestionamentos Melhor utilização de banda Suporte estrutural e eficiente a aplicações distribuídas Modelo consistente de distribuição de conteúdo

48 Desvantagens com Multicast Entrega de pacotes no estilo best effort Sem mecanismo de controle de fluxo Duplicação de pacotes Sem mecanismos de ordenamento de pacotes Multicast é baseado em UDP

49 Multicast - Aplicações Multicast enables coordination - it is well suited to loosely coupled distributed systems (of people, servers, databases, processes, devices...) RFC 3170

50 Multicast - Aplicações Conferências multimídia Distribuição de dados Multicast de dados em tempo real Simulações e Games

51 Multicast - Aplicações Um-para-muitos (1toM) distribuição programada de áudio/vídeo push media: notícias, clima, esportes, etc. distribuição de arquivos e caching anúncios monitoração

52 Multicast - Aplicações Muitos-para-muitos (MtoM) conferências multimídia processamento distribuído jogos com múltiplos jogadores colaboração

53 Multicast - Endereçamento Endereços Classe D: primeiros 4 bits do endereço devem ser 1110: 224.0.0.0 - 239.255.255.255 Para associar um host ao um grupo multicast (= end. multicast) usa-se o protocolo IGMP entre host e roteador.

54 Objetivo: encontrar uma árvore (ou árvores) conectando roteadores que possuam membros de grupo multicast local Árvore: não são todos os caminhos entre os roteadores usados Baseada na fonte: uma árvore diferente de cada transmissor para os receptores Árvore compartilhada: a mesma árvore é usada por todos o membros do grupo Roteamento multicast: indicação do problema

55 Roteamento multicast: indicação do problema(2)

56 Métodos: Árvore baseada na fonte: uma árvore por origem Shortest path trees Repasse pelo caminho reverso Árvore compartilhada pelo grupo: grupo usa uma árvore Minimal spanning (Steiner) Center-based trees Métodos para construir multicast trees

57 mcast forwarding tree: árvore de rotas de caminho mais curto da origem para todos os receptores Algoritmo de Dijkstra R1 R2 R3 R4 R5 R6 R7 2 1 6 3 4 5 i roteador com membro de grupo anexado roteador sem nenhum membro de grupo anexado link usado para encaminhamento, i indica link de ordem adicionado por algoritmo LEGENDA S: source Shortest Path Tree

58 if (datagrama mcast recebido no link de entrada do menor caminho de retorno à origem) then dispara datagramas para todos os links de saída else ignora datagrama Baseia-se no conhecimento dos roteadores sobre caminhos de unicast mais curtos dele até o transmissor Cada roteador possui comportamento de encaminhamento simples: Reverse Path Forwarding

59 Resultado é um reverse SPT de origem específica. Pode ser uma má escolha com links assimétricos R1 R2 R3 R4 R5 R6 R7 roteador com membro de grupo anexado roteador sem nenhum membro de grupo anexado datagrama será encaminhado LEGENDA S: source datagrama não será encaminhado Reverse Path Forwarding: exemplo

60 Árvores de encaminhamento contêm subárvores com membros de grupo sem multicast Não necessita encaminhar datagramas por subárvores abaixo Mensagens prune são enviadas por upstream pelo roteador com membros de grupo sem nenhum downstream R1 R2 R3 R4 R5 R6 R7 roteador com membro de grupo anexado roteador sem nenhum membro de grupo anexado mensagem prune LEGENDA S: source links com encaminhamento multicast P P P Reverse Path Forwarding: pruning

61 Steiner Tree: árvore de custo mínimo conectando todos os roteadores com membros de grupo anexados Problema é NP-completo Existe uma heurística excelente Não é usado na prática: Complexidade computacional Informação sobre toda a rede é necessária Monolítica: reexecuta sempre que um roteador precisa se juntar/deixar. Shared-Tree Steiner Tree

62 Única árvore de entrega compartilhada por todos Um roteador é identificado como centro da árvore para se juntar: Roteador de borda envia uma join-msg unicast endereçada ao roteador de centro join-msg processada pelos roteadores intermediários e encaminhada rumo ao centro join-msg ou encontra um ramo da árvore para seu centro, ou chega até o centro O caminho tomado pela join-msg torna-se um novo ramo da árvore para esse roteador Center-based trees

63 Suponha que R6 foi escolhido como centro: R1 R2 R3 R4 R5 R6 R7 roteador com membro de grupo anexado roteador sem nenhum membro de grupo anexado ordem de caminho onde são geradas mensagens join LEGENDA 2 1 3 1 Center-based trees: um exemplo

64 P.: Como conectar ilhas de roteadores multicast num mar de roteadores unicast? Datagrama mcast encapsulado dentro de um datagrama normal (sem endereço mcast) O datagrama IP normal é enviado pelo túnel via unicast IP regular para o roteador mcast receptor O roteador mcast receptor desencapsula para obter o datagrama mcast topologia física topologia lógica Tunelamento

65 IPv6 Motivação inicial: o espaço de endereços de 32-bits em processo de esgotamento. Motivações adicionais: melhorar o formato do header para permitir maior velocidade de processamento e de transmissão mudanças no header para incorporar mecanismos de controle de QOS necessidade de maior simplicidade para renumeração e autoconfiguração IPv6 formato dos datagramas: cabeçalho fixo de 40 bytes não é permitida fragmentação

66 IPv6 Header

67 IPv6 Header (2) Priority: permitir definir prioridades diferenciadas para vários fluxos de informação Flow Label: identifica datagramas do mesmo fluxo. (conceito de fluxo não é bem definido). Next header: identifica o protocolo da camada superior ou um header auxiliar

68 Formato do endereço IPv6

69 Formato do endereço Ipv6 (2)

70 Outras mudanças do IPv4 Checksum: removido inteiramente para reduzir o tempo de processamento em cada hop Options: são permitidas, mas são alocadas em cabeçalhos suplementares, indicados pelo campo Next Header ICMPv6: nova versão de ICMP tipos de mensagens adicionais, ex. Packet Too Big funções de gerenciamento de grupos multicast

71 Transição do IPv4 para IPv6 Nem todos os roteadores poderão ser atualizados simultaneamente não haverá um dia da virada universal A rede deverá operar com os dois tipos de datagramas simultaneamente presentes Duas abordagens propostas: Dual Stack: algusn roteadores com pilhas de protocolos duais (v6, v4) podem trocar pacotes nos dois formatos e traduzir de um formato para o outro Tunneling: IPv6 transportado dentro de pacotes IPv4 entre roteadores IPv4

72 Dual Stack Approach

73 Tunneling IPv6 dentro do IPv4 onde necessário

74 Update da ARIN sobre IPv6 IPv4 status, free pool da IANA c/ 24 /8's e alocação média de 10 a 12 /8's por ano Quando sobrarem apenas cinco /8's, vai um /8 para cada RIR Alocações de IPv6 crescem exponencialmente

75 Endereço Anycast Um único endereço IP atribuído a várias interfaces espalhadas numa rede Datagrama destinado a um endereço anycast é entregue em apenas uma interface Prefixo anunciado (IGP + BGP) a partir de múltiplas origens Interface de destino determinada a partir dos protocolos de roteamento (mais próxima) Potencialmente útil para a criação de sistemas de alta disponibilidade

76 Endereço Anycast (2) Exemplo de uso: DNS root-servers Redução no retardo das requisições para root-servers Melhor balanceamento da carga Escalabilidade e disponibilidade Serviço com mais imunidade a ataques de DDOS Sistema Autônomo é formado por ilhas - não há rede interna interligando os roteadores de borda!!!