03.01 IP Multicast Introdução

Transcrição

1 03.01 IP Multicast Introdução Fonte: Cisco RDC/ISEL-DEETC-SRT 1

2 Introdução Porquê Multicast? Quando se envia os mesmos dados a múltiplos receptores Melhor utilização da largura de banda disponível Menor processamento host/router Os endereços dos receptores é desconhecido à origem Aplicações Conferências áudio/vídeo Anúncios de serviços/descoberta de recursos Distribuição de stock Ex.: IPTV, Shoutcast, VLC RDC/ISEL-DEETC-SRT 2

3 Unicast/Multicast Host Unicast Router Host Multicast Router RDC/ISEL-DEETC-SRT 3

4 IP Multicast Service Model RFC 1112 Cada grupo Multicast é identificado por um endereço pretencente à classe D Membros do grupo podem estar em qualquer ponto da Internet Os membros juntam-se e abandonam do grupo e indicam isto aos seus routers Emissores e receptores são distintos Os emissores não precisam de se juntar ao grupo Os routers escutam em todos os endereços de multicast e usam protocolos de encaminhamento multicast para gerir os grupos RDC/ISEL-DEETC-SRT 4

5 IP Multicast Service Model (Cont.) Endereços de grupo Endereços classes D 3 bits de maior peso activos ( ) Desde o até Well known addresses atribuídos pela IANA Uso reservado: até todos os hosts que suportem multicast na subrede todos os routers na subrete Endereços de uso dinâmico Global scope: Limited scope: Site-local scope: /16 Organization-local scope: /14 RDC/ISEL-DEETC-SRT 5

6 IP Multicast Service Model (Cont.) Mapear endereços IP em endereços multicast da data link RFC 1112 define o OUI 0x01005e Os 23-bits de menor peso do endereço IP 23 bits do endereço IEEE (eg e ) Usado pela Ethernet RDC/ISEL-DEETC-SRT 6

7 IP Multicast Service Model (Cont.) Protocolos Host-to-Router (IGMP) Hosts Routers Multicast Routing Protocols (PIM) RDC/ISEL-DEETC-SRT 7

8 Internet Group Management Protocol IGMP Define a forma como os hosts indicam aos routers sobre qual o grupo de multicast que pretendem receber Os routers solicitam os grupos aos hosts directamente ligados O RFC 1112 especifica a primeira versão do IGMP O IGMP v2 e o IGMP v3 introduzem melhorias 0940_03F8_c1 NW97_US_106 RDC/ISEL-DEETC-SRT 8 8

9 Reverse Path Forwarding Um router encaminha um datagrama multicast se for recebido na interface usada para enviar datagramas unicast até à origem Unicast Receiver B C Source A F D E Multicast RDC/ISEL-DEETC-SRT 9

10 Reverse Path Forwarding Se a verificação de RPF tiver sucesso o datagrama é encaminhado Se falhar, o datagrama é descartado Quando um datagrama é encaminhado, é enviado através das interfaces listadas na lista de interfaces de saída O pacote nunca é encaminhado de volta pela interface RPF RDC/ISEL-DEETC-SRT 10

11 Características Source Shortest Path ou Source Distribution Tree Notação: (S, G) S = Source G = Group A B D F Receiver 1 C Receiver 2 E RDC/ISEL-DEETC-SRT 11

12 Características (2) Shared Distribution Tree Source 1 Notação: (*, G) * = All Sources G = Group A B D (Shared Root) F Source 2 C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 12

13 Características (3) Distribution trees Source tree Usa mais memória O(S x G) mas obtêm-se caminhos óptimos desde a origem até a todos os receptores, minimiza o atraso Shared tree Usa menos memória O(G) mas pode-se obter caminhos sub óptimos da origem até a todos os receptores, pode introduzir atraso extra Protocolos PIM, DVMRP, MOSPF, CBT RDC/ISEL-DEETC-SRT 13

14 Características (4) Tipos de protocolos multicast Dense-mode Comportamento de broadcast e prune Semelhante ao envio de uma emissão de rádio Sparse-mode Comportamento de entrada nos grupos explícita Semelhante ao pay-per-view RDC/ISEL-DEETC-SRT 14

15 Características (5) Protocolos dense-mode Assume uma filiação de grupo densa Os ramos que são pruned não recebem dados Podem ser grafted mais tarde para reduzir a latência do join DVMRP Distance Vector Multicast Routing Protocol Dense-mode PIM Protocol Independent Multicast RDC/ISEL-DEETC-SRT 15

16 Características (6) Protocolos sparse-mode Assume que os membros de um grupo estão espalhados ao longo de uma região grande Usa source ou shared distribution trees Entrada no grupo explícita assume que ninguém quer o pacote a não ser que o peça As mensagens de join são propagadas do receptor para a origem ou para os Rendezvous Points (PIM em modo sparse mode) ou para o Core (Core Based Tree) RDC/ISEL-DEETC-SRT 16

17 DVMRP Broadcast and prune As source trees são criadas a pedido baseadas nas regras RPF Usa a sua própria tabela de encaminhamento Ex., uso de poison reverse Muitas implementações mrouted, Bay, Cisco RFC 1075 Apareceu o draft da v3 mas caiu em desuso RDC/ISEL-DEETC-SRT 17

18 PIM Dense Mode Broadcast and prune ideal para grupos densos As source trees são criadas a pedido baseando-se na regra de RPF Se a origem fica inactiva a árvore é eliminada Problemas em escalar RFC3973 RDC/ISEL-DEETC-SRT 18

19 PIM Dense Mode Os ramos que não têm interesse nos dados são pruned Os grafts server para alguém se juntar a uma source tree já existente Usa asserts para determinar quem vai ser o forwarder para uma LAN no caso de existirem múltiplos routers a ligar a árvore a essa rede Apaga todos as ligações ponto a ponto que não sejam RPF Limita os prunes nas ligações ponto a ponto que sejam RPF RDC/ISEL-DEETC-SRT 19

20 Exemplo PIM-DM Source Link Data Control A B G C D F H E I Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 20

21 Exemplo PIM-DM (2) Source Initial Flood of Data and Creation of State A B G C D F H E I Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 21

22 Exemplo PIM-DM (3) Source Prune to Non-RPF Neighbor A B Prune G C D F H E I Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 22

23 Exemplo PIM-DM (4) Source C and D Assert to Determine Forwarder for the LAN, C Wins A B G C Asserts D F H E I Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 23

24 Exemplo PIM-DM (5) Source I Gets Pruned E s Prune is Ignored G s Prune is Overridden A B Prune G C D F Join Override Prune H E I Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 24

25 Exemplo PIM-DM (6) Source New Receiver, I Sends Graft A B G C D F Graft H E I Receiver 1 Receiver 3 Receiver 2 RDC/ISEL-DEETC-SRT 25

26 Exemplo PIM-DM (7) Source A B G C D F H E I Receiver 1 Receiver 3 Receiver 2 RDC/ISEL-DEETC-SRT 26

27 PIM Sparse Mode Modelo de entrada em grupo (join) explícita Os joins dos receptores são enviados para o Rendezvous Point (RP) Os emissores registam-se no RP Os dados fluem pela shared tree e viajam apenas para redes onde os dados da origem são necessários Os routers mais próximos dos utilizadores podem-se juntar à source tree se enviarem joins em direcção à origem As verificações de RPF para a shared tree usam o RP As verificações de RPF para a source tree usam a origem RDC/ISEL-DEETC-SRT 27

28 PIM Sparse Mode Apenas um RP é escolhido para um grupo O RP é configurado estaticamente ou dinamicamente (Auto-RP, anúncios PIM v2 candidate RP) Os dados são encaminhados baseando-se no source state (S, G) Se existir, senão é baseado no shared state (*, G) RFC 4601, actualizado no RFC 5059 RDC/ISEL-DEETC-SRT 28

29 Exemplo PIM-SM Source Link Data Control A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 29

30 Exemplo PIM-SM (2) Source Receiver 1 Joins Group G C Creates (*, G) State, Sends (*, G) Join to the RP A B RP D Join C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 30

31 Exemplo PIM-SM (3) Source RP Creates (*, G) State A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 31

32 Exemplo PIM-SM (4) Source Source Sends Data A Sends Registers to the RP Register A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 32

33 Exemplo PIM-SM (5) Source RP de-encapsulates Registers Forwards Data Down the Shared Tree Sends Joins Towards the Source Join Join A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 33

34 Exemplo PIM-SM (6) Source RP Sends Register-Stop Once Data Arrives Natively Register-Stop A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 34

35 Exemplo PIM-SM (7) Source C Sends (S, G) Joins to Join the Shortest Path (SPT) Tree A B RP D (S, G) Join C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 35

36 Exemplo PIM-SM (8) Source When C Receives Data Natively, It Sends Prunes Up the RP tree for the Source. RP Deletes (S, G) OIF and Sends Prune Towards the Source (S, G) Prune A B RP D (S, G) RP Bit Prune C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 36

37 Exemplo PIM-SM (9) Source New Receiver 2 Joins E Creates State and Sends (*, G) Join A B RP D (*, G) Join C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 37

38 Exemplo PIM-SM (10) Source C Adds Link Towards E to the OIF List of Both (*, G) and (S, G) Data from Source Arrives at E A B RP D C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 38

39 Exemplo PIM-SM (11) Source New Source Starts Sending D Sends Registers, RP Sends Joins RP Forwards Data to Receivers through Shared Tree Register A B RP D Source 2 C E Receiver 1 Receiver 2 RDC/ISEL-DEETC-SRT 39

40 Inter-domain Multicast Routing RDC/ISEL-DEETC-SRT 40

41 Introdução Multicast em larga escala Ponto de vista de um operador Não queremos os mesmos dados a atravessar as ligações múltiplas vezes poupar largura de banda Queremos entrar e sair dos grupos dinamicamente sem notificar todas as origens pay-per-view Queremos descobrir um recurso mas não sabemos quem o está a fornecer Reduzir a latência inicial para os subscritores de um grupo RDC/ISEL-DEETC-SRT 41

42 Modelo de um host Deve ser o mais simples possível Quanto enviar dados, não é preciso fazer mais nada Mapear o endereço da camada de rede com o de data link Os routers é que descobrem onde estão os receptores Quando receber dados, precisa de: Indicar aos router qual o grupo que está interessado (via IGMP) Configurar a placa de rede para receber os endereços MAC correspondentes ao grupo Multicast Os hosts podem ser emissores e/ou receptores de um determinado grupo RDC/ISEL-DEETC-SRT 42

43 Modelo de um host (1) Questões termos de arquitectura e protocolos Múltiplos endereços IP de grupo mapeiam num único endereço físico É preciso filtragem na camada IP Os hosts ao juntarem-se a um grupo recebem tráfego de todas as origens a enviar para esse grupo Idealmente os hosts podiam indicar de que origem pretendem receber (IGMPv3) É fácil filtrar as origens mas é difícil filtrar os destinos RDC/ISEL-DEETC-SRT 43

44 Modelo de um router Como os hosts podem enviar a qualquer altura para qualquer grupo, os routers têm de estar preparados para receber dados em todos os endereços de grupo de nível 2 E saber quando encaminhar ou descartar os pacotes Que estado é que um router tem de manter? Interfaces que levam aos receptores (OIF Outgoing Interface) Origens dos dados quando usar uma source distribution tree Apagar o estado dependendo no protocolo de routing multicast (e.g. Dense Mode) RDC/ISEL-DEETC-SRT 44

45 Conceitos de distribuição de dados Os routers precisam de manter o estado para entregar dados para baixo numa árvore de distribuição Source trees O router mantém o estado (S,G) para que os pacotes possam fluir da origem para todos os receptores Shared trees O router mantém o estado (*,G) para que os pacotes fluam da raiz da árvore para todos os receptores Como é que a árvore é criada? On demand, em resposta à chegada de dados Protocolos dense-mode (PIM-DM e DVMRP) MOSPF Controlo explícito Protocolos sparse-mode (PIM-SM e CBT) RDC/ISEL-DEETC-SRT 45

46 Conceitos de distribuição de dados (1) Construir a árvore requer conhecimento sobre onde estão os membros Enviar um flood de dados para encontrar onde é que os membros não estão (protocolos dense-mode) Enviar informação sobre a pertença a um grupo (MOSPF), e construir a árvore conforme os dados chegam Enviar joins explícitos e manter o estado dos joins (protocolos sparsemode) RDC/ISEL-DEETC-SRT 46

47 Conceitos de distribuição de dados (2) A construção de source trees requer conhecimento da localização das fontes Em protocolos dense mode, aprende-se quando os dados chegam (a cada nível da árvore) Em protocolos sparse-mode, aprende-se quando os dados chegam à shared tree (nos routers folha apenas) Ignorar baseando-se no encaminhamento vs direcção do RP Tomar atenção se o encaminhamento for feito para a source tree Para construir uma shared tree é preciso saber onde o core (RP) está Pode ser aprendido dinamicamente através do protocolo de routing (Auto- RP, PIMv2) Pode ser configurado nos routers Pode usar um serviço de directoria RDC/ISEL-DEETC-SRT 47

48 Conceitos de distribuição de dados (3) Source trees fazem sentido para: Emissões de rádio Aplicações com poucas fontes para muitos destinos Aplicações que precisem de um alto débito e baixo atraso Controlos de acesso por fonte As shared trees fazem sentido para: Muitas fontes de baixo débito Aplicações que não precisam de um atraso baixo Politica consistente e controlo de acesso através dos participantes num grupo Onde a maior parte das source trees se sobrepõe sobre o ponto de vista de topologia com uma shared tree RDC/ISEL-DEETC-SRT 48

49 Obstáculos à implementação não técnicos Como cobrar pelo serviço É o serviço que corre sobre multicast? Ou é o transporte? Cobra-se por fonte/origem, destino ou ambos? Como controlar o acesso Deverão ser as fontes limitadas em débito? Deverão ser os destinos ter um débito limitado? Problemas de segurança DoS Escutas mais simples uma vez que os receptores são desconhecidos RDC/ISEL-DEETC-SRT 49

50 Obstáculos à implementação técnicos O estado das source trees é um problema se o multicast se tornar popular O estado dos grupos é um outro problema quando o multicast crescer grupos com apenas 3 membros na Internet inteira Os ISPs não querem depender dos RPs dos competidores Ligamos as shared trees? Temos uma única shared tree ao longo dos domínios? Usamos as source trees apenas para grupos inter-domain? A topologia de rede para tráfego unicast pode ser diferente da de multicast ao longo dos domínios Devido a restrições físicas/topológicas Devido a políticas É preciso um protocolo de encaminhamento inter-domain que distinga políticas unicast vs multicast RDC/ISEL-DEETC-SRT 50

51 Como controlar o estado da tabela de encaminhamento na rede? Problema fundamental de descobrir a filiação de grupos Flood and Prune DVMRP PIM-DM Broadcast Membership MOSPF DWRs Rendezvous Mechanism PIM-SM BGMP RDC/ISEL-DEETC-SRT 51

52 Mecanismos de Rendezvous Porque não usar PIM-SM? Onde pôr a raiz da shared tree (RP) Problemas dos operadores em ter RPs de outros Se usarmos o PIM-SM Os mapeamentos de grupos-rp têm de ser distribuídos pela Internet Quatro possibilidades para distribuir o mapeamento grupo-rp Multi-level RP Clusters anycast MSDP Directory service RDC/ISEL-DEETC-SRT 52

53 Multi-level RP Ideia: ligar as shared tress hierarquicamente Os RPs de Nível-0 estão dentro dos domínios Propagam os joins de routers abaixo para um RP Nível-1 que pode estar noutro domínio As árvores de Nível-0 ficam ligadas através de RPs Nível-1 Se existirem múltiplos RPs de Nível-1, iterar até aos RPs de Nível-2 Problemas Requer mudanças no protocolo PIM Se não localizarmos o RP de Nível-0 na fronteira, os routers PIM intermédios podem pensar que existe dois RPs para o grupo Ainda tem o problema dos outros operadores, existe pelo menos um nó na raiz da hierarquia Os dados têm de fluir até ao RP de mais alto nível RDC/ISEL-DEETC-SRT 53

54 Clusters anycast Ideia: ligar as shared trees em clusters Partilha de recursos entre ISPs Cada RP em cada domínio é um router de fronteira Construir clusters de RPs nos pontos de interligação (ou em nuvens em dense-mode) A alocação de grupos é por cluster, não por utilizador ou domínio O router de fronteira mais próxima é usado como um RP Os routers dentro de um domínio vão usar o RP do domínio Desde que tenhamos um RP para o grupo num ponto de interligação Se não, vamos usar o RP mais próximo do ponto de interligação (pode ser um RP noutro domínio) RDC/ISEL-DEETC-SRT 54

55 MSDP Multicast Source Discovery Protocol Ideia: ligar os domínios entre eles Multicast Source Discovery Protocol Em vez de ligar árvores, ligamos as fontes conhecidas a todas as árvores Um RP num domínio tem uma sessão de peering MSDP com um RP noutro domínio Funciona sobre TCP Mensagens Source Active (SA) indicam fontes activas num domínio A topologia lógica é construída apenas para distribuir mensagens SA RDC/ISEL-DEETC-SRT 55

56 MSDP Como funciona A origem fica activa num domínio PIM-SM Os seus pacotes são registados pelo PIM no RP do domínio O RP envia mensagens SA para os seus peers MSDP Esses peers encaminham o SA para os outros peers upstream Se um peer noutro domínio tem clientes para o grupo no qual a fonte está enviar, junta-se à fonte (modelo Flood-and-Join) Não existe uma shared tree ao longo dos domínios Cada domínio pode depender unicamente no seu RP Não é preciso guardar estado dos SA em cada peer MSDP Pode-se fazer cache do estado dos SA para acelerar a latência dos joins RDC/ISEL-DEETC-SRT 56

57 Serviços de directoria Ideia: permitir uma única shared tree ao longo dos domínios, ou usar uma source tree apenas a) Uma única shared tree ao longo dos domínios Colocar o RP no domínio do cliente Localização óptima do RP caso o domínio tenha uma fonte multicast ou cliente activo Politica para RP é consistente com a política de domínio para os prefixos unicast Usar a directoria para encontrar o endereço do RP para um determinado grupo RDC/ISEL-DEETC-SRT 57

58 Serviços de directoria (1) Exemplo O cliente que quer receber envia reports IGMP para o O router do primeiro salto resolve para pim-routers.mcast.net É devolvido o endereço IP do RP O router de primeiro salto envia um Join de PIM em direcção ao RP Todos os routers obtêm endereços dos RP através de DNS Quando o DNS dinâmico estiver em produção será mais fácil alterar os registos A Todos os routers obtêm os endereços dos RP através de DNS Entretanto usa-se endereços de loopback nos routers e move-se este pelo domínio RDC/ISEL-DEETC-SRT 58

59 Serviços de directoria (2) b) Evitar utilizar as shared trees Construir source trees PIM-SM ao longo dos domínios Colocar múltiplos registos A no DNS para descrever as fontes para o grupo sources.pim-routers.mcast.net IN CNAME dino-ss20 IN CNAME jmeylor-sun dino-ss20 IN A jmeylor-sun IN A RDC/ISEL-DEETC-SRT 59

60 Soluções normalizadas Escalar o routing e a atribuição de grupos pode ser atingida utilizando o BGMP/MASC Border Gateway Multicast Protocol Multicast Address-Set Claim Usar o BGP4+ (MBGP) para lidar com a distribuição de endereços multicast em paralelo com unicast, permite que as topologias sejam diferentes entre si. RDC/ISEL-DEETC-SRT 60

61 BGMP (Border Gateway Multicast Protocol) Usar um protocolo parecido com o PIM entre domínios ( BGP para multicast ) O BGMP constrói uma shared tree de domínios para um grupo Para que possamos usar um mecanismo de rendezvous ao nível do domínio A shared tree é bidireccional A raiz da shared tree dos domínios está no domínio de raiz Corre em routers que são fronteira para um domínio de routing multicast Funciona sobre TCP tal como o BGP Joins e prunes atravessam os domínios Pode construir source trees unidireccionais MIGP indica à fronteira sobre as filiações em grupos RFC 3913 RDC/ISEL-DEETC-SRT 61

62 MASC (Multicast Address Set Claim) Como é que alguém determina o domínio de raiz para um dado grupo? Prefixos de grupo são temporariamente emprestados a domínios Alocados pelo ISP que em troca os recebeu do seu fornecedor de upstream Pedidos para alocação de grupos resolve os problemas de colisões Alocações de grupos são anunciadas ao longo dos domínios É necessário alguém que agregue as alocações de grupos Multicast Address Allocation Servers Tradeoff entre a agregação e o pedido antecipado de endereços de grupos As alocações de prefixos de grupo não são atribuídas a domínios são emprestadas As aplicações têm de ser alteradas RFC 2909 RDC/ISEL-DEETC-SRT 62

63 BGP4+ (MBGP) Extensões multi-protocolo para o BGP4 RFC 4760 MBGP permite a construção de uma RIB unicast e uma RIB multicast com apenas um protocolo Pode usar a topologia de peering existente ou uma nova (multicast) MBGP transporta prefixos unicast de fontes de multicast RDC/ISEL-DEETC-SRT 63

64 MBGP Cenário 1 Uma única interligação para operadores para peering multicast Cada ISP administra o seu RP na interligação Tanto o RP como todos os border routers correm MBGP A interligação corre PIM-DM Cada operador corre PIM-SM internamente RDC/ISEL-DEETC-SRT 64

65 MBGP Cenário 2 Múltiplos pontos de interligação entre operadores Os operadores podem fazer peering de multicast para os grupos desde que os seus RPs respectivos estejam colocados na mesma interligação Senão usam MSDP para que as fontes que os RPs conhecem numa determinada ligação possam indicar a outros RPs onde fazerem o join RDC/ISEL-DEETC-SRT 65