Cellule TA-MRAM

Genericamente, os grupos IP Multicast dividem{se em duas categorias: permanentes e transientes. Ambas as categorias utilizam enderecos IP de classe D (gama [224.0.0.0, 239.255.255.255]).

Os grupos permanentes utilizam enderecos bem conhecidos, tipicamente na zona baixa da gama [224.0.0.0, 224.255.255.255] e registados pela Internet Assigned Numbers

Informac~ao ainda mais actualizada sobre enderecos permanentes pode tambem ser obtida atraves do comando \host -l mcast.net".

Por sua vez, os grupos transientes s~ao criados, dinamicamente,por necessidade, pelas aplicac~oes que usufruem, esporadicamente, das capacidade multiponto do IP, n~ao haven- do, actualmente, nenhum mecanismo em operac~ao capaz de assegurar uma reserva de enderecos mutuamente exclusivos31. Nestas circunst^ancias, e perfeitamente possvel que o trafego multiponto gerado por dois conjuntos distintos de aplicac~oes se \misture", caso o endereco IP de classe D escolhido seja o mesmo.

Ao nvel da variante multiponto do S3L, foram tomadas medidas no sentido de resolver, o tanto quanto possvel, o problema da colis~ao de enderecos: opcionalmente, pode ser solicitada a aplicac~ao s3lmgowner que detecte a exist^encia de um grupoIP Multicast em actividade, com o mesmo endereco do grupo que se pretende gerir.

A coexist^encia de mais do que um dono do grupo para o mesmo enderecoIP Multicast deve ser evitada, por raz~oes obvias: basta uma diferenca mnima nas chaves GIK, nos

algoritmos ou ate na temporizac~ao da GIK para que seja incompatvel o trafego gerado

sob ambos os domnios de qualidades de servico. Adicionalmente, pode n~ao existir mais nenhum dono do grupo para o endereco pretendido, mas e perfeitamente admissvel que esse grupo esteja em actividade, com trafego IPMulticastde outra natureza que n~ao S3L. 6.4.1 Detecc~ao na Propria Maquina

A detecc~ao de outro dono S3L, do mesmo grupo, localizado na mesma maquina que o novo dono, e trivial, porquanto os demonioss3lmgownerreservam recursos de uma forma que os

identica facilmente. Recordando o que foi dito na secc~ao 6.2.1, os pedidos de junc~ao s~ao recebidos atraves de umsocketde domnio Unix, localizado em/tmp, e designado segundo um esquema semelhante ao referido na secc~ao 4.4 para os demonioss3lkeyxserver, mas

que leva tambem em conta o enderecoIPMulticast. Pela analise do conteudo de/tmp, um demonios3lmgownerem arranque, ca imediatamente a saber da exist^encia de outro que

controla o mesmo grupo. Todavia, a n~ao exist^encia de outro demonio s3lmgowner para

esse grupo n~ao e conclusiva, dado que a maquina pode ja pertencer ao grupo em causa, por via de outra aplicac~ao que tenha efectuado a junc~ao independentemente de procedimentos S3L32. Neste caso, a detecc~ao deve dirigir{se ao permetro denido pela rede local (LAN), contemplando tambem a propria maquina.

6.4.2 Detecc~ao na Rede Local

A detecc~ao de elementos do grupo pretendido na LAN da qual faz parte a maquina onde o novo dono quer executar e possvel, desde que exista pelo menos um \encaminhador mul- tiponto33" em actividade nessa LAN. Esse encaminhador pode existir implementado quer em hardware (embora a base instalada de encaminhadores com capacidades multiponto 31A este proposito, em [BZ93] sugere{se a criac~ao de umaMulticast Group Authority(MGA), organizada

hierarquicamente numa estrutura semelhante ao DNS, possibilitando a distribuic~ao din^amica de pacotes de enderecos multiponto e mantendo informac~ao sobre a composic~ao dos grupos.

32A junc~ao aqui em causa refere{se a realizac~ao de uma operac~ao

IP ADDMEMBERSHIP, atraves da primi-

tivasetsockopt, sobre umsocketdo tipoSOCK DGRAM, e pode ser observada no codigo que exemplica um

cliente S3L multiponto, na secc~ao B.2.8 do ap^endice B.

seja ainda reduzida), quer sob a forma de um demonio | o mrouted. O encaminhador

e as maquinas da LAN com \capacidades IP Multicast"34 executam o protocolo Internet Group Management Protocol (IGMP) [Fen96], atraves do qual o encaminhador mantem um registo dos grupos IP Multicast que t^em elementos na LAN. Desta forma, o encami- nhador pede aos encaminhadores vizinhos que lhe passem o trafego IP Multicast dirigido apenas aos grupos activos na sua LAN. Periodicamente35, um encaminhador multiponto solicita a todas as maquinas da LAN que lhe enviem informac~oes acerca dos grupos IP Multicast a que pertencem. Estes pedidos (membership queries), bem como as respectivas respostas (membership reports), s~ao dirigidos ao grupo224.0.0.1, ao qual pertencem, por

omiss~ao, todas as maquinas de uma LAN com capacidades IP Multicast.

Assim, para que uma maquina da LAN que a saber se um determinado endereco IP Multicast tem membros associados nessa LAN, bastar{lhe{a auscultar o trafego IGMP, nomeadamente os relatorios de pertenca (membership reports). Precisamente, o demonio

s3lmgowner permite, sob pedido expresso (opc~ao -b), executar essa detecc~ao. Porem, a

analise de trafego IGMP so e possvel atraves de um socket de tipoSOCK RAW, associado ao

protocoloIPPROTO IGMP, estando a criac~ao deste tipo de sockets limitada, por raz~oes obvias

de seguranca36, a utilizadores com privilegios de super{utilizador. Consequentemente, a aplicac~ao s3lmgowner e gerada com setuid root, a m de permitir a detecc~ao de grupos

activos por utilizadores normais. Caso se prescinda desta funcionalidade, e sempre possvel gerar novamentes3lmgowner sem privilegios especiais (ver a secc~ao A.1 do ap^endice A).

6.4.3 Detecc~ao num Contexto Global

A preocupac~ao com a pre{activac~ao do mesmo grupo fora do ^ambito da rede local jus- tica{se apenas quando se pretende criar um grupo cujos elementos ir~ao, possivelmente, dispersar{se por redes distintas. Caso contrario, os procedimentos descritos anteriormente, em conjunc~ao com a manutenc~ao do par^ametrottl(time{to{live) dos pacotes IP Multicast

com o valor 1 (a m de n~ao serem nunca encaminhados para o exterior da sua LAN de origem) s~ao sucientes para uma operac~ao sem problemas.

Quanto a detecc~ao de elementos do grupo fora das fronteiras da rede local, n~ao existe, actualmente, um metodo generico e universal para o efeito. Tal deriva, sobretudo, da conjugac~ao dos seguintes factores:

1. nem todos os encaminhadores t^em capacidades multiponto. Protocolos de encami- nhamento multiponto como o Distance Vector Multicast Routing Protocol (DVMRP) [WPD88], o Multicast Open Shortest Path First (MOSPF) [Moy94] ou o Protocol Independent Multicast(PIM) [EFHT97] so recentemente foram introduzidos nos en- caminhadores comercialmente mais bem sucedidos, pelo que a base instalada destes dispositivos e, ainda, pouco signicativa;

2. consequentemente, a propria experi^encia na utilizac~ao intensiva desses protocolos e tambem diminuta, pelo que s~ao de prever correcc~oes ao rmware/software dos en- caminhadores, a medida que eventuais problemas sejam detectados. Naturalmente, 34A ttulo de curiosidade, rera{se que o comando

ping -t 1 -c 2 224.0.0.1 fornece a lista das

maquinas da LAN com capacidade de processar trafegoIPMulticast. 35De 125 segundos em 125 segundos, de acordo com [Fen96]. 36Basta lembrar que um

isto gera alguma desconanca relativamente a viabilidade de utilizar o IP Multicast em aplicac~oes de grande escala e onde, eventualmente, o transporte de informac~ao crtica (sobre um protocolo que ja e, por natureza, \inavel" e \n~ao{sequenciado") seja necessario;

3. mesmo dispondo de encaminhadores multiponto em hardware, ou recorrendo, na sua aus^encia, a utilizac~ao de tuneis IPIP entre demoniosmrouted, os proprios protocolos

de encaminhamento multiponto carecem de mecanismos de base, que permitam a detecc~ao de grupos activos a partir de pontos que n~ao pertencem a uma rede com elementos nesses grupos. Estes protocolos estabelecem uma especia de arvore/grafo de encaminhamento, para cada grupo, que liga os encaminhadores das redes que t^em pelo menos um elemento nesse grupo. Consequentemente, noutras redes sem elementos nesse grupo n~ao existe a hipotese de saber se o grupo esta activo algures, porque os encaminhadores so mant^em informac~ao de pertenca sobre os grupos activos na sua rede, bem como se disp~oem a receber trafego apenas para esses grupos, \podando"37 os ramos da arvore de encaminhamento que n~ao lhes interessam; 4. os mecanismos de rewall38 mais populares, baseados em gateways de aplicac~ao,

n~ao suportam protocolos n~ao{orientados{a{conex~ao, como o UDP (que transporta os datagramas IP Multicast), limitando a utilizac~ao do IP Multicast ao interior da rewall. Neste caso, a desvantagem derivada do facto de n~ao ser possvel aceder a trafego IP Multicast originado no exterior e, de certa forma, compensada pela garantia de Privacidade do trafego que circula no interior da rewall, bem como pela imunidade a \mistura" com trafego proveniente de fontes externas e dirigido tambem ao mesmo grupo.

Em face deste cenario, a criac~ao de grupos transientes a escala de toda a Internet, ga- rantindo a exclusividade do endereco IP de classe D usado e, naturalmente, problematica. Geralmente, a soluc~ao passa pelo anuncio previo de que determinado endereco vai ser usado, \ocialmente", a partir de determinada data, durante um intervalo de tempo bem denido. Existem inclusivamente ferramentas capazes de anunciar e detectar anuncios da utilizac~ao de um determinado endereco IP Multicast. Em http://www.merit.edu/ net-research/mbone/index/titles.html pode ser encontrada uma lista de aplicac~oes

dessa categoria, genericamente designadas de Session Announcement Utilities, bem como de inumeras outras que tiram partido do IP Multicast.

37Do ingl^es

pruning.

Analise de Desempenho

A m de averiguar o impacto das qualidades de servico disponibilizadas pelo S3L relati- vamente a utilizac~ao simples e directa dos sockets de Berkeley, foi efectuado um estudo comparativo baseado na medic~ao de tempos resultantes da adopc~ao de cada uma dessas abordagens. Acima de tudo, pretendia{se averiguar qual o preco a pagar pela Privacida- de, Autenticac~ao, Integridade e Compress~ao1, em ambas as modalidades ponto{a{ponto e multiponto do S3L.

7.1 Material de Apoio

Para a realizac~ao dos testes de desempenho, foram seleccionadas duas maquinas, interli- gadas atraves de uma rede Ethernet de 10 Mbps e conguradas de forma id^entica:

 um microprocessador Intel Pentium a 166 MHz;

 placa{m~ae com chipsetIntel 430 HX e 512Kb de cache pipelined burst;  32Mb de memoria EDO e 2Gb de disco EIDE de 10ms;

 sistema operativo Linux (vers~ao 2.0.30 do kernel, distribuic~aoSlackware 3.2). Uma vez que os testes realizados tinham em vista, sobretudo, a comparac~ao, em ter- mos relativos, da \abordagem Berkeley" e da \abordagem S3L" e n~ao tanto a medic~ao de tempos de desempenho absolutos, a adopc~ao destas maquinas em detrimento de ou- tras mais rapidas e perfeitamente aceitavel. Adicionalmente, registe{se que tais maquinas constituem, actualmente, o nvel de entrada nas congurac~oes disponibilizadas pelo mer- cado de PCs, pelo que os tempos obtidos ser~ao sempre susceptveis de melhoramento em congurac~oes de melhor nvel.