Protocolos de Roteamento Multicast

Daniel Barroso Monteiro

Escola de Engenharia – Universidade Federal Fluminense – UFF

Rua Passo da Pátria 156, Bloco D, 5o andar – 24210-540 – Niterói – RJ – Brasil

danielbarrosomonteiro@gmail.com

Resumo. A primeira parte deste trabalho tem como objetivo realizar um

estudo comparativo das características entre os três principais protocolos de

roteamento multicast: o DVMRP, PIM e o MOSPF. A segunda parte descreve

uma proposta de projeto de roteamento multicast para a rede IP da

Universidade Federal Fluminense (UFF) para transmissão da TV

Universitária.

1. Introdução

Novas aplicações emergentes como TV sobre IP, videoconferência, computação distribuída, radiodifusão, seminários e palestras na Internet são alguns exemplos de processos que necessitam de comunicação multiponto. Existem três métodos fundamentais para transmissão de dados em uma rede: unicast, broadcast e multicast. Tráfegos unicast são trocados normalmente entre hosts específicos, como um computador pessoal e um servidor Web. Tráfegos broadcast são enviados a todos os usuários de uma rede. Tráfegos multicast são um exemplo de tráfego destinado a apenas uma parte específica de usuários em uma rede.

Tanto broadcast quanto unicast são fáceis de implementar em uma rede. Para o unicast, os dados são entregues a um destinatário único na rede. A idéia de uma rede suportar multicast torna-se muito mais complexa por que os usuários devem se identificar e requisitar participação nos grupos multicast. Os dados serão enviados aos usuários participantes e a rede deverá ser capaz de limitar que o tráfego não propague para direções onde não exista interesse, de forma a não consumir banda desnecessariamente.

Imagine a difusão de uma rádio IP onde cada conexão unicast utiliza 8 kbps de banda de rede. É fácil perceber a economia de rede quando comparamos este tráfego enviado via

unicast com o tráfego enviado por multicast. Quanto mais usuários estão dispostos a receber a mesma programação o crescimento de banda é mínimo com o uso do multicast, conforme observado na figura 1:

Figura 1 – Comparativo do consumo de banda em conexões de 8kbps enviadas via multicast e unicast X crescimento do número de usuários.

A grande maioria dos tráfegos multicast é unidirecional. Existem estudos de multicast bidirecional, porém, não será o foco deste trabalho. Imagine agora, um servidor transmitindo TV via WEB para milhares de usuários na Internet. Seria impossível para o servidor manter conexões TCP ativas com todos esses usuários. Dessa forma, os fluxos de dados multicast são implementados usando-se o protocolo UDP.

Na seção 2 desde trabalho será mostrado o funcionamento do multicast nas LANs com o uso do protocolo IGMP [5]. Também será mostrado que para a transmissão dos dados multicast nas redes WANs é necessário o uso de recursos de roteamento multicast. Serão abordadas as características dos protocolos de roteamento multicast mais comuns, onde destacamos o DVMRP, PIM e MOSPF.

É importante que para o completo entendimento dos conceitos e protocolos apresentados neste trabalho o leitor possua o prévio conhecimento das principais características da família de protocolos IP e de roteamento como o RIP e OSPF.

A UFF possui uma rede óptica metropolitana interligando seus campi em Niterói. Nesta infra-estrutura própria é utilizado, como camada de enlace para o protocolo IP, um anel de roteadores interligados via Gigabitethernet.

A área de comunicação universitária possui necessidade de difusão da TV Universitária por esta rede IP. A programação da TV Universitária atualmente é acessível, na rede interna, através do download de grandes arquivos de vídeo digitalizado contendo pequenos trechos de programação. Esse download é feito via web browser onde, para

cada conexão ao servidor, grande quantidade de banda é consumida para cada usuário que realiza uma diferente cópia desde arquivo de vídeo.

Na seção 3 deste trabalho será apresentada uma proposta de roteamento, endereçamento e melhores práticas no uso do multicast bem como uma proposta de QoS para a rede IP da UFF de forma a dar suporte à transmissão do streaming de vídeo da TV Universitária e abrir uma nova fase para a rede em aplicações transportadas na forma de multicast.

2. Multicast

2.1. Endereçamento Multicast

O Internet Assigned Number Authority (IANA) é o órgão gestor das faixas de endereços IP na Internet [1]. O IANA dedicou uma faixa, conhecida como “Classe D”, especificamente para o endereçamento multicast, como exibido na Figura 2. Esta faixa em notação decimal compreende os endereços entre 224.0.0.0 a 239.255.255.255. Os endereços desta classe D são subdivididos em subgrupos de aplicações conforme ilustrado na tabela 1:

Tabela 1 – faixa endereçamento multicast por aplicações [1]

Faixa de Endereçamento Multicast Aplicações Reservadas

224.0.0.0 – 224.0.0.255 Reservada para protocolos de roteamento.

224.0.1.0 – 224.0.1.255 Controle de blocos Internet.

224.0.2.0 – 238.255.255.255 Faixa pública de endereços (Internet).

239.0.0.0 – 239.255.255.255 Faixa privada de endereços.

Figura 2 – Classes IP onde N representa rede (network) e H host. A classe D foi reservada para endereços multicast.

2.2. Mapeamento do endereço MAC Ethernet para o IP multicast

O IANA reservou também um bloco de endereços MAC Ethernet que começam com 01:00:5E, em hexadecimal. Metade deste bloco foi reservada para os endereços multicast, começando em 01:00:5E:00:00:00 e terminando em 01:00:5E:7F:FF:FF.

Esta reserva permitiu que os 23 bits restantes do endereço MAC sejam correspondentes ao endereço do grupo IP multicast. Para o mapeamento são substituídos os 23 bits menos significativos bits do endereço IP multicast nestes 23 bits disponíveis do endereço MAC Ehternet.

Dessa forma, quando um host está interessado em receber tráfego multicat de determinado grupo basta ficar “escutando” o barramento Ethernet a procura dos pacotes destinados ao endereço MAC do grupo multicast correspondente.

2.3. Internet Group Multicast Protocol Ver.2 (IGMP v2)

O IGMP [5] é um protocolo usado para requisitar a participação em um grupo multicast. A participação em um grupo multicast é dinâmica, ou seja, membros podem entrar ou sair do grupo a qualquer tempo. Um usuário (host) pode ser membro de um ou mais grupos multicast, simultaneamente.

Quando um host tem a intenção de participar de um grupo multicast (endereços classe D), ele envia uma mensagem IGMP de join para o roteador local. Se múltiplos roteadores existem em um mesmo segmento de rede, será mutuamente eleito um designated router (DR) que irá gerenciar todas as mensagens IGMP deste segmento. Após um roteador receber um ou mais joins para um grupo específico, serão encaminhados pacotes ao grupo pela interface apropriada. O roteador apenas encaminha uma cópia do pacote de dados por interface. Se existe mais de um host para receber o pacote em uma mesma interface, todos receberão o mesmo pacote por estarem monitorando o segmento à espera do MAC multicast do grupo. O roteador periodicamente verifica se ainda existem hosts que querem participar do grupo enviando mensagens chamadas queries. Essas queries são transmitidas para um endereço multicast específico (224.0.0.1) que é monitorado por todos [5]. Os hosts que ainda desejam participar dos grupos multicast respondem a essas queries com uma mensagem do tipo membership report. Se o roteador perceber que não há mais respostas às suas queries, o grupo multicast específico será removido de sua tabela de encaminhamento. A versão 2 do protocolo IGMP implementa a mensagem leave que permite ao host anunciar sua saída do grupo multicast permitindo ao roteador imediatamente atualizar sua tabela de encaminhamento.

A figura 3 apresenta o formato das mensagens IGMP.

Figura 3 – Formato da mensagem IGMP [2].

O campo vers fornece a versão do protocolo. O campo type identifica a mensagem em um dos seus dois tipos: Host Membership Query ou Host Membership Report. O campo unused é um campo não utilizado. O campo checksum contém o checksum para os oito octetos da mensagem. Por fim, o campo group address é utilizado pelos hosts para informar a sua associação ou desassociação em um grupo particular [2].

O papel do IGMP será sempre o de incluir ou remover novos hosts ou difusores multicast na rede, sendo este o protocolo suportado pela maioria dos sistemas operacionais atuais. Para o encaminhamento dos pacotes multicast é necessário de uso de algum protocolo de roteamento multicast, onde três dos mais usados atualmente serão apresentados na próxima seção.

A figura 4 mostra parte dos protocolos da pilha TCP/IP. Notamos que o protocolo IGMP está no mesmo nível do protocolo IP, não fazendo parte ou sendo transportado pelos protocolos da camada de transporte.

Figura 4 – Protocolos da pilha TCP/IP.

2.4. Distance Vector Multicasting Routing Protocol (DVMRP)

O primeiro mecanismo de roteamento multicast foi desenvolvido por Steve Deering, da Xerox PARC, e é chamado Distance Vector Multicasting Routing Protocol [3]. O roteador multicast baseado no DVMRP mantém o conhecimento topológico da rede através de um protocolo de roteamento distance-vector, sobre o qual é implementado

um algoritmo de transmissão de difusão seletiva chamado Truncated Reverse Path

Broadcasting (TRPB) [2].

Os roteadores DVMRP enxergam a topologia da rede como um único domínio. Cada roteador mantém uma entrada na tabela de roteamento para cada sub-rede e troca mensagens de roteamento periodicamente com seus vizinhos.

O DVMRP difere do RIP de uma forma muito importante, enquanto o RIP trabalha em termos de roteamento e encaminhamento dos pacotes até um destino em particular, o DVMRP mantém informação dos caminhos de retorno para a origem (difusor) do tráfego multicast [3] (TRPB).

O algoritmo TRPB encaminha pacotes multicast calculando a árvore de caminho reverso mais curto desde a origem para todos os possíveis receptores dos pacotes multicast. Cada roteador multicast deve determinar sua posição na árvore, relativa à origem, e então, determinar por qual interface será o caminho mais curto para o destino (receptor). Os pacotes então serão encaminhados pela interface que possuir este caminho mais curto, assim, as interfaces que não possuem o caminho mais curto serão excluídas da árvore sendo este processo chamado de pruning [3].

O protocolo DVMRP é um protocolo dense-mode, ou seja, a filosofia do protocolo considera que existem muitos transmissores e receptores na rede, de forma que é mais vantajoso transmitir todos os fluxos multicast em todos os links da rede. Caso um roteador verifique que não possui hosts interessados em certo grupo multicast, ele responde (no sentido inverso do tráfego multicast) indicando que não deseja receber tráfego do grupo. Note que, além do desperdício de banda implícito nessa abordagem, existem também conseqüências para os roteadores, que são obrigados a manter informações sobre todos os grupos ativos na rede, e não somente daqueles para os quais existam clientes interessados na recepção. Assim o roteador precisa de mais memória para manter estes dados e mais CPU para realizar todo este processamento [7].

2.5. Protocol Independent Multicast - Sparse Mode (PIM-SM)

Novos protocolos de roteamento multicast surgiram no início dos anos 90. Estas famílias de protocolos foram denominadas coletivamente de Protocol Independent

Multicast (PIM). O nome PIM é devido ao fato de o encaminhamento multicast não depender de nenhum protocolo de roteamento unicast específico. O MOSPF, por exemplo, requer o uso do OSPF como protocolo de roteamento unicast. Assim, o PIM usará a tabela de roteamento unicast existente não importando como ela fora construída [1].

Uma destas famílias de versões é chamada de PIM Dense Mode (PIM-DM). O nome PIM Dense Mode implica em dizer que o protocolo trabalha de forma similar ao apresentado na seção anterior (DVMRP), ou seja, a filosofia do PIM-DM é a de enviar dados multicast para todos os hosts e roteadores. Como este protocolo não é comumente empregado em grandes redes, nosso estudo será direcionado a versão PIM Sparse Mode

(PIM-SM) que é atualmente o protocolo de roteamento multicast mais utilizado no mundo.

O protocolo PIM-SM [6] é um protocolo que existe exclusivamente entre roteadores, ou seja, hosts e difusores (fontes) não participam deste protocolo. O PIM-SM possuiu várias características encontradas nos protocolos de roteamento unicast tais como: mensagens de descoberta, informações de topologia e notificações/detecções de erro. A grande diferença do PIM-SM e outros protocolos de roteamento unicast está no fato de não serem trocados quaisquer tipos de base de dados entre os roteadores.

O PIM-SM gera periodicamente mensagens de hello para descobrir e manter o estado das sessões com seus vizinhos. Essas mensagens são multicast e utilizam o endereço dedicado 224.0.0.13. Após a descoberta dos vizinhos, os roteadores PIM-SM podem realizar os joins (semelhante aos joins do IGMP só que agora realizado pelo protocolo PIM) nos grupos multicast específicos. A mensagem de join irá especificar em qual grupo o roteador quer participar. Esta mensagem é representada normalmente com a notação (*,G) ou (S,G), onde * ou S especificam a fonte (difusor) e G o grupo multicast de interesse [1]. O PIM-SM é exatamente o oposto do PIM-DM no fato de, no modo PIM-DM, o tráfego multicast ser encaminhado para todos os roteadores, até o momento em que esses informem para parar (prune).

O PIM-SM implementa árvores de encaminhamento para cada grupo multicast. Essas árvores são chamadas de Rendezvous Point Trees (RPT), tendo como ponto central ou raiz o roteador chamado de Rendezvous Point (RP). Essas RPTs podem estar configuradas para possibilitar, após o estabelecimento do fluxo de dados multicast, uma otimização para Shortest Path Trees (SPT). As SPTs na verdade são caminhos multicast otimizados que ligam diretamente as folhas da ávores multicast sem passar pelo RP, ou seja, os dados multicast fluirão diretamente entre o difusor e o receptor usando o melhor caminho fornecido pelo protocolo de roteamento unicast, como ilustrado na figura 5.

Figura 5 – Diferença do fluxo de dados RPT e SPT

A figura 6 mostra o fluxo de pacotes entre o difusor e os hosts participantes do grupo multicast. Note que é enviado apenas um pacote por cada interface dos roteadores e o tráfego flui apenas por aquelas interfaces que possuem os melhores caminhos até os destinos.

Figura 6 – Fluxo de dados entre o difusor e os hosts participantes do grupo multicast.

O protocolo PIM tem se mostrado largamente utilizado pela facilidade de implementação e pelo baixo consumo de recurso de processamento nos roteadores. A grande maioria dos fabricantes de roteadores já implemente suporte ao protocolo PIM-SM em seus sistemas operacionais.

2.6. Multicast Open Shortest Path First (MOSPF)

Existe também uma extensão para o protocolo de roteamento Open Shortest Path First (OSPF), denominada Multicast Open Shortest Path First (MOSPF) [4]. O protocolo OSPF é baseado no estado dos enlaces, diferente do RIP, que calcula suas tabelas de rotas na contagem de saltos entre nós de rede ou roteadores.

O MOSPF transmite os pacotes IP multicast da origem para os vários membros do grupo, gerando assim uma árvore. Esta árvore tem como raiz o roteador de origem do pacote e todos os galhos terminam em hosts participantes do grupo multicast. Este esquema de roteamento, onde o caminho dos pacotes depende da origem e dos destinos e a árvore possui raiz na origem, é denominado source/destination routing. Ele é diferente da maioria dos algoritmos de roteamento unicast, incluindo o OSPF, que se baseiam somente no destino do datagrama para o roteamento. A necessidade de considerar a origem para tomar as decisões do roteamento causa maior quantidade de cálculos de roteamento, porém resulta em melhores caminhos em termos de utilização da rede e menor retardo para hosts individuais pertencentes ao grupo.

O MOSPF utiliza o protocolo IGMP para estabelecer a localização de membros de grupos, enviando mensagens IGMP do tipo membership query e recebendo mensagens membership report como resposta. De posse destas informações o roteador MOSPF as distribui por todo o Sistema Autônomo (AS) através do envio de um novo tipo anúncio de estado de enlace, o group-membership-LSA, que indica os pedaços do mapa (topologia) da rede que possuem membros do grupo multicast.

Utilizando este mapa, o roteador MOSPF calcula, na primeira vez que um pacote multicast com uma dada origem e destino é recebido, a árvore com raiz na origem de menor caminho para o pacote. As ramificações da árvore que não possuem membros são eliminadas, de modo que o pacote não é enviado para onde não é necessário. O resultado deste cálculo da árvore é então armazenado para uso dos pacotes multicast do grupo na medida em que forem recebidos posteriormente.

O cálculo de roteamento do MOSPF é muito similar ao cálculo do roteamento unicast utilizado no OSPF, ambos utilizando o algoritmo de Dijkstra para calcular as árvores de menor caminho. No MOSPF, entretanto, existem potencialmente muitas diferentes árvores calculadas, possivelmente uma para cada combinação da origem e destinos. Assim, existem mecanismos para garantir que todos os roteadores MOSPF calculem a árvore de menor caminho absolutamente iguais, o que é essencial para a correta transmissão multicast [2].

As áreas OSPF podem ser vistas como organizadas em uma hierarquia de dois níveis, onde o nível superior corresponde à área do backbone (área 0). Para distribuir os group-

membership-LSAs, o grupo é anunciado para a área 0, de forma que o backbone possua

completo conhecimento dos grupos de todas as áreas. Entretanto, a informação de associação aos grupos não é anunciada de volta para as áreas que não são backbone. Isso reduz o tamanho do banco de dados dos estados dos enlaces da área. Para compensar, o conceito de roteadores receptores de anúncios multicast é introduzido. Com este mecanismo, tais roteadores recebem todos os pacotes multicast, independente do destino. Assim, para habilitar a entrega dos pacotes além dos limites da área, todos os roteadores MOSPF conectando áreas não-backbone ao backbone se anunciam como receptores de anúncios multicast para as áreas não-backbone [2].

O MOSPF possui como vantagem sobre o DVMRP um aumento de estabilidade. A tecnologia de estado dos enlaces do MOSPF converge mais rapidamente que o DVMRP, que sofre dos mesmos problemas do protocolo RIP quando acontecem mudanças na topologia de uma rede redundante [2]. Uma das grandes desvantagens do protocolo MOSPF é a de ser somente suportado em redes que possuem o como protocolo de roteamento unicast o OSPF.

3. Multicast na rede IP da UFF

3.1. Rede da UFF

Em 2005 a Universidade Federal Fluminense realizou um processo de substituição de sua rede suportada por uma infra-estrutura com backbone ATM para uma rede baseada em tecnologia ethernet. Todos os campi, na cidade de Niterói, são interligados através de uma rede óptica própria conforme mostrado na figura 7.

Figura 7 – Rede óptica da UFF em Niterói [8].

Esta rede baseada em ethernet permitiu que o núcleo estivesse interligado por meio de enlaces a 1Gbps através do uso de roteadores/switches de custo acessível, podendo estes ser expandidos a 10Gbps. O fabricante de equipamentos escolhido foi a D-link[9] com os modelos DXS3326GSR, DGS-3312SR e DGS-3324Sri para o núcleo da rede.

As principais características e suporte a protocolos dos equipamentos do núcleo da rede são mostradas a seguir [9]:

• Alta densidade de portas, com 10/100Mbps, Gigabit em cobre, suporte Gigabit de fibra SFP.

• Opção de ligação a 10Gbps.

• Elevada largura de banda (backplane) para interligação em estrela a 120Gbps e pilha em anel de 40Gbps.

• Suporte de encaminhamento de pacotes, suportando modos RIP v.1, v.2, OSPF, DVMRP e PIM-DM e SM.

• Qualidade de Serviço (QoS) multicamada (L2, L3, L4).

• Suporte a jumbo frame.

O diagrama lógico da rede da UFF consiste na interligação em anel entre os roteadores do núcleo que realizam o papel de roteamento/encaminhamento na rede. Os switches de acesso estão espalhados pelos campi da universidade e estão ligados ao núcleo da rede em nível 2 (L2) com topologia estrela, conforme mostrado na figura 8.

Figura 8 – topologia lógica da rede da UFF em Niterói [8].

Os modelos de roteadores D-link instalados suportam os protocolos de roteamento multicast DVMRP e PIM, e nos switches de acesso o protocolo suportado é IGMP V.2.

O roteador do site NTI é a escolha ideal para RP

3.2. Multicast na rede da UFF

A área de comunicação universitária possui na intranet uma TV que é acessível via web por todos que estão conectados na rede IP da UFF. O acesso ao vídeo é realizado na forma de um download do arquivo contendo o trecho de vídeo de interesse.

Existem dois limitadores na forma atual de acesso ao vídeo da TV Universitária. A primeira está relacionada ao vídeo não ser transmitido na forma de streaming, ou seja, o vídeo deve ser completamente copiado para a estação de destino para posteriormente ser reproduzido. Como os arquivos contém algumas dezenas de megabytes, estas cópias podem levar dezenas de minutos. Para solucionar este problema, o responsável na edição do vídeo deverá criá-lo com a opção streaming habilitada no codificador. Dessa maneira, o vídeo será reproduzido na medida em que for recebido pelo usuário. Isso será fundamental para o envio via multicast. Outro limitador, e diretamente relacionado a este trabalho, está na forma em que os arquivos de vídeo são enviados aos usuários. O arquivo de vídeo é copiado pelo usuário, ou seja, via unicast. Isso significa que para cada usuário que tenha interesse em assistir a programação da TV será aberta uma conexão que consumirá N megabytes de rede e recursos de acesso a disco e processamento no servidor. Imagine agora que a programação esteja simultaneamente sendo acessada por 100 usuários internos. Isso consumiria 100 X N megabytes de rede e provavelmente o servidor não suportaria manter todas essas conexões ativas. Como motivador para este trabalho, propomos um estudo para envio deste vídeo na forma de streaming via multicast, o que será detalhado no decorrer desta seção.

Os roteadores da rede IP da UFF suportam dois dos protocolos discutidos na segunda seção deste trabalho. Realizando uma comparação quanto às características e funcionalidades entre o DVMRP e o PIM-SM, a escolha ideal para a rede seria o uso do PIM por se tratar de um protocolo de modo esparso, ou seja, previne a inundação da rede com pacotes multicast e consome menos recursos dos roteadores. A recomendação do uso do PIM-SM é baseada no fato de que o vídeo da TV Universitária esteja accessível a todos na rede e que os pacotes multicast serão encaminhados apenas pelos enlaces que realmente possuam usuários interessados em assisti-lo.

O primeiro passo para a ativação do multicast (PIM-SM) é a escolha de um dos elementos de rede para ser o Rendezvous Point (RP). Como o roteador de núcleo localizado campi do NTI é o que está mais próximo do difusor, esta seria a escolha recomendada para RP (Figura 8). Todas as árvores multicast do protocolo PIM terão como raiz este equipamento do NTI. A escolha de RP em um equipamento significa que o endereço IP de uma de suas interfaces será o endereço do RP. Como todas as interfaces são passíveis de falha, recomenda-se a eleição de uma interface do tipo loopback como RP para manter a maior disponibilidade possível.

Para ativar o protocolo PIM-SM nos demais roteadores, todas as interfaces entre os próprios roteadores, devem estar com o protocolo PIM-SM ativo e, também, todos devem ter configurado o endereço de loopback do roteador do NTI como RP. Ainda nos

roteadores, as interfaces de LAN, conectadas aos switches de acesso, devem estar com o protocolo IGMP V.2 ativo. Normalmente, por padrão, os equipamentos estão com o IGMP configurado de fábrica. Uma vez realizadas todas estas etapas de eleição do RP, configuração do PIM-SM nas interfaces WAN e IGMP V.2 nas interfaces LAN, a rede está pronta para suportar multicast.

O software VIC [10] (Video Conferencing Tool) é uma poderosa ferramenta freeware disponível para a maioria dos sistemas operacionais Linux e Windows e poderá ser instalado em uma máquina para ser difusor de tráfego multicast. A partir de qualquer ponto da rede poderá ser certificado se o multicast está sendo recebido. Detalhes sobre a instalação e funcionamento da ferramenta podem ser encontrados no site www-

nrg.ee.lbl.gov/vic.

Endereços multicast deverão ser escolhidos para os difusores. Como a faixa disponível está entre 239.0.0.0 e 239.255.255.255, e o conceito de sub-rede (máscara de rede) não existe para endereços multicast, os endereços podem ser alocados linearmente nesta faixa. Para a TV Universitária, por exemplo, poderá ser usado o endereço 239.0.0.1. Recomenda-se a separação em sub-faixas para permitir a segmentação de serviços e a delimitação da área de abrangência de cada grupo. Filtros ou listas de acesso devem ser configurados nos roteadores para permitir que apenas os grupos multicast conhecidos sejam permitidos na rede, evitando que tráfegos multicast desconhecidos se propaguem pela rede.

Outro fato importante é a necessidade do uso de Qualidade de Serviço (QoS) na rede. Como os tráfegos multicast, na maioria dos casos, usam o protocolo UDP e são mídias contínuas sensíveis temporalmente, o uso de QoS é fundamental para o perfeito funcionamento dos diferentes serviços na rede.

Os roteadores atualmente instalados na rede suportam QoS no modelo Diffserv com até 8 filas, sendo uma delas de alta prioridade (priority) para baixa latência e jitter. Recomenda-se para o transporte de mídias em tempo real, como VoIP ou videoconferência, o uso desta fila priority. Paras as mídias contínuas como áudio e vídeo não interativas a necessidade principal é a de baixa perda de pacotes, desta forma, recomenda-se o uso de uma fila do tipo WFQ dedicada para este tráfego. Outras filas especiais poderão ser criadas para tráfegos de importância dentro da universidade como o correio eletrônico, web e acesso a bancos de dados.

A figura 9 mostra um exemplo que poderá ser usado para a escolha das filas de tratamento diferenciado de pacotes no modelo Diffserv para a rede da universidade. As marcações EF e AF41 são sugestões para os tráfegos de voz e vídeo, respectivamente. Para o transporte da TV Universitária, recomendamos o uso da marcação AF11.

Figura 9 – Proposta de QoS Diffserv para a rede da UFF

4. Conclusão

O uso do multicast como forma de transporte de mídias contínuas tem mostrado uma série de benefícios. Um dos pontos a se destacar é quanto ao uso inteligente dos recursos de rede ficando evidente a inexistência de milhares de fluxos de dados para atender milhares de usuários. Aplicações destinadas a grandes massas de usuários passam a ocupar menos recursos de rede e processamento em servidores, evitando que sejam redimensionados conforme aumento da demanda e tornando os serviços mais escaláveis. Vale destacar que, com a economia de recursos, associada à redução de carga nos servidores e na rede, torna a própria rede mais disponível a outras aplicações não multicast.

Os protocolos de roteamento mais modernos como o PIM e o MOSPF passaram a ser incluídos nas novas compilações de sistemas operacionais dos equipamentos de rede, o que tem facilitado cada vez mais a ampliação da área de abrangência do multicast.

O grande motivador para a ativação do multicast na rede da UFF foi a possibilidade da difusão do vídeo da TV Universitária. Dessa forma, uma vez o multicast ativo, as possibilidades de novos serviços são inúmeras. Poderão agora, por exemplo, transmitir palestras, cursos, seminários, aulas e qualquer outro tipo de vídeo ou áudio destinado ao corpo de alunos, professores e funcionários da UFF sem grandes investimentos em infra-estrutura de rede.

Referências

[1] Spirent Communications Inc., Multicast Routing – PIM Sparce Mode and Other Protocols, USA, 2003, www.spirentcom.com.

[2] MELCHIORS, CRISTINA, Sistemas Interpessoais de Videoconferência (MBone), UFRGS, Porto Alegre,1997.

[3] RFC 1075: Distance Vector Multicast Routing Protocol. Novembro de 1998.

[4] RFC 1584: Multicast Extensions to OSPF,1994.

[5] RFC 2236: Internet Group Management Protocol, Version 2, 1997.

[6] RFC 2362: Protocol Independent Multicast - Sparse Mode.,1998.

[7] Rede Nacional de Ensino e Pesquisa, Entrevista com Adenilson Raniery, Brasil, 2002, www.rnp.br.

[8] Schara, Luiz, Projeto: Atualização da Rede UFF, UFF, Brasil, 2005.

[9] D-LINK Eletronics, USA, 2007, www.dlink.com.

[10] Network Research Group, University of California, USA, 2007, http://www-nrg.ee.lbl.gov/vic.