Internet Group Management Protocol - Verso 1 e 2 e

Real Time Protocol (RTP)

Introduo

possvel classificar um host, com relao a sua capacidade de multicast, em um dos trs nveis
abaixo, chamados de nveis de conformidade:

Nvel 0: sem suporte a IP multicasting

No existe, at esta data, nenhum requerimento que todas as implementaes baseadas em IP

suportem multicasting. Hosts de nvel 0 no sero afetados, em geral, por atividade deste tipo. A
nica exceo acontece, em alguns tipos de rede local, onde a presena de hosts de nvel 1 ou 2
pode causar o envio equivocado de datagramas IP multicast para hosts de nvel 0.

Nvel 1: capacidade para enviar, mas no para receber trfego multicast

O nvel 1 permite que um host tome parte em alguns servios multicast, como localizao de
recursos ou reportagem de status, mas no permite que o mesmo se associe a um grupo
de hosts.

Nvel 2: suporte total a IP multicasting

O nvel 2 permite que um host se associe ou deixe grupos de hosts, como tambm envie
datagramas IP para os mesmos. Isto requer a implementao do Internet Group Management
Protocol (IGMP) e extenso dos servios de IP e de rede local nas interfaces dos hosts.

Endereos de grupos de hosts

Grupos de hosts so identificados por endereos classe D, isto , aqueles cujos quatro bits de
ordem mais alta so iguais a "1110".

Na notao Internet padro, endereos de grupos de hosts variam de 224.0.0.0 at

239.255.255.255. O endereo 224.0.0.0 garantido no pertencer a nenhum grupo e 224.0.0.1
designado ao grupo permanente de todos os hosts IP (incluindo gateways). Isto usado para
enderear todos os hosts multicast em redes diretamente conectadas. No h um
endereo multicast (ou outro endereo IP) para todos os hosts na Internet.

Modelo de implementao de um host IP

As extenses multicast da implementao de um host IP esto especificadas no modelo de

camadas ilustrado abaixo. Nesse modelo, as implementaes do ICMP e do IGMP (para hosts de
 nvel 2) so consideradas parte do mdulo IP. J o mapeamento de endereos IP para endereos
de rede local considerado como responsabilidade dos mdulos de rede local.

Internet Group Management Protocol version 1 (IGMPv1)

O Internet Group Management Protocol (IGMP) usado por um host IP para informar suas
associaes a grupos de hosts para qualquer roteador multicast imediatamente vizinho. Trata-se
de um protocolo assimtrico e especificado aqui do ponto de vista do host, no de um
roteador multicast. Desta forma, mensagens IGMP so encapsuladas em datagramas IP, com
nmero de protocolo igual a 2. Todas as mensagens que dizem respeito a hosts tm o seguinte
formato:

Version

A verso atual igual 1. A verso 0, especificada na RFC-988, encontra-se obsoleta.

Type

No que concerne aos hosts, existem dois tipos de mensagens IGMP:

 1. Host Membership Query
2. Host Membership Report

Unused

Campo no usado. zerado quando enviado e ignorado quando recebido

Checksum

O checksum calculado fazendo-se o complemento de um de 16-bits do complemento

de um da soma dos 8-octetos da mensagem IGMP. Esta frase parece estranha? Talvez
uma consulta a um livro de lgica binria resolva o problema...

Group Address

Em uma mensagem do tipo 1 (Host Membership Query), o campo de endereo de grupo

zerado quando enviado e ignorado quando recebido.

Em uma mensagem tipo 2 (Host Membership Report), o campo de endereo de grupo

contm o endereo IP do grupo de host sendo informado.

Descrio informal do protocolo

Roteadores multicast enviam mensagens Host Membership Query (chamadas de Queries) para
descobrir quais grupos de hosts tm membros nas redes locais diretamente
conectadas. Queries so endereadas ao grupo que engloba todos os hosts (endereo 224.0.0.1),
e tm time-to-live no cabealho IP igual a um.

Os hosts, ao receberem uma Query, respondem a atravs de mensagens Host Membership

Reports (as chamadas Reports), informando os grupos a que pertencem atravs da interface de
rede em que a Query foi recebida. Para evitar uma exploso de Reports concorrentes e reduzir o
nmero total destas mensagens transmitidas, duas tcnicas so usadas:

1. Quando um host recebe uma Query, ao invs de enviar Reports imediatamente, ele liga um
cronmetro regressivo para cada um dos grupos a que est associado na interface em que
a Query foi recebida. Cada cronmetro ajustado para um valor diferente, escolhido
aleatoriamente entre 0 e N segundos. Quando um cronmetro expira, um Report gerado para o
grupo de hostscorrespondente. Logo, Reports so espalhados durante um intervalo de N
segundos, ao invs de ocorrerem ao mesmo tempo.
2. Um Report enviado com o endereo IP de destino igual ao endereo do grupo de hosts sendo
informado, e com um time-to-live igual a 1, de modo que outros membros do mesmo grupo na
mesma rede podem receber o Report. Se um host ouvir um Report direcionado a um grupo que
faz parte, ele pra o cronmetro correspondente a este grupo e no gera o respectivo Report.
Ento, normalmente, somente um Report ser gerado para cada grupo presente na rede, pelo
membro cujo cronmetro expirar primeiro. Note que roteadores multicast recebem todos os
datagramas IP multicast, logo no precisam ser endereados explicitamente. Um fato importante
 que roteadores no precisam saber que hosts pertencem a que grupo, somente que pelo
menos um host pertence a um determinado grupo em uma rede particular. Isto j suficiente
para o roteador saber se deve repassar, ou no, pacotes para um determinado grupo em uma
rede diretamente conectada.

Montagem Da Tabela De Grupos Nos Roteadores Multicast

Periodicamente, roteadores multicast enviam Queries para atualizar seus conhecimentos sobre
grupos presentes em uma rede particular. Se nenhum Report for recebido para um grupo
particular depois do envio de algumas Queries, os roteadores assumem que o grupo no tem
membros locais e que no precisam repassar datagramas multicast originados remotamente para
este grupo na rede local. Queries so normalmente enviadas com pouca frequncia (no mais que
uma por minuto) para manter o overhead IGMP nos hosts e na rede pequeno. Entretanto, quando
um roteador multicast inicializado, vrias Queries so enviadas em um curto perodo com a
finalidade que montar sua tabela de grupos locais rapidamente.

Quando um host se associa a um novo grupo, ele deve transmitir um Report para aquele grupo,
ao invs de esperar por uma Query, no caso de ser o primeiro membro do grupo na rede. Para se
resguardar da possibilidade do Report inicial ser perdido ou danificado, recomendado que seja
este repetido uma ou duas vezes depois de curtos lapsos de tempo.

Internet Group Management Protocol, Version 2 (Igmpv2)

O IGMPv2 mais do que uma simples reedio da verso 1 com algumas modificaes. Ele veio
para resolver os problemas que no eram notados quando as palavras velocidade e latncia ainda
no faziam parte da orao diria dos projetistas e administradores de rede.

No h necessidade de uma explanao de todo o protocolo. Sero explicadas, com detalhes, as

diferenas desde a primeira verso. Assim, o que no for abordado, deve ser assumido que ficou
como na verso anterior.

Mudanas desde IGMPv1

Os campos Version e Type foram combinados em um nico campo Type

Para um roteador diferenciar mensagens Host Membership Report enviadas por

um host IGMPv1 ou IGMPv2, um novo valor de Type foi adotado;

Um novo Type foi criado para mensagens Leave Group Message IGMPv2;

A mensagem Host Membership Query foi mudada, de modo que o campo Unused da verso
anterior contm um novo valor, o Max Response Time;

Existe um mecanismo de eleio do Querier . No IGMPv1, a eleio do mesmo era feita pelo
protocolo de roteamento multicast, e protocolos diferentes usavam mecanismos diferentes. Isto
 poderia resultar em mais de um Querier por rede, portanto o processo de eleio foi padronizado
no IGMPv2.

Type

Existem trs tipos de mensagens IGMP que dizem respeito a interao host-roteador:

0x11 = Host Membership Query

General Query

Usada para descobrir que grupos tm membros em uma rede diretamente

conectada.

Group-Specific Query

Usada para descobrir se um determinado grupo tm membros em uma rede

diretamente conectada.

0x16 = Host Membership Report Verso 2

Usado para diferenciar Reports das diferentes verses.

0x17 = Leave Group

Quando um host deixa um grupo multicast, se foi o ltimo a responder a uma Query com
um Membership Report, ele deve enviar uma mensagem Leave Group para o grupo de
todos os roteadores multicast (224.0.0.2). Se no foi o ltimo a responder, ento ele pode
no enviar esta mensagem, j que, provavelmente, existem outros membros na subrede.

Isto uma otimizao para reduzir o trfego. No entanto, um host sem espao de
armazenamento suficiente para recordar se foi, ou no, o ltimo a responder uma Query,
pode sempre enviar uma mensagem Leave Group quando deixar o grupo.

Quando um Querier recebe uma mensagem Leave Group em uma interface que o grupo
tem membros, ele envia [Last Member Query Count] Group-Specific Queries a cada
[ Last Member Query Interval ] para o grupo em questo. Essas Group-Specific
Queries tm o valor do campo Max Response Time igual ao Last Member Query Interval.
 Se nenhum Reportfor recebido depois que o tempo de resposta da ltima Query expirar,
o roteador assume que o grupo no tem membros locais.

Obs.: Para manter a compatibilidade com a verso anterior, ainda permitido usar a
mensagem do tipo 0x12 = Version 1 Membership Report.

Max Response Time

O campo Max Response Time s significativo em Host Membership Queries, e

especifica o intervalo de tempo mximo permitido entre o recebimento da Query e o envio
de um Report em unidades de 1/10 segundos.

Variar o valor deste campo permite que roteadores IGMPv2 otimizem o intervalo de
tempo entre o momento que um host deixa um grupo e o instante que o protocol de
roteamento notificado que no h mais membros. Se o roteador no for notificado que
no h mais membros em um determinado grupo, ele continuar a repassar pacotes at
que a entrada desse grupo na tabela expire.

Checksum

O checksum o complemento de um de 16-bits do complemento de um da soma dos 8-

octetos da mensagem IGMP.

Group Address

Numa mensagem do tipo 1 (Host Membership Query), o campo de endereo de grupo

zerado quando enviado e ignorado quando recebido.

Em uma mensagem tipo 2 (Host Membership Report), o campo de endereo de grupo

contm o endereo IP do grupo de hostsendo reportado.

O processo de eleio do querier

Todos os roteadores multicast comeam como Querier nas suas redes diretamente conectadas.
Se um roteador multicast recebe uma Query de um roteador com IP menor que o seu, ele no
deve se tornar Querier naquela rede. Se ele no receber nenhuma dessas mensagens de outro
roteador durante [ Other Querier Present Interval ], ele permanece no seu papel de Querier.

DEFINIES IMPORTANTES

Robustness Variable

Este valor permite fazer uma estimativa da perda de pacotes em uma subrede. Se uma subrede
tem uma alta perda de pacotes, esta varivel pode ser aumentada.
 Last Member Query Interval

o valor do campo Max Response Time em Group-Specific Queries enviadas em resposta a

Leave Group Messages, e tambm o tempo entre Group-Specific Messages.

Last Member Query Count

O nmero de Group-Specific Queries enviadas antes do roteador assumir que no existem

membros locais.

Query Interval

o intervalo entre General Queries enviadas pelo Querier.

Other Querier Present Interval

Diz respeito ao perodo de tempo que deve transcorrer antes que um roteador multicast decida
que no existe mais nenhum roteador multicast que poderia ser o Querier.

Querier

O roteador designado para transmitir IGMP Membership Queries na rede.

TABELA DE DESTINO DE MENSAGENS

Tipo de Mensagem Grupo de Destino

General Query Todos os Sistemas (224.0.0.1)
Group-Specific Query o grupo sendo interrogado
Membership Report o grupo sendo informado
Leave Message Todos os Roteadores (224.0.0.2)

Introduo Ao Real Time Protocol (Rtp)

O Real Time Protocol prov servios de entrega fim-a-fim para dados com caractersticas de
tempo real como udio e vdeo interativo. Esses servios incluem identificao do tipo de dado,
numerao sequencial, timestamping e monitoramento de entrega. Aplicaes, tipicamente,
executam o RTP sobre UDP para fazer uso dos seus servios de multiplexao e checagem
(checksum). O RTP suporta transferncia de dados para mltiplos destinos usando
distribuio multicast se possvel.

Note-se que o RTP no prov qualquer mecanismo para assegurar entrega sincronizada ou
qualquer outro tipo de qualidade de servio ou garantia de entrega. Isto deve ser assegurado
pelos servios das camadas inferiores. O RTP tambm no garante a entrega, no evita que os
pacotes cheguem fora de ordem, nem assume que a rede confivel. Entretanto, ele permite que
sejam adicionados mecanismos de segurana, quando necessrios, bem como controle de fluxo e
de congestionamento. As aplicaes devem ser adaptativas para poderem acomodar a variao
do fluxo de dados em tempo real.

Apesar do RTP ser primariamente projetado para satisfazer as necessidades de conferncias

multimdia com muitos participantes, ele no est limitado a somente este tipo de aplicao.
Armazenamento de dados contnuos, simulao interativa distribuda e aplicaes de controle e
medio tambm podero achar o RTP conveniente.

O RTP pode ser definido como consistindo de duas partes intimamente conectadas:

O Real Time Protocol (RTP), que transmite dados que tem propriedades de tempo real;

O RTP Control Protocol (RTCP), que monitora a qualidade do servio e distribui informaes
sobre os participantes de uma sesso.

O RTP representa um novo estilo de protocolo, isto , foi projetado para ser flexvel de modo a
prover as informaes requeridas por uma determinada aplicao e ser normalmente integrado
dentro do processamento da aplicao, ao invs se ser implementado numa camada separada.

Vrias aplicaes que usam o RTP, tanto comerciais quanto experiementais, j foram
implementadas a partir das especificaes. Essas aplicaes incluem ferramentas de udio e
vdeo, monitores de trfego, entre outras. Os usurios dessas aplicaes j chegam aos
milhares. Entretanto, o estado atual da Internet no consegue suportar toda a demanda por
servios de tempo real. Servios de grande largura de banda usando RTP, como vdeo, podem
degradar seriamente a qualidade de servio de outras aplicaes. Logo, os desenvolvedores
devem tomar as precaues necessrias para limitar o consumo de banda ao mnimo necessrio
nesses casos.

Referncias Bibliogrficas

D. D. Clark and D. L. Tennenhouse, "Architectural considerations for a new generation of

protocols," in SIGCOMM Symposium on Communications Architectures and Protocols,
(Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review,
Vol. 20(4), Sept. 1990.

Postel J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September
1981.

Fenner W., "Internet Group Managenment Protocol, Version2", draft-ietf-idmr-igmp-v2-08, Xerox

PARC, November 1, 1997

Deering S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, Computer
Science Department, August 1989
Schulzrinne H., Fokus GMD, Casner S., Frederick R., Jacobson V., "RTP: A Tranport Protocol for
Real-Time Applications", STD Track, RFC 1889, Audio-Video Transport Working Group, January
1996.