Proje to para Edital - Progra m a de Grupos de Trabalho da RNP 2 0 0 4-2 0 0 5 1 Dados Gerais do Projeto Título: Coord e n a d o r: Vicecoord e n a d o r: Duraçã o do projeto: Parcerias: Implantação e Avaliação de Desempenho de Protocolos de Transmissão Multicast Confiável na RNP Valter Roesler. CV resumido em anexo e na base Latte s Marinho P. Barcellos. CV resumido em anexo e na base Latte s. 12 meses University of Manchester e BT Exact (ambos na Inglaterra) 2 Sumário Executivo Multic a s t, na sua form a mais simples, pode ser definido como a trans miss ão de um pacote para múltiplos destinat á rios, reunidos em um grupo e referenciados através do mesmo. IP multicast surgiu no início dos anos 90, e desd e ent ão a pres e n ç a de supor t e a multica s t nativo em equipam e ntos de rede é cada vez mais comum. Até recente m e n t e, multicast era relativam ent e pouco utilizado, pelo menos em relação ao que se imaginava inicialmente. Entretanto, a situação parece estar finalment e mudando. Na Europa, grandes provedor es começam a habilitar multicast em suas redes em função de solicitações de clientes. Aplicações como Acce s s Grid têm funcionado como propulsore s da tecnologia, demonstra n do que multicast é adequado e pode ser usado sem maiores problem a s de gerência. As aplicações potenciais de multicast, ou seja, que emprega m comunicação multiponto, são muitas. [Diot, 2000] identifica quatro classes de aplicações multicast: distrib uição de áudio e vídeo : uma fonte transmite fluxos de áudio e vídeo em tempo real através da Internet para múltiplos receptor es simultaneamente; áudio, videoconfe r ê n c i a e aplicaç õ e s colab or ativa s de grup o: uma extensão da distribuição de áudio e vídeo, estas aplicações permitem que usuários interajam ;
aplica ç õ e s push: entreg a de dados de forma confiável quando usuários assina m determinados canais, recebe ndo informações específicas de seu interess e; transf er ê n c i a de arquivo s : a trans miss ão de dados de uma localida d e par a muit a s outr a s, incluindo webcaching, banco s de dados distribuídos e gravação remota de registros (logs). IP multicast é uma tecnologia habilitadora, pois permite a trans miss ão de pacotes IP de forma mais rápida, eficiente e com menor custo. No entanto, não oferece qualquer garantia de entrega, e o modelo de controle de grupo é descentralizado e aberto : não é necessário ser membro do grupo para enviar ao mesmo, não existe um mecanismo que garant a reserva prévia de um grupo, não é possível preve ni r que um dado host assin e um grupo e pass e a recebe r dados, etc. Protocolos de multicast confiáv el visam aumentar as garantias ao usuário, acresce nta n do certo nível de confiabilidade na entrega de pacotes a receptores. Em outras palavras, perdas de pacotes na rede são recupe r a d a s através de um mecanismo de controle de erro, que pode ser rea tivo (ARQ Automatic Repeat Request) ou proa tivo (FEC Forward Error Correction) [Paul, 1998]. O desenvolvimento de protocolos multicast confiável repres e nta um enor m e desafio. A princip al bar r e i r a tecnológic a a ser vencid a, alvo da comunidade de pesquisa em redes de computadores nos últimos anos, é o projeto de mecanis mos escaláveis. Os principais mecanis mos implement a m controle de erro, controle de congestiona m e n t o, controle de sessão, ou trata m de aspectos de segur a nça. A comunidade científica, desde 1994, tem analisado as propriedades básicas destes mecanismos, o que levou à proposta de novos protocolos multic a s t confiável. Alguns dest e s protoc olos fora m implementados, e têm sido usados em menor escala. Exemplos disso são o RMTP- II [Whetten, 1998] e o MDP [Macker, 1999]. O IETF, através do seu Grupo de Trabalh o em Transp ort e Mult i c a s t Confi áv e l (Working Group on Reliable Multicast Transport), concentra esforços da comunidade científica e dirige o processo de padronização de protocolos multicast confiável. Até o momento, o Grupo abordou apenas o transporte de grandes quantida d es de dados de um para vários, para grupos potencialmente grandes. O Grupo se encarregará da padronização de protocolos em geral através da composição de um conjunto de RFCs que especificam blocos de construção (Building Blocks, ou BBs) [RFC 3048, 2001] e instanciações de protocolos (Protocol Instantiations, ou PIs ). Blocos de construç ão são um conjunto de compone ntes modulares facilmente separáveis e comuns a múltiplos protocolos. Suas vantagens são a possibilidade de reuso e redução no tempo de verifica ç ã o do protoc olo. Eles são utiliza dos junt a m e n t e com APIs abstratas que definem os métodos de acesso e seus argumentos.
Como exemplos de BBs sendo padronizados pelo IETF pode- se citar codificação FEC, confirmações negativas (NACKs), controle de congestiona m e n t o e seguranç a [RFC 3048, 2001]. Inst a n ci a ç õ e s de protocolos são os protoc olos em si, ou seja, especificações que definem a lógica que cola as partes e a funcionalidade adicional mínima necessária para materializar um protocolo funcional a partir de um ou mais blocos de construç ão. Pod e m ser divididos nas seg uin t e s qua t r o famílias [RFC 304 8, 200 1]: NACK-based Reliable Multicast Protocol (NOR M ): protoc olos de multicast confiável baseados em trans missão de NACKS, ou seja, baseados na técnica ARQ, mencionada anteriormente. Um exemplo de protocolo que utiliza est a técnic a é o MDP2 [Macke r, 1997]; Tree-Based ACK: protoc olos que utiliza m confir m a ç õ e s positivas de ACK, porém com servidores interm e diários a fim de evitar implosões de ACKs. Um exemplo é o RMTP- II [Whetten, 1998]; Asynchronous Layered Coding (ALC): protoc olos de multica s t confiável que não necessita m retransmis sões, pois utilizam técnicas de FEC, conforme mencionado anterior m e nte. Nessa linha, está em andam e nto a pa dronização do FLUTE, protocolo para trans miss ão unidirecional de arquivos sem realimentação. FLUTE é inerente m e n t e escalável, e se encontr a atualmente no Draft 8 [Paila, 2004]; Router Assist: protocolos que utiliza m o apoio dos rote a d o r e s interm e diários a fim de reduzir a quantidad e de NACKs circulando na rede. Um exemplo é o PGM [Farinacci, 1998]. No entanto, mais recente m e n t e a trilha que visava padronizar os protocolos do tipo TrACK foi abandon a d a, devido a uma mudança na política da Sun Microsyste m s: esta financiava o desenvolvimento do protocolo JRMS, que era a base para criação dos padrões de protocolos basea dos em árvore. Outra razão para isso, segundo os autores do JRMS, foi a complexidade de se criar e manter uma árvore lógica de reparo multicast. Protocolos que depende m de suporte da rede apresenta m inerentes problem as de implantaç ã o, devido à heterogeneidade da rede. Na prática, portanto, o Grupo de multic a s t confiável do IETF tem focado nas famílias de protoc olo do tipo NORM e ALC, confor m e desc rit o em maior detal h e a segui r. Dent r o da família NORM, existe o draft do prot o c o l o NOR M [Adamson, 2004], que é projetado para oferecer transporte confiável fim- a- fim de grandes objetos (dados ou streams). Para implement a r trans miss ão confiável, NORM emprega um mecanismo de confirmação seletiva e negativa, e FEC (através dos respectivos blocos de construção). Um esque m a de controle de congestionamento é especificado para permitir que o protocolo NORM compartilhe larg u r a de ban d a de form a amig áv el (just a) com outro s proto colo s de transport e tal como TCP. NORM oferece mecanis mos adicionais para conduzir sessões multicast com coordenação prévia limitada entre
trans missores e receptores. Segundo [Adamson, 2004], NORM permite que trans missores e receptores entrem e saiam de sessões multicast com sobrecarga mínima de controle e tempo de sincronização entre participantes. NORM é capaz de operar tanto em modo multicast recíproco (quando receptores são capazes de enviar multicast) como com conectividade assimétrica (possivelmente sem um caminho unicast de retorno) entre trans missor e receptores. NORM foi projetado para ser autoadaptativo para uma gama de condições de rede com préconfigur ação mínima ou inexistente, exibindo convergência e operação eficiente mesmo em situações de perda de pacotes e substanciais atrasos de transmissão. Dent r o da família ALC, existe o prot o c o l o ALC [RFC 3450, 2002], designa do para entrega confiável e maciça de dados. O ALC combin a os BBs de Layered Coding Transport (LCT) e Forward Error Correction (FEC) para oferecer entreg a assíncrona e multi- taxa para um número ilimitado de receptores concorrent e s a partir de um único transmissor. Cada receptor pode iniciar a recepção de um objeto assincrona m e n t e, e a taxa de entreg a de dados em cada receptor na sessão é ajustada de acordo com sua própria capacida de. O ALC omite de sua definiç ã o facilida d e s que não seja m escal áv eis, o que não impe d e que aplicaç õ e s tenh a m que utiliza r outros mecanis mos como controle de sessão que acabe m por limitar a escalabilidade. 2.1 Proposta de Trabalho A proposta deste Grupo de Trabalho é montar uma estrut ur a de multicast confiável na RNP, explorando o suporte nativo à multicast atualmente existente [Raniery, 2002], e então avaliar experi m e n t a l m e n t e um conjunto de impleme ntações destes protocolos. Ênfase será dada aos protocolos em padronizaç ão pelo IETF, porém a análise não é restrita aos mesmos. As implementações de protocolos a ser e m consid e r a d a s par a test e s são, em princípio, as seguintes: MDP: imple m e n t a ç ã o do Multicast Dissemination Protocol em desenvolvimento pelo Naval Research Laboratory 1 ; NORM: implementação em desenvolvimento pelo Naval Research Laboratory 2 ; NORM, ALC/LCT e FLUTE: implementações em desenvolvimento pelo INRIA, incluidas na biblioteca MCL 3 ; 1 http://manimac.itd.nrl.navy.mil/mdp/ 2 http://nor m.pf.itd.nrl.navy.mil/ 3 http://www.inrialpes.fr/planete/people/roca/ mcl/mcl.html
ALC/LCT e FLUTE: implementações em desenvolvimento pela Tampere University of Technology 4. Todos os protocolos acim a poss u e m uma licenç a que per mi t e o livre uso e modifica ç ã o. Não é objetivo do GT des e nvolve r um novo protocolo ou aperfeiçoar mecanismos destes, embor a é provável que seja feita uma cont rib ui ç ã o científica nest e sentido, e reto r n o seja dado aos autores (o vice- coordenador do projeto vem mantendo contato com Brian Adamson, no NRL, e Vincent Roca, no INRIA). Os cenários de teste a serem examinados serão restritos pela funcionalidade disponibilizada pelas implementações, e guiados pelas características de cada aplicação potencial de multicast na RNP. Em particular, vislumbra m os criar cenários para avaliar as seguintes aplicações, em ordem de importância: cenários para transf er ê n c i a de arquivos : a transmissão de arquivos cobre uma série de aplicações importantes, como espelh a m e n t o de sites e distrib uiç ã o de dados científicos. Em particular, com a entra d a do canal de televisão universitário via RNP, consid e r a m o s os benefícios advindo s do uso de multic a s t confiável par a o envio de enor m e s arq uivos codificados a partir da estação cabeça de rede para todas as emissoras envolv idas. A transmissão vai envolver tipicamente o envio dos progra m a s codificados e de uma grade de program a ç ã o de 24h, sendo que 12h serão inéditas. Atualment e existem 31 emissoras de televisão envolvidas na RITU (Rede de Intercâmbio entre TVs Universitárias). distrib uição de áudio e vídeo : por exemplo, aquele empregado em transmissões de tempo real feita por rádios baseadas na Internet. A diferença é que, com multicast confiável, a perda de pacotes será parcial ou totalmente corrigida nos destinos, e haverá um compa rtilha m e n to justo de largu r a de band a com outr os fluxos na red e; audioconf e r ê n c i a, videoconf e r ê n c i a e aplica ç õ e s colaborativas de grup o : exemplos são Access Grid (já empregado anteriormente na RNP) e outras ferram e n t a s de áudio ou videoconferê ncia. jogos distrib uíd o s em rede : a área de jogos em rede está crescendo rapidam e n t e nos últimos anos, o que justifica a investigaç ão desta como aplicação de multicast na RNP. A avaliação será realizada de acordo com as seguintes métricas: des e m p e n h o (em termos de vazão efetiva); atraso (entre saída do trans missor e chegad a no destino); cust o (largur a de banda consumida, considerando número de usuá r io s atingido s); e robust e z (percentual de sessões bem sucedidas). 4 http://atm.tut.fi/mad/
Projeta mos o desenvolvimento dos trabalhos em 4 etapas, conforme descrito a seguir. A prim e ira fase será baseada no estudo das implementações (parâm et r os, funciona m e n to, e uma série de asp e c t o s prá tico s envolvido s) e dos princípio s básico s que reg e m o funcion a m e n t o dos protoc olos, segu n d o o que está definido em RFCs, drafts ou artigos científicos. As implement ações serão examinad a s em detalhe, averiguando -se seu estado atual de implementação e sua adequação para cada um dos cenários propostos. Paralelam e n t e a isso, deverão ser instaladas e configur ad a s as máquinas nos PoPs remotos bem como na sede do GT proposto. A seg u n d a fase será dedicada ao desenvolvimento de scripts para automaç ão dos experimentos, segundo cada um dos cenários propostos. A terceir a fase será de execução dos experimentos, com repetição exaustiva dos diversos tipos de transferência, coleta de resultados e levantam e n to estatístico. Por fim, na quarta fase os resultados serão reunidos e processados em documentos, na forma de manuais de utilização (da infraestrutura instalada, testada e avaliada) e de artigos para publicação em workshops, conferências e periódicos. O trabalho proposto por este GT está espelhado em iniciativa similar executada pelo vice- coordenador na SuperJANET, a rede de alta velocidade do Reino Unido. No projeto MUST 5, é investigado o uso de protocolos multica s t confiável em aplic aç õ e s de Compu t a ç ã o em Grade. A experiência adquirida naquele projeto será de fundamental valia na conduç ão técnica do GT proposto. Além disso, os resultados obtidos na RNP serão compara dos com aqueles obtidos na SuperJANET, auxiliando no entendim ento dos mesmos. 2.2 Referê ncias Ada m s o n, B. et. al. NACK-Oriented Reliable Multicast Protocol (NORM). Inte r n e t Draft, Janeiro, 2004. Dio t, C., et. al. Deployment Issues for the IP Multicast Service and Architecture. IEEE Network magazine, Special issue on Multicasting. January/February 2000 Farin a c c i, D. et. al. PGM reliable transport protocol specification. 1998. Pail a, T. et. al. FLUTE - File Delivery over Unidirectional Transport. Inte r n e t Draft, Junho, 2004 Mack e r, J.; Adam s o n, B. Multicast Dissemination Protocol, version 2 (MDPv2). http://manim ac.itd.nrl.navy.mil/mdp. 1999. Pa u l, Sa nj o y. Multicasting on the Internet and its applications. Massachusetts: Kluwer Academic Publishers. 1998, 421p. 5 http://www.sve.man.ac.uk/research/atoz/must/must.html
Raniery, Adenils o n. Multicast nativo no backbone RNP2: panorama atual de implantação. RNP: NewsGene r a tion, v.6, n.3, 21 de maio de 2002. RFC 345 0. Luby, M. et. al. Asynchronous Layered Coding (ALC) Protocol Instantiation. RFC 304 8. Whett e n, B. et. al. Reliabl e Multica s t Trans p ort Buildin g Block s for One- to- Many Bulk- Data Transf er. 200 1. Whett e n, B. et. al. The RMTP-II Protocol. 1998. 3 Avaliação dos Resultados O proje to propos t o prevê uma série de result a d o s, e eles têm mecanis mos diferentes de medição para avaliar seu sucesso. A seguir uma lista de resultados, juntament e com o método de medição de sucesso. Defini ç ã o de modelo de multicast confiáv el na rede RNP : definiç ã o do melho r modelo de multica s t confiável, para cada tipo de aplicação, considerando as característica s da rede brasileira. Será gerado um relatório compar a n do os protocolos analisados em termos de desempenho, atraso, escalabilidade e robustez, bem como os pontos fortes e fracos de cad a um deles. Implanta ç ã o do projet o- piloto : será feito um projeto- piloto na RNP para validar os resultados. Diversos PoPs recebe r ão máquinas para participar deste projeto, tornando- se redirecionadores de tráfego multicast confiável das aplicações citadas anteriormente. Possibilidade de novos serviço s : com o multicast confiável implantado, a RNP pode oferecer novos serviços na rede, e as possibilidades são diversas, abrangendo quaisque r necessidad e s para transmissão de arquivos um para muitos de form a confiável. Public a ç ã o de artigo s em periódi c o s : o projeto visa a implantaç ã o de multicast confiável na RNP, porém, espera- se que os resultados traga m contribuições à comunidade científic a, que ser ão divulga d a s na form a de artigos. 4 Transferência de Tecnologia Os protoc olos implan t a d o s são públicos, e sua utilizaç ã o vai estar detalha d a na forma de manuais de usuário. Cada protocolo vai possuir um manual contendo a metodologia de instalaç ão, bem como suas vantagens, desvant a g e n s e aplicações preferenciais. Além disso, vai ficar disponível em diver s o s PoPs da rede RNP toda a infra- estrutura de multicast confiável montada, pronta para utilizaç ã o futur a.
5 Resumo: Atendimen to desta Proposta aos Critérios de Seleção Estabelecidos O Edital estabelece um conjunto de critérios de avaliação das propostas de GTs, os quais acreditamos serem plenam ente atendidos por esta: resultados e impactos esperados: estrutura de software instalada e devidam e n t e configura d a, manuais e relatórios; aplicabilidade dos resultados na RNP: trat a- se de disponi biliza r ferram e nt a s e recomendações de uso. O estudo refere -se à RNP, com sua infra- estrutura e suporte a roteamento multicast; colaboração internacional: o vice- coord e n a d o r se encon t r a em pós- doutora do na Inglaterra, executando projeto com objetivos bastant e similares, aplicado na SuperJANET (rede de alta velocid a d e do Reino Unido); grau de inovação tecnológica: embora exista bastante literatura sobre protocolos multicast e mecanis mos escaláveis, pouco ainda se conhece sobre o funcionam e nto destes protocolos e supõ e -se que protocolos multic a s t confiável deve r ã o ser aperfeiçoados nos próximos anos (consider e, por exemplo, a evoluç ã o sofrid a pelo TCP após sua popula riz a ç ã o); abrangência da proposta: os objetivos e met a s dest a propos t a estã o bem claros e pode m ser atingido s atr a v é s da metodologia indicada, seguindo -se as quatro etapas definidas. viabilidade técnica: o objetivos são cabíveis dent r o dos prazos estipul a d o s e a dime n s ã o da equip e (além disso, existe experiência similar já em andam e n to, como descrito na colaboração internacional); realizações e competência do grupo no tema ou área estratégica: ambo s coordenador e s possue m larga experiência na área proposta, protocolos multicast, como pode ser claramente notado nos CVs dos mesmos; estratégias de apropriação dos resultados a serem obtidos pela RNP: manutenção dos equipamentos instalados nos PoPs, devidam e n t e configura dos, com distribuição do software relacionado a usuários finais, divulgação de manuais e instruções em sites. 6 Cronogra m a de Execução O cronogra m a e os objetos entregáveis são fixos, conforme consta no edital. Portanto, transcreveu -se o que consta no edital a
seguir. O GT compromete- se a entrega r os objetos solicitados nas datas combinadas. Data Descri ç ã o 30/09/2004 Relatório de progresso bimestral Relatório de progresso bimestral. 30/11/2004 Documento de Diagnóstico e Alternativas: termo de referência, objetivos estratégicos, contornos, pré- requisitos, inventários, aplicações, etc Relatório de progresso bimestral. 31/01/2005 Documento de Projeto Piloto: arquitetur a, req uisitos de hw/s w, protocolos, desc riç ã o dos testes, resultados esperados, trata m e nto e anális e; Plano de Implantação: ação, atividades, tarefas, cronogra m a de implantação. 31/03/2005 Relatório de progresso bimestral. Maio / 2005 Divulgação no workshop RNP. Relatório de progresso bimestral. 31/05/2005 Plano de Implantação da Transferência de Tecnologia: ação, atividades, metodologia, tarefas, cronogra m a s, recursos, document a ç ão. Relatório de progresso bimestral. Documento de Avaliação do Piloto: descrição, resultados, problem as, soluções na 31/07/2005 implementação. Documento de Recomendações para Produção: arquitetura, requisitos de hw/sw, protocolos, descrição dos testes, resultados esperados, tratam e nto e análise. 7 ANEXO A: Curriculum Vitae Resumido do Coordenador Nom e : Valter Roesler roesler@exatas.unisinos.br, www.inf.unisinos.br/ ~ r o e sler Formação acadê m i c a: Dout orado : PPGC - UFRGS. Ênfase em Sistem as de Informação com Redes de Computadores concluído em 2003. Mestrad o : PPGC - UFRGS. Ênfase em Redes de Computadores concluído em 1994. Graduaç ã o : Engenharia Elétrica UFRGS concluído em 1988. CV Lattes resumido em anexo.
8 ANEXO B: Curriculum Vitae Resumido do Vice-Coordenador No m e : Marin h o Barc ellos (Antonio Marin h o Pilla Barcellos) marinho@exatas.unisinos.br, marinho.barcellos@man.ac.uk, www.inf.unisinos.br/ ~ m a r i n ho Formação acadê m i c a: Dout orado : University of Newcastle upon Tyne concluído em 1998. Mestrad o : PPGC UFRGS concluído em 1993. Graduaç ã o : Ciência da Computaç ão UFRGS concluído em 1989. CV Lattes resumido em anexo.