• Save
Multicast on Cisco Network
Upcoming SlideShare
Loading in...5
×
 

Multicast on Cisco Network

on

  • 4,680 views

Relatório para TAR 2008/2009 sobre Multicast em redes Cisco.

Relatório para TAR 2008/2009 sobre Multicast em redes Cisco.

Statistics

Views

Total Views
4,680
Views on SlideShare
4,677
Embed Views
3

Actions

Likes
6
Downloads
0
Comments
0

2 Embeds 3

http://www.lmodules.com 2
http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Multicast on Cisco Network Multicast on Cisco Network Document Transcript

    • IP Multicast Bernardo Pina Filipe Cunha Pedro Fernandes Departamento de Ciências de Computadores 2008/2009
    • Índice 1 INTRODUÇÃO ........................................................................................................................ 3 2 IP MULTICAST ........................................................................................................................ 4 2.1 Spanning Tree................................................................................................................ 5 2.2 Algoritmos de criação das árvores ................................................................................ 5 2.2.1 Reverse Path Forward ........................................................................................... 5 2.2.2 Shortest Path Tree ................................................................................................. 6 2.2.3 Shared Tree (Steiner Tree) .................................................................................... 7 2.2.4 Center Based Tree ................................................................................................. 7 2.3 Protocolos IP Multicast ................................................................................................. 8 2.3.1 Internet Group Management Protocol (IGMP) ..................................................... 8 2.3.2 Protocol Independent Multicast (PIM)................................................................ 10 2.3.3 Distance Vector Multicast Routing Protocol (DVMRP) ....................................... 11 2.3.4 Multicast Open Shortest Path First (MOSPF) ...................................................... 12 3 INTRODUÇÃO AO LABORATÓRIO ........................................................................................ 13 3.1 Software necessário .................................................................................................... 13 3.1.1 SDR (Session Directory) ....................................................................................... 13 3.1.2 Ferramentas de documentos compartilhados e edição de texto ....................... 13 3.1.3 Ferramentas de vídeo e áudio............................................................................. 13 3.2 Topologia de rede ....................................................................................................... 14 3.3 Método usado ............................................................................................................. 14 4 LABORATÓRIO ..................................................................................................................... 16 4.1 Outros pacotes capturados na rede ............................................................................ 26 5 CONCLUSÃO ........................................................................................................................ 29 6 BIBLIOGRAFIA ...................................................................................................................... 30 7 ANEXOS ............................................................................................................................... 31 2
    • 1 INTRODUÇÃO No final dos anos 80, ninguém tinha noção do impacto que o IP Multicast teria nas nossas vidas, nas mais diversas áreas: finanças, transportes, entretenimento, etc. Hoje as aplicações multicast estão presentes em quase todo o lado, intimamente associadas a uma serie de situações do nosso dia-a-dia. Desde as comuns videoconferências, seja com familiares ou colegas de trabalho, até ao vulgar sítio de e-learning que costumamos aceder diariamente. Todos eles podem partilhar a particularidade, imperceptível para o utilizador normal, de executarem sobre IP Multicast. Para perceber como esta tecnologia evoluiu, e tornou-se uma ferramenta estratégica e importante para redes de negócios, temos de voltar atrás e entender como é que as coisas eram feitas antes desta inovação revolucionária. Tradicionalmente, quando alguém precisava de transmitir uma mesma informação para vários destinos, a fonte teria de emitir, para a rede, uma cópia separada para cada destino. Se a fonte fosse um stream de vídeo, a enviar a mil utilizadores simultaneamente, isto significaria que o emissor teria de criar mil cópias dessa mesma stream e envia-la mil vezes para a rede. Isto pressupõe um enorme esforço por parte do servidor/emissor assim como uma incrível sobrecarga, claramente ineficiente, da rede. Assim entramos na revolução trazida pelo IP multicast. O IP Multicast permite que os utilizadores consigam distribuir eficientemente informação - como vídeo, voz e dados - entre utilizadores remotos, reduzindo assim o congestionamento no lado do servidor, ao possibilitar o envio de uma stream apenas para a rede. Toda a informação que tem necessidade de ser enviada para vários destinos ao mesmo tempo pode tirar partido desta tecnologia. De entre os vários benefícios podemos enunciar:  Eficiência elevada (largura de banda, etc)  Aumento de escalabilidade  Eliminação de redundância  Redução de sobrecarga nos servidores e processadores  Aumento de performance 3
    • 2 IP MULTICAST Mas como funciona afinal o multicast? O funcionamento do Multicast está intimamente ligado a criação de “árvores”. Estas “árvores” são dinamicamente criadas através do uso de dois simples protocolos (a título de exemplo): IGMP e PIM. O IGMP é usado pelos receptores/emissores (utilizadores normais), para comunicarem com os routers, e o PIM é usado pelos routers que participam na rede, para comunicarem entre si. Para realizar transmissões de dados através do IP Multicast, as máquinas são organizadas em grupos e recebem um endereço comum, o endereço do grupo Multicast. Quando alguma máquina pretende enviar datagramas para todas as máquinas de um determinado grupo, simplesmente envia os datagramas para o endereço do grupo: um endereço IP classe D (compreendido entre 224.0.0.0 e 239.255.255.255). Funções Endereços Multicast Reservados Local Network Control Block 224.0.0.0-224.0.0.255 Internetwork Control Block 224.0.1.0-224.0.1.255 Spanning Tree Multicast Groups 224.1.0.0-224.1.255.255 SDP/SAP Block 224.2.0.0-224.2.255.255 Administratively Scoped 239.0.0.0-239.255.255.255 Tabela 1: Tabela com alguns dos endereços reservados para serviços IP Multicast. Os grupos multicast são dinâmicos, os membros podem ingressar ou sair a qualquer momento. Não existem restrições para o número de membros de um grupo e uma estação pode participar de mais de um grupo ao mesmo tempo, assim como pode enviar datagramas a um grupo sem lhe pertencer. Existem grupos que possuem um endereço conhecido, fixo, denominados grupos permanentes. Mas apenas o endereço é permanente, os membros destes grupos não são fixos e, num dado momento, um grupo permanente pode ter qualquer número de membros, inclusive zero. Os endereços IP multicast que não são reservados para nenhum grupo permanente estão disponíveis para atribuição dinâmica de grupos temporários. Estes grupos existem apenas enquanto possuem membros, sendo depois eliminados. O Multicast pode ser usado numa rede física simples ou através da Internet. Neste último caso, os datagramas são transmitidos por gateways multicast especiais denominados routers multicast. Uma estação transmite um datagrama multicast como um multicast de rede local, que atingirá todos os membros do grupo pertencentes a rede local. Se o datagrama possuir um IP time-to- live (correspondente ao campo time-to-live do datagrama IP) maior que um, o router multicast ligado a rede transmite o pacote para todas as outras redes que possuem membros do grupo, desde que sejam atingíveis dentro do seu time-to-live. Os routers multicast pertencentes as redes destinos completam a entrega, transmitindo o datagrama como multicast local. Se dois utilizadores, pertencentes ao mesmo grupo multicast, requisitassem uma mesma stream multicast e estivessem em localizações diferentes, utilizariam IGMP para comunicar 4
    • com a rede. Os routers mais próximos desses, que percebem IGMP, iriam então usar o PIM para se interconectarem numa reacção em cadeia em direcção ao emissor da stream. Agora entra o conceito chave do IP Multicast: packet replication. O Packet replication acontece quando a stream chega a bifurcação que leva a cada um dos destinos da stream. Nesse router, e só aí, a informação é replicada e transmitida para ambos os destinos simultaneamente. O resultado final é uma árvore cujos ramos interconectam apenas os receptores interessados, permitindo que estes recebam uma cópia singular da informação. Ilustração 1: Funcionamento do IP Multicast. 2.1 Spanning Tree Como são criadas essas árvores? Existem uma serie de condicionantes e factores importantes que devem ser levados em conta. As árvores não devem conter ciclos. Tal comprometeria desde logo a eficiência da rede, uma vez que possibilitaria a ocorrência de fenómenos de flooding. Dados esses factos, a árvore terá de ser uma spanning tree. Uma spanning tree é uma árvore composta por todos os nós de um dado grafo inicial, sem no entanto existir ciclos entre os mesmos. Existem apenas as ligações mínimas para que todos os nós estejam interligados. 2.2 Algoritmos de criação das árvores 2.2.1 Reverse Path Forward O algoritmo Reverse Path Forwarding (RPF) é utilizado para encaminhar os pacotes, com a adição de dois conceitos: prunes e grafts. Assim, quando o primeiro pacote multicast de determinado grupo chega ao router, ele, encaminha-o para toda a árvore multicast, excepto para quem lhe enviou o pacote, ou já foi visitado. 5
    • O router “emissor” recebe mensagens de prune (corte/poda) nos caminhos onde não deve ser encaminhado o pacote (caminhos que não contenham nenhum terminal activo naquele grupo multicast). O resultado é que todos os routers da árvore devem estar cientes da existência daquele grupo, armazenando-o na sua tabela como activo (se tem receptores activos) ou pruned (se não tem receptores activos). Quando um terminal quer fazer um join num grupo multicast pruned, envia a mensagem IGMP ao router mais próximo, que deve enviar uma mensagem do tipo graft para refazer o caminho até a origem. Ilustração 2: Funcionamento do RPF. 2.2.2 Shortest Path Tree O algoritmo Shortest Path Tree (SPT) dá origem a um subgrafo, de um grafo já existente, em que as distâncias entre a fonte (nó raiz) e todos os outros nós, é mínima. A fim de minimizar o comprimento total de um caminho, o percurso desde o nó raiz até cada um dos nós, tem que ser o caminho mais curto entre eles. Senão, esse tipo de percurso é substituído com um outro caminho mais curto, e é obtido uma “spanning tree” mais leve em que o comprimento total desse caminho, do nó raiz aos restantes nós, é o menor. De seguida serão apresentados dois dos mais conhecidos algoritmos de construção de “Shortest Path Tree”, O algoritmo Dijkstra e o Bellman-Ford.  Dijkstra’s Algorithm Este algoritmo soluciona o problema do caminho mais curto num grafo dirigido ou não dirigido com arestas de peso com valores não negativos, em tempo computacional O ([m+n]log n) onde m é o número de arestas e n é o número de vértices. A complexidade deste algoritmo é quadrada, ou seja: O(n*n).  Bellman-Ford Algorithm O Algoritmo de Bellman-Ford é um algoritmo de busca de um caminho mínimo num dígrafo ponderado, ou seja, cujas arestas têm pesos, inclusive negativos. O Algoritmo de Dijkstra resolve o mesmo problema, num tempo menor, porém exige que todas as arestas tenham pesos positivos. Portanto, o algoritmo de Bellman-Ford é normalmente usado apenas quando existem arestas de peso negativo. O algoritmo de Bellman-Ford executa em tempo O(v*a) onde “v” é o número de vértices e “a” o número de arestas. 6
    • 2.2.3 Shared Tree (Steiner Tree) Neste tipo de algoritmo é calculada uma árvore de custo mínimo, com todos os routers que contêm membros de um determinado grupo Multicast. Este algoritmo representa um problema de computação complexa, de classe “NP-complete” (Nondeterministic Polynomial). A característica mais notável para problemas “NP-complete” é a de não existir uma solução rápida para eles. Ou seja, o tempo necessário para resolver o problema usando qualquer um dos algoritmos mais conhecidos aumenta muito rapidamente à medida que o tamanho do problema aumenta. E este é um dos principais problemas deste algoritmo, pois é um tipo de problema “NP-complete”, ou seja, muito difícil de resolver. No entanto, é importante referir que existem excelentes heurísticas sobre este problema. Não é usada na prática pois é de uma complexidade computacional elevada e é necessária informação sobre toda a rede. A figura abaixo ilustrada exemplifica o funcionamento deste algoritmo. 4 3 2 1 2 2 1 1 Ilustração 3: Funcionamento de uma Shared Tree. 2.2.4 Center Based Tree Neste tipo de algoritmo é usada uma única árvore que é partilhada por todos os “routers”. Um router é identificado como sendo o “centro” da árvore. Exemplificando este algoritmo temos que:  O router num vértice envia em “unicast” um “join” endereçado para o router central.  Essa mensagem prossegue pelos “routers” intermédios ate chegar ao router central.  A mensagem ou chega ao centro ou percorre um ramo que já existe.  O caminho percorrido pela mensagem passa a ser um novo ramo da árvore para esse router que enviou a mensagem. 7
    • A figura abaixo ilustrada exemplifica o funcionamento deste algoritmo em que o router R6 é o escolhido para ser o router central. LEGEND R1 router with attached R4 3 group member R2 router with no attached 2 group member 1 R5 path order in which join messages generated R3 1 R6 R7 Ilustração 4: Funcionamento do Center Based Tree 2.3 Protocolos IP Multicast 2.3.1 Internet Group Management Protocol (IGMP) O Internet Group Management Protocol (IGMP) é um protocolo de comunicação utilizado para gerir os grupos de IP multicast. É utilizado apenas entre os terminais e os routers multicast adjacentes (Figura 1). Este protocolo permite a um terminal, informar o router adjacente, de que uma aplicação tem intenção de se juntar a um determinado grupo multicast. Dado que este protocolo apenas se limita à comunicação entre os dispositivos já referidos, torna-se clara a necessidade de outro protocolo para a coordenação de routers multicast que se encontram na restante rede. Isto é feito por algoritmos de routing multicast ao nível da camada de rede como o PIM, DVMRP e o MOSPF (descritos posteriormente), só para citar os mais conhecidos. Ilustração 5: Funcionamento do IGMP. Mensagens IGMP 8
    • As mensagens IGMP, que permitem gerenciar os grupos IP multicast, podem ser de três tipos diferentes:  membership_query Este tipo de mensagem é enviado pelos routers para todos os terminais a ele ligados, para determinar todos os grupos multicast a que esses mesmos terminais pertencem. Pode também determinar quando um terminal se tornou membro de um grupo multicast específico, indicando o endereço do grupo em questão no campo Multicast group address do pacote.  membership_report É o tipo de mensagem utilizado pelos terminais para responder aos membership_query. Pode também ser gerada por terminal no caso de este se juntar a um grupo multicast sem aguardar por um membership_query enviado pelo router multicast adjacente.  leave_group Mensagens deste tipo são geradas por um terminal quando este sai de um grupo multicast. Apesar da aparente importância deste tipo de mensagem, esta é de carácter opcional. Isto porque os routers tem outra forma de determinar este evento: quando um router envia mensagens membership_query com o endereço do grupo em questão e não recebe resposta de um determinado terminal, admite que esse terminal já não pertence a esse grupo. IGMP snooping O snooping IGMP é o processo de escuta de tráfego IGMP utilizado nos switches. Tal como o nome indica, permite que os switches escutem toda a troca de pacotes entre terminais e routers numa rede multicast, à medida que os processam. Quando o IGMP snooping se encontra activo, o switch analisa todos os pacotes trocados entre os terminais, e os routers multicast a ele ligados. Quando um switch escuta um report de um terminal relativamente a um grupo multicast, adiciona o número da porta do terminal à lista de multicast do respectivo grupo. Da mesma forma, quando escuta uma mensagem IGMP Leave, remove a entrada da tabela, correspondente ao terminal que pretende deixar o grupo. O snooping IGMP pode ajudar a reduzir consideravelmente o tráfego multicast, relativo a streaming e outras aplicações IP que consumam grande largura de banda. Enquanto um switch que não entenda multicast vai reencaminhar o tráfego para todas as suas portas (Figura 3), um switch utilizando snooping IGMP apenas o fará para os terminais que realmente estejam interessados nessa informação (Figura 4). Esta redução de tráfego multicast, reduz não só o processamento de pacotes no switch mas também reduz a quantidade de trabalho necessária nos terminais, visto que não terão que receber e filtrar todo o tráfego multicast gerado na rede. 9
    • Ilustração 6: Funcionamento do IGMP Snooping. 2.3.2 Protocol Independent Multicast (PIM) O Protocol-Independent Multicast (PIM) – RFC 2362 - é um protocolo de routing multicast, que permite a distribuição de dados na forma um-para-muitos e de muitos-para-muitos através da Internet. A parte “protocol-independent”, refere-se ao facto do PIM não incluir um mecanismo de descoberta de topologia de rede próprio. Em vez disso, utiliza informação de routing fornecida por outros protocolos de routing tradicionais como o OSPF ou RIP. Para desempenhar a sua tarefa, dispõe de quatro modos de distribuição: Dense Mode (DM) O dense mode, utilizado em situações em que os membros de um determinado grupo se encontrem distribuídos por toda a rede e obrigue assim grande parte dos routers da rede a participar no processo de routing de datagramas multicast. O PIM-DM utiliza uma técnica “flood-and-prune”. Inicialmente os pacotes multicast são enviados para toda a rede e depois são “cortados” todos os ramos da rede que não tenham terminais interessados nesta informação. Sparse Mode (SM) O outro modo de operação é o sparse mode. Neste modo, o número de routers com utilizadores multicast ligados é pequeno, comparativamente ao número total de routers da rede. Este modo de operação é indicado para situações em que é necessário um controlo mais apertado do tráfego na rede, especialmente quando lidamos com grandes quantidades de tráfego comparativamente à largura de banda de que dispomos. Quando um router (designated router) recebe datagramas de um terminal para ser distribuído pela rede, este encapsula-os em mensagens PIM de controlo e reencaminha- os por unicast para o rendezvous point (RP). Esse RP é depois responsável pela distribuição da mensagem para os destinos pretendidos. Isto torna o PIM-SM bastante escalável, na medida em que os datagramas apenas são enviados pelo caminho realmente necessário, sem sobrecarregar routers que não aqueles por onde os datagramas irão passar. 10
    • Bidirectional PIM (BM) Este terceiro modo do PIM é baseado no Sparse Mode. A principal diferença esta no método de envio de dados do emissor para o RP Router. No modo Bidir os dados são enviados para o RP router por uma shared tree cujos ramos são bidireccionais – existem fluxos de dados em ambas as direcções, em qualquer ramo. Não há necessidade de encapsulamento dos pacotes e as regras de reencaminhamento são bastante mais simples. A grande vantagem em relação ao SM, é que o BM escala muito bem quando existem muitas fontes para o mesmo grupo. No entanto, pode dar-se que o tráfego seja forçado a seguir uma shared tree ineficiente, pelo facto do BM não seguir o conceito de source- based trees. PIM Source-specific multicast (SSM) É um método de distribuir pacotes multicast onde os únicos pacotes que são entregues ao destino são os originados pela fonte especificada pelo receptor. Dessa forma, este método proporciona uma redução a nível do tráfego na rede e ganhos a nível de segurança. No entanto, como este método necessita de explicitar o IP da fonte sobre a qual pretende receber tráfego, só funciona usando o protocolo IGMPv3 em IPv4 ou o MLDv2 em IPv6. Rendezvous Point Um router que actue como Rendezvous Point (RP), é utilizado como um meio de comunicação temporário para ligar um terminal que pretenda tornar-se membro de um grupo multicast, à árvore “source-specific” já existente, conhecida pelo RP. Assim que o volume de tráfego atinja um threshold, o terminal passa a fazer parte de uma outra árvore, não dependente do RP. Este RP pode ser configurado de três formas diferentes:  manual, em cada um dos routers ligados ao RP;  auto-RP, existe um processo de selecção dinâmica do RP;  Bootstrap Router, apenas em routers com PIM versão 2 por haver problemas de compatibilidade com a versão 1;  Anycast RP, possibilita o uso de dois ou mais RP routers e ainda o uso de backup RP routers;  Embedded RP, permite embeber o endereço do RP router num grupo multicast any- source multicast. 2.3.3 Distance Vector Multicast Routing Protocol (DVMRP) O Distance Vector Multicast Routing Protocol (DVMRP) – RFC 1075 - é outro dos protocolos de routing multicast, que permite a partilha de informação entre routers, para facilitar o transporte de pacotes multicast através de redes. A informação para o reencaminhamento de pacotes é calculada com base no protocolo RIP: o router gera a sua tabela de routing com os grupos multicast que este tem conhecimento e respectiva distância. Quando um pacote multicast é recebido, é reencaminhado pelas suas interfaces de acordo com a informação contida nessas tabelas. 11
    • A grande diferença entre o RIP e este protocolo é que enquanto o primeiro se preocupa em fazer chegar os pacotes até o seu destino específico, o DVMRP preocupa-se em reter informação dos caminhos de retorno para a origem dos datagramas multicast. O DVMRP utiliza mensagens IGMP na troca de informação com outros routers. 2.3.4 Multicast Open Shortest Path First (MOSPF) O MOSPF é uma extensão multicast do protocolo de roteamento IP, Open Shortest Path First (OSPF). Protocolo este, baseado no estado das ligações, ao contrario do RIP que baseia-se na contagem dos nós. O MOSPF transmite os datagramas IP multicast da origem para os vários membros do grupo sem formar ligações, gerando uma árvore. Esta árvore tem como raiz o nó da origem do datagrama, e todos os “ramos” terminam em membros do grupo. Este esquema de roteamento, onde o caminho dos datagramas depende da origem e dos destinos é denominado source/destination routing. Ele é diferente da maioria dos algoritmos unicast, incluído o OSPF, que se baseiam somente no destino do datagrama ao fazer o roteamento. A necessidade de considerar a origem para tomar decisões de roteamento causa maior quantidade de cálculos, porém resulta em melhores caminhos em termos de utilização da rede e atraso para membros individuais do grupo. Neste protocolo, os datagramas são marcados com a sua classificação do Type of Service(TOS). O caminho do datagrama multicast no MOSPF pode assim variar consoante a classificação TOS utilizada. No entanto, a classificação TOS no protocolo MOSPF é, como no OSPF, opcional. 12
    • 3 INTRODUÇÃO AO LABORATÓRIO No nosso trabalho laboratorial pretendemos demonstrar algumas das características do IP Multicast, nomeadamente o método de funcionamento de grupos Multicast. Com esse intuito usou-se o SDR (Session Directory Tool) e o NTE (Network Text Editor). Montou-se então uma rede que nos permitiu perceber os conceitos fundamentais do IP Multicast, nomeadamente o protocolo IGMP, entre os computadores e os routers mais próximos, e os protocolos de routing Multicast que permitem que os routers troquem datagramas multicast entre si, como o caso do PIM. Usou-se o Wireshark para capturar todas as mensagens trocadas na rede. 3.1 Software necessário Actualmente, as principais aplicações multicast estão relacionadas com vídeo, áudio e texto compartilhado. Antes que se possa realmente realizar uma conferência em qualquer destes cenários, é necessário alocar, reservar e anunciar uma sessão multicast. Além disso, uma vez anunciado o canal, cada terminal precisa aceder aos anúncios, podendo então entrar e sair de um grupo. É aqui que entram as ferramentas de anúncio de sessão, como por exemplo o SDR (Session Directory). Para a transmissão de dados propriamente dita é necessário associar a esta ferramenta de anúncio de sessão, outras ferramentas que possibilitem que os respectivos dados sejam enviados ao longo da rede. 3.1.1 SDR (Session Directory) A ferramenta SDR permite que sejam reservados e alocados canais multicast de áudio, vídeo e quadro branco (texto) para conferências e que se participe nos diversos grupos anunciados. 3.1.2 Ferramentas de documentos compartilhados e edição de texto Com estas ferramentas, é possível compartilhar, entre os membros da sessão, documentos em tempo real, efectuando anotações sobres estes a qualquer momento. São especialmente úteis em transmissões de conferências, onde é possível utilizar a ferramenta como um “retroprojector virtual”, onde uma apresentação para o público local também pode ser apresentada para membros virtuais. Entre as ferramentas principais deste tipo temos o WhiteBoard(WB) e o Shared Mosaic. Para a edição de texto mais simples, temos por exemplo a ferramenta Network Text Editor (NTE). Esta ferramenta permite abrir uma sessão de “chat”, onde qualquer pessoa nessa sessão pode editar ou apagar texto. 3.1.3 Ferramentas de vídeo e áudio As ferramentas de vídeo não necessitam de nenhum equipamento adicional além do próprio terminal para receber o vídeo. Utilizam uma série de algoritmos de compressão de vídeo. Entre as ferramentas mais utilizadas estão a Net Vídeo (NV), Vic (VideoConference) e INRIA Videoconferencing System (IVS). Entre as ferramentas de áudio mais utilizadas em multicast estão o Visual Audio Tool (VAT), o Network Voice Terminal (Nevot) e o INRIA Videoconferencing System (IVS). Estas ferramentas utilizam diversos padrões de compressão de áudio, tais como o Pulse Code Modulation (PCM), 13
    • o Adaptative Differential Pulse Code Modulation (ADPCM), Group Special Mobile (GSM) e Linear Predictive Coding (LPC). 3.2 Topologia de rede Ilustração 7: Topologia da rede idealizada para o trabalho prático. Material utilizado:  4 Routers Cisco 2500 (2503)  3 Terminais com: o Session Directory Tool (SDR) 3.0 o Network Text Editor (NTE) 2.3 o Wireshark 1.0.5 o minicom 3.3 Método usado Os terminais foram configurados com endereços estáticos seguindo a topologia de rede demonstrada na Ilustração 7 e funcionaram como emissores e receptores de um grupo IP Multicast. Vamos agora analisar ao pormenor alguns aspectos da configuração dos routers (ver em Anexos), justificando as nossas opções: Os routers foram configurados com RIP como protocolo de encaminhamento e com PIM sparse-dense-mode como protocolo de encaminhamento de datagramas multicast. 14
    • ip subnet-zero Esta configuração permite usar endereços que contenham o algarismo zero. ip multicast-routing Permite aos routers fazerem reencaminhamento de pacotes Multicast entre os nós da rede. ip classless Com esta configuração o router consegue reencaminhar os pacotes multicast para as supernets. ip http server Este comando activa o HTTP 1.1 server, incluindo o user interface em ambiente web. no keepalive Esta configuração foi necessária de forma a evitar mensagens de Loop reply entre os routers. router rip Utilizou-se o RIP em detrimento do OSPF, uma vez que este último (apesar de mais usado actualmente em IGP) é mais direccionado para redes de grandes dimensões. Por esse facto, achamos mais conveniente usar o protocolo RIP por estar mais vocacionado para redes locais. ip pim sparse-dense-mode Utilizou-se o protocolo PIM (Protocol Independent Multicast) porque não é dependente de nenhum protocolo Unicast em particular para descobrir a topologia da rede e utilizou-se o modo específico deste protocolo “sparse-dense-mode”. Este modo de operação do PIM permite que este opere tanto em “sparse-mode” como em “dense-mode”, dependendo das configurações que são dadas. No nosso caso prático, os routers acabaram por funcionar em sparse-mode. ip pim rp-address 10.10.1.1 Atribuiu-se um RP router estático que foi adicionado em todas as configurações. Dada a finalidade da rede que idealizamos, acabou por ser a configuração mais conveniente. A utilização de auto-RP, onde a atribuição dos RP é dinâmica, faria mais sentido numa rede de grande dimensão e com alta imprevisibilidade. As restantes configurações, dos routers e dos terminais, encontram-se em anexo. Executou-se o programa SDR em todos os terminais, iniciando-se uma sessão Multicast num deles. 15
    • 4 LABORATÓRIO Vamos então proceder ao trabalho prático de demonstração do funcionamento e capacidades do IP Multicast. Recapitulando, vamos dispor de três terminais (Terminal 1, Terminal2 e Terminal3) que vão estar a ser utilizados por três utilizadores “virtuais” (user1, user2 e user3). Temos então que o user1 decide organizar uma reunião com indivíduos que têm os mesmos interesses, utilizando as valências do IP Multicast. Decide então criar uma sessão Multicast para anunciar a esses interessados que vai decorrer uma reunião, no tradicional modo de “chat” de texto, daí a algumas horas. O user1 executa então o SDR e inicia a tal sessão, onde vai ser criado o grupo Multicast referenciado pelo respectivo IP de classe D. Este grupo vai ser então referenciado com o IP 239.255.136.156 Ilustração 8: Terminal1 inicia a sessão multicast. 16
    • Ilustração 9: Captura do pacote SAP/SDP, no Wireshark, quando o Terminal1 inicia a sessão multicast. Ilustração 10: O pacote IGMP do Terminal1 para o Router1, a comunicar que existe uma sessão Multicast nesse terminal 17
    • O user1 fica assim a espera que mais interessados se juntem ao chat para iniciar a reunião. Ilustração 11: O Terminal1 (já conectado a sessão multicast) começa a enviar pacotes relativos a comunicação, para o grupo Multicast. Router1#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet0 00:03:28 00:02:53 192.168.10.1 Tabela 2: As tabelas de IGMP do Router1, antes da criação e join ao grupo Multicast. Router1#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.255.136.156 Ethernet0 00:04:58 00:02:30 192.168.10.2 239.255.255.255 Ethernet0 00:14:55 00:02:24 192.168.10.2 224.1.127.255 Ethernet0 00:14:55 00:02:26 192.168.10.2 224.2.127.254 Ethernet0 00:14:55 00:02:29 192.168.10.2 224.0.1.75 Ethernet0 00:14:55 00:02:27 192.168.10.2 224.0.1.40 Ethernet0 00:25:56 00:02:24 192.168.10.1 Tabela 3: As tabelas de IGMP do Router1, após a criação e join ao grupo Multicast. Nota: como se pode reparar o Router1 juntou-se não só ao IP do grupo Multicast que o user1 criou, como também a uma serie de outros IP Multicast. Esses outros IP Multicast, são endereços especiais reservados, que possibilitam o normal funcionamento do Multicast. Vamos mais a frente voltar a falar nesses endereços. 18
    • RPRouter#show ip mroute summary IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.136.156), 00:11:02/00:03:23, RP 10.10.1.1, OIF count: 1, flags: S (192.168.10.2, 239.255.136.156), 00:11:01/00:02:08, OIF count: 0, flags: PT (*, 239.255.255.255), 00:20:59/00:03:22, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.1.127.255), 00:20:59/00:03:23, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.2.127.254), 00:20:59/00:03:22, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.0.1.75), 00:20:59/00:03:22, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.0.1.40), 01:23:43/00:00:00, RP 10.10.1.1, OIF count: 2, flags: SJCL Tabela 4: No Router RP, após o user1 se ter juntado ao grupo Multicast. Como se vê a informação foi passada do Router1 para o RP Router. Router2#show ip mroute summary IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:28/00:00:00, RP 10.10.1.1, OIF count: 1, flags: SJCL Router3#show ip mroute summary IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:19:20/00:00:00, RP 10.10.1.1, OIF count: 1, flags: SJCL Tabela 5: Tanto o Router2 como o Router3 desconhecem esses grupos Multicast, por enquanto. 19
    • O user2, que por acaso até tinha o SDR aberto, detecta que existe uma sessão multicast disponível e adiciona-se a mesma. Ilustração 12: O user2 recebe o SAP/SDP announcement da sessão criada pelo user1. Ilustração 13: Captura do pacote IGMP, no Wireshark, quando o terminal2 adiciona-se ao grupo multicast criado pelo user1, no terminal1. 20
    • Router2#show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.255.136.156 Ethernet0 00:04:50 00:02:26 192.168.20.2 239.255.255.255 Ethernet0 00:10:46 00:02:26 192.168.20.2 224.1.127.255 Ethernet0 00:10:46 00:02:25 192.168.20.2 224.2.127.254 Ethernet0 00:10:46 00:02:27 192.168.20.2 224.0.1.75 Ethernet0 00:10:46 00:02:32 192.168.20.2 224.0.1.40 Ethernet0 01:28:54 00:02:32 192.168.20.1 Tabela 6: No Router2 podemos ver as tabelas IGMP nos quais mantêm-se controlo dos grupos aos quais o user2 pertence. Ilustração 14: Captura, no Wireshark, dos pacotes UDP correspondentes as trocas de mensagens entre os users. 21
    • Router2#show ip mroute summary IP Multicast Routing Table Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.136.156), 00:04:30/00:02:59, RP 10.10.1.1, OIF count: 1, flags: SJCF (192.168.10.2, 239.255.136.156), 00:04:29/00:02:58, OIF count: 1, flags: CJT (192.168.20.2, 239.255.136.156), 00:04:30/00:03:29, OIF count: 1, flags: CFT (*, 239.255.255.255), 00:10:27/00:02:59, RP 10.10.1.1, OIF count: 1, flags: SJC (192.168.10.2, 239.255.255.255), 00:01:24/00:01:35, OIF count: 1, flags: CJT (*, 224.1.127.255), 00:10:27/00:02:44, RP 10.10.1.1, OIF count: 1, flags: SJC (*, 224.2.127.254), 00:10:28/00:02:45, RP 10.10.1.1, OIF count: 1, flags: SJC (*, 224.0.1.75), 00:10:28/00:02:51, RP 10.10.1.1, OIF count: 1, flags: SJC (*, 224.0.1.40), 01:28:42/00:00:00, RP 10.10.1.1, OIF count: 1, flags: SJCL Tabela 7: No Router2, onde se comprova que após o join do user2 o Router2 já incluiu na sua tabela os participantes da sessão Multicast. O user3, um grande interessado no tema da reunião, decide também juntar-se ao grupo. Ilustração 15: Ao ligar o SDR o user3 faz join a um conjunto de grupos IP Multicast especiais (tal como tínhamos já visto na Tabela 3) 22
    • Esses IP Multicast adicionais são reservados para serviços especiais (ver Tabela abaixo). IPv4 Multicast Addresses Endereços Descrição Capturados Local Network 224.0.0.0-224.0.0.255 224.0.0.1 Todos os sistemas presentes Control na sub-rede Block 224.0.0.2 Todos os routers presentes na sub-rede Internetwork 224.0.1.0-224.0.1.255 224.0.1.40 cisco-rp-discovery Control 224.0.1.75 Session Initiation Protocol Block (SIP) Spanning Tree 224.1.0.0- 224.1.127.255 Spanning Tree Multicast Multicast 224.1.255.255 Groups Groups SDP/SAP 224.2.0.0- 224.2.127.255 SAPv0 Announcements Block 224.2.255.255 Administratively 239.0.0.0- 239.255.136.156 IP do nosso grupo Multicast Scoped 239.255.255.255 Tabela 8: Enunciamos alguns dos endereços Classe D correspondentes a grupos Multicast especiais, que foram capturados na nossa rede. Assim temos já reunidos os três users na nossa sessão Multicast. Ilustração 16: Imagem do NTE com os três users a trocar mensagens 23
    • No entanto, o user3 acaba por ter de sair mais cedo da reunião e desactiva a ligação a sessão Multicast. Ilustração 17: Captura, no Wireshark, do pacote IGMP que prova a saída do terminal3 do grupo Multicast. Nota: Este pacote é destinado ao IP 224.0.0.2, que corresponde a contactar todos os routers multicast na sub-rede do router de origem. 24
    • Ilustração 18: Mais uma vez, ao desligar o SDR, o user3 desliga-se também de todos os grupos Multicast especiais. RPRouter#show ip mroute summary IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.255.136.156), 01:02:50/00:02:59, RP 10.10.1.1, OIF count: 1, flags: S (192.168.10.2, 239.255.136.156), 01:02:49/00:02:59, OIF count: 0, flags: PT (192.168.20.2, 239.255.136.156), 00:00:34/00:02:59, OIF count: 0, flags: PT (*, 239.255.255.255), 01:12:46/00:03:00, RP 10.10.1.1, OIF count: 1, flags: S (192.168.10.2, 239.255.255.255), 00:00:10/00:02:49, OIF count: 0, flags: PX (*, 224.1.127.255), 01:12:46/00:03:14, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.2.127.254), 01:12:46/00:03:07, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.0.1.75), 01:12:47/00:03:08, RP 10.10.1.1, OIF count: 1, flags: S (*, 224.0.1.40), 02:15:40/00:00:00, RP 10.10.1.1, OIF count: 2, flags: SJCL Tabela 9: Prune do Router3 da tabela Multicast do RP Router. 25
    • É visível na tabela de routing Multicast do RP Router, que a entrada para a sub-rede 192.168.30.0/24, foi apagada da lista correspondente ao grupo Multicast da nossa sessão. Isso prova que o Router3 acabou de ser pruned, não participando mais como router multicast, visto o único Terminal, potencialmente interessado na sessão, já ter transmitido a mensagem IGMP leave_group. 4.1 Outros pacotes capturados na rede Uma série de outros tipos de pacotes foram capturados durante o nosso trabalho prático. Interessa pois analisar as suas características mais em pormenor. Ilustração 19: Mensagem de PIM Hello Este PIM Hello tem como finalidade informar os restantes routers multicast, que o emissor do pacote é também router multicast. É uma forma dos routers que funcionam em PIM, se darem a conhecer uns aos outros. Nota: Este pacote é destinado ao endereço Multicast especial 224.0.0.13, endereço de controlo da rede local responsável pelo PIM. 26
    • Ilustração 20: Mensagem de CDP protocol O Cisco Discovery Protocol (abreviado CDP) é um protocolo proprietário da camada de ligação desenvolvido pela Cisco Systems que tem como principal função a descoberta de equipamentos na rede, facilitando a compreensão da topologia da rede e de sua arquitectura. Nota: No caso de termos interfaces a comunicar com redes remotas desconhecidas, deve-se desactivar este género de pacotes. O facto de estes pacotes serem encaminhados para redes externas, pode potencialmente comprometer a segurança da nossa rede local, pelo facto de fornecermos informações relevantes a terceiros. No entanto, não foi este o caso do nosso ambiente de teste. 27
    • Ilustração 21: Mensagens de RIPv1 response. Estas mensagens visam realizar periodicamente o update das tabelas de roteamento nos routers. Nota: Reparar que a métrica de alcance das diferentes sub-redes, coincidem exactamente com a topologia imposta. 28
    • 5 CONCLUSÃO Fundamentalmente, o IP Multicast está a mudar a nossa forma de trabalhar, jogar, viver e aprender, providenciando soluções inovadoras que são simples e seguras. Esta tecnologia de conservação de largura de banda, reduz o tráfego e sobrecarga dos servidores ao distribuir, simultaneamente, uma única stream de informação a várias centenas de utilizadores. As aplicações que mais tiram partido da tecnologia IP Multicast incluem: as de vídeo- conferência, e-learning e distribuição de software, entre muitas outras. Através do estudo pormenorizado do IP Multicast e da implementação desta tecnologia, numa situação prática, conseguimos compreender em profundidade o protocolo e as suas valências. Foram mostrados os aspectos fundamentais do IGMP (Membership query, Membership report e Leave group) bem como do PIM (join/prune e PIM hello) e um dos seus modos de funcionamento (Sparse mode). 29
    • 6 BIBLIOGRAFIA http://www.dcc.fc.up.pt/~mrodrigues/teaching/tar0809/ip%20broadcast%20and%20multicast .pdf http://www.networksorcery.com/enp/protocol/ip/multicast.htm http://www.iana.org/assignments/multicast-addresses/ http://www.dataconnection.com/multicast/pimprotocol.htm http://www.multicasttech.com/faq/ http://www.cisco.com/en/US/docs/internetworking/technology/handbook/IP-Multi.html http://en.wikipedia.org/wiki/Bellman-Ford_algorithm http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-multicast/html/mcast- overview12.html 30
    • 7 ANEXOS ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Router1 ! ip subnet-zero ! ip multicast-routing ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip pim sparse-dense-mode no keepalive no shutdown ! interface Serial0 mtu 1100 ip address 10.10.2.1 255.255.255.0 ip pim sparse-dense-mode clockrate 9600 no shutdown ! interface Serial1 mtu 1100 ip address 10.10.1.2 255.255.255.0 ip pim sparse-dense-mode no shutdown ! interface BRI0 no ip address shutdown ! router rip network 10.10.0.0 network 192.168.10.0 network 192.168.20.0 network 192.168.30.0 ! ip classless ip http server ip pim rp-address 10.10.1.1 ! line con 0 exec-timeout 0 0 31
    • line aux 0 line vty 0 4 login ! end Figura: Configuração do Router1 ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Router2 ! ip subnet-zero ! ip multicast-routing ! ! ! interface Ethernet0 ip address 192.168.20.1 255.255.255.0 ip pim sparse-dense-mode no keepalive no shutdown ! interface Serial0 mtu 1100 ip address 10.10.3.1 255.255.255.0 ip pim sparse-dense-mode clockrate 9600 no shutdown ! interface Serial1 mtu 1100 ip address 10.10.2.2 255.255.255.0 ip pim sparse-dense-mode no shutdown ! interface BRI0 no ip address shutdown ! router rip network 10.10.0.0 network 192.168.10.0 network 192.168.20.0 network 192.168.30.0 ! ip classless 32
    • ip http server ip pim rp-address 10.10.1.1 ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 login ! end Figura: Configuração do Router2 ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Router3 ! ip subnet-zero ! ip multicast-routing ! ! ! interface Ethernet0 ip address 192.168.30.1 255.255.255.0 ip pim sparse-dense-mode no keepalive no shutdown ! interface Serial0 mtu 1100 ip address 10.10.4.1 255.255.255.0 ip pim sparse-dense-mode clockrate 9600 no shutdown ! interface Serial1 mtu 1100 ip address 10.10.3.2 255.255.255.0 ip pim sparse-dense-mode no shutdown ! interface BRI0 no ip address shutdown ! router rip network 10.10.0.0 33
    • network 192.168.10.0 network 192.168.20.0 network 192.168.30.0 ! ip classless ip http server ip pim rp-address 10.10.1.1 ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 login ! end Figura: Configuração do Router3 ! version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname RPRouter ! ip subnet-zero ! ip multicast-routing ! ! ! interface Ethernet0 no ip address shutdown ! interface Serial0 mtu 1100 ip address 10.10.1.1 255.255.255.0 ip pim sparse-dense-mode clockrate 9600 no shutdown ! interface Serial1 mtu 1100 ip address 10.10.4.2 255.255.255.0 ip pim sparse-dense-mode no shutdown ! interface BRI0 no ip address shutdown 34
    • ! router rip network 10.10.0.0 network 192.168.10.0 network 192.168.20.0 network 192.168.30.0 ! ip classless ip http server ip pim rp-address 10.10.1.1 ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 login ! end Figura: Configuração do RP Router 35