Roteamento Multicast na Internet

Lus Henrique Maciel Kosmalski Costa

luish@gta.ufrj.br

Otto Carlos Muniz Bandeira Duarte

otto@gta.ufrj.br

Grupo de Teleinformtica e Automao  GTA Universidade Federal do Rio de Janeiro COPPE/EE - Programa de Engenharia Eltrica C. P. 68504 - CEP 21945-970 - Rio de Janeiro - RJ - Brasil Tel. +55 21 2260-5010 r.240 Fax +55 21 2562-8628

1 Princpios Bsicos do IP Multicast

Muitas das novas aplicaes da Internet, como vdeo-conferncia, ensino distncia e TV na Internet, pertencem categoria de comunicao de grupo, ao contrrio de outras aplicaes que constituem conversaes ponto-a-ponto. Estas novas aplicaes podem ter vrias fontes e muitos receptores que podem chegar a milhes, como no caso da TV na Internet. Um servio multicast eciente necessrio uma vez que a utilizao de mltiplos canais unicast invivel em termos dos recursos da rede e da capacidade de processamento das estaes. O IP Multicast implementa esta funcionalidade na camada de rede, sendo composto por um modelo de servio e gerenciamento de grupo, e por protocolos de roteamento [1]. Neste captulo, so apresentados os conceitos fundamentais do IP Multicast.

1.1 Modelo de Servio

O modelo de servio IP Multicast dene um grupo como uma conversao aberta, onde:

qualquer um pode participar, sem exigncia de autorizao; uma estao pode pertencer a vrios grupos diferentes, sem qualquer restrio; uma fonte pode enviar dados para um grupo multicast, pertencendo, ou no a este grupo; o grupo dinmico, uma estao pode entrar ou sair a qualquer momento; o nmero e a identidade dos membros do grupo no so conhecidos nem pela fonte e nem pelos receptores.
Um grupo identicado por um endereo IP multicast (Seo 1.2). Alguns endereos so reservados para propsitos especcos (p. ex., identicar todas as estaes da rede, ou todos os roteadores).

1.1.1 Suporte ao Multicast na Estao

Para que uma estao possa utilizar o servio multicast, ela deve implementar o protocolo IGMP (Internet Group Management Protocol). Estaes e roteadores devem ser capazes de lidar com um novo tipo de endereo, o endereo IP multicast. Alm disso, para que uma estao suporte o servio IP multicast, a sua interface de servio IP deve ser estendida [2] para que:

Apoiado por recursos da CAPES, CNPq e FAPERJ.

 esta estao possa se conectar ao grupo, ela deve reprogramar a camada rede, e, possivelmente, as camadas mais baixas, de forma a receber pacotes endereados para grupos multicast; uma aplicao desta estao que se conectou a um grupo multicast, e que envia dados para este grupo, deva ser capaz de escolher se os pacotes devem ser enviados em loopback de forma que a aplicao receba os dados que ela produz; uma estao seja capaz de limitar o escopo dos pacotes multicast enviados. O pacote IP possui um campo Time-To-Live (TTL) em seu cabealho, que originalmente servia para limitar o tempo de vida de um pacote na rede e diminuir os efeitos de loops temporrios do roteamento IP. Na prtica, porm, o valor do campo TTL diminudo de 1 a cada roteador atravessado pelo pacote IP, e no por um intervalo de tempo. Desta forma, no IP Multicast, o campo TTL utilizado para controlar o alcance (em nmero de ns) que um pacote pode percorrer na rede a partir da fonte.
Quando uma aplicao sinaliza camada de rede que ela deseja se conectar a um grupo multicast, o software de rede verica se a estao j est conectada a este grupo. Em caso negativo, uma mensagem relatrio IGMP (a ser detalhado na Seo 1.3) enviada na rede local. Alm disso, o endereo IP multicast do grupo mapeado no endereo multicast de nvel mais baixo, e a interface de rede reprogramada de forma a aceitar pacotes multicast enviados para este grupo. importante notar que a estao se conecta a um grupo multicast em uma interface, ou seja, uma estao com diversas interfaces de rede pode escolher a interface atravs da qual se conectar ao grupo multicast. No nvel da rede local, o servio IP multicast pode tirar vantagem da tecnologia de rede utilizada. Considere por exemplo a tecnologia Ethernet. No Ethernet, so possveis transmisses ponto-a-ponto, broadcast, e multicast. Uma faixa de endereos MAC do Ethernet foi reservada para o servio multicast. Os endereos multicast Ethernet possuem o bit menos signicativo do byte mais signicativo igual a 1. O endereo multicast Ethernet ento formado pela operao lgica ou dos 23 bits menos signicativos do endereo IP multicast com o endereo Ethernet 01.00.5E.00.00.00 (Figura 1). Por exemplo, o endereo IP multicast 224.0.2.2 mapeado no endereo multicast Ethernet 01.00.5E.00.02.02. Como consequncia, endereos IP multicast que diferem apenas pelos 9 bits mais signicativos so mapeados no mesmo endereo multicast Ethernet. Isto signica que a cada quadro recebido pela camada Ethernet, a camada de rede deve vericar se o endereo IP multicast corresponde ao endereo desejado.
32 bits 1110 28 bits

Endereo IP Multicast 5 bits

239.225.0.1 23 bits

Endereo Multicast Ethernet Prefixo 25 bits

01-00-5e-7f-00-01 23 bits 48 bits

Figura 1: Mapeamento entre os endereos multicast IP e Ethernet.

Tambm possvel emular a transmisso multicast utilizando o broadcast Ethernet e um ltro de entrada no nvel IP, esta era a soluo utilizada nas primeiras placas Ethernet que no suportavam o servio multicast. A utilizao do servio multicast em uma rede fsica que no suporta a difuso (como o ATM, por exemplo) mais complexa e menos eciente. Algumas vezes, a soluo a utilizao de um servidor que concentra o trfego multicast e o redistribui para os receptores interessados, atravs de n conexes ponto-a-ponto, ou de uma conexo ponto-a-multiponto, se esta for possvel (caso do ATM). Os protocolos GARP (Generic Attribute Registration Protocol) e GMRP (GARP Multicast Registration Protocol), denidos no Padro IEEE 802.1p [3], servem para coordenar a distribuio multicast entre pontes e comutadores. O protocolo GARP fornece a funcionalidade de roteamento no nvel de enlace, enquanto o protocolo GMRP implementa a funcionalidade de gerenciamento de grupo, equivalente ao que o IGMP realiza no nvel de rede.

1.1.2 Criao e Destruio de um Grupo Multicast

Criar um grupo multicast consiste, para a fonte de trfego, na escolha de um endereo multicast e no envio de dados para este endereo. Aps o recebimento de pacotes para um novo endereo multicast, os roteadores criam um novo estado de reenvio (forwarding state) e conguram uma rvore de distribuio para este grupo multicast. Se no existirem receptores interessados neste grupo, a rvore de distribuio limitada pelo roteador correspondente ao primeiro salto na rvore (em protocolos de roteamento por fonte, p. ex., DVMRP) ou por um roteador central (no caso de protocolos de roteamento que constroem rvores centradas, p. ex., PIM-SM). No entanto, dependendo do protocolo, os roteadores podem guardar estado para este grupo, ainda que no enviem dados (o protocolo armazena estado para ramos podados da rvore). A destruio de um grupo multicast consiste, simplesmente, na parada do envio de dados, pela fonte, para o endereo multicast. Como a rvore de distribuio implementada atravs de soft-states nos roteadores, a rvore de distribuio vai desaparecer pouco a pouco, aps o estouro de temporizadores (p. ex., o programa mrouted utiliza um temporizador de 5 minutos por default).

1.2 Endereamento
Um endereo multicast no identica uma mquina, mas um grupo, sendo dinamicamente alocado, e vlido durante toda a sesso multicast. No IPv4, um endereo multicast possui os quatro primeiros bits iguais a 1110, o que corresponde faixa de 224.0.0.0 a 239.255.255.255. Esta faixa corresponde, no projeto original do endereamento IP em classes, Classe D. Embora a noo de Classes A, B e C tenha deixado de ser utilizada no roteamento inter-domnio [4], a Classe D continuou reservada para o IP multicast. Um endereo IP multicast possui o formato mostrado na Figura 2.
0 1 1 1 0 x x x x x x x x x x x x x x x x x x x x x x x x x x x 31 x

Figura 2: Formato do endereo multicast IPv4. Em regra geral, um endereo multicast temporrio, sendo requisitado e atribudo dinamicamente. Entretanto, os endereos de 224.0.0.0 a 224.0.0.255 foram reservados pelo IANA (Internet Assigned Numbers Authority). Esta faixa corresponde a endereos de escopo local ao enlace (link-local) e portanto no devem ser encaminhados por roteadores, independente do valor

Tabela 1: Exemplos de endereos multicast reservados. 224.0.0.1 224.0.0.2 224.0.0.4 224.0.0.5 All Hosts All Multicast Routers All DVMRP Routers All OSPF Routers

de seu campo TTL. Adicionalmente, alguns endereos so reservados para servios especcos. A Tabela 1 mostra alguns exemplos desses endereos reservados. O restante da faixa de endereos Classe D (224.0.1.0 a 239.255.255.255) corresponde a endereos multicast dinmicos. O endereo multicast no atribudo por uma entidade reguladora, como o IANA faz para as faixas de endereos unicast. Em princpio, o endereo multicast dinamicamente escolhido pela fonte de dados. Portanto, existe um risco de que diversas fontes escolham o mesmo endereo multicast. Dependendo do escopo (denido pelo campo TTL) de cada trfego, uma aplicao pode ser corrompida, recebendo pacotes de outras aplicaes. Portanto, existe a necessidade de um esquema de alocao de endereos parte para evitar colises. No entanto, uma vez que no existe uma estrutura hierrquica de endereamento, a alocao de endereos multicast pode ser complexa. Existem diferentes mtodos para limitar o escopo do trfego multicast, os principais so apresentados a seguir. Os diferentes mecanismos de alocao de endereos multicast existentes so apresentados nas Sees 1.2.4 e 1.2.5.

1.2.1 Endereos e Escopos

A faixa de endereos multicast dinmicos (224.0.1.0 a 239.255.255.255) foi subdividida pelo IANA, de acordo com diferentes escopos para os grupos multicast. Os endereos de 224.0.1.0 a 238.255.255.255 podem ser utilizados por aplicaes com escopo global. J os endereos de 239.0.0.0 a 239.255.255.255 tm escopo limitado. Os endereos na faixa 239.253.0.0/16 devem ser utilizados por aplicaes de escopo local ao site, l os endereos 239.192.0.0/14 so reservados ao escopo local organizao.

1.2.2 Limitando o Escopo usando o Campo TTL

No IPv4, o controle do escopo dos pacotes multicast tambm pode ser realizado atravs do campo TTL (Time To Live) do cabealho IP. Numa transmisso unicast, o campo TTL decrementado de uma unidade a cada vez que o pacote encaminhado por um roteador. O pacote descartado se o valor do TTL chegar a zero. No IP Multicast, e em especial no MBone, o campo TTL freqentemente utilizado para limitar a distncia na rede (em nmero de saltos) que um pacote multicast pode atingir. No entanto, nem sempre uma regio pode ser denida por um determinado nmero de saltos. Desta forma, alm do funcionamento normal do campo TTL, os roteadores so congurados com thresholds (valores limites) para os tneis e enlaces multicast. Quando um threshold est congurado, o roteador decrementa normalmente o TTL do pacote, como no unicast, mas ir descartar o pacote se o valor obtido for menor que o valor do threshold. Congurando-se thresholds consistentes nas bordas de uma regio, uma estao emissora pode garantir que o seu trfego no escapar desta regio, bastando para tanto atribuir um valor de TTL dos pacotes emitidos inferior ao threshold. Tipicamente, os valores de TTL inicial mostrados na Tabela 2 so utilizados [5] na denio de escopos. importante observar que as noes de organizao, regio e continente no so explicitamente denidas, outros valores de TTL aparecem na literatura.

Tabela 2: Valores de TTL tpicos. Escopo rede local site regio global TTL inicial 1 15 63 127

Threshold  16 64 128

1.2.3 Escopos Administrativos

A implementao de escopos atravs do campo TTL do cabealho IP possui algumas limitaes. Em alguns casos difcil escolher um valor de TTL adequado para o escopo desejado. Por exemplo, impossvel congurar duas zonas de escopo que se sobrepem parcialmente. Para enfrentar situaes onde o escopo por TTL no ecaz, passou-se a usar o escopo administrativo (que logo foi implementado pelo mrouted e na maior parte dos roteadores). O escopo administrativo dene uma fronteira especicando uma faixa de endereos multicast que no sero encaminhados pelo roteador, em nenhuma das direes. O escopo administrativo mais exvel que o escopo por TTL (as fronteiras podem ter qualquer formato) mas possui algumas desvantagens. Para saber a distncia que um pacote vai percorrer na rede, a fonte de dados precisa conhecer todas as zonas s quais ela pertence. Alm disso, uma vez que as fronteiras so bi-direcionais, duas zonas de escopo que se sobreponham, totalmente ou em parte, tm que obrigatoriamente utilizar faixas de endereos disjuntas. Desta maneira, idealmente, as zonas deveriam ser alocadas de forma hierrquica  da maior para a menor zona. Esta tarefa no entanto complexa, uma vez que no existe uma autoridade com esta funo. Alm destes problemas, pode-se facilmente errar a congurao de uma fronteira, bastando para isso mal congurar, ou esquecer de congurar, um roteador. Os erros de congurao tambm podem ocorrer com o escopo por TTL, mas de uma maneira geral, pode-se congurar o TTL com um valor um pouco maior que o necessrio e, assim, garantir o funcionamento da aplicao, com o custo de o trfego multicast estar atingindo uma parte da rede inutilmente. Com o escopo administrativo mais difcil de se congurar esta margem de segurana. Um protocolo para facilitar a congurao administrativa de escopos foi padronizado pelo IETF (Internet Engineering Task Force). O Multicast Zone Announcement Protocol (MZAP) [6] possibilita descoberta automtica de zonas de escopo, assim como zonas mal conguradas.

1.2.4 Alocao Esttica de Endereos Multicast

Enquanto um mecanismo de alocao dinmica de endereos multicast era denido pelo IETF, um mecanismo esttico de alocao, chamado endereamento GLOP [7], foi proposto como soluo transitria para o problema de alocao de endereos. A faixa de endereos 233/8 foi reservada pelo IANA para a alocao esttica de endereos multicast [7]. A idia bsica do mecanismo incluir o identicador de Sistema Autnomo (AS  Autonomous System) no endereo multicast. Assim, os 16 bits do nmero de AS (nmero que identica de maneira nica os domnios utilizados no roteamento inter-domnio) so tomados como os 16 bits do meio do endereo multicast, como mostrado na Figura 3. Desta forma, ao Sistema Autnomo 16007 atribuda a faixa de endereos de 233.64.7.0 a 233.64.7.255.

0 233

8 16 bits AS

23 24 local bits

31

Figura 3: Formato do endereo multicast IPv4 alocado estaticamente.

1.2.5 Arquitetura de Alocao Dinmica de Endereos Multicast

O IETF criou um grupo de trabalho especco para a elaborao de uma arquitetura de alocao de endereos multicast. O resultado do trabalho do grupo MALLOC (Multicast-Address Allocation) foi a arquitetura MAAA (Multicast Address Allocation Architecture) [8]. A arquitetura MAAA possui trs camadas, que incluem um protocolo cliente-servidor (MADCAP), um protocolo intra-domnio (Multicast AAP) e um protocolo inter-domnio (MASC). O protocolo MADCAP (Multicast Address Dynamic Client Allocation Protocol) [9] um protocolo cliente-servidor que permite que as estaes requisitem os servios de alocao de endereos multicast de um servidor de endereos multicast (o servidor MADCAP). O design do protocolo semelhante ao do protocolo DHCP (Dynamic Host Conguration Protocol) [10]. O protocolo Multicast AAP (Multicast Address Allocation Protocol) [11] utilizado pelos servidores MADCAP para coordenar a alocao de endereos dentro de um domnio, de forma a evitar colises (a alocao de um mesmo endereo multicast por duas aplicaes diferentes). O protocolo MASC (Multicast Address Set Claim) [12] se encontra no topo da hierarquia da arquitetura MAAA. O MASC utilizado para coordenar a alocao de endereos no nvel inter-domnio. O MASC serve para um n (normalmente, um roteador) requisitar e alocar um ou mais prexos (faixas) de endereos multicast para o domnio ao qual o n pertence. Estes endereos sero utilizados por grupos iniciados por estaes dentro de seu domnio. O MASC utiliza o mesmo conceito de domnios do roteamento inter-domnio da Internet, ou seja, o de Sistemas Autnomos (AS), e trabalha em conjunto com o BGP (Border Gateway Protocol) [13] para difundir a informao de alocao de endereos. A alocao hierrquica, domnios lhos (ou sub-domnios) escutam as faixas de endereos multicast alocadas por seus domnios pais, e selecionam sub-faixas que sero utilizadas de acordo com suas necessidades. Quando um roteador MASC percebe que no h espao de endereamento multicast suciente, ele procede requisio de uma faixa maior. O MASC aloca as faixas de endereos de forma dinmica, utilizando um mecanismo de escuta e pedido, com deteco de colises. Assim, domnios-lhos escutam as faixas de endereos alocadas por seu pai, podendo selecionar sub-faixas a partir destas faixas, e devem neste caso propagar as faixas selecionadas a seus irmos, tornando pblico o requerimento destas faixas. Os ns que esto em processo de requisio de uma faixa devem esperar um determinado tempo, antes de considerarem-la alocada, para detectar possveis colises com as faixas alocadas por seus irmos. Aps este perodo, as faixas alocadas com sucesso devem ser informadas ao servidor MAAS do domnio, e aos outros domnios, atravs do protocolo BGP. Para tanto, so utilizadas rotas de grupo (group routes) do BGP. Estas rotas de grupo do BGP so utilizadas pelo protocolo BGMP (Border Gateway Multicast Protocol) [14] para a construo de rvores multicast inter-domnio (Seo 3.2). Aps este processo, os servidores MAAS podem atribuir endereos multicast da faixa alocada a grupos iniciados dentro de seu domnio. A Figura 4 ilustra a alocao hierrquica feita pelo MASC. Os domnios A, D e E so provedores de backbone. Os domnios B e C so provedores regionais, clientes de A, e possuem os provedores F e G como clientes, respectivamente. Suponha que B deseja obter uma faixa de endereos para seu domnio, e que o Domnio A j tenha obtido a faixa de endereos 224.0.0.16, utilizando o MASC. Os domnios B e C so lhos de A, que anuncia sua faixa de endereos, 224.0.0.16, a todos

Domnio D

Domnio E

D1 A4 A1

E1

Domnio A 224.0.0.0/16

A3 B1 Domnio B 224.0.128.0/24

A2 C1 Domnio C 224.0.1.0/25

B2

C2

F1 Domnio F

G1 Domnio G

Figura 4: Alocao hierrquica de endereos pelo MASC.

os seus lhos. Suponha que B requeira a sub-faixa 224.0.1.0/24 da faixa de A. B informa seu domnio pai, A, e outros domnios-irmos que estejam diretamente conectados a B , desta requisio. O domnio A por sua vez propaga este pedido a todos os outros domnios-lhos. No caso em que algum dos domnios-irmos j tenha alocado a faixa pedida, ou parte desta, este envia um anncio de coliso. Este o caso do domnio C , que possui a faixa 224.0.1.0/25. Ao ouvir o anncio de coliso, B deve tentar uma nova faixa, por exemplo 224.0.128.0/24. Em seguida, B deve esperar por anncios de coliso durante um determinado intervalo de tempo, antes de considerar que a faixa tenha sido alocada com sucesso. Se nenhuma coliso ocorrer, B comunica a faixa de endereos obtida a seus servidores MAAS locais, e a outros domnios, utilizando rotas de grupo BGP. Como ser visto em mais detalhes na Seo 3.2, quando um domnio X anuncia uma rota de grupo BGP, para a faixa multicast F , isto signica que X pode ser utilizado como rota para chegar ao domnio-raiz dos grupos dentro da faixa F . Por exemplo, o roteador de borda B1 anuncia a rota de grupo correspondente faixa 224.0.128.0/24 ao roteador A3 no domnio A. Uma vez que todos os roteadores de borda de um domnio so ligados por uma malha de conexes BGP internas, a rota de grupo de B1 passada para A1, A2 e A4. Como o domnio A s recebeu uma rota para este prexo, a rota por B a escolhida. Se houvesse mltiplas rotas, a escolha seria realizada atravs dos atributos das rotas, como feito pelo BGP para rotas unicast. As rotas de grupo so armazenadas pelos roteadores BGP dentro de uma tabela chamada G-RIB (Group - Route Information Base). A rota de grupo de B1 armazenada por A3 em sua G-RIB como (224.0.128.0/24, B1), indicando que o roteador B1 o prximo salto para chegar ao domnio raiz para os grupos dentro de 224.0.128.0/24. Os roteadores A1, A2 e A4 armazenam (224.0.128.0/24, A3) em suas G-RIBs, uma vez que A3 o seu prximo salto correspondente. A agregao de rotas de grupo funciona da mesma forma que para as rotas unicast no BGP. Por exemplo, uma vez que a faixa de endereos de A, 224.0.0.0/16, engloba a faixa de endereos da rota de B1, 224.0.128.0/24, os roteadores de borda de A no anunciam a rota de B1 a outros domnios, mas apenas a rota agregada. No exemplo acima, o roteador A1 anuncia a rota de grupo (224.0.0.0/16, A1) ao roteador E1 no domnio E . Desta forma, a informao de alocao de endereos multicast pelo protocolo MASC propagada a todos os outros domnios. Polticas de transmisso para o trfego multicast podem ser implementadas, da mesma forma

que para o trfego unicast, pela propagao seletiva dos anncios de rotas de grupo pelo BGP. Por exemplo, um domnio pode anunciar rotas de grupo apenas para as faixas de endereos alocadas por ns dentro de seu prprio domnio, ou por domnios clientes. Desta forma, ele pode evitar a utilizao de seus recursos por trfegos encaminhados para um domnio-raiz de terceiros. A separao da alocao de endereos multicast em dois nveis, inter-domnio e intra-domnio, permite com que endereos multicast sejam alocados rapidamente, internamente a um domnio, da mesma forma que endereos unicast so rapidamente alocados dentro de uma rede, enquanto que a alocao de prexos unicast para um domnio mais lenta.

1.3 Gerenciamento de Grupo - IGMP/MLD

O Internet Group Management Protocol (IGMP) um protocolo de nvel 3 (como o ICMP). No IPv6, o protocolo responsvel pelo gerenciamento de grupos multicast o MLD (Multicast Listener Discovery). O IGMP responsvel por informar o roteador multicast local da presena de estaes interessadas em escutar um determinado grupo multicast. Diferentes verses do protocolo IGMP existem:

IGMP verso 1: especicado em [15]. IGMP verso 2: especicado em [16]. A maior diferena do IGMPv2 em relao ao IGMPv1 a introduo do mecanismo de fast leave. IGMP verso 3: especicado em [17]. A verso 3 adiciona a possibilidade de ltragem de trfego por fonte.
A operao do protocolo IGMP pode ser dividida em duas partes: o lado estao e o lado roteador. Quando uma estao se conecta pela primeira vez a um grupo multicast G, ela programa sua interface de rede para receber o trfego multicast desejado e envia uma mensagem IGMP Join na rede local. Esta mensagem informa o(s) roteador(es) locais que existe um receptor interessado no grupo multicast G. Para conhecer a identidade dos grupos multicast para os quais existe interesse nas suas redes locais, o roteador multicast local envia periodicamente mensagens QUERY, interrogando as estaes conectadas rede local sobre a presena de ouvintes para algum grupo multicast. Cada estao que deseje escutar um grupo responde interrogao com uma mensagem relatrio (REPORT), onde so listados os endereos multicast dos grupos nos quais a estao est interessada. Um mecanismo de cancelamento de resposta utilizado, para evitar a imploso do roteador multicast. Um receptor no envia o seu relatrio imediatamente aps a recepo de um QUERY, mas apenas aps um intervalo de tempo aleatrio, durante o qual ele escuta os relatrios emitidos por outras estaes. Se os grupos nos quais o receptor tem interesse forem pedidos por outras estaes, ele pode suprimir o envio do seu relatrio. Quando a aplicao correspondente ao grupo multicast G termina, e a estao no tem mais interesse em receber o trfego endereado para G, a estao reprograma sua interface de rede para no mais repassar o trfego multicast para a camada superior, e pra de enviar mensagens IGMP. No IGMPv1, quando todas as estaes que estavam conectadas ao grupo G na rede local deixam de escutar esse grupo, o trfego para o grupo G continua a ser enviado por um intervalo de tempo, equivalente ao timeout (tempo de validade) do estado G no roteador. Para diminuir a latncia de desconexo do grupo, no IGMPv2 foi introduzido um novo tipo de mensagem, Leave, que permite a desconexo explcita do grupo multicast. Alm disso, um conjunto de regras de processamento garante que um receptor que deixa o grupo no desconectar os outros.

O IGMP um protocolo de sinalizao que se restringe ao dilogo local entre as estaes receptoras e o roteador multicast local (ou roteador de primeiro salto). O escopo do IGMP local. A criao da rvore de distribuio multicast independente do IGMP, sendo responsabilidade dos roteadores multicast no escopo de longa distncia (wide-area), que executam um protocolo de roteamento multicast.

1.3.1 O Protocolo IGMPv3

A Verso 3 do IGMP acrescenta o suporte a ltragem de fontes, ou seja, as estaes tm a possibilidade de anunciar o interesse na recepo de pacotes enviados para um endereo de grupo multicast, apenas por determinadas fontes, ou por qualquer fonte, exceto determinadas fontes. Essa informao pode ser utilizada pelos protocolos de roteamento multicast para evitar o envio de pacotes de determinadas fontes multicast para redes onde no existem receptores interessados [17]. Para permitir a congurao dos ltros no IGMP, uma modicao da API socket necessria. Desta forma, um pedido IGMPv3 possui o seguinte formato:
IPMulticastListen (socket, interface, mcast-address, filter mode, source list)

onde o lter mode pode ser INCLUDE ou EXCLUDE. Por exemplo, para especicar que um receptor deseja escutar o grupo multicast G e receber apenas os dados enviados pelas fontes S1 e S2, o pedido ter a seguinte forma:
IPMulticastListen (socket, interface, G, INCLUDE,{S1, S2})

Se por outro lado o receptor deseja ouvir o grupo G mas receber dados enviados por todas as fontes, exceto S1 e S2, o pedido ser:
IPMulticastListen (socket, interface, G, EXCLUDE, {S1, S2})

As operaes equivalentes ao join(, G) e leave(, G) das verses anteriores do IGMP so equivalentes a:

Join = IPMulticastListen (socket, interface, G, EXCLUDE, {}) Leave = IPMulticastListen (socket, interface, G, INCLUDE, {})

2 Roteamento Multicast Intra-domnio

O protocolo IGMP restrito ao dilogo local entre os receptores e o primeiro roteador multicast. Para que o trfego multicast seja encaminhado atravs de vrios saltos, a criao de uma rvore de distribuio necessria, sendo responsabilidade do protocolo de roteamento. Este captulo apresenta os principais protocolos de roteamento IP multicast, evidenciando sua evoluo desde o DVMRP, o primeiro protocolo proposto com o modelo de servio IP Multicast.

2.1 Os Diferentes Algoritmos de Roteamento Multicast

Existem diferentes algoritmos para a criao da rvore de distribuio multicast. No entanto, de uma maneira geral, os protocolos de roteamento multicast mais difundidos podem construir dois tipos de rvore de distribuio: rvores por fonte (source-based trees, ou source-specic trees) ou rvores compartilhadas (ou centradas  center-based trees). A diferena bsica entre as duas

rvores de distribuio que para cada fonte de dados multicast necessria a criao e manuteno de uma rvore por fonte, enquanto que a rvore compartilhada utilizada por vrias fontes. Como conseqncia, a raiz da rvore por fonte o prprio n fonte de trfego, enquanto que a rvore compartilhada tem por raiz um n arbitrrio da rede (idealmente localizado no centro da rede). Antes de descrever os diferentes protocolos de roteamento, apresentada a modelagem mais freqente para o problema de roteamento multicast. Em seguida, so apresentados os principais algoritmos propostos na literatura, e que serviram de base para a implementao dos protocolos de roteamento multicast Internet.

2.1.1 O Problema de Roteamento Multicast

O problema do roteamento multicast pode ser modelado da seguinte forma. A rede pode ser modelada por um grafo direcionado, G, consistindo de um conjunto V de vrtices (ns) e de um conjunto E de enlaces [18, 19]. Um enlace direcionado do grafo G, entre os ns u e v representado pelo par (u, v). Considere que M o conjunto dos ns do grupo multicast, incluindo os ns fonte (M um sub-conjunto de V ). O problema de roteamento multicast consiste em descobrir uma ou mais topologias de interconexo, rvores, sub-conjuntos de G, que incluem todos os ns em M . Quando uma nica rvore construda, independente do n fonte, esta uma topologia de interconexo compartilhada, ou rvore compartilhada. Quando vrias topologias so construdas, uma por fonte, a soluo para o problema um conjunto de topologias de interconexo direcionadas pela fonte, ou rvores por fonte. Nas sees a seguir so apresentados exemplos de algoritmos pertencentes s duas categorias de solues. importante observar que o modelo apresentado no considera a presena de enlaces simtricos. Na prtica, os enlaces de transmisso podem ser bi-direcionais e possuir caractersticas semelhantes nas duas direes, o que signica que o grafo G possui diversos enlaces no-direcionados.

2.1.2 O Algoritmo de Inundao

No algoritmo de inundao, ao receber um pacote multicast, o n verica se esta a primeira vez que o pacote recebido. Se este o caso, o pacote enviado em cada uma das interfaces de sada, exceto aquela pela qual o pacote foi recebido. Caso contrrio o pacote descartado. A diculdade est no teste de primeira recepo do pacote. Uma soluo seria o n gravar todos os pacotes recebidos at ento. Outra possibilidade seria cada pacote carregar a lista dos ns atravessados. Por exemplo, o protocolo OSPF (Open Shortest Path First) [20] utiliza um algoritmo de inundao onde o roteador compara a data (um nmero de controle do banco de dados) do pacote recebido com a data de modicao de seu prprio banco de dados. Embora este algoritmo seja simples e robusto, sua implementao inviabilizada pelo consumo de memria e recursos da rede. No entanto, a inundao serviu de base para algoritmos mais complexos utilizados em alguns dos protocolos de roteamento multicast implementados.

2.1.3 rvores de Cobertura

Outra soluo para o problema de roteamento multicast consiste na construo de uma rvore de cobertura (spanning tree). A rvore de cobertura consiste num sub-grafo da topologia da rede incluindo todos os ns em M , sem ciclos fechados. Pode-se adicionar o objetivo de custo mnimo ao problema, onde o custo total igual soma dos custos de cada enlace utilizado na rvore (freqentemente, utiliza-se um custo unitrio para cada enlace, e o custo da rvore igual ao nmero de enlaces da rvore). Este tipo de rvore de cobertura de custo mnimo conhecido como rvores de Steiner. O problema de rvores de Steiner em redes NP-completo no caso geral. Adicionalmente, no caso mais geral, pode ser associado um custo cuv a cada enlace. Se o custo mnimo no for tomado como objetivo, um algoritmo simples existe: (1) selecionase um ncleo (n raiz) e (2) forma-se a rvore com os enlaces utilizados nos caminhos mais curtos

(shortest paths) entre o n raiz e todos os outros ns do grupo. Esta a idia bsica do algoritmo RPF (Reverse Path Forwarding), descrito na seo a seguir. Ao contrrio do algoritmo de inundao, numa rvore de cobertura alguns enlaces da rede podem no ser utilizados na distribuio multicast.

2.1.4 rvores RPF

A construo de uma rvore de cobertura por fonte (na realidade, por sub-rede fonte de dados) mais simples que uma rvore de cobertura para todas as fontes e receptores. O primeiro algoritmo para construir este tipo de rvore, e que mais tarde deu origem ao RPF (Reverse Path Forwarding) era conhecido por Reverse Path Broadcasting (RPB). O algoritmo RPB simples. Ao receber um pacote da fonte S , um roteador R verica se o pacote foi recebido pela interface de sada que ele usaria para enviar dados a S , ou seja, se o pacote chegou pelo caminho reverso entre a fonte S e o roteador R. Em caso armativo, o roteador reenvia o pacote em todas as interfaces de rede, exceto a interface por onde o pacote chegou. Seno, o pacote descartado. Este teste conhecido como RPF check. A interface pela qual o roteador espera receber pacotes de uma determinada fonte referenciada como o enlace pai. Os enlaces pelos quais o pacote enviado so conhecidos como lhos. Este algoritmo bsico foi melhorado para reduzir a duplicao desnecessria de pacotes, dando origem ao algoritmo Reverse Path Forwarding (RPF). Para tanto, preciso que o roteador que recebe um pacote multicast seja capaz de determinar se o roteador no enlace lho o considera como estando no caminho mais curto para a fonte. Se este for o caso, o pacote enviado para este roteador vizinho. Se no for o caso, o pacote no enviado para este vizinho, uma vez que este iria fatalmente descart-lo por no estar chegando atravs do enlace pai para aquele determinado par (fonte,grupo). A informao necessria para tomar esta deciso de envio no sentido descendente do uxo relativamente fcil de obter de um protocolo de roteamento baseado no estado do enlace (linkstate ), uma vez que cada roteador mantm uma base de dados da topologia para todo o domnio de roteamento. Se um protocolo de roteamento do tipo vetor-distncia for utilizado, um vizinho pode avisar seu salto anterior de um determinado par (f onte, grupo) atravs de suas mensagens de atualizao de roteamento ou eliminar a rota reversamente. Qualquer das duas tcnicas permite a um roteador no caminho ascendente do uxo determinar se o roteador vizinho o considera no caminho mais curto para determinado par (f onte, grupo). A principal vantagem do RPF sua relativa ecincia e facilidade de implementao. O algoritmo no exige que um roteador tenha conhecimento da rvore de distribuio inteira nem requer um mecanismo especial para parar o processo de envio, como a inundao. Alm disso, o RPF garante o envio eciente pois os pacotes multicast sempre seguem o caminho mais curto da fonte de dados para o grupo de destino. Por outro lado, uma grande desvantagem a distribuio do trfego para todos os ns da rede, mesmo aqueles que no tm interesse neste trfego. Para reduzir este problema, uma variante do RPF onde so utilizadas podas foi proposta. O tipo de rvore construda chamada TBT (Truncated Broadcast Tree). O primeiro passo consiste na inundao da rede (ood), onde todos os roteadores recebem todos os pacotes multicast. Na segunda etapa, um roteador folha que recebe um pacote multicast para o qual ele no possui receptor interessado envia uma mensagem de poda na direo contrria do uxo. Passo a passo, os roteadores intermedirios so informados da ausncia de receptores multicast em partes da rvore, e evitam o envio de pacotes multicast para estas partes da rede. Esta variante do RPF possui a vantagem de eliminar o trfego multicast em partes da rede onde ele no necessrio, mas por outro lado, ainda necessita da inundao peridica de toda a rede, para que seja possvel a conexo rvore de novos receptores. Uma vez que os membros de um grupo e a topologia da rede esto mudando dinamicamente, o estado podado de uma rvore de envio multicast deve ser atualizado em intervalos regulares. Periodicamente, a informao de

poda removida da memria de todos os roteadores e o prximo pacote para o par (fonte,grupo) enviado para todos os roteadores nas folhas da rvore. Isto resulta em uma nova rajada de mensagens de poda, permitindo a rvore multicast se adaptar s necessidades da rede. Alm disso, os roteadores que esto em partes da rede onde no h receptores armazenam, de qualquer forma, estado para todos os grupos multicast, o estado de poda. Os protocolos DVMRP e PIM-DM utilizam este algoritmo (conhecido como  ood and prune).

2.1.5 rvores Centradas

Nos algoritmos de rvores centradas (ou rvores compartilhadas) a rvore de distribuio multicast construda a partir de um n central da rede. Os receptores (roteadores multicast de ltimo salto) enviam os pedidos de conexo ao grupo para este roteador central (ou roteador core). Cada roteador atravessado pelo pedido de conexo armazena a interface pela qual o pedido chegou para construir a rvore de distribuio. O roteador core utilizado por todas as fontes que enviam para o grupo multicast, por isso a rvore de distribuio chamada compartilhada. O trfego multicast para cada grupo enviado e recebido pela mesma rvore de distribuio, no importando a fonte. O protocolo CBT (Seo 2.5) foi o primeiro a utilizar rvores multicast centradas.

2.2 A Implantao do Servio Multicast na Internet

O servio IP Multicast comeou a ser implantado na Internet no incio da dcada de 90. A implantao experimental do multicast foi realizada atravs de uma rede virtual mundial, o MBone (Multicast backBone) [21]. O MBone uma rede virtual, ou overlay, construdo sobre a topologia Internet. O overlay necessrio uma vez que apenas um sub-conjunto dos roteadores da Internet implementa o servio multicast. Portanto, o MBone constitudo por tneis que interconectam os roteadores multicast. Todos os pacotes multicast so encapsulados em pacotes unicast (utilizando encapsulamento IP dentro de IP). Desta forma o pacote pode ser encaminhado por roteadores unicast. Em cima da rede virtual MBone executado o protocolo de roteamento DVMRP (descrito na seo a seguir). A utilizao de tneis possibilitou a rpida implementao de uma infraestrutura multicast experimental, mas possui algumas inecincias, como por exemplo o fato de um pacote atravessar o mesmo enlace fsico mais de uma vez, se diferentes tneis multicast compartilharem este enlace.

2.3 O Protocolo DVMRP

O DVMRP (Distance Vector Multicast Routing Protocol) [22] foi o primeiro protocolo utilizado no MBone (Multicast Backbone), a rede virtual criada para desenvolver o IP Multicast. O DVMRP utiliza vetores de distncia (como o protocolo de roteamento unicast RIP [23]) para construir rotas unicast para cada destino (neste caso, fonte de dados multicast). A distncia expressa em nmero de saltos, como no RIP. A rvore multicast criada utilizando o algoritmo RPF (Reverse Path Forwarding) e as tabelas de roteamento unicast construdas pelo DVMRP. Quando um roteador DVMRP recebe dados de uma determinada fonte, ele verica se os dados chegaram pela interface que ele utilizaria para ir fonte (caminho reverso) e ento reenvia estes dados em todas suas interfaces de sada, inundando a rede. Roteadores que no esto interessados no uxo de dados enviam mensagens de poda ao roteador de onde receberam os dados. Este mecanismo conhecido por inundao-e-poda (ood-and-prune). A descoberta de fontes ativas se faz atravs da recepo dos dados, por isso a inundao da rede feita periodicamente. Isto inviabiliza a utilizao do DVMRP em grande escala. Durante a implantao inicial do DVMRP no MBone, no havia podas de ramos da rvore, e as transmisses eram limitadas apenas pelo campo TTL (Seo 1.2.2). A partir de 1993, todas as

implementaes do DVMRP passaram a utilizar a verso com podas do algoritmo RPF. Ainda assim, alguns pacotes inundam regularmente toda a rede MBone, limitando-se apenas pelo campo TTL e por valores limite administrativamente congurados (Seo 1.2.3). A inundao peridica necessria para a descoberta de novos receptores.

2.3.1 Funcionamento Bsico do DVMRP

As portas de um roteador DVMRP podem ser uma interface fsica diretamente conectada a uma sub-rede ou um tnel para outra ilha multicast. Todas as interfaces so conguradas com uma mtrica que indica o custo para determinada porta e um valor TTL que limita o escopo de uma transmisso multicast. Alm disso, cada interface tnel precisa ser congurada com dois parmetros adicionais: o endereo IP da interface local do roteador e o endereo IP da interface do roteador remoto. Um roteador multicast s ir enviar um pacote atravs de uma interface se o campo TTL no cabealho do pacote for maior que o TTL associado interface. De acordo com o RPM (Reverse Path Multicasting, algoritmo implementado pelo DVMRP), o primeiro datagrama para cada par (fonte,grupo) enviado atravs da rede inteira (limitado apenas pelo campo TTL do pacote). O datagrama inicial enviado para todos os roteadores folha, que transmitem mensagens de poda de volta para a fonte caso no existam membros do grupo conectados s sub-redes nas folhas. As mensagens de poda criam uma rvore especca com o caminho mais curto para cada fonte. O DVMRP possui um mecanismo para que um ramo podado possa ser enxertado de volta rapidamente. O roteador que havia enviado a mensagem de poda pode enviar uma mensagem para a eliminao desta to logo descubra membros para um determinado (fonte,grupo) numa sub-rede conectada a si. As mensagens de enxerto (graft) so enviadas na direo da fonte, permitindo que ramos anteriormente podados sejam reativados. Quando houver mais de um roteador DVMRP em uma sub-rede, um deles escolhido como o roteador designado (Designated Router  DR), cando responsvel pelo envio de mensagens ao IGMP para a descoberta de membros dos grupos. O roteador com o menor endereo IP escolhido como o DR, salvo a condio em que os roteadores possuem diferentes mtricas para a fonte, caso em que o DR ser o roteador com a menor mtrica. Uma vez que o DVMRP foi desenvolvido para rotear trfego multicast e no unicast, o roteador em geral vai executar um processo para o envio multicast e outro para o unicast. O processo DVMRP periodicamente troca mensagens de atualizao das tabelas de roteamento com vizinhos capazes de rotear multicast. Estas atualizaes so independentes das geradas pelo protocolo utilizado para o roteamento unicast. O DVMRP utiliza-se de uma tabela de roteamento, que no contm informao sobre os membros dos grupos multicast e de uma tabela de envio. A tabela de roteamento contm como elementos principais a sub-rede fonte, ou seja, o endereo de uma sub-rede que contenha estaes gerando trfego multicast ; a mscara para esta sub-rede; o roteador anterior na direo da sub-rede fonte e o campo TTL, utilizado para o gerenciamento da tabela signicando o nmero de segundos at que uma entrada seja retirada. A tabela de envio contm os seguintes campos: sub-rede fonte, neste caso a sub-rede contendo estaes gerando datagramas multicast endereados a grupos especcos; o grupo multicast, endereo IP Classe D para o qual datagramas so endereados, uma sub-rede fonte pode conter fontes para vrios grupos multicast; um campo porta de entrada para cada par (fonte,grupo); e um campo portas de sada, atravs das quais datagramas destinados a um (fonte,grupo) so enviados. A Figura 5 ilustra o funcionamento do protocolo de roteamento unicast do DVMRP. A construo da rvore TBT (Truncated Broadcast Tree) se d de forma anloga ao protocolo RIP (Route Information Protocol) [23], ou seja, atravs da troca de vetores de distncia. A Figura 5 mostra a construo da rvore TBT para a Rede N 1 (ou seja, considerando que a Rede N 1 fonte do multicast, e as Redes N 2 e N 3 receptores). A rvore TBT uma rvore reversa,

portanto, a Rede N 1 o destino para o qual se construiro rotas unicast.

Rede N1

R1

R2

R6 1 33 1 33 2 34 R3 R4 R5 3 1 3 35

Rede N4

R7

Rede N2

Rede N3

Figura 5: Construo da rvore DVMRP. Os roteadores R1 e R2 esto diretamente conectados N 1, portanto R1 e R2 anunciam a seus vizinhos uma rota para N 1 com comprimento de 1 salto. O roteador R4 recebe apenas um anncio de rota para N 1, portanto seu prximo salto para N 1 R2. Para comunicar R2 que R4 o utilizar como pai na rvore multicast, o DVMRP utiliza um mecanismo de poison-reverse especial. O roteador R4 envia um vetor de distncia com mtrica igual a (32 + mtrica recebida do pai ) a R2 (32 o valor innito no DVMRP). Desta forma, R2 marca a interface que o conecta a R4 como interface lha na rvore de distribuio de N 1, construindo um ramo da rvore. O roteador R3 recebe dois anncios de rota para N 1 de mesmo comprimento, para escolher uma nica rota, R3 escolhe a rota anunciada pelo vizinho de endereo IP mais baixo (suponha que seja R2). O roteador R3 envia ento um vetor com distncia 33 para R2, construindo mais um ramo da rvore TBT. Na prxima etapa, os roteadores R3 e R4 enviam vetores de distncia a seus demais vizinhos (com a mtrica da rota que eles possuem, acrescida de 1 salto, exatamente como no funcionamento do RIP). Desta forma, R5 aprende que possui uma rota para N 1, passando por R4, com dois saltos. R5 envia o poison-reverse correspondente a R4. Finalmente, R6 e R7 recebem o vetor de distncia de R5. Neste cenrio, R6 e R7 esto na mesma rede, e portanto apenas um dos roteadores deve se conectar rvore, o roteador designado (DR). No DVMRP, o roteador com endereo IP mais baixo escolhido geralmente como DR (suponha que seja R6 neste cenrio). Considere agora um n na rede N 1 que envia dados para o grupo multicast G1. Existem receptores interessados em G1 nas redes N 3 e N 4 (Figura 6). Inicialmente, a nica informao de roteamento que os ns possuem o estado deixado pelo protocolo unicast do DVMRP, ou seja, uma rvore TBT que cobre todas as sub-redes da topologia. Portanto, no incio os dados enviados pela fonte S1 iro inundar toda a rede. Como na rede N 2 no existem receptores interessados no grupo G1, o roteador R3 envia uma mensagem de poda (prune) ao seu roteador pai (R2), de forma que o trfego cessa de uir para N 2. A ausncia de receptores interessados no grupo detectada, em vez de sua presena. Por isso, necessrio que o processo de inundao seja repetido periodicamente (os estados de poda so volteis), pois esta a nica forma de anunciar a existncia de novas fontes/grupos aos eventuais receptores em redes podadas, como N 2. A utilizao de uma rvore TBT pelo DVMRP tem a vantagem de restringir a inundao inicial do trfego multicast aos ramos desta rvore. No entanto, redes onde no existem receptores so periodicamente inundadas. Alm disso, o DVMRP implementa seu prprio roteamento

Rede N1
Fonte 1

R1

R2

prune

R6 receptor (G1 )

R5

Rede N4

R3

R4

R7

Rede N2

Rede N3

receptor (G1 )

Figura 6: Envio de dados no DVMRP.

unicast, em vez de utilizar as informaes do protocolo unicast em uso (como faz o protocolo PIM). Ainda com relao ao roteamento unicast, o DVMRP, por utilizar vetores de distncia, sofre dos mesmos problemas de convergncia lenta que seu equivalente unicast, o RIP [24].

2.4 O Protocolo MOSPF

O Multicast Open Shortest Path First (MOSPF) [25] uma extenso do protocolo de roteamento unicast OSPF (Open Shortest Path First) [20]. Este um protocolo projetado especicamente para distribuir informao de topologia unicast em um nico Sistema Autnomo (AS). O OSPF utiliza mensagens de estado do enlace (Link State Advertisement  LSA) que so trocadas por todos os roteadores da rede, de forma que cada um capaz de construir um mapa atualizado da topologia da rede [24]. Com esta informao, cada roteador capaz de calcular o caminho mais curto entre dois ns quaisquer da rede, utilizando o algoritmo de Dijkstra. Os roteadores MOSPF mantm uma imagem da topologia atual da rede atravs do protocolo OSPF. O MOSPF construdo sobre o OSPF verso 2 [25], e mantm a compatibilidade com este. O MOSPF, diferentemente do DVMRP, no prov suporte para tneis. O MOSPF estende as mensagens de atualizao do estado do enlace do OSPF com a informao de grupos multicast ativos. Cada roteador anuncia a presena de receptores interessados em determinado grupo multicast conectados a alguma de suas sub-redes. Desta forma, o MOSPF pode construir uma rvore de distribuio multicast baseada nos caminhos mais curtos para cada receptor (o caminho entre a fonte e o receptor o mesmo caminho unicast). Este tipo de rvore de distribuio chamado de rvore de caminhos mais curtos, ou rvore SPT (Shortest-Path Tree). A utilizao das mensagens de estado de enlace dispensa a utilizao da inundao peridica de dados feita pelo DVMRP, mas por outro lado inviabiliza a utilizao do MOSPF em redes muito grandes. O roteamento no MOSPF[26] pode ser dividido em intra-rea e inter-rea, em termos da rea OSPF em questo. A Figura 7 mostra os principais elementos do roteamento intra-rea. Os roteadores MOSPF utilizam-se do IGMP para obter informao sobre os grupos e seus membros. Assim, os roteadores mantm uma base de dados local com os grupos e respectivas listas de

membros, diretamente conectados a uma sub-rede. Em qualquer sub-rede, as consultas ao IGMP so realizadas por um nico roteador, o Designated Router (DR), responsvel tambm por escutar as mensagens de entrada de estaes em grupos geradas pelo IGMP. Num ambiente contendo roteadores MOSPF e OSPF, um roteador MOSPF deve ser o DR. No exemplo da Figura 7, o roteador R7 anuncia aos outros roteadores da rea que ele possui receptores para os grupos multicast GA e GB , atravs da inundao da rede com LSAs listando estes grupos. Da mesma forma, o roteador R9 inunda a rede com LSAs anunciando a existncia de receptores interessados no grupo GA . O caminho mais curto para cada (f onte, grupo) construdo sob demanda quando o roteador recebe o primeiro datagrama para este par especco. Aps esta chegada, a rvore de distribuio pode ser construda atravs do algoritmo de Dijkstra. Desta forma, a fonte S1 pode construir a rvore SPT mostrada na Figura 7. Em seguida, as informaes de grupo armazenadas podem ser utilizadas para a poda dos ramos que no levam a sub-redes contendo membros do grupo especco. Para enviar um datagrama multicast para os membros de um grupo no sentido descendente do uxo, o roteador deve determinar sua posio na rvore.

Fonte S1 Fonte S2 (S1,GA ) R1 (S1,GA ) R2 (S1,GA ) R3

R4 (S1,GA ) rea OSPF R5

(S1,GA )

R6 R8 LSA (R9{GA }) IGMP

IGMP

R7(DR)

LSA (R7{GA ,G B })

(S1,GA ) R9(DR)

receptor (GA ) receptor (GB ) receptor (GB )

receptor (GA )

Figura 7: Funcionamento do MOSPF intra-rea. Para um determinado datagrama, todos os roteadores em uma mesma rea OSPF calculam a mesma rvore de envio de caminho mais curto. Diferentemente do OSPF, o MOSPF no suporta o conceito de roteamento com vrios caminhos de mesmo custo. Em contraste com o DVMRP, o primeiro datagrama multicast no precisa ser enviado para todos os roteadores na rea. O clculo sob demanda possui a vantagem de espalhar no tempo o clculo das rotas, resultando em um menor impacto aos roteadores participantes. Cada roteador MOSPF possui uma tabela de cache de envio, contendo como informao principal os endereos de grupo de destino, fontes para este grupo, a interface atravs da qual o datagrama deve ser recebido e as interfaces atravs das quais este deve ser enviado, alm de um

campo TTL que representa o nmero mnimo de saltos pelos quais um datagrama ir passar at atingir um membro de um determinado grupo. A informao deste cache de envio atualizada periodicamente, e mantida enquanto os recursos do sistema estiverem disponveis (i.e., memria) ou at haver uma mudana de topologia. Os roteadores MOSPF devem desconsiderar os roteadores unicast na construo de suas rvores de envio. Este fato pode trazer alguns problemas, datagramas multicast podem atravessar um caminho que no seja o timo caso existam roteadores unicast no melhor caminho; mesmo que haja conectividade unicast para um destino, pode no ser possvel a conexo multicast; o envio de um datagrama unicast e outro multicast entre os mesmos ns fonte e destino pode seguir caminhos diferentes. O roteamento inter-rea envolve o caso onde a fonte de um datagrama e pelo menos um de seus destinos residem em reas OSPF diferentes. As maiores diferenas so relacionadas com a forma como a informao dos membros dos grupos propagada e o modo como a rvore de distribuio construda. No MOSPF, um sub-conjunto dos roteadores de fronteira das reas, os Area Border Routers (ABRs), funcionam como transmissores de trfego inter-rea. Este roteador conhecido como Multicast ABR (MABR). Na hierarquia OSPF, existe uma rea considerada a rea backbone, ou rea 0, e outras reas OSPF comuns (ou reas OSPF, simplesmente). Um roteador MABR conecta uma rea OSPF rea OSPF backbone. Um transmissor multicast inter-rea responsvel pelo envio de informao sobre os membros dos grupos entre as reas e de datagramas multicast. Para permitir o envio de trfego multicast entre reas, os roteadores MABR utilizam o conceito de receptor multicast coringa (wildcard receiver). O receptor multicast coringa um roteador que recebe todo o trfego multicast em sua rea, no importando os membros dos grupos. Para tanto, o receptor coringa injeta em sua rea OSPF LSAs com o ag receptor coringa ligado. Este ag indica que o roteador possui membros conectados para todos os grupos. Em reas comuns, todos os roteadores multicast inter-rea (MABRs) so coringas, injetando LSAs com o ag receptor coringa ligado na rea comum. Isto garante que todo o trfego multicast gerado numa rea comum ser enviado para o transmissor multicast inter-rea (o MABR estar conectado a qualquer rvore multicast dentro da rea), e se necessrio ento para a rea backbone. Para completar o roteamento inter-rea, o MOSPF dene mais um tipo de mensagem de estado de enlace (LSA), o LSA de Resumo de Grupos (Summary Membership LSA). Este LSA lista todos os grupos multicast de interesse dentro de uma rea OSPF. Os roteadores multicast interrea injetam LSAs de Resumo de Grupos na rea 0. Desta forma, os roteadores na rea backbone possuem informao de grupos e membros para todas as reas. Assim o trfego multicast pode ento ser enviado para membros de todas as reas. A Figura 8 ilustra o funcionamento do roteamento MOSPF inter-rea. Suponha que a fonte S1 na rea 1 comea a enviar dados para o grupo multicast GB . Ao receber o trfego enviado a GB , cada roteador na rea 1 calcula a rvore de caminhos mais curtos (utilizando o algoritmo de Dijkstra) com raiz em S1 e cobrindo todos os receptores de GB . Na rea 2, a fonte S2 comea a enviar dados para o grupo GA . Mais uma vez, os roteadores podem construir uma rvore de distribuio (com raiz S2) dentro da rea 2 graas informao de receptores interessados difundida atravs dos LSAs de grupo multicast. Esta rvore conecta os Receptores 4 e 5 fonte S2. At ento, os roteadores na rea 2 no sabem que existem receptores interessados no grupo GA na rea 1. Neste cenrio, os roteadores M ABR1 e M ABR2 so congurados como receptores coringa, injetando LSAs com o ag correspondente ligado nas reas 1 e 2, respectivamente. Desta forma, o roteador M ABR1 enxertado na rvore multicast de S1, e M ABR2 conectado rvore de S2. Alm disso, o roteador M ABR1 injeta na rea 0 LSAs de resumo listando os grupos GA e GB . O roteador M ABR2 injeta LSAs informando que a rea 2 possui receptores interessados no grupo GA . Os roteadores na rea 0 utilizam a informao contida nestes LSAs de resumo de

R01 rea OSPF 0 (MABR1{GA ,GB }) R03

R02

R04

(MABR2{GA })

(MABR1 {*}) MABR1 MABR2 (MABR2 {*}) R11 R12 rea OSPF 1 R14 R15 R25 R16 R17 R18 receptor 4 (GA ) receptor 1 (GA ) receptor 2 (GB ) receptor 3 (GB ) receptor 5 (GA ) Fonte S1 (GB ) Fonte S2 ( GA ) R19 R26 R27 R13 R23 R24 R21 rea OSPF 2

R22

Figura 8: Funcionamento do MOSPF inter-rea.

grupo para saber quais roteadores MABR devem ser includos na rvore SPT do backbone, para quais fontes. Desta forma, o trfego injetado por M ABR2 na rea 0 (fonte S2, grupo GA ) pode ser encaminhado para o roteador M ABR1. No caso de roteamento multicast inter-rea, no realizada a construo da rvore exata de caminhos mais curtos, rvores incompletas so construdas porque a informao detalhada dos membros dos grupos e da topologia da rede no distribuda atravs das reas OSPF. Desta forma, pode haver o transporte de trfego multicast desnecessrio, pois o trfego sempre enviado ao roteador MABR como resultado do mecanismo de receptor coringa. Quanto ao roteamento inter-domnios (inter-AS, ou entre Sistemas Autnomos), o funcionamento do MOSPF bastante semelhante ao roteamento inter-rea. Os roteadores de backbone so informados atravs dos LSAs de resumo de grupo sobre quais MABRs possuem receptores interessados em quais grupos. Alguns dos roteadores na fronteira entre estes Sistemas Autnomos (ASBRs - Autonomous System Border Routers ) so designados como transmissores multicast inter-AS (Multicast AS Border Router  MASBR). Quando recebe trfego multicast proveniente de fora do AS, o MASBR re-encaminha este trfego para os roteadores MABR, de acordo com a necessidade. Os roteadores MASBR tambm utilizam o mecanismo de receptor coringa nos LSAs que propagam dentro da rea 0, desta forma eles recebem todo o trfego multicast da rea e podem anunci-lo no nvel inter-domnio. Em resumo, o MOSPF um protocolo para uso dentro de um nico domnio, e exige que este domnio execute o protocolo de roteamento unicast OSPF. O MOSPF possui problemas de escalabilidade, por um lado porque a informao de estado do enlace e grupos de interesse inunda a rede periodicamente e por outro lado porque o algoritmo de Dijkstra deve ser executado para todas as fontes multicast  grupos multicast muito dinmicos podem prejudicar o desempenho do sistema.

2.5 O Protocolo CBT

O protocolo Core Based Trees (CBT) [27, 28] foi o primeiro a utilizar rvores centradas. A rvore de distribuio construda pelo CBT bi-direcional, e compartilhada por todas as fontes de um mesmo grupo multicast, diminuindo a quantidade de estado armazenada nos roteadores. A raiz da rvore CBT um n especco da rede (chamado core), em vez da fonte de dados como no DVMRP ou MOSPF. Os roteadores na rvore de distribuio armazenam uma entrada por grupo, em vez de uma entrada por (f onte, grupo) em suas tabelas de roteamento. Desta forma, o CBT mais escalvel que o DVMRP e OSPF, em termos da quantidade de estado armazenada nos roteadores. Quando um receptor deseja conectar-se a um grupo multicast, ele envia uma mensagem de enxerto (join) na direo do core. Esta mensagem cria estado em cada roteador atravessado e faz com que uma mensagem de reconhecimento seja enviada ao roteador anterior, construindo a rvore multicast. Quando uma fonte envia dados para o grupo multicast (na direo do core), estes so distribudos na rvore a partir do primeiro roteador a receb-los. Este roteador reenvia os dados em todas as interfaces de rede pertencentes rvore multicast, exceto a interface pela qual os dados foram recebidos, de forma a evitar loops. A Figura 9 ilustra o mecanismo de construo da rvore CBT. Os receptores localizados nas redes N 3 e N 4 anunciam seu interesse em receber o grupo G atravs do protocolo IGMP. Os roteadores designados respectivos, DR3 e DR4, enviam mensagens join(G) em direo ao roteador Core associado ao grupo G. As mensagens join deixam estado para o grupo G nos roteadores R4, R6 e R5.
Rede N1 Rede N2

R1 Fonte S1

Fonte S2

join (G) R3 R2

R4 join (G) CBT join (G) join (G) Core join (G) R6 IGMP IGMP DR3 DR4 R5 join (G)

Rede N3 Rede N4
receptor (G) receptor (G) receptor (G)

Figura 9: Construo da rvore multicast CBT. Se um membro do grupo envia dados ao grupo, os pacotes so encaminhados pelo seu roteador local a todos os seus vizinhos CBT que esto conectados rvore de distribuio de G. Este o caso da fonte S1 na Figura 10. Cada roteador que recebe um pacote multicast para o grupo G o reenvia em todas as interfaces de sada que esto na rvore G, exceto aquela por onde o

pacote chegou. Por esta razo, a rvore CBT compartilhada e bi-direcional, os pacotes podem uir sobre a rvore dos membros na direo do Core ou na direo contrria, despendendo do posicionamento da fonte. A rvore compartilhada, pois todas as fontes a utilizam  e todos os receptores recebem todas as fontes.
Rede N1 Rede N2
(S1,G)

R1 Fonte S1 (S1,G) R3 R2 (S2,G)

Fonte S2

R4 (S1,G) (S1,G) CBT (S2,G) (S1,G) (S2,G) Core R6 (S1,G) IGMP DR3 DR4 (S2,G) IGMP (S2,G) R5 (S2,G) (S1,G) (S2,G)

Rede N3 Rede N4
receptor (G) receptor (G) receptor (G)

Figura 10: Distribuio de dados na rvore CBT. O modelo de servio IP multicast no exige que uma fonte seja membro do grupo multicast, desta forma possvel no CBT que o roteador local da rede de uma fonte para o grupo G no esteja conectado rvore de G. Por exemplo, a fonte S2 na Figura 10 (nesta gura, a linha cheia representa os enlaces que pertencem rvore G). Neste caso, o pacote encaminhado salto a salto, na direo do roteador Core. Se o pacote, eventualmente, atingir um roteador que esteja na rvore G, ele encaminhado na rvore a partir deste ponto. No caso da fonte S2, o trfego multicast distribudo sobre a rvore a partir do roteador R6 (Figura 10). O protocolo CBT permite que vrios roteadores core sejam especicados, criando redundncia para o caso em que o core no esteja disponvel. O CBT eciente em termos do estado armazenado nos roteadores. Apenas os roteadores que pertencem rvore de distribuio para o grupo G mantm estado para G (diferentemente do DVMRP e MOSPF), e nenhum roteador mantm estado por fonte. Assim, o CBT mais escalvel que protocolos de inundao-e-poda, especialmente para grupos esparsos  onde apenas algumas partes da rede possuem membros. Apesar de suas vantagens, o CBT possui algumas limitaes. O algoritmo pode resultar na concentrao de trfego prximo aos roteadores centrais (razes) das rvores, uma vez que o trfego de todas as fontes atravessa os mesmos enlaces medida em que se aproximam do centro. Alm disso, uma nica rvore de envio compartilhada pode criar rotas sub-timas para determinados uxos, resultando em maiores atrasos, uma questo crtica para aplicaes multimdias. Conseqentemente, no CBT a localizao do core crtica pois dene a forma da rvore de distribuio. Alm disso, o CBT no dene um mecanismo de mapeamento entre grupos multicast e roteadores core.

2.6 O Protocolo PIM

O PIM (Protocol Independent Multicast) [29] constitudo de dois protocolos diferentes, de modo denso (PIM-DM) e modo esparso (PIM-SM). O PIM-DM destinado a redes onde os membros do grupo esto densamente distribudos, sendo funcionalmente muito similar ao DVMRP. Desta forma, o PIM-DM utiliza a inundao peridica da rede, com mensagens de poda. J o PIM-SM foi projetado para o roteamento em grande escala, e assume que a distribuio de receptores na rede esparsa. Neste caso, protocolos que utilizam a inundao da rede so inadequados. O PIM-SM constri rvores compartilhadas baseado em mensagens join, como o CBT, porm as rvores PIM-SM so uni-direcionais. A fonte encapsula os dados em unicast e os envia a um n de rendez-vous (RP) que em seguida os distribui na rvore multicast. possvel no PIM-SM mudar para uma rvore por fonte, para fontes com alta taxa de transmisso. Desta forma, a localizao do RP menos crtica no PIM-SM que o core no CBT.

2.6.1 O Protocolo PIM Dense Mode

Enquanto a arquitetura do PIM foi dirigida para a necessidade de prover rvores de distribuio de modo-esparso escalveis, esta dene tambm um novo protocolo de modo-denso (PIM-DM). Este deve vir a ser utilizado em ambientes onde a faixa de transmisso disponvel seja abundante e os grupos densos, como numa LAN de um campus universitrio. O PIM-DM similar ao DVMRP do ponto de vista do algoritmo utilizado, o RPM. No entanto, h algumas diferenas importantes. O PIM-DM se apia na existncia de um protocolo de roteamento unicast para se adaptar a mudanas de topologia, mas independente dos mecanismos do protocolo especco. Por outro lado, o DVMRP contm um protocolo de roteamento integrado que utiliza seu prprio mecanismo de troca de mensagens para atualizao das tabelas de roteamento. O MOSPF usa a informao contida na base de dados de estado dos enlaces do OSPF, sendo o MOSPF especco apenas para o OSPF. Diferentemente do DVMRP, que calcula um conjunto de interfaces lhas para cada par (f onte, grupo), o PIM-DM simplesmente envia o trfego multicast em todas as interfaces no sentido descendente do uxo at que mensagens de poda explcita sejam recebidas. O PIM-DM convive com a duplicao de pacotes para eliminar a dependncia do protocolo de roteamento e evitar o overhead associado com a construo de uma base de dados contendo os enlaces pais/lhos. A Figura 11 ilustra o funcionamento do processo de inundao e poda implementado pelo PIM-DM. Neste exemplo, o trfego multicast gerado pela fonte S1, localizada na rede N 1, inunda toda a rede. Cada roteador da rede, ao receber o trfego, checa se este chegou pela interface utilizada pelo roteador para chegar rede N 1 (teste RPF). Em caso armativo, o roteador reenvia o pacote em todas as suas interfaces de sada (onde estejam conectados vizinhos PIM-DM). Desta forma, todos os enlaces da rede so utilizados, diferentemente do DVMRP com sua rvore TBT. Alm disso, alguns pacotes podem ser transportados em um enlace nos dois sentidos, por exemplo entre os roteadores R4 e R5. Este o preo pago pelo PIM por no implementar um protocolo de roteamento unicast, como o DVMRP. Aps a inundao inicial, alguns roteadores da rede enviaro mensagens de poda (prune) para parar o trfego multicast enviado a G1. Este o caso de roteadores que no possuem receptores interessados no trfego multicast de G1, como R7. Roteadores que no possuem vizinhos interessados em G1 (ou seja, ns que no possuem lhos na rvore) tambm enviam mensagens de poda (este o caso de R8 e R3). Alm disso, roteadores que receberam o trfego de S1 atravs de uma interface diferente da interface correta pelo teste RPF tambm enviam podas nestas interfaces, R4, R5 e R9 so exemplos deste caso. O resultado do processo de inundao e poda do PIM-DM uma rvore SPT reversa, ou seja, resultado da unio dos caminhos mais curtos dos receptores para a fonte. Embora o trfego de dados para G1 no esteja chegando a todos os roteadores da rede, existe estado para esta

prune(S,G1 ) R7 prune(S,G1 ) prune(S,G1 ) R3 R8 prune(S,G1 )

Rede N1

R2 R4 prune(S,G1 ) receptor (G1 ) R9 R1 prune(S,G1 )

Rede N3

receptor (G1 ) R3 Fonte S1 R5

R6

Rede N2

receptor (G1 )

Figura 11: Distribuio de dados no protocolo PIM-DM.

fonte/grupo (S1, G1) em todos os roteadores da rede. O estado (S1, G1) continuar armazenado enquanto a fonte S1 estiver transmitindo. No PIM-DM, as podas (estados prune) so estados volteis, que expiram a cada 3 minutos. Isto ocasiona a inundao de toda a rede, exatamente como no caso inicial, com esta mesma freqncia. Por este motivo, o PIM-DM adequado apenas para redes onde os receptores esto densamente distribudos.

2.6.2 O Protocolo PIM Sparse Mode

O PIM Sparse Mode (PIM-SM) [30] foi desenvolvido para situaes onde vrias estaes desejam participar de uma conferncia multicast mas a inundao peridica de toda a rede com trfego multicast no se justica, seja porque o nmero de receptores pequeno, ou pelos receptores estarem concentrados em certas regies da topologia. Para tratar este tipo de cenrio, de distribuio esparsa dos receptores, o PIM-SM foi projetado para limitar o trfego multicast de forma que somente os roteadores interessados em receber trfego de um determinado grupo o enxerguem. O PIM-SM diferente dos algoritmos multicast de modo-denso em dois aspectos principais. Roteadores com membros diretamente conectados ou membros no caminho descendente do uxo se conectam rvore de distribuio atravs da transmisso de mensagens join explcitas. Se um roteador no se tornar parte de uma rvore de distribuio pr-denida (a rvore compartilhada), no receber o trfego multicast endereado para o grupo. Em contraste, os algoritmos de mododenso assumem a pertinncia do grupo no sentido descendente do uxo e continuam a enviar o trfego multicast at que mensagens explcitas de poda sejam recebidas. O procedimento padro adotado nos algoritmos de modo-denso o envio do trfego, enquanto que no modo-esparso o padro bloquear o trfego a menos que este seja explicitamente requisitado. Alm disso, as rvores construdas so rvores compartilhadas em vez de rvores por fonte. O PIM-SM emprega, como o CBT, ns centrais rede que so utilizados como raiz da rvore

compartilhada. No PIM, estes roteadores especiais so chamados de pontos de rendez-vous (RP), este o lugar da rede onde os receptores encontram as fontes. Cada grupo multicast (endereo Classe D) associado a um RP da rede, atravs de um mecanismo de congurao. Para cada grupo, existe apenas um RP ativo. Cada receptor que deseja se conectar a um grupo contata o roteador ao qual est diretamente conectado, atravs do protocolo IGMP. Este roteador (DR) por sua vez entra na rvore de distribuio do grupo multicast atravs do envio de uma mensagem join para o RP primrio do grupo. As mensagens join enviadas na direo do RP constroem, de forma explcita, uma rvore de distribuio. No PIM-SM, independentemente do nmero e da localizao dos receptores, as fontes se registram com o RP e enviam uma nica cpia de cada pacote multicast para os receptores conectados ao RP. Da mesma forma, independentemente do nmero de fontes, os receptores devem sempre se conectar ao RP para receber o trfego multicast enviado ao grupo. O funcionamento do PIM-SM baseado nesta rvore compartilhada com raiz no roteador RP. Este modelo requer que os roteadores mantenham algum estado (a lista dos RPs, contendo o mapeamento endereo multicast - RP) antes da chegada dos pacotes multicast. Por outro lado, protocolos multicast de modo-denso so orientados pelos dados, uma vez que eles no denem qualquer estado para o grupo at a primeira chegada de pacotes. A especicao do PIM-SM permite, por outro lado, a troca da rvore compartilhada ((, G)) por uma rvore por fonte. Esta troca de rvore pode ser congurada, tomando geralmente como parmetro a taxa de envio de dados da fonte. A partir de um certo valor limite da taxa de dados recebidos de uma determinada fonte, os roteadores de ltimo salto (roteadores diretamente conectados a receptores) podem tomar a deciso de trocar de rvore. A partir de ento, o roteador passa a emitir mensagens PIM join(S, G) na direo da fonte S . Estas mensagens trafegam salto por salto at o roteador de primeiro salto conectado fonte S . O roteador de ltimo salto no pra, no entanto, de enviar mensagens join(, G) para o RP, pois isso faria com que trfego de outras fontes ativas para o grupo G (e fontes que venham a car ativas) no fosse recebido. Por outro lado, o roteador de ltimo salto deve enviar uma mensagem de poda especial ao RP, RP bitprune(S, G), para evitar que o trfego gerado por S seja recebido em duplicata. As Figuras 12 e 13 ilustram o funcionamento do protocolo PIM-SM. Suponha que existem duas fontes de trfego, S1 e S2, localizadas nas redes N 1 e N 2, respectivamente. Ambas enviam dados para o grupo multicast G, que possui receptores nas redes N 3 e N 4. A partir do momento em que o roteador de primeiro salto de S1, R1, detecta uma fonte de dados ativa para o grupo G, este registra a fonte S1 junto ao RP (atravs do envio de uma mensagem PIM register(S1, G) ao RP). Na realidade, o roteador R1 encapsula os dados enviados por S1 dentro das mensagens PIM register, mensagens que so enviadas em unicast ao RP. Quando o RP recebe as mensagens register(S1, G), ele desencapsula os dados multicast e os envia sobre a rvore compartilhada. O mesmo processo usado para qualquer fonte que comea a enviar dados endereados a G, como S2. A construo dos ramos da rvore compartilhada realizada pelo envio de mensagens join(, G) enviadas pelos roteadores de ltimo salto, na direo do RP. Por exemplo, o roteador DR3 detecta a presena de receptores interessados no grupo G atravs do protocolo IGMP. DR3 envia ento um join(, G) ao RP. O mesmo ocorre para o roteador DR4, construindo a rvore compartilhada mostrada na Figura 12. Suponha que os roteadores DR3 e DR4 foram congurados com um valor x = 0 para a taxa de transmisso da fonte, a partir da qual ocorrer a troca para rvore por fonte. Suponha tambm que a taxa de transmisso de S1 maior que x, e que a taxa de S2 menor que x. Neste caso, o roteador DR3 toma a deciso de trocar da rvore compartilhada para a rvore por fonte, enviando mensagens join(S1, G) fonte S1. Esta mensagem cria estado (S1, G) nos roteadores R4 e R1. Alm disso, DR3 envia mensagens de poda, RP bit prune(S1, G) ao roteador RP. Isto evita que o trfego de S1 seja recebido em duplicata na rede N 3. O roteador

Rede N1 Rede N2

R1 Fonte S1 enc. (S1,RP) enc. (S2,RP) R2 enc. (S2,RP) R4 enc. (S1,RP) R3

Fonte S2

PIM-SM

RP (*,G) R5 R6 (*,G) (*,G) IGMP DR4

IGMP

DR3

Rede N3 Rede N4
receptor (G) receptor (G) receptor (G)

Figura 12: rvore compartilhada no PIM-SM.

Rede N1 Rede N2
(S1,G) R1 Fonte S1 (S1,G) R3 (S1,G) R4 enc. (S2,RP) enc. (S2,RP) R2 enc. (S2,RP) Fonte S2

PIM-SM

RP (*,G) (S1,G) R5 (S1,G)

R6 (*,G) IGMP DR3 (S1,G)

(*,G) IGMP DR4

Rede N3 Rede N4
receptor (G) receptor (G) receptor (G)

Figura 13: rvore por fonte no PIM-SM.

DR4 toma a mesma deciso, criando estado (S1, G) nos roteadores R6 e R5. A partir de ento, o trfego endereado a G enviado por S1 segue utilizando uma rvore de distribuio SPT reversa, enquanto o trfego de S2 continua a ser transportado na rvore compartilhada. Alm da troca entre rvore compartilhada e por fonte, disparada pelos roteadores de ltimo salto, possvel tambm que o RP se conecte ao roteador de primeiro salto atravs de uma rvore por fonte. De forma semelhante, congura-se um valor para a taxa de transmisso da fonte a partir do qual o RP ir enviar uma mensagem join(S, G) fonte. Assim, criado mais um ramo da rvore reversa SPT entre a fonte e o RP. Desta forma, possvel a criao de uma rvore SPT completa, mesmo que essa atravesse o RP, que armazenar estado (S, G) neste caso. A idia por trs da utilizao de rvores por fonte, apenas para determinadas fontes, motivada pelo fato de rvores compartilhadas poderem apresentar atraso maior que rvores por fonte (pois os receptores tm que passar pelo RP). Para minimizar os problemas causados por uma m localizao do RP dentro da topologia da rede, criou-se a possibilidade de troca da rvore para uma rvore por fonte.

3 Roteamento Multicast Inter-domnio

A implementao do IP Multicast no nvel inter-domnio complexa [31]. Uma vez que o PIMSM se baseia no roteamento unicast para construir a rvore multicast (assumindo que o caminho reverso unicast adequado para o trfego multicast), mensagens de controle da rvore podem ser recebidas por roteadores no-multicast, dicultando a operao do protocolo. Alm disso, a utilizao do PIM-SM no inter-domnio tem ainda dois problemas: o projeto de um mecanismo escalvel de mapeamento de grupos multicast para RPs e a inter-dependncia introduzida pela prpria utilizao de RPs entre os ISPs (Internet Service Provider). A localizao de um RP em um ISP alheio pode ser inaceitvel, de um ponto de vista estratgico.

3.1 A Arquitetura MBGP/MSDP

A soluo de curto-prazo para os problemas acima a combinao dos protocolos MBGP (Multiprotocol Extensions for BGP-4) [32] e MSDP (Multicast Source Discovery Protocol) [33]. O MBGP permite que mltiplas tabelas de roteamento possam ser mantidas para diferentes protocolos. Desta forma, os roteadores podem construir tabelas diferentes para rotas unicast e multicast. O MBGP armazena as rotas multicast em uma tabela chamada M-RIB (Multicast Route Information Base). O protocolo MSDP tenta solucionar o problema de inter-dependncia entre os ISPs. Cada ISP roda o protocolo PIM-SM dentro de seu domnio, com um conjunto prprio de RPs para todos os grupos dentro de seu domnio. Os roteadores RPs de um mesmo domnio so interconectados, assim como conectados a RPs de outros domnios, utilizando conexes de controle MSDP, formando uma malha. Quando uma fonte comea a emitir, o RP em seu domnio notica RPs em outros domnios desta fonte ativa. Receptores em outros domnios enviam mensagens join especcas para esta fonte. A Figura 14 mostra o processo de construo da rvore multicast inter-domnio. Suponha um grupo multicast G, com uma fonte ativa, S1, localizada no Domnio 2 e receptores distribudos nos dois domnios. Dentro do Domnio 1, os receptores r1 e r2 se conectam ao roteador RP 1, ponto de rendez-vous do Domnio1, atravs do envio de mensagens join(, G). Processo semelhante ocorre dentro do Domnio 2 para os receptores r3 e r4. Duas rvores compartilhadas, isoladas, so construdas (na Figura 14(a), as linhas cheias indicam os enlaces pertencentes s rvores). Quando a fonte S1 comea a emitir dados, seus pacotes so encapsulados dentro de mensagens P IM register e enviados a RP 2, de acordo com o comportamento normal do PIM-SM. O roteador RP 2 desencapsula os dados e os envia, na rvore compartilhada, aos receptores r3 e r4.

MSDP

RP1 join(*,G) PIM-SM Domnio 1 R2 join(*,G) join(*,G) R3

fonte_ativa(S)

RP2 join(*,G) join(*,G) PIM-SM Domnio 2

MBGP

BR1

BR2

R4 join(*,G) join(*,G)

R5

IGMP DR1 DR2

DR3

DR4

R1

receptor r3 receptor r1 receptor r2 receptor r4 Fonte S1

(a) Construo das rvores PIM-SM intra-domnio.

MSDP

RP1 join(S,G) PIM-SM Domnio 1 R2 join(*,G) R3 BR1

MBGP join(S,G) join(S,G)

RP2 join(S,G)

join(S,G)

PIM-SM Domnio 2 BR2 R4 join(S,G) join(S,G) R5 join(S,G)

IGMP DR1 DR2

DR3

DR4

R1

receptor r3 receptor r1 receptor r2 receptor r4 Fonte S1

(b) Construo da rvore inter-domnio PIM-SM/MSDP.

Figura 14: Funcionamento do PIM-SM/MSDP/MBGP.

Alm disso, o roteador RP 2 anuncia a existncia de uma fonte ativa a todos os RPs conectados malha MSDP. O roteador RP 1 recebe ento uma mensagem dizendo que a fonte S1 est ativa para o grupo G (Figura 14(a)). Ao receber a noticao, roteadores que possuem receptores interessados no grupo G, como o caso de RP 1, enviam uma mensagem join especca para a fonte S1 (join(S1, G)), atravs dos roteadores de inter-domnio, que rodam o protocolo MBGP (Figura 14(b)). Esta mensagem constri um ramo da rvore que liga R1, roteador de primeiro salto de S1, a RP 1. Desta forma, o trfego ser transmitido entre os domnios, para RP 1, e chegar aos receptores r1 e r2 (Figura 15). Alm disso, supondo que a fonte S1 ultrapassa o limite de taxa de transmisso congurado para o PIM-SM, os roteadores de ltimo salto DR3 e DR4, emitem mensagens join(S1, G), trocando a rvore compartilhada por uma rvore especca fonte S1. Neste exemplo, RP 2 toma a mesma deciso e constri mais um ramo da rvore SPT (Figura 14(b)). O envio de dados atravs das rvores especcas ocorre como mostrado na Figura 15.
MSDP

RP1

MBGP

RP2

PIM-SM Domnio 1 R2 R3 BR1 BR2 R4 R5

PIM-SM Domnio 2

IGMP DR1 DR2

DR3

DR4

R1

receptor r3 receptor r1 receptor r2 receptor r4 Fonte S1

Figura 15: Envio de dados atravs do PIM-SM/MSDP. O protocolo MSDP utiliza as mensagens join especcas normais do PIM-SM, passando entre os domnios atravs do protocolo MBGP e se conectando fonte de dados. Por outro lado, o MSDP s constri rvores compartilhadas dentro de cada domnio, (nunca no inter-domnio) evitando que se dependa de RPs remotos para o envio de trfego entre dois membros do mesmo domnio. Embora o MSDP resolva o problema da interconexo de domnios PIM-SM, ele possui algumas desvantagens. Um problema de escalabilidade que os RPs em todos os domnios devem ser noticados de toda fonte que comece a enviar dados. Alm disso, alguns RPs iro guardar essa informao em um cache de forma a que membros que se interessem pelo grupo aps o incio da transmisso possam fazer com que seus RPs correspondentes enviem mensagens join especcas fonte. Considerando que o MSDP um protocolo inter-domnio, esta caracterstica compromete sua escalabilidade com relao ao nmero de fontes e grupos ativos. Alm disso, para garantir que os primeiros pacotes emitidos pela fonte sejam recebidos pelos membros em outros domnios, os dados devem ser encapsulados e enviados com as mensagens de fonte-ativa do MSDP, a todos os RPs conectados malha MSDP. Alm disso, se os dados no forem encapsulados, fontes que enviam dados em rajadas, espaadas de alguns minutos, poderiam nunca ser recebidas por membros em outros domnios, pois o estado de roteamento (S1, G) poderia ter expirado a cada vez que a enviasse.

Portanto, o MSDP no uma soluo de longo prazo, mas foi implementado por alguns ISPs, pois resolve os problemas de inter-conexo de domnios PIM-SM. Por outro lado, a partir do momento em que o nmero de usurios multicast se tornar mais expressivo, a utilizao do MSDP ser invivel. O grupo de trabalho do IETF responsvel pela padronizao do MSDP, aps vrias revises do padro, decidiu no mais trabalhar na especicao do protocolo.

3.2 O Protocolo BGMP

O Border Gateway Multicast Protocol (BGMP) [14] um protocolo de roteamento multicast inter-domnio que tenta resolver alguns dos problemas das outras solues existentes. O BGMP rene algumas das idias dos protocolos de roteamento anteriores, e tenta ser mais amigvel do ponto de vista do provedor de servios  seu projeto se assemelha ao protocolo BGP [13], o nico protocolo de roteamento unicast inter-domnio utilizado atualmente na Internet. O BGMP constri rvores compartilhadas para os grupos multicast ativos e permite que os domnios receptores construam ramos especcos para a fonte no inter-domnio, quando necessrio. O comportamento padro construir ramos compartilhados no inter-domnio pois em geral a conectividade neste nvel menor que no intra-domnio. Alm disso, as rvores so bi-direcionais para diminuir a dependncia de terceiros. O BGMP est atualmente em curso de padronizao pelo IETF [34]. O BGMP um protocolo inter-domnio que adota alguns princpios de projeto do BGP, familiares dos provedores de servio. Como o BGP, o BGMP utiliza o protocolo de transporte convel TCP para transmitir a informao de roteamento. Alm disso, a mquina de estados com noticao de erros do BGMP similar do BGP. O BGMP constri rvores compartilhadas bi-direcionais. Este tipo de rvore permite uma menor quantidade de estados de reenvio multicast nos roteadores, sendo mais escalvel que os outros tipos de rvore (por fonte e compartilhadas uni-direcionais). No entanto, para manter compatibilidade com outros protocolos, o BGMP pode construir ramos uni-direcionais especcos por fonte. rvores bi-direcionais so adequadas para aplicaes de tipo N xM (N fontes e M receptores, ou vrios para vrios, como por exemplo jogos distribudos ou vdeoconferncias). rvores uni-direcionais so teis para aplicaes de fonte nica e sensveis ao atraso. Uma das caratersticas originais do BGMP a raz da rvore compartilhada ser um Sistema Autnomo (AS), no um roteador como no PIM-SM ou CBT. Cada AS deve ser associado a um endereo de grupo multicast. Utilizar o AS ao qual est associado um endereo de grupo especco como raiz da rvore de distribuio deste grupo razovel, porque existem grandes chances de que este AS possua membros interessados neste grupo. Alm disso, utilizar um AS como raiz da rvore, em vez de um roteador, proporciona maior estabilidade e tolerncia a falhas. Um nmero de AS menos sujeito a mudanas que o endereo de um roteador, alm disso, utilizar o nmero de AS facilita a implementao de redundncia dentro do AS. Dado um endereo multicast, a rvore compartilhada do BGMP tem por raiz o domnio para o qual foi alocada a faixa de endereos que o inclui. Desta forma, o BGMP supe um mecanismo para descobrir qual o AS responsvel por cada endereo multicast. Isto pode ser conseguido atravs do protocolo MASC [12], como mostrado na Seo 1.2.5, ou atravs da alocao global de endereos multicast, como realizado, por exemplo, na arquitetura de endereamento do IPv6 (Seo 5). O protocolo MASC realiza a alocao temporria de endereos da faixa Classe D do IPv4 e ento distribui estas associaes atravs do protocolo Multiprotocol BGP (MBGP) [32]. O MBGP permite saber que endereo multicast est associado a qual nmero de AS, e desta forma saber onde as mensagens join devem ser enviadas. Alm disso, o MBGP permite que as topologias unicast e multicast sejam diferentes. A Figura 16 mostra um exemplo de rvore de distribuio construda pelo BGMP. Os roteadores de borda implementam dois protocolos de roteamento multicast, o BGMP no nvel inter-domnio, e um protocolo de roteamento intra-domnio, como PIM-SM ou DVMRP, nomeado genericamente como MIGP (Multicast Interior Gateway Protocol).

Suponha um grupo multicast, G, criado por uma estao pertencente ao domnio B . A estao obtm para G o endereo multicast 224.0.128.1, pertencente faixa de endereos associada ao domnio B . Quando uma estao no domnio C se conecta ao grupo, uma mensagem join enviada pelo MIGP ao componente BGMP do melhor roteador de sada (segundo o BGP) para o endereo 224.0.128.1, C1 na Figura 16. O roteador C1 consulta sua tabela de rotas de grupo, G-RIB, e encontra como melhor rota (224.0.0.0/16, A2) para o destino 224.0.128.1. C1 cria uma lista de alvos em sua tabela de encaminhamento multicast com um alvo pai e uma lista de alvos lhos para o endereo G. O alvo pai o prximo salto na direo do domnio raiz do grupo G. Um alvo lho identica um roteador BGMP ou o componente MIGP do qual uma mensagem join foi recebida. No caso de C1, o alvo pai A2, e o nico alvo lho seu prprio componente MIGP. Esta entrada de encaminhamento, de tipo (, G), signica que um pacote multicast recebido para G encaminhado para todos os alvos da lista, exceto aquele pelo qual o pacote foi recebido, implementando desta forma a rvore bi-direcional compartilhada. Os roteadores de borda BGMP possuem conexes de controle TCP uns com os outros, que so utilizadas para encaminhar mensagens de enxerto (join) e poda (prune). Aps a criao de sua entrada na tabela de encaminhamento, C1 envia uma mensagem join(, G) ao alvo pai A2. Ao receber esta mensagem, A2 consulta sua tabela de roteamento e encontra a rota (224.0.128.0/24, A3), indicando A3 como prximo salto para a raiz de G. A2 cria ento uma entrada de encaminhamento, com seu componente MIGP, com A3 como alvo pai e C1 como alvo lho. Uma vez que A3 um parceiro BGMP interno (roteador BGMP dentro do mesmo domnio), A2 transmite o join para seu componente MIGP, que toma as medidas necessrias para implementar o encaminhamento de pacotes endereados a G dentro do domnio A. De maneira semelhante, a mensagem join(, G) se propaga at o domnio B . Os ramos de rvore representados por echas bi-direcionais na Figura 16 so construdos, supondo que existem receptores para o grupo G nos domnios D, F e H .
Ramo da rvore compartilhada Ramo da rvore por fonte Domnio D Domnio E

D1

E1

A4

A1 Domnio A 224.0.0.0/16

A2 A3 C1 B1 Domnio B 224.0.128.0/24 Domnio raiz 224.0.128.1 C2 B2 F2 Domnio F F1 G2 Domnio G G1 H2 H1 Domnio H Domnio C 224.0.1.0/25

Figura 16: rvore de distribuio multicast BGMP. Os dados podem chegar rvore de G, mesmo quando emitidos por estaes que no tenham se conectado a G, respeitando o modelo de servio IP multicast. Suponha um emissor no domnio E , que no possui membros do grupo G. A estao envia dados endereados a 224.0.128.1,

estes dados chegam ao melhor roteador de sada, no caso E1, graas ao protocolo de roteamento MIGP. Uma vez que E1 no possui estado para este grupo, ele simplesmente reenvia os dados para o prximo salto na direo do domnio raiz de G, o domnio B , para o qual A1 prximo salto neste caso. Uma vez que A1 tambm no possui estado para G, o pacote reenviado utilizando o MIGP implementado por A de forma a atingir o prximo salto na direo de B . Por exemplo, se o protocolo MIGP for o DVMRP, o pacote multicast ser inundado na rede do domnio A, atingindo outros roteadores de borda BGMP. No caso, os roteadores de borda A2, A3 e A4 pertencem rvore de distribuio de G, desta forma os dados so reenviados na rvore a todos os membros do grupo. Quando um roteador BGMP, ou seu componente MIGP, no possui conexes com mais nenhum membro do grupo, ele envia uma mensagem de poda (prune) para o alvo pai armazenado em sua tabela de encaminhamento. Quando sua lista de alvos lhos se esvazia, o roteador BGMP tambm procede poda. Desta forma, o tamanho da rvore de distribuio BGMP adaptado ao conjunto de membros atualmente conectados ao grupo, de forma dinmica. A especicao do BGMP tambm permite que ramos da rvore especcos a uma fonte sejam construdos. Por exemplo, na Figura 16, o domnio F possui uma conexo ao domnio D que no passa pelo domnio raiz de G, B . Neste caso, supondo que exista uma fonte S1, localizada no domnio D, emitindo para o grupo G, o roteador F 2 pode enviar uma mensagem de enxerto especca, join(S, G), ao roteador A4. A utilizao de ramos especcos a uma fonte pode ser til em casos onde o caminho mais curto para a fonte S a partir de um domnio no coincide com a rvore bi-direcional a partir deste domnio, e o domnio utiliza um protocolo de roteamento como o DVMRP ou PIM-DM, que constri rvores por fonte dentro do domnio. Neste caso, o teste RPF para a fonte S falharia, j que o trfego no estaria chegando pelo caminho mais curto na direo de S . A nica soluo para este problema, sem os ramos especcos, seria o roteador BGMP de entrada do domnio (pela rvore bi-direcional) encapsular os dados e os enviar ao roteador de sada para a fonte S (que do ponto de vista do teste RPF, o roteador correto para recepo do trfego multicast de S ). Com a utilizao de ramos especcos, a encapsulao pode ser evitada. Se endereos multicast alocveis globalmente existem, ento o BGMP pode utilizar qualquer arquitetura de alocao de endereos esttica para obter a identicao de um AS a partir de um endereo multicast. A combinano o BGMP com um espao de endereamento sucientemente grande, como o do IPv6, tem o potencial de prover escalabilidade para uma maior gama de aplicaes que as solues de roteamento atuais.

4 Solues Alternativas e Novos Protocolos

Devido lenta implantao do servio multicast na Internet, diferentes solues alternativas foram propostas [35]. Este captulo apresenta as principais propostas neste sentido.

4.1 Novos Protocolos de Roteamento

Diferentes propostas foram feitas para simplicar o servio multicast. O protocolo EXPRESS reduziu a conversao multicast para o caso mais simples de 1 para N, introduzindo a noo de canal. Esta denio simplica a alocao de endereos e distribuio de dados, e cobre a maioria das aplicaes atuais. O servio SSM (source-specic multicast) foi inspirado no protocolo EXPRESS e est atualmente em fase nal de padronizao pelo IETF (Internet Engineering Task Force). O SSM implementado pelos protocolos IGMPv3, que suporta a ltragem de fontes, e por uma verso modicada do PIM-SM, chamada PIM-SSM. O protocolo PIM-SSM simplica o IP Multicast, mas no permite sua implantao gradual.

4.1.1 O Protocolo EXPRESS

O protocolo EXPRESS (EXPlicitely REquested Single Source multicast) [36] foi projetado para otimizar a distribuio multicast para uma nica fonte. O protocolo EXPRESS prope a extenso do modelo IP Multicast com a abstrao de canal. Um canal multicast um servio de distribuio multicast, de fonte nica, identicado pelo par (S, E), onde S o endereo da fonte de dados e E um endereo de destino do canal. Apenas a fonte S autorizada a enviar dados no canal (S, E). Ao se conectar a um canal, um membro recebe apenas os dados transmitidos por S para E . Dois canais, (S, E) e (S , E) no possuem qualquer relao, apesar do endereo de destino em comum. A rvore de distribuio EXPRESS construda pelo ECMP (Express Count Management Protocol) [36], um protocolo de gerenciamento que alm de manter a rvore, suporta a contagem de membros por fonte e votao. O protocolo foi especialmente projetado para aplicaes de tipo assinatura, usando canais lgicos, como TV na Internet ou distribuio de arquivos. Embora tenha sido elaborado para aplicaes de fonte nica, aplicaes com mltiplas fontes podem ser construdas utilizando-se vrios canais, ou permitindo que vrias fontes utilizem o mesmo canal utilizando um mecanismo de mais alto nvel para que todas as fontes passem pela mesma estao-fonte do canal. A proposta EXPRESS importante por representar uma soluo simples para o problema de alocao de endereos multicast. A concatenao de um endereo unicast com um endereo IP Classe D (utilizado como E na identicao do canal) proporciona um identicador nico para o canal multicast, uma vez que o endereo unicast nico, por denio. Alm disso, a abstrao de canal simplica, intrinsecamente, alguns problemas de gerenciamento de grupo, como o controle de acesso ao envio de dados. O protocolo ECMP (Express Count Management Protocol) acrescenta mecanismos para a contagem de membros do grupo. O modelo de canal proposto no EXPRESS foi adotado pelo IETF, dando origem a um novo servio dentro do IP Multicast, denominado Source-Specic Multicast (SSM). O protocolo PIM-SSM implementa o servio SSM, porm no incorpora qualquer mecanismo de gerenciamento de grupo adicional.

4.1.2 O Servio Source-Specic Multicast

A proposta do EXPRESS motivou a implementao do servio SSM (Source-Specic Multicast) na Internet. O modelo de canal introduzido pelo EXPRESS simplica bastante a arquitetura multicast, porque a alocao de endereos multicast passa a ser um problema local fonte de dados, e porque a distribuio multicast pode ser implementada por um protocolo de roteamento mais simples. No IPv4, o servio SSM implementado pelo protocolo PIM-SSM (Protocol Independent Multicast - Source Specic Multicast) [37] e pelo protocolo IGMPv3 [17]. A verso 3 do protocolo IGMP necessria, pelo mecanismo de ltragem de fontes presente apenas nesta verso. Na verdade, o mecanismo de ltragem possui mais funcionalidade do que seria necessrio para implementar o servio SSM. O protocolo PIM-SSM uma verso modicada (simplicada) do protocolo PIM-SM, com novas regras de tratamento de mensagens e com a capacidade de interpretar corretamente as mensagens IGMPv3 enviadas pelas estaes. O PIM-SSM considera a existncia de uma nica fonte por canal multicast, e constri exclusivamente rvores de distribuio por fonte, em vez de rvores compartilhadas como o PIM-SM. Desta forma, no h necessidade de roteadores de rendez-vous (RPs) para gerenciar a rvore, nem de mecanismos de mapeamento de endereos multicast para RPs. Mecanismos de descoberta de fontes no inter-domnio, como o protocolo MSDP, tambm no so necessrios. Por outro lado, o PIM-SSM supe que os receptores potenciais conhecem o endereo da fonte, sendo assim capazes de gerar pedidos IGMPv3 transportando este endereo. O mecanismo de descoberta de fontes utilizado na prtica est fora do escopo da denio do PIM-SSM. A descoberta pode ser realizada atravs de servios como o correio eletrnico, publicao na web, ou pelo protocolo SAP

(Session Announcement Protocol) [38]. O IANA alocou uma faixa de endereos multicast exclusiva para a utilizao do servio SSM, a faixa 232/8 (232.0.0.0 232.255.255.255). Assim, possvel a coexistncia do servio especco fonte (implementado pelo protocolo PIM-SSM na faixa exclusiva) com o servio IP Multicast tradicional (utilizando o PIM-SM, fora da faixa exclusiva). Para tanto, as implementaes do PIM-SM devem ser modicadas, tanto nos roteadores de borda (BR  Border Router) quanto nos roteadores de backbone. Alm disso, o protocolo IGMPv3 deve ser implementado em todas as estaes e roteadores de primeiro-salto. Ainda assim, o modelo SSM obteve uma grande aceitao da comunidade de pesquisa, uma vez que mais simples e elimina algumas das limitaes da arquitetura de distribuio multicast PIM-SM/MBGP/MSDP.

O servio SSM baseado no PIM-SSM e IGMPv3

Quando um receptor deseja se conectar a um canal multicast, ele envia um pedido IGMPv3 ao seu roteador DR, especicando o par de endereos (S, G). Se o endereo G pertence faixa exclusiva do servio SSM, o roteador DR envia uma mensagem join(S, G) na direo da fonte, de forma a ser adicionado rvore de distribuio do canal (S, G). Se ao invs disso o endereo G est fora da faixa SSM, o roteador ter o comportamento normal do protocolo PIM-SM, ou seja, enviando uma mensagem join(, G) em direo ao RP. Aps a recepo do primeiro pacote da fonte, atravs da rvore compartilhada, o DR pode eventualmente se conectar rvore por fonte, enviando uma mensagem join(S, G). Neste caso, porm, o receptor no se beneciar das vantagens do servio SSM. O DR receber os dados enviados por qualquer fonte ao grupo G atravs da rvore compartilhada. Se o DR no implementar a ltragem de fontes, todos os dados sero encaminhados ao receptor. A Figura 17 mostra os componentes do modelo SSM no IPv4.

IGMPv3 Fonte S1 MBGP DR (S1,G) PIM-SSM (S2,G) BR (S2,G) BR (S2,G) (S2,G) PIM-SSM receptor(S2,G) (S2,G)

DR IGMPv3 Fonte S2

receptor ({S1,S2}, G)

Figura 17: O modelo de distribuio PIM-SSM/IGMPv3. Para garantir a coexistncia e a compatibilidade entre os protocolos PIM-SM e PIM-SSM, as fontes PIM-SM devem utilizar apenas endereos multicast fora da faixa exclusiva SSM, enquanto as fontes SSM devem se limitar a esta faixa. O comportamento dos roteadores designados e dos roteadores de rendez-vous deve ser modicado, portanto. Os roteadores DR devem enviar uma mensagem join(S, G) diretamente, sem passar pelo RP, se o endereo multicast G um endereo SSM. Ao mesmo tempo, os RPs no devem aceitar um pedido join(, G) na faixa exclusiva SSM

e no devem se apresentar como candidatos (no processo de eleio de RPs) para endereos na faixa SSM. Fontes no devem enviar dados para o RP, se o endereo destino corresponde a um canal multicast. Ao invs disso, elas devem utilizar a rvore por fonte diretamente.

4.1.3 O Protocolo REUNITE

O protocolo REUNITE (REcursive UNIcast TrEes) [39] introduziu a tcnica de unicast recursivo para a distribuio multicast. A idia utilizar a infra-estrutura de roteamento unicast para realizar a distribuio multicast. De maneira semelhante aos protocolos EXPRESS e PIMSSM, o REUNITE constri apenas rvores por fonte. Um grupo identicado pelo par (endereo unicast da fonte, nmero de porta) e pacotes de dados possuem endereos destino unicast. A motivao inicial do REUNITE foi a observao de que em rvores multicast tpicas, a maioria dos roteadores simplesmente reenvia os pacotes recebidos de uma interface de entrada atravs de uma nica interface de sada. Em outras palavras, os roteadores de ramicao da rvore so minoria (Figura 18). Estas caractersticas j haviam sido observadas por Pansiot e Grad [40] e foram conrmadas mais recentemente por Chalmers e Almeroth [41]. Apesar disso, em todos os protocolos multicast IP, todos os roteadores atravessados pela rvore de distribuio armazenam informao por grupo (ou por fonte/grupo). A idia no REUNITE foi ento dividir o estado de roteamento em duas tabelas, uma tabela de controle (Multicast Control Table  MCT) e uma tabela de reenvio de pacotes (Multicast Forwarding Table  MFT). A MCT armazenada no plano de controle dos roteadores, enquanto que a MFT instalada no plano de dados. Apenas ns de ramicao da rvore possuem entradas na tabela de reenvio, MFT, outros roteadores apenas guardam informao na tabela de controle, MCT, que no consultada durante o envio de dados. Os roteadores de ramicao utilizam a informao armazenada na MFT para realizar a duplicao de pacotes corretamente.
S

Figura 18: Forma de uma rvore multicast tpica. O REUNITE identica uma conversao multicast por um par <S, P>, onde S o endereo unicast da fonte e P um nmero de porta, escolhido pela fonte. O REUNITE no utiliza endereos multicast IP Classe D. medida que os receptores se conectam rvore, o protocolo preenche as tabelas MCT e MFT de forma a construir a rvore. Os estados armazenados nas tabelas so volteis (soft-state). O REUNITE utiliza dois tipos de mensagens para construo e manuteno da rvore: join e tree. Mensagens join so periodicamente enviadas pelos receptores na direo da fonte (S ). J as mensagens tree so periodicamente enviadas em multicast pela fonte, para atualizar o estado voltil da rvore. Apenas os ns de ramicao para o grupo <S1 , P1 > mantm entradas <S1 , P1 > em sua tabela MFT. A tabela de controle, MCT, no

usada no encaminhamento de dados. Roteadores de simples reenvio (que no realizam bifurcao na rvore) possuem entradas MCT para <S1 , P1>, mas nenhuma entrada MFT para este grupo.

A distribuio multicast atravs de unicast recursivo

A idia de base da tcnica de unicast recursivo utilizar endereos de destino unicast nos pacotes de dados. Roteadores que atuam como ns de ramicao da rvore de um determinado grupo so responsveis pela criao de cpias dos pacotes de dados. Estas cpias possuem seus endereos de destino modicados, de forma a que todos os membros do grupo recebam uma cpia da informao. A Figura 19 ilustra a distribuio de dados no protocolo REUNITE. A fonte envia os dados endereados ao primeiro membro que se conectou ao grupo. Em um n de ramicao, Rn , os pacotes recebidos possuem como endereo de destino o endereo do primeiro receptor, ri , que se conectou ao grupo na sub-rvore abaixo de Rn . O receptor ri armazenado em uma entrada especial da MFT, MFT<S >.dst. O roteador Rn cria uma cpia dos dados para cada receptor presente em sua MFT (o endereo de destino de cada cpia igual ao endereo unicast do receptor). A cpia original do pacote reenviada a ri . Neste exemplo, S produz pacotes de dados endereados a r1 (estes pacotes chegam a r1 inalterados). O roteador R1 cria uma cpia do pacote com endereo de destino r4 . O roteador R3 simplesmente reenvia os pacotes sem precisar consultar sua MFT. O roteador R5 cria uma cpia do pacote para r8 e nalmente R7 cria cpias para r5 e r6 .

Figura 19: rvore de distribuio REUNITE. A tcnica de unicast recursivo permite a implementao progressiva do servio multicast porque o reenvio de dados baseado em endereos unicast. Desta forma, roteadores que no implementam o multicast so suportados de forma transparente. Estes roteadores so incapazes de funcionar como ns de ramicao da rvore, mas podem, no entanto, reenviar os pacotes sem problemas, uma vez que estes so endereados em unicast.

A Figura 20 ilustra o mecanismo de construo da rvore REUNITE com um exemplo onde este falha na construo da SPT. Considere as rotas unicast: r1 >R2 >R1 >S ; S >R1 >R3 >r1 ; r2 >R3 >R1 >S ; S >R4 >r2 . Suponha os seguintes eventos: r1 se conecta a <S, P >, r2 se conecta a <S, P > e r1 deixa o grupo. O receptor r1 assina o canal atravs do envio de um join(S, r1 )1 para S . Esta mensagem atinge S uma vez que no existe estado para este canal nos roteadores. Diz-se que r1 se conectou ao canal <S, P > em S . A fonte S comea ento a produzir mensagens tree(S, r1 ) que so enviadas a r1 (em unicast). As mensagens tree instalam soft-state para <S, P > nos roteadores pelos quais elas passam. Os roteadores R1 e R3 criam uma entrada <S, r1 > em suas MCTs. Em seguida, r2 se conecta ao canal. O join(S, r2 ) trafega na direo de S atingindo a rvore em R3 . O roteador R3 descarta a mensagem join(S, r2 ), cria uma MFT<S > com dst igual a r1 , adiciona r2 MFT<S > e remove <S, r1 > de sua MCT. O roteador R3 se torna um n de ramicao e vai conseqentemente produzir mensagens tree(S, r2 ) quando da recepo de tree(S, r1 ). Diz-se que r2 se conectou ao canal em R3 . Pacotes de dados enviados para o canal (endereados para r1 ) so duplicados em R3 e endereados a r2 . Mensagens join subseqentes enviadas por r1 e r2 atualizam o soft-state das entradas respectivas nas MFTs de S e R3 . Nesta congurao, r1 recebe os dados de S atravs do caminho mais curto, mas no r2 . Uma vez que as rotas unicast entre S e r2 so assimtricas e como R3 intercepta o join(S, r2 ), os dados seguem o caminho S >R1 >R3 >r2 , o mesmo caminho utilizado pelas mensagens tree para irem da fonte S a r2 (Figura 20(a)).

Figura 20: O mecanismo de construo da rvore REUNITE. Os estados mantidos na MCT e MFT so soft-state. Os receptores periodicamente enviam mensagens join(S, ri ) e a fonte periodicamente produz uma mensagem tree(S, ri ) em multicast. Para se desconectar do canal o receptor deve simplesmente parar o envio de mensagens join. Quando a rvore est estabilizada, os tree(S, ri ) atualizam o soft-state de entradas ri nas MCTs
1

No resto desta seo, o termo <S > pode ser usado no lugar de <S, P > referindo-se ao canal multicast.

dos roteadores assim como as entradas MFT<S >.dst = ri . Os join(S, rj ) atualizam a entrada rj na MFT do n onde rj se conectou a <S >. Na Figura 20, os join(S, r1 ) atualizam r1 na MFT de S e os join(S, r2 ) atualizam r2 na MFT de R3 . Suponha agora que r1 deixa o grupo, parando de emitir join(S, r1 ). Como a entrada r1 na MFT de S deixa de ser atualizada, aps a expirao do temporizador t1 a entrada r1 se torna stale (desatualizada). Um segundo temporizador, t2, criado e vai destruir a entrada r1 caso esta no seja mais atualizada. Uma vez que r1 est stale, S envia mensagens tree(S, r1 ) marcadas (Figura 20(b)). Mensagens tree(S, r1 ) marcadas signicam que o uxo de dados endereados a r1 pode cessar em breve, logo a parte da rvore contendo r1 nas tabelas de roteamento deve ser recongurada. As MFT nos ns de ramicao que possuem MFT<S >.dst = r1 tornam-se stale aps a recepo das mensagens tree marcadas. Em ns de simples reenvio, a recepo de tree(S, r1 ) marcadas causa a destruio de entradas r1 da MCT. Conseqentemente, os join(S, r2 ) deixam de ser interceptados por R3 (porque sua MFT est stale) e atingem S . Desta forma, r2 agora se conecta ao canal <S, P > em S (Figure 20(c)). Algum tempo depois, t2 ir expirar, acarretando a retirada de r1 das MFTs de S e R3 . Como R3 pra de receber mensagens tree, sua MFT<S > destruda (Figura 20(d)). Agora, r2 recebe os dados atravs do caminho mais curto a partir de S. O roteamento assimtrico pode levar o REUNITE a produzir cpias desnecessrias de pacotes em certos enlaces.2 A Figura 21 mostra um exemplo. O primeiro receptor, r1 , envia um join(S, r1 ) que segue o caminho r1 >R4 >R2 >R1 >S . As mensagens tree(S, r1 ) seguem a rota S >R1 >R6 >R4 >r1 . Suponha agora que r2 se conecta e que o join(S, r2 ) passa por r2 >R5 >R3 >R1 >S . Os tree(S, r1 ) (produzidos por S ) e os tree(S, r2 ) (criados em R1 ) atravessam ambos o enlace R1 -R6 . Como R6 no recebe mensagens join destes receptores, ele no se identica como n de ramicao. S produz pacotes de dados endereados a r1 , em seguida R1 cria cpias endereadas a r2 . Desta forma duas cpias de cada pacote atravessam o enlace R1 -R6 .

Figura 21: Duplicao de pacotes devido a rotas assimtricas no REUNITE. Como conseqncia, o custo (nmero de cpias do mesmo pacote nos enlaces da rede) de uma rvore REUNITE pode ser maior que o custo de uma rvore por fonte (source tree) construda
Esta possibilidade tambm existe para redes contendo roteadores puramente unicast ou quando um roteador REUNITE est sobrecarregado. Em ambos os casos, o n de ramicao migrar para um roteador no ideal podendo acarretar a duplicao de pacotes. Consultar [39] para uma descrio detalhada.
2

por um protocolo tradicional como PIM-SM (Protocol Independent Multicast - Sparse Mode)[30], uma vez que a tcnica RPF (Reverse Path Forwarding) garante que no mximo uma cpia de cada pacote trafegar por cada enlace da rede.

4.1.4 O Protocolo HBH

O protocolo HBH (Hop-By-Hop multicast routing protocol) [42] utiliza a tcnica de unicast recursivo, como o REUNITE, mas adota a abstrao de canal do EXPRESS e SSM. Como o REUNITE, o HBH suporta de forma transparente a presena de roteadores unicast puros. No entanto, o HBH constri rvores SPT (shortest-path tree) ao invs de rvores SPT reversas, como a maioria dos outros protocolos. O algoritmo de construo da rvore evita a duplicao desnecessria de pacotes em cenrios onde o roteamento unicast assimtrico. O HBH possui um algoritmo de construo de rvores capaz de tratar os casos patolgicos devidos s assimetrias do roteamento unicast. O HBH utiliza duas tabelas, MCT e MFT, que possuem aproximadamente a mesma funo que no REUNITE. A diferena que cada entrada nas tabelas de HBH armazena o endereo do prximo n de ramicao em vez do endereo dos receptores nais (exceto no roteador de ramicao mais prximo do receptor). A MFT no possui entrada dst. A Figura 22 ilustra a distribuio multicast em uma rvore HBH. Os pacotes de dados recebidos por um roteador de ramicao, Hn , possuem endereo de destino unicast igual a Hn (no REUNITE os dados so endereados a MFT.<dst>). Esta diferena de concepo torna a estrutura da rvore HBH mais estvel que a REUNITE, j que no HBH as entradas correspondentes a receptores esto localizadas prximas s folhas da rvore. O HBH identica o canal multicast atravs do par <S, G>, onde S o endereo unicast da fonte e G um endereo IP classe D alocado pela fonte. Isto evita o problema de alocao de endereos multicast e mantm a compatibilidade com IP Multicast. Desta forma, o HBH pode suportar nuvens IP Multicast como folhas da rvore de distribuio.

Figura 22: rvore de distribuio HBH.

A estrutura da rvore HBH possui a vantagem de maior estabilidade das entradas nas tabelas de roteamento que o REUNITE. A contrapartida que no HBH cada pacote recebido por um n de ramicao produz n + 1 cpias modicadas enquanto em REUNITE n cpias so produzidas. O mecanismo de gesto da rvore de HBH reduz o impacto da sada de um membro na estrutura da rvore. Isto possvel porque a entrada correspondente a um receptor localizada o mais prximo possvel deste receptor no HBH.

Gesto da rvore HBH

O protocolo HBH utiliza trs tipos de mensagem: join, tree e f usion. Mensagens join so periodicamente enviadas pelos receptores na direo da fonte e atualizam o estado de reenvio (entradas na MFT) no roteador onde o receptor se conectou ao canal. Um n de ramicao se conecta ele prprio ao canal, no prximo n de ramicao na direo da fonte. Desta forma, as mensagens join podem ser interceptadas por ns de ramicao que em seguida enviam mensagens join assinadas por eles prprios. A fonte periodicamente envia uma mensagem tree em multicast sobre a rvore que responsvel por atualizar o resto da estrutura da rvore. Mensagens f usion so enviadas por ns de ramicao em potencial e participam na construo da rvore em conjunto com as mensagens tree. Cada n HBH na rvore de distribuio de S possui uma MCT<S > ou uma MFT<S >. Um n de simples reenvio possui uma MCT<S > com uma nica entrada qual dois temporizadores so associados, t1 e t2. Quando t1 expira, a MCT torna-se stale, sendo destruda aps a expirao de t2. Um n de ramicao da rvore de S possui uma MFT<S >. Dois temporizadores, t1 e t2, so associados a cada entrada na MFT<S >. Quando t1 expira a entrada torna-se stale, sendo destruda aps a expirao de t2. No HBH, uma entrada stale usada pra o reenvio de dados, mas no causa a produo de mensagens tree. Uma entrada na MFT<S > no HBH pode tambm estar marcada. Uma entrada marcada usada no reenvio de mensagens tree, mas no no reenvio de dados. Em [42] apresentada uma descrio detalhada das regras de processamento das mensagens HBH. As idias bsicas so: o primeiro join enviado por um receptor nunca interceptado, chegando fonte; mensagens tree so periodicamente enviadas em multicast pela fonte; estas so combinadas com mensagens f usion enviadas por ns de ramicao em potencial de forma a construir e renar a estrutura da rvore. Considere novamente o exemplo da Seo 4.1.3 para mostrar a construo da rvore HBH. A Figura 23 retoma o cenrio da Figura 20. O receptor r1 se conecta ao canal em S , que comea o envio de mensagens tree(S, r1 ). Estas mensagens criam uma MCT<S > contendo r1 nos ns H1 e H3 (Figura 20(a)). Quando r2 se conecta ao canal enviando o primeiro join(S, r2 ), este no interceptado chegando a S (o primeiro join nunca interceptado). O tree(S, r2 ) produzido pela fonte cria uma MCT<S > em H4 (Figura 23(b)). Ambos os receptores esto conectados fonte atravs do caminho mais curto (fonte receptor). Suponha agora que r3 (rotas unicast: S >H1 >H3 >r3 e r3 >H3 >H1 >S ) se conecta ao canal. r3 envia um join(S, r3 ) para S , que comea a enviar mensagens tree(S, r3 ). Como H1 recebe duas mensagens tree diferentes, este envia um f usion(S, r1 , r3 ) na direo da fonte. A recepo do f usion faz com que S marque as entradas r1 e r3 e inclua H1 na MFT<S >. Da mesma forma que H1 , H3 recebe os tree(S, r1 ) e tree(S, r3 ) e envia ento uma mensagem f usion(S, r1 , r3 ) para a fonte (Figura 23(c)). A MFT de H3 agora contm r1 e r3 . Os join(S, r1 ) subseqentes so interceptados por H1 e atualizam a entrada r1 (marcada) na MFT de H1 . Os join(S, r3 ) atualizam a entrada r3 na MFT de H3 . A distribuio de dados se passa da seguinte forma. A fonte S envia pacotes endereados a H1 , que os reenvia endereados a H3 . O roteador H3 cria cpias que so enviadas a r1 e r3 . Subseqentemente, como S deixa de receber os join(S, r1 ) e join(S, r3 ), as entradas correspondentes em sua MFT so destrudas. A estrutura estabilizada

Figura 23: O mecanismo de construo da rvore HBH.

da rvore mostrada na Figura 23(d). Desta forma, o HBH utiliza o n de ramicao ideal para a distribuio multicast. O problema apresentado na Figura 21 resolvido atravs do envio de um f usion(S, r1 , r2 ) de H6 para a fonte, de maneira equivalente ao exemplo desta seo.

4.2 Protocolos de Roteamento Especializados

Outros protocolos de roteamento que se baseiam em um servio de comunicao de grupo especco foram propostos. Em geral, estes protocolos so especializados para um determinado tipo de aplicao ou tecnologia de rede. Os protocolos XCAST [43] e DCM (Distributed Core Multicast) [44] foram projetados para evitar o problema de escalabilidade em termos da quantidade de grupos multicast ativos. Estes protocolos tentam diminuir a quantidade de estados por grupo armazenada pelos roteadores. O XCAST transporta uma lista explcita de receptores dentro de um novo cabealho IP (no caso do IPv4) ou de uma extenso de roteamento (no caso do IPv6). Cada roteador deve examinar este cabealho para descobrir se este roteador um ponto de ramicao da rvore. Em caso armativo, o roteador cria uma cpia do pacote para cada ramo da rvore, com as correspondentes listas dos receptores alcanveis a partir de cada interface de sada. O XCAST escalvel em termos de grupos ativos, pois no armazena estado por grupo nos roteadores. Por outro lado, o tamanho do grupo limitado uma vez que a lista explcita dos receptores transportada nos pacotes de dados. O DCM utiliza uma estratgia diferente. Vrios roteadores core (Distributed Core Routers  DCRs) so distribudos na periferia da rede. Os DCRs utilizam um protocolo especco para o gerenciamento dos membros dos grupos multicast. Cada rede local possui um DCR responsvel pelo envio de trfego aos receptores locais. O ganho de escalabilidade do DCM est no fato de apenas os roteadores DCR armazenarem informao sobre os grupos multicast ativos.

Alguns protocolos foram propostos para o caso especco das redes ad hoc. O AMRoute [45, 46] um sistema implementado especializado para redes ad hoc. O AMRoute primeiro constri uma topologia virtual em malha sobre a qual construda uma rvore de distribuio compartilhada. O ODMRP (On-Demand Multicast Routing Protocol) [47] outro protocolo multicast para redes ad hoc. No ODMRP, a fonte de dados responsvel por construir uma malha interligando os receptores atravs da qual so inundados os dados. O MAODV [48] constri uma rvore compartilhada sob demanda, utilizando o mesmo tipo de mecanismo de pedido/resposta implementado pelo AODV para o trfego unicast.

4.3 Redes Multicast Virtuais

Devido lenta implantao do servio multicast, diferentes propostas surgiram para um servio de comunicao de grupo alternativo [49]. Em geral, estas propostas consideram que a camada de rede, ou no implementa o servio de distribuio multicast, ou o implementa apenas em algumas regies. Desta maneira, a maioria das solues propostas contri overlays (redes virtuais) que implementam a funcionalidade de multicast sobre a camada IP. Estes overlays podem ser implementados por roteadores ou pelas estaes nais. No primeiro caso, a maior parte das propostas pertencem categoria da gerao automtica ded tneis. O segundo tipo de soluo pode ser classicado como multicast aplicativo. Nesta categoria, a prpria aplicao implementa o servio de comunicao de grupo de que neceessita, ou algumas vezes um middleware implementado e prov o servio a diferentes aplicaes. Recentemente, a gerao automtica de tneis multicast vem sendo discutida no IETF. A gerao automtica de tneis consite em um programa, ou protocolo, que congura de maneira automatizada tneis multicast. Um dos mecanismos de tunelamento utilizados atualmente para interconectar duas redes multicast isoladas o UMTP (UDP Multicast Tunneling Protocol) [50]. O UMTP encapsula os datagramas multicast dentro de datagramas unicast UDP, o que possibilita sua implementao como um processo de nvel usurio nas estaes nais. Os tneis UMTP conectam uma estao mestre, que periodicamente envia mensagens join-group, a uma estao escravo. Diferentes mecanismos foram propostos no IETF para automatizar a gerao de tneis UMTP. Finlayson et al. [51] propuseram que roteadores multicast tambm pudessem ser uma das extremidades nos tneis UMTP. Neste caso, e assumindo que o servio SSM seja utilizado, as mensagens UMTP join-group so endereadas fonte SSM (em vez de a uma extremidade de tnel explcita) e interceptadas pelo primeiro roteador multicast encontrado na direo da fonte. Um nmero de porta UDP especial deve ser reservado, para permitir que o roteador multicast identique a mensagem UMTP join-group. Liefooghe e Goossens [52] propuseram um mecanismo de localizao dinmica de servidores de tneis. A escolha de um servidor adequado leva em conta, primeiramente, a proximidade do cliente, de acordo com uma hierarquia onde os servidores so classicados de acordo com sua posio geogrca. Alm disso, um mecanismo de caracterizao de caminhos proposto para que se possa escolher um servidor entre os diferentes servidores de um mesmo nvel geogrco. O cliente constri tneis UMTP provisrios com todos os servidores possveis, em seqncia. O cliente envia trfego em um canal de teste sobre este tnel, este trfego reenviado sobre o tnel pelo servidor. Um mecanismo de controle de uxo por taxa implementado sobre este canal de teste, e as medidas obtidas compem uma mtrica utilizada para escolher o melhor servidor de tneis. O AMT (Automatic Multicast Tunnelling) [53] um protocolo alternativo que no se baseia no UDP, podendo transportar outros protocolos. O AMT prope um mecanismo semelhante ao 6to4 [54], proposto para a construo de tneis IPv6 sobre redes IPv4. Desta forma, o AMT trata a Internet unicast (a nuvem de roteadores que no falam multicast), como um enlace nobroadcast de mltiplo acesso (NBMA  Non-Broadcast Multi-Access link). O AMT implementa pseudo-interfaces de rede que so utilizadas como rota default para o trfego multicast. Um

Site AMT (por exemplo, uma rede que implementa o multicast, mas que no est conectada infra-estrutura multicast nativa de uma rede backbone) possui um Gateway AMT (uma estao ou roteador) que implementa uma pseudo-interface AMT. O Gateway AMT se comunica com um roteador Relay AMT, que est conectado infra-estrutura multicast nativa. O protocolo se baseia em um prexo anycast especial para anunciar a rota para um roteador Relay AMT disponvel na infra-estrutura unicast. O trfego multicast encapsulado em UDP entre os roteadores Relay AMT e o Gateway AMT. Por default, todo o trfego multicast produzido na infra-estrutura multicast nativa ser encaminhado para o Site AMT. Para evitar o reenvio de todo o trfego, os autores do AMT prope a utilizao do IGMP como protocolo de sinalizao. O AMT permite a recepo de trfego multicast no Site AMT, e possibilita que uma fonte no Site AMT emita trfego. A arquitetura LAR (Logical Addressing and Routing architecture) proposta por Pansiot et al. [55] se diferencia dos mecanismos de gerao automtica de tneis. O LAR prope a utilizao de uma estrutura de endereamento lgica em cima da estrutura de endereamento IP padro. A idia que as estaes possuam endereos lgicos, como os nomes de domnio utilizados no servio DNS (Domain Name Service). Os endereos lgicos so utilizados para identicar estaes mveis, estaes com mltiplas conexes rede (multi-homed), e grupos multicast. No caso do multicast, o DNS contm uma associao entre o nome do grupo, o endereo do grupo, e o endereo do gerente do grupo. Quando uma estao deseja se conectar a um grupo multicast, ela deve aprender a partir do DNS qual a estao gerente responsvel por este grupo. O gerente de grupo controla o acesso de emissores e receptores ao grupo. A construo da rvore de distribuio se baseia em mensagens join e join acknowledgement, que transitam em direes opostas, desta forma o LAR capaz de implementar rvores SPT, como o protocolo HBH. No entanto, a estrutura LAR se prope a substituir o modelo de grupo do IP Multicast, enquanto que o HBH adota o modelo SSM.

4.4 Multicast Aplicativo

Neste tipo de sistema, as estaes nais so responsveis por criar uma topologia de distribuio no nvel aplicao, algumas vezes misturando o roteamento multicast e unicast. Existem diferentes motivaes para implementar o multicast aplicativo. Em geral, esta soluo proporciona maior controle sobre a rvore criada; servios adicionais podem ser facilmente implantados; e estaes que no suportam o multicast nativo so suportadas. Porm, no se pode atingir a mesma ecincia na utilizao dos recursos da rede proporcionada pelo uso do multicast nativo. O multicast aplicativo tambm conhecido por multicast baseado na estao (Host-based Multicast). As estaes nais (ou, algumas vezes, ns bem conhecidos, como por exemplo um roteador de sada) e auto-conguram para criar uma topologia de distribuio com mltiplos ns, s vezes misturando os roteamentos multicast e unicast. Por exemplo, onde o multicast a tcnica mais eciente (como no caso de mltiplas estaes localizadas em um segmento Ethernet), uma rea multicast mantida. Em outras situaes, quando o roteamento unicast mais adequado, ou a nica opo (por exemplo no roteamento inter-domnio), tneis unicast so criados. Existem diferentes motivaes para o multicast aplicativo:

oferecer controle total da rvore na topologia virtual; funcionalidades adicionais podem ser facilmente implementadas (por ex., utilizar comunicao convel sobre um enlace com fortes perdas, no caso de um caminho com roteadores freqentemente congestionados, etc.); a incluso de ns mveis que no implementam o roteamento multicast padro; a incluso de reas bem especcas (por ex., uma rede ad hoc onde os ns se comunicam sem nenhuma infra-estrutura) que se baseiam em protocolos de roteamento multicast dedicados;

 a incluso de ns que no possuem acesso a nenhum servio multicast.

Diversos sistemas de multicast aplicativo foram propostos [49]. A maneira como a distribuio realizada sobre a topologia virtual um dos fatores que diferenciam os sistemas. A construo da rvore pode ser realizada de forma centralizada ou distribuda. Entre os sistemas centralizados, h os que supem conhecimento total (por ex. HBM  Host-Based Multicast [56]) ou parcial da topologia (por ex. ALMI  Application Level Multicast Infrastructure [57]). Entre os sistemas distribudos, h os que constroem diretamente uma rvore de distribuio, e outros que primeiro constroem uma topologia em malha. Por exemplo, o Narada utiliza como topologia virtual uma malha completa entre as estaes nais [58]. Sobre esta malha, o Narada constri uma rvore usando o algoritmo Reverse Path Forwarding (RPF). Outros sistemas que primeiro constroem uma malha podem ser encontrados em [59, 60]. J o Yoid, proposto em [61] um mecanismo de multicast aplicativo que constrti a rvore diretamente. O Yoid utiliza um ponto de rendez-vous que fornece informaes sobre a sesso multicast e realiza algumas funes de gerenciamento e sinalizao. Em [62] descrito o protocolo de gerenciamento de rvores do Yoid, o YMTP (Yoid Tree management Protocol). A arquitetura do Yoid bastante complexa pois considera outros mecanismos alm do roteamento, como por exemplo o transporte convel. Outros exemplos de protocolos da categoria de implementao direta da rvore so o TBCP (Tree Building Control Protocol) [63] e HMTP (Host Multicast Tree Protocol) [64].

5 O Servio Multicast no IPv6

O IP Multicast deve ser uma das tecnologias chave na implantao da nova gerao da Internet, com o protocolo IPv6. Uma vez que no IPv4 o multicast foi introduzido como uma extenso, nem todos os ns IPv4 implementam o servio multicast. Por outro lado, a especicao do IPv6 requer que todos os ns suportem o multicast. Como consequncia imediata, uma implementao IPv6 no tem que suportar tneis multicast, usados no IPv4 para interconectar as ilhas multicast. Embora as noes bsicas do IP Multicast, como o modelo de servio, sejam comuns ao IPv4 e ao IPv6, algumas caractersticas novas so introduzidas no multicast IPv6. Enquanto no IPv4 o escopo de um grupo multicast na maioria das vezes especicado utilizando o campo TTL do pacote de dados, o IPv6 limita de maneira explcita o escopo dos pacotes atravs de um campo xo do endereo multicast. A arquitetura de endereamento IPv6 [65] incorpora o escopo dentro dos endereos unicast e multicast. Um campo de 4 bits reservado para a denio do escopo nos endereos multicast. Os roteadores no encaminham pacotes multicast cujo escopo especco est fora do domnio dentro do qual o endereo multicast vlido. Outra diferena importante com relao ao IPv4, que muitas das implementaes do multicast IPv4 utilizam endereos unicast para identicar uma interface de rede, isto no adequado no IPv6. Um n IPv6 pode associar mltiplos endereos a uma nica interface, o que poderia provocar erros de congurao. Portanto, um endereo multicast IPv6 identica um grupo de interfaces (geralmente em ns distintos). Os endereos multicast IPv6 possuem o formato mostrado na Figura 24.
8 bits 11111111 4 bits flgs 4 bits scop 112 bits group ID

Figura 24: Formato do endereo multicast IPv6. Os primeiros 8 bits com valor 1 no incio do endereo IPv6 identicam este endereo como sendo um endereo multicast. A arquitetura de endereamento IPv6 na sua especicao atual [66]

dene apenas o ltimo dos 4 bits de ags, chamado T . Os 3 primeiros bits dos ags so reservados e devem utilizar o valor 0. O bit T = 0 indica um endereo multicast alocado permanentemente (well-known address) [67], atribudo pelo IANA (Internet Assigned Numbers Authority). O bit T = 1 indica um endereo alocado temporariamente (ou endereo transiente). O campo scop, de 4 bits, transporta um valor de escopo multicast, usado para limitar o alcance de um grupo multicast. O IETF est atualmente trabalhando em uma extenso da arquitetura de endereamento IPv6 que permite a alocao de endereos multicast baseada nos prexos de endereos unicast [68]. A idia poder delegar endereos multicast ao mesmo tempo que os prexos unicast, desta forma os operadores de rede podem identicar suas faixas de endereos multicast sem a necessidade de um protocolo de alocao de endereos inter-domnio. O formato de endereo atualmente proposto mostrado na Figura 25.
8 bits 11111111 4 bits flgs 4 bits scop 8 bits reserved 8 bits plen 64 bits network prefix 32 bits group ID

Figura 25: Formato do endereo multicast IPv6 baseado no prexo unicast. Neste novo formato, um segundo ag, P , foi introduzido no campo flgs. O bit P = 1 indica um endereo multicast alocado com base no prexo de rede, seno, P = 0. Alm disso, se P = 1, ento T deve possuir valor igual a 1. O campo plen especica o comprimento do campo de prexo de rede que identica a sub-rede. O campo network prefix identica o prexo de rede da sub-rede unicast qual o endereo atribudo, e o ltimo campo, group ID, um identicador de grupo de 32 bits. Alguns dos protocolos descritos anteriormente, como o PIM-SM, j possuem implementaes para o IPv6 com as adaptaes necessrias. Para o suporte do servio SSM, existem ainda algumas questes em discusso, como a reserva de uma faixa de endereos exclusiva. Uma faixa de endereos SSM pode ser obtida a partir de endereos multicast alocados com base no prexo unicast, sendo atualmente discutida no IETF [68]. Outros protocolos, como o MSDP e o MBGP, ainda no foram tratados para o IPv6. O MSDP provavelmente no existir no IPv6. Suas chances de ser implementado diminuem com o sucesso do servio SSM, e com o desenvolvimento do protocolo BGMP. Um componente essencial do servio SSM no IPv4 o protocolo IGMPv3. No IPv6, a funcionalidade do IGMP includa no protocolo ICMP (Internet Control Message Protocol) [69]. A primeira verso IPv6 do IGMP foi chamada MLD (Multicast Listener Discovery) [70]. A verso 1 do MLD implementa a mesma funcionalidade que a verso 2 do IGMP, e corresponde traduo do IGMPv2 para a semntica do IPv6. O Multicast Listener Discovery utilizado por roteadores IPv6 para descobrir a presena de ouvintes multicast nos enlaces diretamente conectados ao roteador (ou seja, estaes interessadas em receber pacotes multicast). A verso seguinte, MLDv2, introduz a ltragem de fontes implementada pelo IGMPv3 no IPv4 [71]. Desta forma, o roteador pode conhecer os grupos de interesse de suas estaes clientes, assim como o conjunto de fontes que estes clientes desejam escutar. O protocolo est em fase nal de padronizao pelo IETF.

Referncias
[1] C. Diot, W. Dabbous e J. Crowcroft, Multipoint communication: A survey of protocols, functions and mechanisms, IEEE Journal on Selected Areas in Communications, vol. 15, no. 3, pp. 277290, abril 1997. [2] M. Handley e J. Crowcroft, Internet multicast today, The Internet Protocol Journal, vol. 2, no. 4, pp. 219, dezembro 1999. [3] I. P. 802, IEEE P802.1p: Supplement to MAC Bridges: Trac Class Expediting and Dynamic Multicast Filtering. IEEE, Incorp. in IEEE Standard 802.1D, Part 3: Media Access Control (MAC) Bridges: Revision, 1998. [4] V. Fuller, T. Li, J. Yu e K. Varadhan, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC 1519, setembro 1993. [5] B. Williamson, Developing IP Multicast Networks. Cisco Press, janeiro 2000. [6] M. Handley, D. Thaler e R. Kermode, Multicast-Scope Zone Announcement Protocol (MZAP). RFC 2776, fevereiro 2000. [7] D. Meyer e P. Lothberg, GLOP Addressing in 233/8. RFC 2770, fevereiro 2000. [8] D. Thaler, M. Handley e D. Estrin, The Internet Multicast Address Allocation Architecture. RFC 2908, setembro 2000. [9] S. Hanna, B. Patel e M. Shah, Multicast Address Dynamic Client Allocation Protocol (MADCAP). RFC 2730, dezembro 1999. [10] R. Droms, Dynamic Host Conguration Protocol. RFC 1531, outubro 1993. [11] M. Handley e S. Hanna, Multicast Address Allocation Protocol (AAP), junho 2000. Work in progress, <draft-ietf-malloc-aap-04.txt>. [12] P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar e D. Thaler, The Multicast Address-Set Claim (MASC) Protocol. RFC 2909, setembro 2000. [13] Y. Rekhter e T. Li, A Border Gateway Protocol 4 (BGP-4). RFC 1771, maro 1995. [14] S. Kumar, P. Radoslavov, D. Thaler, C. Alaettinoglu, D. Estrin e M. Handley, The MASC/BGMP architecture for inter-domain multicast routing, in ACM SIGCOMM'98, pp. 93104, setembro 1998. [15] S. Deering, Host Extensions for IP Multicasting. RFC 1112, agosto 1989. [16] W. Fenner, Internet Group Management Protocol, Version 2. RFC 2236, novembro 1997. [17] B. Cain, S. Deering, I. Kouvelas, B. Fenner e A. Thyagarajan, Internet Group Management Protocol, Version 3. RFC 3376, outubro 2002. [18] L. Sahasrabuddhe e B. Mukherjee, Multicast routing algorithms and protocols: a tutorial, IEEE Network, pp. 90102, janeiro 2000. [19] B. Wang e J. C. Hou, Multicast routing and its QoS extension: Problems, algorithms, and protocols, IEEE Network, pp. 2236, janeiro 2000. [20] J. Moy, OSPF version 2. RFC 2328, abril 1998.

[21] K. C. Almeroth, The evolution of multicast: From the MBone to interdomain multicast to Internet2 deployment, IEEE Network, pp. 1020, janeiro 2000. [22] D. Waitzman, C. Partridge e S. Deering, Distance Vector Multicast Routing Protocol. RFC 1075, novembro 1988. [23] G. Malkin, RIP Version 2. RFC 2453, novembro 1998. [24] C. Huitema, Routing in the Internet. Prentice Hall, 2nd ed., 1999. [25] J. Moy, Multicast Extensions to OSPF. RFC 1584, maro 1994. [26] J. Moy, MOSPF: Analysis and Experience. RFC 1585, maro 1994. [27] T. Ballardie, P. Francis e J. Crowcroft, Core based trees (CBT), in SIGCOMM'93 - Communications Architectures, Protocols and Applications, pp. 8595, 1993. [28] A. Ballardie, Core Based Trees (CBT) Multicast Routing Architecture. RFC 2201, setembro 1997. [29] S. Deering, D. L. Estrin, D. Farinacci, V. Jacobson, C.-G. Liu e L. Mei, The PIM architecture for wide-area multicast routing, IEEE/ACM Transactions on Networking, vol. 4, no. 2, pp. 153162, abril 1996. [30] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma e L. Wei, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specication. RFC 2362, junho 1998. [31] I. Brown, J. Crowcroft, M. Handley e B. Cain, Internet multicast tomorrow, The Internet Protocol Journal, vol. 5, no. 4, pp. 219, dezembro 2002. [32] T. Bates, Y. Rekhter, R. Chandra e D. Katz, Multiprotocol Extensions for BGP-4. RFC 2858, junho 2000. [33] D. M. (Editor) e B. F. (Editor), Multicast Source Discovery Protocol (MSDP). Work in progress, <draft-ietf-msdp-spec-14.txt>, novembro 2002. [34] D. Thaler, Border Gateway Multicast Protocol (BGMP): Protocol Specication. Work in progress, <draft-ietf-bgmp-spec-03.txt>, junho 2002. [35] C. Diot, B. N. Levine, B. Liles, H. Kassem e D. Balensiefen, Deployment issues for the IP multicast service and architecture, IEEE Network, pp. 7888, janeiro 2000. [36] H. W. Holbrook e D. R. Cheriton, IP multicast channels: EXPRESS support for large-scale single-source applications, in ACM SIGCOMM'99, setembro 1999. [37] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, J. Meylor, D. Meyer, G. Shepherd e B. Haberman, An Overview of Source-Specic Multicast (SSM). Work in progress, <draftietf-ssm-overview-04.txt>, novembro 2002. [38] M. Handley, C. Perkins e E. Whelan, Session Announcement Protocol. RFC 2974, outubro 2000. [39] I. Stoica, T. S. E. Ng e H. Zhang, REUNITE: A recursive unicast approach to multicast, in IEEE INFOCOM'2000, maro 2000. [40] J.-J. Pansiot e D. Grad, On routes and multicast trees on the Internet, ACM Computer Communication Review, vol. 28, no. 1, pp. 4150, janeiro 1998.

[41] R. C. Chalmers e K. C. Almeroth, Modeling the branching characteristics and eciency gains in global multicast trees, in IEEE INFOCOM'2001, abril 2001. [42] L. H. M. K. Costa, S. Fdida e O. C. M. B. Duarte, Hop by hop multicast routing protocol, in ACM SIGCOMM'2001, pp. 249259, agosto 2001. [43] R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms e O. Paridaens, Explicit Multicast (Xcast) Basic Specication. Work in progress, <draft-ooms-xcast-basic-spec-04.txt>, janeiro 2003. [44] L. Blazevic e J.-Y. L. Boudec, Distributed core multicast (dcm): a multicast routing protocol for many groups with few receivers, ACM SIGCOMM Computer Communication Review, vol. 29, no. 5, pp. 621, outubro 1999. [45] M. Liu, R. Talpade e A. McAuley, Amroute: Adhoc multicast routing protocol, Technical Report TR 99-1, CSHCN, 1999. [46] Bommaiah, A. McAuley, R. Talpade e M. Liu, AMRoute: Adhoc multicast routing protocol, agosto 1998. work in progress; <draft-manet-amroute-00.txt>. [47] S.-J. Lee, W. Su e M. Gerla, On-demand multicast routing protocol in multihop wireless mobile networks, ACM/Baltzer Mobile Networks and Applications, vol. 7, no. 6, pp. 441 453, dezembro 2002. [48] E. M. Royer e C. E. Perkins, Multicast operation of the ad-hoc on-demand distance vector routing protocol, in Mobile Computing and Networking, pp. 207218, agosto 1999. [49] A. El-Sayed, V. Roca e L. Mathy, A survey of proposals for an alternative group communication service, IEEE Network, vol. 17, no. 1, pp. 4651, janeiro 2003. [50] R. Finlayson, The UDP Multicast Tunneling Protocol. Work in progress, <draft-nlaysonumtp-07.txt>, setembro 2002. [51] R. Finlayson, R. Perlman e D. Rajwan, Accelerating the Deployment of Multicast Using Automatic Tunneling. Work in progress, <draft-nlayson-mboned-autotunneling-00.txt>, fevereiro 2001. [52] P. Liefooghe e M. Goossens, An architecture for seamless access to multicast content, in IEEE Conference on Local Computer Networks, novembro 2000. [53] D. Thaler, M. Talwar, L. Vicisano e D. Ooms, IPv4 Automatic Multicast Without Explicit Tunnels. Work in progress, <draft-ietf-mboned-auto-multicast-01.txt>, abril 2002. [54] B. Carpenter e K. Moore, Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, fevereiro 2001. [55] J.-J. Pansiot, A. Alloui, T. Noel e D. Grad, A new architecture for sparse-mode inter-domain multicasting, in EUNICE Open European Summer School, setembro 2000. [56] A. El-Sayed e V. Roca, A host-based multicast (HBM) solution for group communications, in 1st IEEE International Conference on Networking, julho 2001. [57] D. Pendarakis, S. Shi, D. Verma e M. Waldvogel, ALMI: An application level multicast infrastructure, in 3rd USENIX Symposium on Internet Technologies and Systems, pp. 49 60, maro 2001.

[58] Y. Chu, S. Rao e H. Zhang, A case for end system multicast, in ACM SIGMETRICS, junho 2000. [59] S. Zhuang, B. Zhao, A. Joseph, R. Katz e J. Kubiatowicz, Bayeux: An architecture for scalable and fault-tolerant wide-area data dissemination, in International Workshop on Network and Operating System Support for Digital Audio and Video, junho 2001. [60] J. Liebeherr, M. Nahas e W. Si, Application-layer multicast with delaunay triangulatios, in IEEE GLOBECOM, novembro 2001. [61] P. Francis, Yoid: extending the multicast internet architecture. Unrefered Report; http://www.aciri.org/yoid/, setembro 1999. [62] P. Francis, Yoid tree management protocol (ytmp) specication. Unrefered Report; http://www.aciri.org/yoid/, dezembro 1999. [63] L. Mathy, R. Canonico e D. Hutchinson, An overlay tree building control protocol, in International Workshop on Networked Group Communication, novembro 2001. [64] B. Zhang, S. Jamin e L. Zhang, Host multicast: A framework for delivering multicast to end users, in IEEE INFOCOM, junho 2002. [65] R. Hinden e S. Deering, IP Version 6 Addressing Architecture. RFC 2373, julho 1998. [66] R. Hinden e S. Deering, IP Version 6 Addressing Architecture, outubro 2002. Work in progress, <draft-ietf-ipngwg-addr-arch-v3-13.txt>. [67] R. Hinden e S. Deering, IPv6 Multicast Address Assignments. RFC 2375, julho 1998. [68] B. Haberman e D. Thaler, Unicast-Prex-based IPv6 Multicast Addresses. RFC 3306, agosto 2002. [69] A. Conta e S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specication. RFC 2463, dezembro 1998. [70] S. Deering, W. Fenner e B. Haberman, Multicast Listener Discovery (MLD) for IPv6. RFC 2710, novembro 1999. [71] R. Vida, L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas e B. Haberman, Multicast Listener Discovery Version 2 (MLDv2) for IPv6, outubro 2002. Work in progress, <draftvida-mld-v2-05.txt>.