Arquitecturas de Rede. para oferta de serviços de Vídeo a Pedido e IPTV. Engenharia de Redes de Comunicações

Transcrição

1 Arquitecturas de Rede para oferta de serviços de Vídeo a Pedido e IPTV Diogo Miguel Mateus Farinha Dissertação para obtenção do Grau de Mestre em Engenharia de Redes de Comunicações Júri Presidente: Professor Doutor Luís Eduardo Rodrigues Orientador: Professora Doutora Teresa Maria Sá Ferreira Vazão Vasques Professor Doutor Rodrigo Seromenho Miragaia Rodrigues Vogal: Professor Doutor Luís Manuel Antunes Veiga Novembro de 2008 I

2 Resumo O IPTV e o vídeo a pedido apresentam-se nos dias que correm como os dois serviços mais promissores e capaz de ajudar os operadores a suportar a perda de lucro do mercado de telefone fixo. Apesar da digitalização de vídeo já existir há muito tempo, as redes existentes até agora tornavam inviável o fornecimento deste tipo de serviços. No entanto, com os grandes avanços quer em termos de codificação quer em termos de redes, estes passaram a poder ser oferecidos aos clientes. O problema, principalmente com o serviço de vídeo a pedido, passa pela forma como este será fornecido aos clientes. Um sistema real de vídeo a pedido, onde cada cliente pode ver o que quiser e quando quiser pode necessitar de uma quantidade de largura de banda da rede extremamente elevada. É neste contexto que surgem soluções de descentralização por parte dos operadores de forma a dotarem a sua rede de maior escalabilidade. No âmbito deste trabalho irá ser proposta uma arquitectura de organização dos servidores de vídeo baseada em modelo peer-to-peer estruturados. Irá ser desenvolvido um protótipo de uma arquitectura que irá ser testada num simulador de redes em conjunto com a solução proposta pelo operador. De acordo com estas simulações serão apresentadas as conclusões a que este trabalho chegou. Palavras-chave: IPTV, Vídeo a Pedido, Arquitecturas de Rede, Peer-to-Peer, Simulação II

3 Abstract IPTV and Video on Demand are, nowadays two promissory services, capable to help the operators to support the lost of profit of the fix phone market. Although the video digitalization isn t recent, the existent networks weren t reliable to support this kind of services. Beside this, with the great advance in technology, concerning the codifications and the networks, these services become attractive to operators and clients. The major problem of the Video on Demand is about the way it can be delivered to the clients. A real system of Video on Demand, where which client can watch the wanted video and whenever he wants, needs a large band of network. At this precisely context, operators try to present some distributed solutions to make their networks more scalable. This work proposes a new architecture to organize video servers in the network, based on the peer-to-peer structure model. It will be developed a prototype of an architecture that will be tested in a network simulator, as well as the operator solution. After simulate the architectures mentioned above, conclusions will be presented. Key-words: IPTV, Video on Demand, architectures of networks, Peer-to-Peer, simulation III

4 Agradecimentos A conclusão deste trabalho não seria possível sem a colaboração de várias pessoas. Em primeiro lugar agradeço à professora Teresa Vazão pela confiança depositada em mim desde o inicio, pelo incentivo e motivação durante todo o trabalho. Tentou sempre auxiliar-me procurando sempre me guiar. Agradeço também ao professor Rodrigo Miragaia Rodrigues que apesar de geograficamente distante tentou sempre me auxiliar quando precisei. Quero também deixar uma palavra de apresso por todos os elementos do grupo de Redes do INESC, ao Laércio Cruvínel pela orientação com o simulador de redes, ao Ricardo Pereira pelos brainstormings e ideias resultantes que contribuíram para melhorar o trabalho. Aos colegas e amigos de faculdade pelo apoio, companheirismo e amizade ao longo do curso, André Claro, Carlos André, Eduardo Batista, Luís Santos, João Matos, e a todos os outros elementos do grupo INESC e de curso. A todos os outros amigos e pessoas fora da faculdade, que também me ajudaram ao longo destes últimos anos. Á Joana pelo apoio e revisões na complicada fase final de conclusão do trabalho. Aos meus pais, irmão, avós pelo apoio incondicional e ensinamentos, mesmo nos meus piores momentos, sem os quais não teria chegado a este ponto. Por fim queria deixar um agradecimento ao Engenheiro José Brás da Portugal Telecom pela colaboração e informações preciosas na realização desta tese. IV

5 Índice Resumo... I Abstract... III Agradecimentos... IV Lista de Tabelas... VIII Lista de Figuras... VIII Lista de Abreviaturas... XII 1 Introdução Televisão IP (IPTV) Evolução da oferta de serviços multimédia em Redes IP Problemas no Fornecimento dos Serviços Arquitectura Genérica para Distribuição dos Serviços Objectivos da tese Estrutura do relatório Estado da Arte Soluções Centralizadas Redes de Distribuição de Conteúdos Introdução Arquitectura CDN Distribuição de Réplicas Encaminhamento de Pedidos Pedidos de Serviço Multicasting One-to-all unicast Application-level multicast Explicit multicasting Internet Group Management Protocol Encaminhamento Multicast Avaliação das soluções centralizadas Soluções Distribuídas V

6 2.2.1 Redes Peer-to-Peer Estruturadas e não Estruturadas Arquitectura Genérica Plaxton Tapestry Pastry Chord Content Addressable Network Kademlia Viceroy Avaliação das Várias topologias Peer-to-Peer Métricas de Avaliação de Serviço Síntese de Avaliação dos Modelos Estudados Arquitectura do Sistema Objectivos e Requisitos Rede do Operador Arquitecturas de Rede Introdução Centralizada Distribuída Protótipo da Rede Componentes do Sistema Introdução Visão Geral Simulador Módulo de Gestão dos Servidores de Vídeo Cache/Storage Simulação de Clientes Módulo Gerador de Tráfego Simulador Introdução VI

7 3.5.2 OPNET NS SSFNet J-Sim Comparação dos Simuladores Simulador Escolhido Configuração da Rede Métricas de Avaliação Testes e Resultados Cenários de Testes Resultados Conclusões Trabalho futuro Referências Anexos VII

8 Lista de Tabelas Tabela 2-1 Comparação entre as várias topologias P2P [21]...35 Lista de Figuras Figura 1-1 Arquitectura genérica para distribuição de serviços Figura 2-1 Topologia de Rede de Distribuição de Conteúdos [6] Figura 2-2 Arquitectura com Componentes de uma CDN [5] Figura 2-3 One-to-all unicast [16] Figura 2-4 Application-level multicast [16] Figura 2-5 Explicit multicasting [16] Figura 2-6 Topologia de uma Rede de Distribuição de Conteúdos P2P [6] Figura 3-1 Arquitectura genérica do operador de telecomunicações para o fornecimento dos serviços de vídeo Figura 3-2 Arquitectura após a primeira fase de descentralização Figura 3-3 Última fase de descentralização com a instalação de servidores no nível SR Figura 3-4 Esquema do funcionamento da solução centralizada ao nível de SR1 e SR Figura 3-5 Esquema do funcionamento da solução distribuída ao nível de SR1 e SR Figura 3-6 Esquema do espaço de identificadores para servidores e vídeos na topologia Chord Figura 3-7 Parcela da rede com um conjunto de servidores ao nível de SR2 que formam um grupo peer-to-peer Figura 3-8 Esquema do protótipo de rede Figura 3-9 Componentes genéricos do sistema desenvolvido e utilizado para a simulação das arquitecturas Figura 3-10 Esquema representando as probabilidades de existência de cada tipo de conteúdo de vídeo VIII

9 Figura 3-11 Esquema temporal representando os pedidos efectuados e duração dos streamings de vídeo durante um intervalo de tempo Figura 3-12 Gráfico com a percentagem de pedidos simultâneos ao longo de um dia Figura 4-1 Largura de Banda ocupada por um servidor individual sem os conteúdos mais populares previamente distribuidos, numa arquitectura centralizada Figura 4-2 Largura de Banda ocupada por um servidor individual sem os conteúdos mais populares previamente distribuídos, na primeira versão da arquitectura distribuída proposta Figura 4-3 Largura de Banda ocupada por um servidor individual sem os conteúdos mais populares previamente distribuídos, na segunda versão da arquitectura distribuída Figura 4-4 Largura de distribuídos ocupada por um servidor individual com os conteúdos mais populares previamente definidos, numa arquitectura centralizada Figura 4-5 Largura de Banda ocupada por um servidor individual sem os conteúdos mais populares, na primeira versão da arquitectura distribuída proposta Figura 4-6 Largura de banda ocupada por um servidor individual com os conteúdos mais populares, na segunda versão da arquitectura distribuída Figura 4-7 Largura de banda ocupada por um servidor SR1 de ligação entre o servidor analisado anteriormente e o core, sem os conteúdos, em arquitectura centralizada Figura 4-8 Largura de banda média utilizada no nível SR1 de rede, sem os conteúdos mais populares previamente distribuídos, numa arquitectura centralizada Figura 4-9 Largura de banda ocupada por servidor SR1 de ligação entre o servidor analisado anteriormente e o core, sem os conteúdos, na primeira versão da arquitectura distribuída Figura 4-10 Largura de banda média utilizada em SR1, sem os conteúdos, primeira versão da arquitectura distribuída Figura 4-11 Largura de banda ocupada por um servidor de SR1 de ligação do servidor analisado e o core, sem os conteúdos, na segunda versão da arquitectura distribuída Figura 4-12 Largura de banda média utilizada SR1, sem os conteúdos, na segunda versão da arquitectura distribuída Figura 4-13 Largura de banda ocupada por servidor SR1 de ligação entre o servidor analisado anteriormente e o core, com os conteúdos, numa arquitectura centralizada IX

10 Figura 4-14 Largura de banda média utilizada no nível SR1, com os conteúdos, numa arquitectura centralizada Figura 4-15 Largura de Banda ocupada por servidor SR1 de ligação entre o servidor analisado anteriormente e o core, com os conteúdos, na primeira versão da arquitectura distribuída Figura 4-16 Largura de banda média utilizada no nível SR1, com os conteúdos na primeira versão da arquitectura distribuída Figura 4-17 Largura de banda ocupada por um servidor SR1 de ligação entre o servidor analisado e o core, com os conteúdos na segunda versão da arquitectura distribuída Figura 4-18 Largura de banda média utilizada no nível SR1, com os conteúdos na segunda versão da arquitectura distribuída Figura 4-19 Utilização média do nível intermédio da rede, ou seja nível SR1, durante o período total dos 10 dias de simulação (240 horas) numa arquitectura centralizada Figura 4-20 Utilização média do nível intermédio da rede, ou seja nível SR1, durante o período total dos 10 dias de simulação (240 horas) numa arquitectura distribuída Figura 4-21 Largura de banda ocupada pelo servidor Core que agrega o servidor SR1 analisado anteriormente. Este teste é efectuado utilizando a arquitectura centralizada Figura 4-22 Largura de banda media utilizada no nível Core IP/MPLS da rede durante um dia de simulação (24 horas). Este teste é efectuado utilizando a arquitectura centralizada Figura 4-23 Largura de banda ocupada pelo servidor Core que agrega o servidor SR1 analisado anteriormente. Este teste é efectuado na primeira versão da arquitectura distribuída Figura 4-24 Largura de banda media utilizada no nível core IP/MPLS da rede durante um dia de simulação (24 horas) na primeira versão da arquitectura descentralizada Figura 4-25 Largura de banda ocupada pelo servidor core que agrega o servidor SR1 analisado anteriormente. Este teste é efectuado na segunda versão da arquitectura distribuída Figura 4-26 Largura de banda media utilizada no nível core IP/MPLS da rede durante um dia de simulação (24 horas) na segunda versão da arquitectura descentralizada Figura 4-27 Ocupação média do core IP/MPLS da rede durante o período total dos 10 dias de simulação (240 horas) numa arquitectura centralizada Figura 4-28 Ocupação média do core IP/MPLS da rede durante o período total dos 10 dias de simulação (240 horas) numa arquitectura distribuída Figura 4-29 Tempo médio de satisfação de pedidos durante o primeiro dia de simulação (24 horas), utilizando a arquitectura centralizada X

11 Figura 4-30 Tempo médio de satisfação de pedidos durante todo o período de simulação (240 horas), utilizando a arquitectura centralizada Figura 4-31 Tempo médio de satisfação de pedidos durante o primeiro dia de simulação (24 horas), utilizando a primeira versão da arquitectura distribuída Figura 4-32 Tempo médio de satisfação de pedidos durante todo o período de simulação (240 horas), utilizando a primeira versão arquitectura centralizada Figura 4-33 Tempo médio de satisfação de pedidos durante o primeiro dia de simulação (24 horas), utilizando a segunda versão da arquitectura distribuída Figura 4-34 Tempo médio de satisfação de pedidos durante todo o período de simulação (240 horas), utilizando a segunda versão arquitectura centralizada Figura 4-35 Distribuição percentual dos pedidos no tempo, numa arquitectura centralizada Figura 4-36 Distribuição percentual dos pedidos no tempo, na primeira versão da arquitectura distribuída Figura 4-37 Distribuição percentual dos pedidos no tempo, na segunda versão da arquitectura distribuída Figura 4-38 Percentagem de tempo médio de satisfação de pedidos Figura 4-39 Percentagem de utilização média de todos os servidores durante o período total de simulação, 10 dias (240 horas) Figura 4-40 Percentagem de utilização média de todos os servidores durante o período total de simulação, 10 dias (240 horas), apresentando apenas as 5 melhores soluções Figura 4-41 Percentagem de utilização média dos servidores de nível intermédio, SR1, durante o período total de simulação, 10 dias (240 horas) Figura 4-42 Percentagem de utilização média dos servidores de nível Core, durante o período total de simulação, 10 dias (240 horas) Figura 4-43 Percentagem de utilização média dos servidores de nível Core, durante o período total de simulação, 10 dias (240 horas), apresentando apenas as 5 melhores soluções XI

12 Lista de Abreviaturas IPTV IP Television VoIP voice over IP IP Internet Protocol ARPU Average Return Per User PCM Pulse Code Modulation ADSL Asymmetric Digital Subscriber Line VDSH Very-high-bit-rate Digital Subscriber Line FTTH Fiber To The Home/Building/Curb FTTB Fiber To The Building FTTC Fiber To The Curb VoD Video-on-Demand TVoD True Video-on-Demand NVoD Near Video-on-Demand DRM Digital Rights Management MPEG - Moving Picture Experts Group CDN Content Distribution Network URI Uniform Resource Identifier k-hst K-hierarchically well-separeted trees DNS Domains Name System HTTP HyperText Transfer Protocol IGMP Internet Group Management Protocol DVMRP - Distance Vector Multicast Routing Protocol DHT Distributed Hash Table CAN Content Addressable Network UDP User Datagram Protocol QoS Quality of Service QoE Quality of Experience STB Set-Top-Box CATV Cable Television XII

13 OpEx Operational Expenditure CapEx Capital Expenditure MPLS Multi Protocol Label Switching XIII

14 1 Introdução 1.1 Televisão IP (IPTV) Evolução da oferta de serviços multimédia em Redes IP A tecnologia de comunicação sobre datagramas IP já é utilizada há décadas. Desde o seu início que era possível a transmissão de dados, voz ou vídeo. No entanto, a capacidade das ligações instaladas não era compatível com os requisitos dos serviços associados à comunicação multimédia. Inicialmente, os operadores de cabo introduziram no seu leque de produtos de telecomunicações, produtos baseados na utilização do serviço de voz suportado na tecnologia Voz sobre IP (VoIP). A diferença de qualidade relativamente ao serviço telefónico convencional era compensada pelo custo inferior do serviço, motivado pela possibilidade de partilha de recursos e pela facilidade de operação e manutenção. Se se juntar a este serviço, o serviço de difusão de televisão e de acesso à Internet já oferecidos, constata-se que a concorrência entre os operadores de telecomunicações têm vindo a aumentar a um ritmo muito acelerado [1]. Para se conseguirem impor no mercado, os grandes operadores de telecomunicações necessitam assim de aumentar a variedade de produtos fornecidos, principalmente com a queda das receitas do serviço de voz. Estas estão assim na linha da frente para adoptar IPTV. Dado que hoje em dia os operadores de telecomunicações já oferecem serviços de acesso à internet sobre IP, a mudança dos clientes para IPTV apresenta-se como algo já esperado. Desta forma conseguem fidelizar o cliente, além de aumentar o seu Average Return Per User (ARPU), ou seja, o que o cliente paga por um dado conjunto de serviços [2][3]. A oferta de um maior conjunto de serviços vai conseguir rentabilizar ainda mais as estruturas de rede existentes, planeando ao mesmo tempo a rede do futuro. Oferecer um serviço de IPTV hoje em dia já não deve ser visto como uma mais-valia para o negócio, mas como uma obrigatoriedade face à concorrência por parte dos operadores de telecomunicações para se manterem competitivas. No entanto, só recentemente, com os avanços nas áreas de digitalização e técnicas de codificação, se tornou viável a transmissão de vídeo de grande dimensão através duma rede de comunicações baseada no protocolo IP. A transmissão de um pequeno vídeo através da tecnologia Pulse Code Modulation (PCM) terá um débito de centenas de Mbit/s, o que torna impossível a sua transmissão através das redes actuais. A recente utilização das técnicas de codificação associadas às normas MPEG-2/H.262 permite obter débitos bastante menores, que rondam os 2 ou 4 Mbit/s. Recentemente, com a introdução da norma MPEG-4 AVC/H.264 estes débitos podem ser ainda mais reduzidos, atingindo valores da ordem dos 1,5 a 2 Mbit/s. Paralelamente a estes desenvolvimentos, também a adopção de tecnologias de acesso de banda larga, com ADSL 2+, VDSH ou mesmo Fiber-To- 14

15 The-Home/Building/Curb (FTTx), permitiram que o serviço IPTV fosse finalmente viável de fornecer. Para complementar o serviço de IPTV os operadores também introduziram o serviço de Vídeo a Pedido (VoD) que se apresenta como uma das grandes oportunidades de negócio para os operadores de telecomunicações. 1.2 Problemas no Fornecimento dos Serviços O problema do fornecimento destes serviços, IPTV e VoD, não é um problema tecnológico, mas antes um problema económico. Se por um lado se pretende rentabilizar as infra-estruturas de rede existentes, parece claro, que estas num futuro próximo serão insuficientes para um adequado fornecimento do serviço para os clientes. O grande problema, e que tem preocupado os operadores, prende-se com arquitectar um sistema VoD que seja escalável. Com o aumento do número de clientes, a largura de banda necessária bem como o número de servidores, poderá aumentar para valores extremamente elevados caso a arquitectura não esteja pensada para proporcionar um serviço escalável. Mesmo com a utilização dos últimos métodos de compressão como MPEG-4, dado que cada cliente terá de ter recursos alocados para satisfazer os seus pedidos, a largura de banda ocupada será da ordem das centenas de Gbps [4]. Simultaneamente, também os níveis de qualidade de serviço sofrerão uma degradação se não se actualizar as actuais infra-estruturas. Portanto, o grande problema destes serviços está associado à sua distribuição, quando efectuada para um número muito elevado de clientes. A questão essencial que se coloca é identificar em que medida se poderá efectuar a distribuição dos mesmos, tendo em conta que este sistema tem de ser escalável, mas ao mesmo tempo não completamente disruptivo das redes actuais e com custos comportáveis. 1.3 Arquitectura Genérica para Distribuição dos Serviços Um serviço de IPTV é um serviço de natureza multicast, enquanto um serviço de VoD pretende ser um serviço de natureza unicast, onde cada cliente vê o vídeo que quer e quando quer. A arquitectura genérica para efectuar a distribuição dos conteúdos referidos é apresentada na figura seguinte. Nela encontram-se os principais componentes do sistema, bem como a sua localização na rede. 15

16 Figura 1-1 Arquitectura genérica para distribuição de serviços Os componentes mais relevantes desta arquitectura são os seguintes: Headend TV Infra-estrutura responsável por receber codificar e transmitir os canais televisão. Middleware Elemento responsável pela integração dos vários componentes, pela gestão de conteúdos e serviços, reporting e ligação aos sistemas de billing e provisioning. Digital Rights Management (DRM) Elemento responsável pela encriptação de conteúdos e gestão do acesso condicionado a estes. VoD Servers Servidores de vídeo organizados segundo uma determinada arquitectura para armazenar e transmitir os vídeos pedidos pelos clientes. Set-top-Boxes (STB) Módulo terminal do cliente, responsável por efectuar a interface com a rede, descodificando DRM e MPEG. Os servidores de vídeo podem ser colocados em várias localizações na rede, de acordo com o tipo de arquitectura pretendida. Numa arquitectura centralizada serão colocados no headend, ao passo que numa arquitectura mais distribuída serão colocados mais próximo do cliente. Apesar da grande generalidade das soluções instaladas pelos operadores de telecomunicações se basearem fortemente em arquitecturas centralizadas, o crescente aumento do volume de tráfego e do número de clientes, conduz ao estudo de soluções alternativas, suportadas em modelos de distribuição mais distribuídos, com um nível de sofisticação superior. 16

17 A instalação de novas arquitecturas mais sofisticadas visa resolver estes problemas, aumentando consequentemente o nível de investimento. É portanto necessário proceder a uma análise do trade-off entre os custos de uma nova infra-estrutura e os ganhos que advenham dela. 1.4 Objectivos da tese O objectivo da presente tese é o estudo de soluções de localização de conteúdos alternativas à solução centralizada. No seu âmbito serão estudados os vários tipos de soluções centralizadas e descentralizadas, nomeadamente a nível de Redes de Distribuição de Conteúdos (CDN), multicasting e arquitecturas P2P. As principais contribuições da tese são assim: Estudo das várias arquitecturas existentes para o fornecimento dos serviços de vídeo; Avaliação da arquitectura que, genericamente os operadores de telecomunicações adoptam; Desenvolvimento de uma nova arquitectura baseada em arquitecturas distribuídas P2P e adaptada à rede existente do operador; Avaliação desta arquitectura, simulando-a num protótipo da rede de um operador de telecomunicações; 1.5 Estrutura do relatório O presente relatório está estruturado em 5 capítulos e 9 anexos. No capítulo 1 é efectuada uma introdução ao tema sobre o qual o trabalho é desenvolvido. No segundo capítulo é apresentado um estudo a arquitecturas possíveis para o fornecimento dos serviço de IPTV e VoD. São efectuadas comparações e avaliações a todas estas arquitecturas. A arquitectura da solução proposta neste trabalho de tese é apresentada no capítulo 3. Também neste capítulo é detalhada a implementação desta solução abordando também os simuladores de rede. Os testes realizados bem como os resultados são apresentados no capítulo 4. Por fim é apresentada uma conclusão em relação ao testes realizados, enquadrando-os com os objectivos propostos neste relatório. 17

18 2 Estado da Arte Vai ser efectuado um estudo com o objectivo de identificar vários tipos de soluções para o fornecimento dos serviços IPTV e VoD. 2.1 Soluções Centralizadas Dentro das soluções centralizadas para efectuar distribuição de conteúdos podem-se ter várias abordagens. Serão tratadas nas secções seguintes as CDN, bem como a utilização de multicasting para o fornecimento dos serviços. Existem dentro destas soluções vários aspectos a ter em conta, que serão abordados neste capítulo. Por fim será efectuada uma avaliação final a estas soluções, concluindo sobre a sua utilidade e capacidades para o fornecimento de serviços de vídeo Redes de Distribuição de Conteúdos Introdução As Redes de Distribuição de Conteúdos já são utilizadas há vários anos na Internet para distribuição de conteúdos de diversas naturezas, tendo como objectivo reduzir o tempo de aquisição/visualização dos mesmos por parte dos utilizadores finais [5]. Neste tipo de soluções, opta-se por colocar estrategicamente vários servidores na rede, passando a fornecer, aos clientes, os conteúdos a partir destes. Este cenário encontra-se ilustrado na Figura 2-1. Conforme se pode constatar, numa CDN existe um ou mais Servidores Fonte, onde estão inicialmente alojados os conteúdos. Estes conteúdos são posteriormente replicados para os Servidores Réplica da CDN, sendo os pedidos dos Clientes satisfeitos a partir dos Servidores Réplica e não dos Servidores Fonte. Figura 2-1 Topologia de Rede de Distribuição de Conteúdos [6] 18

19 O fornecimento de conteúdos a partir de um único ponto central pode apresentar vários problemas de escalabilidade e de desempenho, sendo também um único ponto de falha no sistema. Ao nível das CDN podem-se ter diferentes implementações dependendo do tipo de problema. A arquitectura de uma CDN pode variar dependendo nomeadamente do nível de recursos, do número de clientes bem como dos conteúdos a disponibilizar Arquitectura CDN Na arquitectura geral de uma CDN, representada na Figura 2-2, os principais componentes são: servidores fonte, sistema de distribuição de conteúdos, sistema de encaminhamento de pedidos, servidores réplica e os clientes finais. Figura 2-2 Arquitectura com os componentes de uma CDN, e a sequência de comunicação entre estes. [5] Distribuição de Réplicas O objectivo dos algoritmos de colocação de réplicas é detectar a melhor localização na rede para a colocação das réplicas [7]. Esta localização vai depender dos objectivos pretendidos, como sejam: minimização da latência média de acesso aos conteúdos por parte dos clientes, a taxa de pedidos a que o servidor fica sujeito, a minimização da largura de banda da rede consumida para transferir os conteúdos para os clientes, e o número de servidores réplica a colocar. A distribuição de réplicas pode ser abordada segundo duas vertentes: a distribuição de servidores réplica e a distribuição de conteúdo réplicas. A distribuição de servidores réplica pretende detectar a melhor localização para os servidores, enquanto a distribuição de conteúdos réplica preocupa-se em escolher o melhor servidor réplica para a colocação do objecto réplica. Para um operador rentabilizar os seus investimentos é de extrema importância conseguir efectuar a melhor distribuição possível tendo em conta os objectivos pretendidos. 19

20 Distribuição Réplicas de Servidores O problema de colocação de servidores réplica prende-se com a selecção de K localizações de entre as N possíveis para colocação dos servidores. Estas localizações pretendem optimizar para uma dada topologia de rede e número de clientes, parâmetros como latências, ou o custo total da infra-estrutura a colocar [8]. Para solucionar o problema descrito foram propostas duas abordagens teóricas [7], Minimum K-center Problem, e k-hierarchically well-separeted trees (k-hst). Estas abordagens modelam o problema de distribuição de servidores como o problema de colocação ao centro, sendo que neste modelo se pretende seleccionar um conjunto de centros que minimizem a distância máxima entre os nós e os centros seleccionados. O algoritmo k-hst [9] resolve o problema de colocação de servidores réplica recorrendo à teoria dos grafos. Neste modelo, a rede é representada como um grafo G (V, E), onde V é o conjunto de nós da mesma e E V x V representa o conjunto de ligações entre os nós. O algoritmo recorre à construção de árvores entre os nós da rede existentes no grafo, procedendo em cada árvore à escolha da localização para o servidor réplica. O algoritmo Minimum K-center Problem [9] é um problema NP-completo que pretende selecionar um conjunto mínimo de localizações para a colocação dos servidores réplica na rede. Dado que as abordagens teóricas se apresentam com um nível de complexidade computacional elevada, foram desenvolvidas algumas heurísticas como Greedy replica placemente [10], Topology-informed placement strategy [11], Hot Spot [12], Tree-based [13] e Scalable Replica Placement [14]. Estas abordagens têm em conta as informações existentes da rede, tais como padrões de tráfego e possíveis locais para colocação das réplicas. Com várias informações da rede conseguem-se soluções adequadas com um custo computacional menor. No algoritmo de greedy replica placement escolhem-se M servidores entre um N possíveis localizações. Para tal, considera-se o custo de acesso, por parte dos clientes, associado a cada uma das possíveis localizações. Escolhe-se o conjunto de localizações com os menores custos. Na iteração seguinte procede-se da mesma forma até que se alcance um conjunto de M localizações tal como pretendido. O problema desta abordagem prende-se com o facto de ser necessária muita informação sobre a localização dos clientes e custos de acesso aos locais. No algoritmo Topology-informed placement strategy, os servidores são colocados em localizações candidatas ordenadas decrescentemente por número de nós ligados a essa localização. Pressupõem-se que quanto mais nós estiverem ligados a esse local, mais rapidamente se consegue alcançar um maior número de nós. No algoritmo Hot-Spot os servidores réplica são colocados perto dos clientes que gerem um maior volume de tráfego. As N potenciais localizações são ordenadas de acordo com o volume de tráfego gerado na sua vizinhança, sendo que são escolhidas as M com maior volume. 20

21 O algoritmo de colocação de servidores réplica Tree-based assume que as topologias subjacentes são árvores. O problema é depois modelado como um problema dinâmico de programação. Nesta abordagem, uma árvore T é dividida em árvores menores T i, onde t = i t i. Scalable Replica Placement, consiste numa Framework escalável de gestão de réplicas. Esta minimiza o número de réplicas necessárias ao mesmo tempo que tem em conta as restrições ao nível de latência máxima dos clientes bem como da capacidade máxima dos servidores. Distribuição de Réplicas de Objectos O problema da distribuição de objectos envolve a selecção de um conjunto K de um total de N servidores réplica, onde um dado objecto deve ser alojado de forma a optimizar os acessos dos clientes, bem como a actualização de conteúdos nas réplicas. Tal como o problema de colocação de servidores réplica, também podemos modelar a colocação de objectos réplica como um problema de colocação ao centro. No entanto, perante a complexidade dos algoritmos em que se baseia este modelo, existem algumas heurísticas que permitem obter aproximações à melhor solução reduzindo grandemente o nível de complexidade. Alguns autores [15], modelaram o problema de colocação de conteúdo como um problema de optimização. O problema passa, mais uma vez, por seleccionar e colocar K réplicas de um objecto em N possíveis servidores, minimizando o número de saltos entre os nós da rede para que o pedido seja servido. Este problema é NP-completo, e foram propostas três heurísticas para a sua solução. A primeira heurística, popularity, baseia-se na popularidade de um determinado objecto como único critério para que cada servidor decida se um determinado objecto deve ser ou não armazenado. A segunda heurística, greedy-single, utiliza uma função de custo definida como o produto entre a popularidade de um dado objecto e a distância do servidor réplica em questão ao servidor original do conteúdo. O objectivo é serem armazenados os conteúdos que sejam mais populares e que estejam mais longe do servidor, tentando minimizar a latência do cliente. Esta heurística pretende minimizar a distância das réplicas ao servidor original, não contanto no entanto com a presença da mesma réplica em outros servidores. Para ultrapassar esta limitação uma terceira heurística, greedy-global, utiliza uma estratégia de replicação coordenada, onde a localização das réplicas é decidida de forma global e coordenada para todos os objectos. Esta heurística utiliza uma função de custo que passa por efectuar o produto entre a taxa total de pedidos de um servidor, a popularidade e a distância entre o servidor a uma cópia do objecto (não tem de ser do servidor original). É então escolhido para cada objecto o servidor réplica que minimiza a função de custo. O autor, utilizando um conjunto de simulações prova que esta heurística é a que apresenta melhor desempenho apesar de ser a mais complexa de utilizar. 21

22 Actualização de Objectos nos Servidores Réplicas A actualização dos conteúdos para os servidores réplica pode ser efectuada considerando três abordagens, cooperative push-based, non-cooperative pull-based e cooperative pull-based [7]. Na primeira abordagem, cooperative push-based os conteúdos são antecipadamente replicados para os servidores réplica. Estes colaboram entre si para reduzir os custos de replicação, nomeadamente colaborando no pedido de réplicas. Neste esquema a CDN mantém a informação sobre a localização dos servidores réplica e dos conteúdos disponibilizados. Os pedidos recebidos são encaminhados para o servidor mais próximo do cliente, ou caso o objecto não exista, para o servidor original. É utilizada uma estratégia heurística greedy-global [15] entre todos os servidores, para decidir sobre a replicação de conteúdos. Na segunda abordagem, non-cooperative pull-based os pedidos dos clientes são directamente reencaminhados para o servidor réplica mais próximo. Se neste servidor não estiver disponível o conteúdo pretendido, então este efectua um pedido ao servidor original para este conteúdo, servindo depois o pedido do cliente. Nesta abordagem nem sempre o melhor servidor réplica pode ser escolhido, podendo, por exemplo, existir um servidor réplica na vizinhança com o conteúdo e portanto não existiria a necessidade de efectuar um pedido ao servidor original. A terceira abordagem, cooperative pull-based, difere da segunda na medida em que existe cooperação entre os servidores réplica. Quando existe um pedido de um cliente, este é redireccionado por Domain Name System (DNS) para o servidor réplica mais próximo. Caso este não disponha do conteúdo pretendido, procura nos restantes servidores réplica por este conteúdo e armazena-o. Pretende-se evitar assim o recurso ao servidor original, o que além de aumento da latência, consumiria largura de banda desnecessária na rede Encaminhamento de Pedidos O sistema de encaminhamentos de pedidos pretende seleccionar, de entre os servidores réplica da CDN que disponibilizem os conteúdos requeridos pelo utilizador final, o mais adequado para satisfazer este pedido. Para tal devem-se ter em conta os seguintes aspectos: Determinar a distância entre o utilizador final que efectua o pedido e os servidores. Normalmente consideram-se métricas como o número de hops, (ou seja, número de nós que um pacote percorre desde o servidor até ao cliente) ou o tempo de ida e volta (isto é, o tempo que decorre entre o cliente efectuar o pedido ao servidor e receber a respectiva resposta, designado por RTT Round Trip Time). As ferramentas ping e traceroute são geralmente utilizadas para calcular as métricas anteriores. No entanto, nenhuma das duas pode ser considerada uma medida totalmente precisa para cálculo da distância. O número de hops não considera o nível de tráfego na rede, e portanto um servidor a menos hops pode não ser o mais adequado ao contrário do que acontece quando se considera por esta métrica. O RTT é altamente variável também, por exemplo em função do tráfego na rede [5]. 22

23 Determinar a disponibilidade de um servidor: Um dado servidor apesar de dispor do conteúdo pretendido, pode estar a servir um número elevado de pedidos e portanto não ter disponibilidade para servir um novo pedido. As principais técnicas para determinar o nível de carga de um servidor são server push e client probe. Na primeira o servidor propaga a informação de carga para o sistema de encaminhamento de pedidos. Na segunda, o sistema de encaminhamento efectua pedidos para detectar o nível de carga dos servidores [5] Pedidos de Serviço Quando um cliente efectua o pedido de um conteúdo existem duas fases necessárias para que esse pedido seja satisfeito. Em primeiro lugar é necessário localizar o servidor réplica que melhor pode servir o cliente. Esta escolha pode ser efectuada com base em vários factores como o nível de carga do servidor, a latência do cliente e distância. A informação respeitante à localização dos servidores pode ser adquirida de forma reactiva ou pro-reactiva. Na primeira, a informação é disponibilizada depois de um pedido do cliente e na segunda pretende-se que a informação seja disponibilizada antecipadamente antes de qualquer pedido do cliente. Outro aspecto importante quando à localização de servidores prende-se com o suporte da camada de encaminhamento da rede ou apenas da camada de aplicação. Para reencaminhar o pedido do cliente para o servidor escolhido anteriormente são utilizadas várias técnicas [7] como o redireccionamento por HyperText Transfer Protocol (HTTP), por DNS, ou ainda Anycasting Multicasting O Multicasting é uma técnica muito utilizada no fornecimento de IPTV e serve para transferir informação multimédia na rede, de forma eficiente, de um emissor para um grupo de receptores. Quando um cliente selecciona um canal existe um streaming de informação entre o headend e o STB do cliente. A utilização de multicasting permite limitar os fluxos de informação a circular na rede, colocando apenas uma cópia de cada pacote a circular nos troços de caminho que são partilhados. Quando os caminhos para os clientes foram distintos a partir de um dado elemento de rede, os pacotes são então enviados para ambos. Ou seja, a partir deste ponto temos dois streamings, mas no restante caminho desde o headend até a este elemento de rede, reduzimos para metade a largura de banda utilizada para este streaming. Se se multiplicar esta situação por centenas ou milhares de clientes verifica-se que existe uma poupança de largura de banda elevadíssima. De um ponto de vista da rede, existem três possibilidades de implementar o multicasting: One-to-all unicast, Application-level multicasting e Explicit multicasting [16] One-to-all unicast Esta abordagem implementa one-sender-to-many-receiver multicast, utilizando comunicações unicasting. Ou seja, não requer qualquer suporte por parte da rede para implementar este nível de abstracção de multicast. Utilizando esta técnica é possível 23

24 implementar multicasting, efectuando o envio de um streaming unicast do emissor para cada um dos receptores (Figura 2-3). Os routers da rede encontram-se a cinzento indicando que não têm qualquer intervenção ao nível de multicasting na comunicação. Figura 2-3 One-to-all unicast. [16] Application-level multicast Esta técnica utiliza também transmissões unicast sendo que o receptor após receber o pacote de dados efectua a sua retransmissão. Desta forma o emissor efectua o streaming unicast para apenas um pequeno número de receptores. Estes receptores após terem recebido o pacote efectuam a retransmissão para outros elementos do grupo, (Figura 2-4). Para que esta técnica seja possível é necessário que os receptores criem e mantenham uma topologia de rede sobresposta (overlay) distribuída, ao nível aplicacional, que permite que se saiba quais são os elementos que fazem parte do grupo a que os elementos devem enviar a informação. 24

25 Figura 2-4 Application-level multicast. [16] Existem três tipos de topologias de overlay para application-level multicast; Tree, Mesh-Tree e Embedded Structure [17]. Na topologia em Tree, os membros de um grupo organizam-se, sendo que cada grupo escolhe sempre um pai. Este pai liga-se a outro grupo e assim sucessivamente formando uma árvore. Além destas ligações, podem ser efectuadas também ligações de controlo, constituindo o plano de controlo responsável pelo controlo do envio dos pacotes de dados. A informação passa então a circular da raiz para as folhas das árvores. Esta abordagem tem como vantagem a sua simplicidade, no entanto, tem também alguns problemas. É necessário prevenir a existência de loops, por exemplo, o pai de um grupo ter como pai outro elemento desse mesmo grupo criando assim um ciclo. Além deste problema é necessário ter em conta que a fracturação da árvore, sendo que a falha de um nó pode implicar a falha de toda a árvore. A topologia Mesh-Tree envolve dois passos na criação de uma rede overlay. Em primeiro lugar os membros da rede distribuem-se e organizam-se numa rede formando o plano de controlo, designado de malha. Posteriormente a este primeiro passo, um protocolo de encaminhamento, por exemplo Distance Vector Multicast Routing Protocol (DVMRP) [18], percorre esta malha estabelecendo para cada um dos nós um único caminho. São construídas árvores de distribuição de conteúdos, tendo como raíz um dos nós constituintes da malha. Em relação à abordagem Tree, a abordagem Mesh-Tree é mais complexa, no entanto, evita o problema de loops, simplifica a gestão das árvores de distribuição de conteúdos, sendo ainda mais resistente a falhas. Numa Embedded Structure é criado um espaço virtual coordenado, sendo que a cada um dos nós da rede corresponde uma parte deste espaço. É atribuído a cada um dos nós da rede, um dado identificador/endereço lógico em função do espaço que ocupam. Os nós neste tipo de 25

26 topologia não armazenam toda a informação de encaminhamento, apenas a referente aos seus vizinhos, evitando assim o uso de protocolos como DVMRP. Desta forma consegue-se atingir um elevado nível de escalabilidade. No entanto, contrariamente às abordagens anteriores, podemos ter restrições em termos do relacionamento, e posteriormente no encaminhamento, entre os vários vizinhos o que pode penalizar a performance do sistema Explicit multicasting A terceira possibilidade de efectuar multicasting consiste em dotar explicitamente a rede de suporte para multicast. Nesta abordagem, é enviado apenas um streaming de dados do emissor. Este streaming é depois replicado num router da rede sempre que seja necessário enviar dados para mais do que uma ligação de saída deste, a fim de se efectuar o encaminhamento para os receptores. Pode-se observar esta técnica na (Figura 2-5), (os routers sombreados a azul indicam que estão activamente envolvidos no multicasting). Figura 2-5 Explicit multicasting. [16] Internet Group Management Protocol No caso de uma comunicação unicast, o endereço IP do destinatário é enviado no datagrama. No entanto para uma comunicação multicast, não é viável que estejam incluídos no datagrama os endereços IP de todos os destinatários. Neste caso existe um endereço IP para cada grupo multicast. Colocam-se algumas questões em relação à gestão destes grupos: como começa um grupo, como termina, como é escolhido o endereço do grupo, como se pode juntar alguém ao grupo, como se controlam os acessos ao grupo e como sai alguém do grupo. Para tratar destas questões é utilizado o protocolo Internet Group Management Protocol (IGMP) [16]. Este protocolo opera entre o utilizador final e o primeiro router a que este esteja ligado. Quando 26

27 um cliente pretende juntar-se a um grupo, informa este router. Todos os routers que estejam envolvidos no multicasting, e portanto estejam a correr o IGMP estão interligados entre si. Para coordenar todos os router multicast, de forma a que os datagramas multicast alcancem o seu destino, é necessária a utilização de algoritmos de encaminhamento multicast ao nível da rede tais como Distance Vector Multicast Routing Protocol (DVMRP) [18] Encaminhamento Multicast Para se conseguir interligar todos os routers multicast de forma a entregar correctamente os datagramas são utilizados algoritmos de encaminhamento multicast [16]. O objectivo destes algoritmos consiste em encontrar uma árvore de ligações entre os vários routers que tenham utilizadores finais multicast ligados a eles. Podem fazer parte desta árvore routers que não sejam multicast desde que estejam a interligar outros routers multicast. Os pacotes multicast são depois encaminhados através desta árvore, desde o emissor até todos os receptores que fazem parte do grupo. Foram adoptadas duas abordagens para determinar as árvores de encaminhamento multicast, Group-Shared Tree e Source-Based Tree. Estas diferem no facto de num caso ser utilizada apenas uma árvore para distribuir os conteúdos de todos os emissores do grupo, enquanto no outro é construída uma árvore para cada um dos emissores. Na primeira abordagem, Group-Shared Tree, é definida uma árvore de encaminhamento para todo o grupo. Os datagramas de todos os emissores deste grupo são enviados segundo esta árvore. O problema neste caso baseia-se apenas na escolha da melhor forma de interligar todos os routers multicast. Uma forma de escolher quais as melhores ligações para encaminhamento consiste em atribuir custos para todas as ligações da rede, e escolher aquelas com menor custo. No entanto esta forma apresenta-se pouco exequível, pois seria necessário saber informação sobre toda a rede, além de que sempre que uma ligação mudasse de custo seria necessário executar o algoritmo de novo. Foi então definida uma alternativa para a construção da árvore de encaminhamento. Nessa alternativa é definida a entidade de um nó central, também conhecido como rendezvous point ou core. Na abordagem center-based, é identificado em primeiro lugar um nó central para o grupo. Todos os routers com clientes finais multicast ligados a si que pertençam ao grupo enviam mensagens unicast de join ao nó central, ou seja, mensagem para se juntarem ao grupo. Esta mensagem é encaminhada na rede até que alcance um nó que já faça parte do grupo, ou o nó central. De qualquer forma o caminho que esta seguir desde o router até ao grupo ou ao nó central passa a ser o caminho adoptado na árvore de encaminhamento, para alcançar esse router. Por outro lado, seguindo uma abordagem Source-Based Tree é construída uma árvore de encaminhamento para cada emissor do grupo multicast. Para tal, pode-se utilizar um algoritmo como o reverse path forwarding (RPF). Segundo este, quando um router recebe um pacote multicast, este encaminha-o para todas as suas saídas desde que o pacote tenha chegado pela ligação pertencente ao caminho mais curto desde este router até ao emissor. Caso o pacote multicast tenha chegado por uma ligação que não pertença ao caminho mais curto até ao emissor, é descartado sem que seja transmitido para as outras saídas do router. Isto porque o 27

28 router sabe que já recebeu ou irá receber este pacote pela ligação que pertence ao caminho mais curto. Não é necessário ao router conhecer todo o caminho mais curto até ao emissor, apenas precisa de saber qual a ligação de entrada que faz parte do seu caminho até ao emissor. Emissores diferentes podem ter ligações de entrada diferentes no router. Dado que os pacotes multicast são enviados para todas as saídas do router pode acontecer o caso em que um dado router recebe pacotes para um grupo multicast, do qual não tem clientes finais multicast. Neste caso esse router envia uma mensagem de prune para o router que lhe enviou o pacote multicast, para que este não lhe envie mais pacotes multicast daquele grupo. Quando um router recebe pacotes de prune de todos os seus nós sucessores, também este pode enviar uma mensagem de prune para o nó precedente que lhe envia estas mensagens multicast Avaliação das soluções centralizadas As duas soluções analisadas neste capítulo, apesar de serem de natureza centralizada servem diferentes propósitos. Uma rede de distribuição de conteúdos pode ser utilizada para fornecer serviços de VoD, enquanto que o multicasting é apropriado para o fornecimento de serviços de IPTV. A utilização de multicasting para o fornecimento de VoD é de todo desapropriada pois num serviço VoD cada cliente vê o pretendido à hora pretendida, ou seja, é um serviço unicast. Por outro lado a utilização de uma rede de distribuição de conteúdos também não é uma solução eficiente para fornecer serviços de IPTV, pois os conteúdos são transmitidos em tempo real do headend. Em suma, o multicating apresenta-se como uma solução muito eficiente neste momento e totalmente adaptada à rede do operador para o fornecimento de serviços IPTV. As redes de distribuição de conteúdos podem ser boas soluções para o fornecimento de VoD no entanto existem outras alternativas tão válidas como esta. 2.2 Soluções Distribuídas Em sistemas de distribuição de conteúdos, as soluções centralizadas apresentam algumas limitações. Com o aumento do número de clientes, este tipo de redes apresenta problemas de desempenho, derivados da falta de escalabilidade. As redes P2P apresentam-se como alternativas às tradicionais arquitecturas cliente/servidor. Uma rede P2P é uma rede composta por um conjunto distribuído, heterogéneo, autónomo e dinâmico de pares que partilham entre si recursos como capacidade de armazenamento ou objectos [19]. Os participantes neste tipo de redes podem funcionar como clientes ou como servidores ao mesmo tempo, recebendo e enviando objectos. Além disso, podem ser acedidos directamente por outros nós da rede sem a necessidade de uma entidade intermédia. Neste trabalho considera-se que os pares constituintes da rede P2P são estáveis, pelo que aspectos relacionados com organização dos nós em termos de partida e chegada à rede não serão abordados. 28