wiki

Computer Networks - Future Internet Testbeds - Part I

Resumo

  • O crescimento da Internet em termos de número de dispositivos, o número de redes associadas a cada dispositivo e a mobilidade dos dispositivos e usuários tornam a operação e o gerenciamento da infraestrutura da rede um desafio muito complexo. Para resolver estes desafios, idéias e soluções inovadores devem ser testadas e avaliadas em ambientes de redes reais e não apenas em simulações ou configurações em laboratório.


  • OFELIA é um projeto europeu do FP7 e seu principal objetivo é endereçar estas questões pela construção e operação de testbeds para a Internet do Futuro com facilidades de multi-camada, multi-tecnologia e geografica distribuída, onde a própria rede é precisamente controlada e programada por pesquisadores usando a emergente tecnologia OpenFlow. Este artigo relata um trabalho feito na primeira metade do projeto, as lições aprendidas bem como as vantagens principais de usar o OFELIA para desenvolvimento e testes de novas idéias em rede.


  • Uma visão sobre os desafios enfrentados no projeto é apresentada, assim como a implementação de uma facilidade de testbed é descrita, sendo incluído nesta descrição, o software de gerenciamento OFELIA Control Framework TestBed. Em sequência, também são mostradas experiências operacionais recentes do projeto, desde que foi aberto para o público em geral, fornecendo 5 diferentes testbeds ou ilhas.


Introdução


  • Quarenta anos após seu nascimento, a Internet ainda mantém protocolos e assumpções de projeto do tempo quando computadores de grande porte eram interconectados por grossos cabos de cobre. O crescimento em termos de números de dispositivos, de número de redes conectadas a cada dispositivo e mobilidade de usuários e dispositivos tornou mais e mais complexa a atividade de operar redes e fornecer qualidade suficiente de experiência para o usuário. Durante os últimos dez anos tornou-se óbvio que seriam obrigatórias mudanças fundamentais nas redes de comunicação. Para endereçar estes requisitos, novas arquiteturas e protocolos para a Internet tem sido propostas em várias linhas de pesquisa, mas a introdução de uma nova arquitetura como a Recursive Inter-Network Architecture (RINA) [ 1 - Computer Networks ] ou Information-Centring Network (ICN) [ 2 - Computer Networks ] dentro da Internet atual é uma tarefa desafiadora, principalmente por três razões: Primeiro, novas soluções precisam seguir princípios de projeto que devem ser providas para serem geralmente válidas. Infraestrutura de rede física é tratada em um sentido amplo e não será movida ou trocada inteiramente; como consequência novas soluções devem tomar em conta parâmetros associados como atraso. Segundo, novas soluções devem trabalhar com tecnologias existentes ou tecnologias que estão despontando no horizonte, em outras palavras, o caminho de migração deve estar visível. Terceiro, soluções devem ser testadas em ambientes de redes reais e não apenas baseado em simulações. [ 3 - Computer Networks ]


  • Portanto, a validação em instalações experimentais é um aspecto importante no processo de desenvolvimento destes novos protocolos desde o conceito até a operação. Um processo típico de realização de um conceito pode ser visto na Fig. 1. O processo começa com a descrição do problema, seguido pela geração das idéias, espaço de soluções próprias e pelo desenvolvimento de algoritmos apropriados. Estes algoritmos são tipicamente solucionados posteriormente e potencialmente validados em uma facilidade experimental. Um aspecto importante é a retroalimentação da indústria para as comunidades e departamentos de pesquisa. Normalmente o que existe são alguns feedbacks apresentados para os problemas e parâmetros de entrada para simulações, mas limitado à orientação no projeto de uma plataforma de validação experimental.



Fig. 1. Comunicação restrita à pesquisa e sociedades industriais durante o ciclo de vida da inovação


Software Defined Networking e OpenFlow


  • Sofftware Defined-Networking (SDN) [ 4 - Computer Networks ] é uma abordagem promissora para desenhar caminhos de migração das tecnologias de rede existentes para novos conceitos e protocolos. O aspecto chave do SDN é a separação de dados e plano de controle. O controlador poderá estar sendo processado em um computador pessoal (PC) e os elementos do caminho de dados (classicamente, um switch Ethernet) precisarão ser menos complexos porque todas as decisões de encaminhamento serão feitas pelo controlador externalizado. Um controlador único pode ser agora conectado a múltiplos switches. formando um amplo comutador lógico. Isto permite otimizações na manipulação do trafego porque o controlador central sabe a topologia interna do domínio completo da rede. O protocolo OpenFlow é uma encarnação da visão SDN. Várias empresas já iniciaram a implantação de dispositivos OpenFlow [ 5 - Computer Networks ] [ 6 - Computer Networks ]. Um razoável conjunto de frameworks controladores já estão disponíveis, tanto de comunidades de pesquisa (NOX, POX, Floodlight, Beacon, etc) quanto de empresas comerciais (NEC, IBM ,etc). Em 2011, a Open Networking Foundation (ONF) [ 7 - Computer Networks ] assumiu a liderança no desenvolvimento do protocolo OpenFlow e a padronização deste mas também assumiu funções auxiliares como configuração e gerenciamento de dispositivos. A ONF também iniciou a certificação de produtos OpenFlow, organizando eventos de interoperabilidade e benchmarking de soluções OpenFlow. Mesmo com o OpenFlow/SDN tornando-se um forte candidato a resolver os problemas desenhados acima existe ainda um gap entre propostas teóricas e experiências práticas das implementações do OpenFlow.


  • Para superar o gap entre a pesquisa teórica de novas arquiteturas Internet/futuras aplicações e a integração prática das pessoas foi declarada como missão e motivação, a configuração do testbed OFELIA iniciado em Outubro de 2010. Denominado como OpenFlow in European Infrastructure and Applications, direciona, em uma linha, protocolos de rede e dispositivos e em outra novas aplicações com uma visão aperfeiçoada para que estruturas de redes subjacentes possam ser experimentadas usando um grande testbed pan-europeu. O testbed OFELIA [ 8 - Computer Networks ] é operacional e aberto, com um serviço de melhor esforço e gratuito, desde Agosto de 2011.

Projeto do testbed OFELIA


  • O projeto OFELIA foi iniciado para projetar um testbed pan-europeu que conecta testbeds individuais instalados pelos parceiros do projeto baseado em uma infraestrutura comum camada 2. Além disso, existe a intenção de que deve suportar experimentos multi-camadas e multi-tecnologias relacionados ao OpenFlow. O objetivo foi expor o OpenFlow como um núcleo de serviços do testbed, permitindo aos usuários precisamente e dinamicamente controlar a própria rede experimental L2 enquanto ao mesmo tempo se tenta limitar a capacidades do OpenFlow, o mímo possível.


  • Inicialmente, o testbed OFELIA foi projetado com cinco parceiros acadêmicos configurando testbeds individuais (chamados ilhas) dentro das suas instalações. A ilha original OFELIA inclui testbeds em iMinds, Unversidade de Bristol, ETHZ, i2CAT e TUB. O projeto de instalações foi extendido com três ilhas adicionais que tem sido configuradas pelos parceiros que foram incluídos no projeto em um estágio posterior através de um processo de Open Calls (Fig. 2). A tabela 1 mostra cada ilha especialista e suas capacidades tecnológicas.


Ilha Especialidades da experimentação
iMinds Hub central da instalação federada, emulação em larga escala, Parede virtual: 100x servidores interconectados, w-iLab.t:testbed sem fio consistindo de nós de sensores, NetFPGA farm: cartões 10Â NetFPGA 1G cards
U. de Bristol Hub nacional para comunidade óptica do Reino Unido, switches L2 e equipamento óptico, experimentos ópticos OpenFlow, Conectividade ao GEANT e JANET, conectividade com o Brasil e EUA via Internet2,
ETHZ Conexões ao OneLab e GENI, permite tráfego de pesquisa operacional em paralelo com o tráfego experimental, ingtegração do testbed OFELIA dentro do perímetro da rede do campus
i2CAT Switches L2 e equipamento óptico (Anel ROADM), conectividade com GEANT e RedIRIS e Brasil (via RedIRIS e RedClara), conectividade com testbed i2CAT’s EXPERIMENTA
TUB Integração do OpenFlow na rede do campus, testbed sem fio BOWL
Creat-Net Ilha distribuída amplamente na cidade baseada em switches L2 e NetFPGAs, usuários opt-in via tecnologias heterogêneas de acesso
CNIT Foco na rede centrada em informação


Tabela 1 - Especialiadades de experimentação por ilha


  • O projeto da instalação foi também desafiador com respeito à conectividade Layer 2 (L2) entre todas as ilhas, que tem sido realizado pela interconexão de testbeds através da ilha iMinds agindo como um hub L2. As ilhas são conectadas, via VPNs sobre a Internet ou via conectividade L2 GEANT nativa [ 9 - Computer Networks ].


  • O projeto de rede experimental OFELIA foi direcionado para oferecer uma diversificada e poderosa infraestrutura OpenFlow que permite experimentar uma rede multi-camada e multi-tecnologia. A infraestrutura básica comum em sequência para conduzir os experimentos no OFELIA, que é oferecida como um serviço para o pesquisador é a infraestrutura de rede OpenFlow Ethernet L2 compartilhada com hosts finais virtualizados. Com esta infraestrutura, uma configuração experimental de rede completa pode ser implantada. Esta configuração inclui hosts finais para estabelecer uma comunicação sobre a rede experimental OpenFlow e para implantar os controladores do experimento onde se pode programar o plano de encaminhamento da rede OpenFlow. Estas aplicações dos host finais são disponibilizadas pelos recursos de computação virtualizados em um Infrastructure as a Service (IaaS) como de costume. Computação física, real e também outros tipos de recursos podem ser também fornecidos por cada ilha individual em cooperação com o pesquisador para preencher as necessidades do experimento.


  • Como parte do projeto OFELIA, a Universidade de Bristol e a ADVA Optical Networking juntas estão se esforçando para providenciar dispositivos ópticos habilitados com OpenFlow na ilha OFELIA U. Bristol. Suporte a OpenFlow é habilitado nos ADVAs ROADM (Reconfigurable Optical Add Drop Multiplexers) que estão disponíveis na ilha Uiversity Of Bristol.


  • Para operar a rede experimental, OFELIA tem também duas redes out-of-band separadas: as redes de controle e de gerenciamento.



Fig. 2. Implantação da facilidade européia OFELIA FP7



  • Para habilitar o pesquisador a registrar-se na estrutura disponível, configurando seus experimentos, requisitando, configurando e liberando recursos, a instalação OFELIA fornece um software de orquestração dos experimentos ou um Framework de Controle, o OFELIA Control Framework (OCF) [ 10 - Computer Networks ], desenvolvido dentro do projeto.


  • Ase seções a seguir irão ilustrar o projeto de diferentes elementos do testbeb OFELIA em maiores detalhes.



Redes Experimentais OpenFlow



  • A rede experimental OFELIA é o núcleo de componentes do testbed OFELIA como se pode ver na Fig. 3. O núcleo da rede é projetado para oferecer um segmento Ethernet OpenFlow-enabled L2 nativo, diretamente conectado aos servidores em máquinas virtuais hosteadas (VMs). Em adição à infraestrutura básica, o testbed foi projetado para permitir a cada ilha oferecer recursos especializados pela conexão direta para a rede OpenFlow. Exemplos de tais recursos são o Virtual Wall [ 11 - Computer Networks ] e o w-iLab.t [ 12 - Computer Networks ] na ilha iMinds ou a infraestrutura BOWL [ 13 - Computer Networks ] no TUB. A tabela 1 mostra cada especialidade das ilhas em relação às capacidades das diversas redes experimentais.



Fig. 3. Topologias OFELIA experimental e rede de controle


  • Como princípio, a rede experimental OpneFlow é projetada para ser uma separação de recursos flexíveis, configurável e limpa sem limitar as capacidades de experimentação especialmente nos aspectos do OpenFlow do usuário OFELIA, Neste sentido, para se tirar o máximo proveito da infraestrutura, a maioria dos projetos de ilhas permite topologia virtual arbitrária pela conexão física de switches OpenFlow em uma topologia mesh parcial ou total e pela conexão de cada um dos hosts finais virtuais ou servidores para múltiplos switches.


  • Como muitos pesquisadores processam diferentes experimentos sobre o mesmo substrato testbed, interferências entre os recursos de rede utilizados é potencialmente possível. Portanto, os recursos associados com cada experimento devem ser propriamente isolados. Esta isolação é executada através do conceito de fatiamento (slicing) do testbed: fatias consistem de recurso que são explicitamente reservados para uso dos pesquisadores e a configuração associada a eles. Eles compõem a base principal dos experimentos processáveis e também encapsulam o estado dos experimentos (exemplo, iniciado, parado, etc).


  • Pelo projeto, o objetivo foi propiciar aos pesquisadores, flexibilidade suficiente para processar experimentos sem estarem limitados pelas práticas de fatiamento e particularmente no fatiamento da rede. Em uma rede OpenFlow, uma fatia pode ser definida como um subconjunto ou porção do tráfego, que a rede traz onde o controle, via protocolo OpenFlow, é dado para um certo controlador OpenFlow, Este conceito é geralmente referenciado como flowspace.


  • Várias estratégias de fatiamento da rede foram avaliadas para conseguir isolação de tráfego (slice) experimental, tal como fatiamento puro baseado em MAC, fatiamento baseado em VLANs e ainda alocações arbitrárias de flowspaces sob demanda. Os detalhes de implementação de fatiamento estão expostos na Seção 3.1.1.


Recursos de computação


  • Um dos objetivos deste projeto é fornecer recursos de computação como um serviço (IaaS) para pesquisadores, e em seguida, implementar aplicações em pontos finais e controladores OpenFlow. Os requisitos básicos deste serviço foram:
    • Sensibilidade da rede: Devido à natureza da experimentação dentro do OFELIA, a configuração da rede no plano de dados do equipamento é crítica, especialmente L2 (topologia, STP, ...). Diferente de outros testbeds, onde os recursos de computação (normalmente recursos de computação virtualizados ou máquinas virtuais ou VMs) exigem apenas conectividade L3, recursos de computação no OFELIA devem estar adequadas ao L2. A configuração da rede para recursos de computação poderiam não interferir com a experimentação e a informação da rede de equipamentos, tais como topologia física L2, devem estar explicitamente disponíveis para o pesquisador do OFELIA.
    • Escalabilidade: A implantação poderia ser suficientemente escalável para suportar o uso concorrente da infraestrutura sem afetar a experiência geral.
    • Custo: A solução adotada poderia ser eficiente em termos de custo, tanto CAPEX quanto OPEX. Em termos de custos operacionais, a solução poderia ser facilmente integrada com o Control Framework, para provisionamento automático e monitoramento de serviços de computação.
    • Desempenho: Embora não seja o principal requisito, desde que o serviço seja fornecido no padrão de melhor esforço, a solução poderia impactar tão pouco quanto possível o desempenho global dos recursos de computação, tanto em termos de potência de computação quanto de largura de banda da rede.


  • Dados os requisitos e as considerações expostas, foi decidido que o projeto da infraestrutura de computação deveria se basear em uma tecnologia de virtualização de computação. Um estudo inicial em 2010-2011 [ 14 - Computer Networks ] foi feito onde várias tecnologias, frameworks e ferramentas foram avaliadas para cada proposta. E foi consensado que inicialmente suportasse a VM baseada em XEN e que poderia ser implementada primeiro para a virtualização do servidor.


Redes de controle e gerenciamento



  • Para suportar a operação da rede experimental OpenFlow, duas rede out-of-band foram projetadas; a rede de controle e a de gerenciamento. A primeira, pelo projeto é destinada a apoiar e tornar acessíveis os diferentes serviços OFELIA, como o ponto de entrada para pesquisadores ao testbed, o acesso ao software de orquestração do testbed ou o acesso aos recursos dos experimentos (exemplo, máquina virtual) bem como outros serviços internos do OFELIA, como DNS. Em adição, a rede de controle poderia também estar conectada a outra ilha com infraestrutura local (exemplo, equipamento não OFELIA). Além disso, a rede de controle e as redes experimentais são projetadas para serem interconectadas entre ilhas e portanto a rede de controle é por projeto, roteada entre ilhas como mostrado na Fig. 3 (b). Serviços VPN da camada 3 foram desenhados para habilitar o acesso de pesquisadores a esta rede através da Internet.


  • Em contraste, a rede de gerenciamento é usada para configurar e manter a própria infraestrutura (isto é, alguma coisa que poderia ser protegida dos pesquisadores) e apenas disponível aos administradores da ilha. Não é esperado (ou não é permitido) que usuários OFELIA usem o gerenciamento de rede ou enviem tráfego sobre ela. Desde que a proposta é gerenciamento local, redes de gerenciamento de ilhas não precisam ser interconectadas como outras redes de gerenciamento de ilhas.


Adaptação do equipamento óptico ao OpenFlow


  • Esta seção destaca o projeto das extensões OpenFlow para equipamentos ópticos e suas integrações dentro do Control Framework. A Fig. 4. mostra a abordagem da integração na qual dispositivos de pacote circuito OpenFlow habilitado são controlados pelo controlador virtualizado de circuito extendido via um novo elemento chamado Optical FlowVisor [ 15 - Computer Networks ]. Ele assume que cada Network Element (NE) é representado como um switch óptico habilitado OpenFlow. A abordagem proposta utiliza OF Circuit Switching Extensions (v0.3) [ 16 - Computer Networks ]. em sequência para descrever aspectos de comutação dos circuitos do switch óptico. O controlador OF pode portanto gerenciar domínios de comutação de pacotes e circuitos e está apto a ver a topologia de rede óptica bem como as informações específicas da camada óptica, por exemplo, comprimentos de onda disponíveis na portas OF. O switch e o processo de descoberta da rede é então conseguido usando o protocolo OF extendido. Em outra frente, a alocação de recursos é conseguida usando um dos dois métodos a seguir: (a) OpenFlow com plano de controle GMPLS integrado e (b) uma pura abordagem OpenFlow.




Fig. 4. Comutação de circuitos unificado (óptico) e plano de controle de comutação de pacotes


  • O objetivo final da adaptação do equipamento óptico é a integração do Extended Optical FlowVisor dentro do OFELIA Control Framework, onde ele estará adequado tanto aos domínios do circuito quando dos pacotes. Isto irá exigir uma extensão das atuais APIs FlowVisor e o OpenFlow Aggregate Manager (AM) que por sua vez fará com que o equipamento óptico fique disponível através do Control Framework para os pesquisadores.


  • Os dispositivos ópticos habilitados OpenFlow estarão disponíveis a partir do Control Framework via um extended OpenFlow Aggregate Manager (AM). Um packet-Optical FlowVisor híbrido irá fatiar ambos os domínios para fornecer um susbtrato virtualizado para o usuário experimentar.


Projeto de Software: o OFELIA Control Framework



  • O OFELIA Control Framework (OCF) pode ser definido como um software de orquestração para a instalação OFELIA FP7. A principal proposta do framework é arbitrar, automatizar e simplificar o ciclo de vida dos experimentos dentro da instalação.


  • Diretivas originais foram tomadas do estudo de casos de uso básicos e das experiências anteriores dos testbeds OpenFlow ativos como os testbeds OpenFlow do projeto GENI [ 17 - Computer Networks ]. Uma análise dos primeiros requisitos coletados resultou num conjunto de princípios que guiaram o projeto do OCF:
    • Recursos de alocação e instanciação: O software poderia suportar alocação, instanciação e desalocação de recursos para o tipo de recurso (exemplo, fatia OpenFlow ou uma máquina virtual) e em um calendarized fashion.
    • Experimento/Projeto baseado em alocação de recursos: A alocação, instanciação e desalocação de recursos deve ser feita por projeto e fatia, sendo a fatia a menor entidade indivisível composta pelos recursos necessários para implementar todo o experimento. Fatias devem estar totalmente isoladas da outra mesmo que elas possam compartilhar a mesma infraestrutura.
    • Federação e autonomia de ilhas: A arquitetura de software poderia inerentemente suportar federações internas (entre ilhas OFELIA) e externas como outros testbeds, que é a cooperação de vários testbeds locais para suportar experiências entre eles sem afetar a autonomia de operação da ilha.
    • Autenticação e Autorização (AA) e conjunto de políticas: O OCF tem que suportar os mecanismos necessários para Autenticação e Autorização (em vários escopos) juntamente com um forte conjunto de políticas (também em vários escopos ou camadas).
    • Usabilidade: Pesquisadores podem ter acesso um a um conjunto amigável de interfaces de usuário. Neste sentido, o principal foco de desenvolvimento será em direção às interfaces Web.
    • Monitoramento: O framework de controle deve apoiar mecanismos de monitoramento para frameworks de controle próprios e recursos de fatiamento.


Arquitetura de software OCF para versões v0.X


  • O projeto da arquitetura inicial do softwre OCF é demonstrado na Fig. 5 (a). Esta arquitetura é ainda muito centrada na implementação, portanto, muito influenciado pela arquitetura individual dos vários instrumentos adotados durante a fase inicial de implementação. No entanto, como parte do plano de trabalho do projeto e seguindo uma abordagem iterativa, a arquitetura tem e está evoluindo junto com a implementação, como será mostrado na Seção 2.5.2. Entretanto, a maioria dos conceitos fundamentais por trás da arquitetura evoluída já estão presentes no projeto. A Fig. 5 (a) mostra a estrutura básica de um único conjunto de software para testbed, composto fundamentalmente por dois tipos de componentes e formalmente correspondendo a duas camadas separadas. Vale ressaltar que, embora a arquitetura nas versões 0.X foram originalmente concebidas para uma única implantação de testbed, o projeto correto autorizado a interfederados em diferentes instâncias do OCF foram executados em testbeds distribuídos.


  • O frontend é o componente da camada superior. que encapsula duas funções: a interface do usuário (web frontend) e também chamado Clearinghouse (terminolodia GENI). A Clearinghouse é quem executa a cobrança dos projetos do testbed, fatiamento e gerenciamento de estado dos usuário, bem como a execução das autenticações e autorizações.




Fig. 5. Evolução da arquitetura do OFELIA Control Framework



  • Componentes da camada mais baixa contém os componentes chamados Resource Managers (RMs) e Aggregate Managers (AMs). Resource Managers são componentes responsáveis ​​por cuidar exclusivamente da gestão de recursos (por exemplo, uma máquina virtuai, um flowspace, . .), Manter o estado de reserva do recurso, realizar a alocação de recursos, configuração, monitoramento e desalocação (no exemplo, duas RMs são mostradas, para Máquinas Virtuais e para recursos OpenFlow).


  • Aggregate Managers por sua vez, tem a mesma API ou APIs northbound como a RM mas, diferentemente das RMs, elas não executam gestão de recursos por conta própria. A missão da AM é' ' costurar ou compor recursos formando outro mais complexo, e cuidar da atomicidade e alocação própria, configuração, monitoramento e desalocação do recurso composto.


  • o mecanismo de federação, não mostrado na figura por simplicidade, é realizado por permitir altas instâncias do componente da camada superior (frontends) para se conectar a outros testbeds RM/AMs, permitindo efetivamente que os usuários utilizem os recursos em vários testbeds.


  • No entanto, esta arquitetura apresenta algumas limitações. Em primeiro lugar, os componentes da camada superior (frontend) devem ser divididos em dois módulos separados logicamente, a interface do usuário e a da Clearinghouse (CH), permitindo que mais interfaces de usuários sejam usadas. Junto com esta divisão, uma definição formal das interfaces entre esses componentes e a interação com a camada de AM/RM também é necessária . Além disso, devido à natureza da implementação cëntrica da arquitetura, que carece de uma definição formal sobre como a combinação ou "a costura" de recursos é tratada (camada de agregação), as propriedades de recursão da arquitetura ou como e onde o conjunto de políticas devem ser implementadas.


Arquitetura de software da OCF para versões futuras v1.X



  • A Fig.. 5 (b) mostra o projeto de arquitetura de software evoluído, destinado a ser implementado a partir da versão 1.0 do OCF em diante. A arquitetura reflete as conclusões obtidas a partir das contribuições do OFELIA em discussões com base em Slice-based Federation Architecture (SFA) com outros projetos como o GENI.


  • Existe uma definição formal de três camadas distintas: a camada de interface do usuário, a camada de Clearinghouse e a camada AM/RM. Interações e interfaces entre essas camadas são formalmente definidas. Federações ainda estão tomando lugar para permitir que interfaces de usuário interajam com outros testbeds com camadas AM/RM enquanto as Clearinghouses lidam com autorizações de solicitações recebidas.


  • A nova arquitetura define que AMs e RMs podem formar uma cadeia hierárquica, também devido ao fato de que todas elas falam com as mesmas APIs e têm os mesmos frameworks de autorização e autenticação. Isto será conseguido uma vez que todas as diferentes AM/RM irão se basear na AMsoil [ 18 - Computer Networks ]. Este framework de pacote de software pode ser considerado como o conjunto de ferramentas base para construir AMs OFELIA. Ele encapsula tarefas comuns que são executadas por cada AM/RM, tais como autenticação e autorização, interfaces, como a API OFELIA nativa, GENI v3 API [ 19 - Computer Networks ] ou SFA [ 20 - Computer Networks ] wrapper e abstrações e mecanismos AM/RM comuns, como reserva e lógica de monitoramento.


  • A agregação das AMs é algo permitido pela própria arquitetura e pode ser implementada de acordo com os requisitos específicos de gestão de recursos (agregação). A arquitetura também define esse componente AM/RM pode implementar políticas localmente de acordo com as necessidades operacionais. Para realizar isto, a biblioteca OFELIA desenvolveu a biblioteca pyPElib [ 21 - Computer Networks ]. pyPElib permite que se adicione regras para avaliar as requisições e algum elemento do modelo de dados das AMs, dependendo das políticas locais. Por último, estes componentes também poderiam estar no comando do monitoramento de recursos.


Implementação


Implantação da rede


  • As seções a seguir expõem alguns detalhes sobre as soluções técnicas adotadas durante a implantação e operação das três redes OFELIA: a rede experimental OpenFlow-enabled, a rede de controle e rede de gerenciamento. Além disso, uma visão geral sobre a implementação da ilha hub OFELIA na Bélgica é dada.


Configuração da rede experimental OpenFlow


  • A rede experimental se extende todas as atuais ilhas implantadas, incluindo as não-públicas. A rede está em conformidade com um único segmento Ethernet pan-europeu OpenFlow-enabled (v1.0), permitindo experimentos L2 em diferentes países. Tal como acontece com o resto das redes, a rede experimental tem o eixo central em iMinds. Cerca de 25 switches OpenFlow-enabled de diferentes fornecedores, como a NEC, a HP (ou seja, o caso da ilha i2CAT na Fig. 6) ou PRONTO, foram implantados, estando aproximadamente 20 deles disponíveis nas ilhas públicas do OFELIA.


  • A maioria dos switches aloca um número significativo de portas a serem gerenciadas pelo protocolo OpenFlow, e essas portas estão interligadas formando uma topologia em malha parcial ou completa. Ao mesmo tempo, os servidores estão geralmente ligados a mais do que um switch, formando um ambiente flexível para as experimentações. Os experimentos podem utilizar topologias formando laços, optando por um laço induzindo flowspace através da OCF. O software avisa o usuário que o flowspace solicitado contém laços, tanto localmente na ilha quanto através de várias outras.


  • Cada ilha utiliza uma instäncia do Flowvisor [ 22 - Computer Networks ] ou VeRTIGO [ 23 - Computer Networks ] para fatiar a rede experimental. Slices baseadss em VLAN-IDs foram selecionados após testes de vários esquemas de fatiamento, para oferecer o máximo de flexibilidade, mas principalmente devido a problemas de escalabilidade com OpenFlow v1.0 e o número limitado de entradas Ternary Content Addressable Memory (TCAM) nos switches. Nota-se que os switches OpenFlow frequentemente extendem-se sobre implementações de hardware legado, que são projetados para separar o tráfego usando VLANs principalmente. A decisão foi a de que uma VLAN-ID ou um grupo de VLAN-IDs seriam atribuídas a cada fatia. Este mecanismo de fatiamento garante uma adequada camada 2 de isolamento para cada fatia, mantendo o número de entradas TCAM no switch usado por fatia para um montante razoável, garantindo a escalabilidade da plataforma de testes. No caso de experimentos específicos que precisem de VLANs, uma gama de VLAN-IDs serão atribuídas, as quais irão fornecem tanto a isolação da fatia quanto a capacidade de ainda trabalhar como VLAN-IDs.


  • No entanto, ilhas individuais ou testbeds podem usar livremente outros mecanismos de corte para fatiamento específicos dentro da ilha (por exemplo, Flowspaces IPv4 ). Além disso, nem a criação da rede experimental OFELIA nem o OCF impedem que o mecanismo de fatiamento usado será sempre a fatia VLAN.


  • Esta interligação é baseado em um mínimo de circuitos L2 de 1 Gbit/s através da rede GEANT quando possíveis e túneis VPN através da Internet pública. Para a interconexão GEANT , o circuito é particionado para fornecer largura de banda dedicada e garantida por um canal de rede de controle. Túneis e circuitos adicionais de VPN podem ser implantados em uma topologia de malha para redundância no controle e nas redes experimentais.



Fig. 6. Implantação da ilha i2CAT (Barcelona)


Controle e gerenciamento da configuração de rede


  • A rede de controle, Fig. 7 (b), é uma rede out-of-band IPv4 que interliga as diferentes ilhas OFELIA. A rede utiliza um esquema de endereçamento privado, com uma sub-rede atribuída a cada ilha. Anúncios e roteamento entre as sub-redes da rede de controle são realizados pelo OSPF rodando num gateway nas respectivas ilhas. Cada ilha tem pelo menos uma conexão com o hub OFELIA, e, adicionalmente, outras conexões redundantes com outras ilhas. Essas conexões são implantadas, ou através de um enlace L2 GEANT dedicado (rede de dados pan-européia dedicada à pesquisa e à comunidade de educação) ou via VPN através da Internet pública.


  • Cada ilha oferece vários serviços, como o frontend OCF, ou ainda serviços mais genéricos, como o LDAP (implantado no hub) e DNS através da rede de controle. Esta rede também fornece acesso aos usuários, através do terminal VPN (OpenVPN), para toda a instalação e, em particular, também para a infraestrutura de servidor, que por sua vez está conectada à rede experimental. Cada ilha também oferece saída para a Internet através das VMs dos usuários.



Fig. 7. Serviços disponíveis em diferentes redes do testbed OFELIA



  • A rede de gerenciamento, Fig. 7 (c), é usado para monitoramento e tarefas administrativas sobre a infraestrutura. A rede de gerenciamento é até agora uma rede opcional: em algumas (partes de) ilhas, sua função deve ser assegurada pela rede de controle, com a vantagem de ser mais simples de implementar, mas colocando em risco a separação de tráfego do usuário. Tanto a rede de controle quanto a de gerenciamento podem ser implementadas como LANs dedicadas, ou como VLAN sobre segmentos da rede de controle da ilha.


Hub OFELIA



  • As ilhas OFELIA estão interligados em uma topologia estrela para o hub OFELIA, localizado na sede iMinds (Bélgica). Além dos principais enlaces para o hub, pode haver links redundantes adicionais entre outras ilhas. A infraestrutura do hub inclui alguma infraestrutura de controle centralizado, como o servidor LDAP principal e o servidor de registro OFELIA público. Um servidor OpenVPN é hospedado para permitir o acesso externo à rede de controle pelos usuários, e para interconectar aos gateways das rede de controle das respectivas ilhas. Para este último, um hub OpenVPN de backup está disponível no TUB, com switch-over entre os dois hubs OpenVPN da controle de rede usando OSPF.


  • O servidor OpenVPN também atua como um hub para as redes experimentais. Estes estão interligados através de túneis L2, e em bridge usando o Open vSwitch (que suporta OpenFlow). Além da interconexão através da Internet, as ilhas também pode se conectar a um switch OpenFlow-capable NEC IP8800 localizado no hub através de circuitos dedicados (por exemplo, usando a rede GEANT ou outros NRNS). O circuito dedicado transporta tráfego experimental mas também tráfego da rede de controle. Por meio das ilhas, usando um circuito dedicado, ele substitui os túneis OpenVPN. A bridge OpenvSwitch e o switch hub NEC estão interligados para completar a rede experimental OFELIA L2.


Implantação dos equipamentos de computação


  • O estudo concluiu que para cumprir os requisitos expostos na Subseção 2.2, a tecnologia de virtualização de servidores com a capacidade de customizar a rede interna e software livre de licença devem ser usados. Fortes candidatos foram XEN [ 24 - Computer Networks ] e KVM [ 25 - Computer Networks ], em conjunto com a biblioteca Libvirt [ 26 - Computer Networks ]. A implementação OCF atual suporta XEN 4.


  • Cerca de 20 servidores foram implantados em OFELIA, tanto para o armazenamento das máquinas virtuais (VMs) dos pesquisadores (VM) quanto para serviços internos. Para os primeiros, a maioria dos servidores estão executando Debian 6.0 (Squeeze), apesar de algumas ilhas estarem com implementações especiais.


Servidor de rede da máquina virtual interna


  • A produção atual da configuração de rede dos servidores VM servidor é baseada em uma configuração específica para o suportar multi-bridge (incluindo suporte VLAN). Ele usa o padrão de bridging do kernel Linux. Os principais objetivos desta implementação inicial foram: (i) suportar múltiplas interfaces experimentais e ao menos uma interface de rede de controle (out-of-band) por VM; (ii) garantir que as interfaces das máquinas virtuais experimentais tenham um mapeamento um-para-um com as interfaces físicas do servidor, expondo claramente a topologia L2 para o pesquisador; (iii) suporte total dos quadros 802.1q marcados nas interfaces máquinas virtuais experimentais; (iv) a configuração deve suportar a implementação de estratégias de limitação de taxa L2 anti-spoofing (MAC, VLAN).


  • A Fig. 8 expõe graficamente a configuração interna de rede dos servidores XEN. Cada VM é fornecida com uma interface out-of-band, conectada à rede de controle (bridge sobre a interface do servidor peth). Esta bridge específica geralmente criada através de uma interface de marcação/desmarcação no servidor ou no domínio, que por segurança e por razões práticas transparentemente marca e desmarca quadros de controle na rede de controle e de gerenciamento, geralmente um segmento L2 out-of-band compartilhado.


  • A configuração também aloca uma bridge por interface física do servidor experimental (ligado à rede OpenFlow) que precisa ser compartilhada com as máquinas virtuais. O software Control Framework garante que a nomeação das interfaces dentro da máquina virtual é consistente com esse mapeamento, reservando-se o primeiro assinalamento (eth0) para a interface de controle out-of-band, e depois atribui o resto dos nomes em conformidade para as interfaces experimentais. Os detalhes exatos da conexão, tais como portas e datapath-id onde as interfaces estão conectadas, estão expostos no front-end OCF.



Fig. 8. Configuração de rede de um servidor virtualizado


Limitações conhecidas da rede interna de servidores e roadmap de desenvolvimento


  • A configuração atual, enquanto estiver conveniente para muitos dos pesquisadores dentro OFELIA, apresenta algumas limitações que foram levadas em consideração durante as experimentações. De um lado, as bridges são switches inerentemente de learning MAC e não OpenFlow controláveis​​, que podem, eventualmente impactar a experimentação se não forem levados em conta. Além disso, as bridges são compartilhados entre as várias máquinas virtuais dentro de um servidor, o que lhes permite comunicar-se através de um caminho direto dentro da rede do servidor, sem atingir o domínio OpenFlow controlado. E por último, mas não menos importante, atualmente há uma ACL limitada e funcionalidade rate-limiting implementada nas bridges.


  • Existe um esforço em curso para produzir uma nova configuração que deve substituir as bridges Linux com instâncias OpenvSwitch. Isto acabará por permitir que o OFELIA melhor exponha a rede interna do servidor para o tráfego experimental. Ao mesmo tempo, isso irá potencialmente restringir o tráfego para impedir duplicação e cross-slice de injeção de tráfego, e usar os recursos avançados de controle de tráfego do OpenvSwitch tais como a taxa limitante.


Adaptação de equipamento óptico para OpenFlow



  • Como explicado na Subseção 2.4, a fim de integrar dispositivos ópticos ao Control Framework do OFELIA, temos que expor dispositivos ópticos usando o OpenFlow. Esta abstração do switch OpenFlow é então usada para fatiar e reservar recursos para a experimentação. A fim de integrar a solução do circuito OpenFlow para o Control Framwork OFELIA, os principais desenvolvimentos foram realizados:


  • Abstração do switch de circuito OpenFlow (Agente OF): um switch habilitado no OpenFlow está exposto a um controlador, representando a chave como uma ou mais tabelas de fluxo em um pipeline OpenFlow [ 27 - Computer Networks ]. Especificações atuais do OpenFlow concentram-se principalmente em domínios de comutação de pacotes, embora um adendo foi incluído para cobrir o domínio óptico, considerando SONET/SDH, Optical Corss Connects (OXCs) e convergência Ethernet/TDM como tecnologias de circuito comutado para OpenFlow 1.0 [ 16 - Computer Networks ].


  • Em cima dessas extensões que suportam a comutação de circuitos, o OFELIA propôs uma especificação de fluxo óptico genérico e extendido [ 28 - Computer Networks ]. Na definição proposta, um fluxo óptico pode ser reconhecido por um identificador de fluxo so-called, composto de porta, comprimento de onda da portadora óptica, largura de banda associada ao comprimento de onda e restrições específicas para a camada física (por exemplo, a sensibilidade para impairments e faixa de potência). A abstração do switch OpenFlow para Elementos de Rede é feita pelo software agente OpenFlow que consiste em uma interface Simple Network Management Protocol (SNMP) que é colada junto com o canal OpenFlow através de um modelo de recursos abstraído. Cada Elemento de Rede com um agente torna-se um switch habilitado OpenFlow. Esta abordagem pode ser vista na Fig. 9. A interface de gerenciamento SNMP oferece funcionalidades avançadas que permitem a configuração do plano de dados e a recuperação da configuração atual do NE.



Fig. 9. Integração do agente OpenFlow


  • Controlador para gerenciar switches de circuito hablitados no OF: o controlador OpenFlow extendido, ao mesmo tempo, pode executar a descoberta da topologia subjacente, quer diretamente do switch OpenFlow ou usando o plano de controle do Generalized Multi-Protocol Label Switching (GMPLS) , ou com uma combinação de ambos. Deste ponto em diante, o controlador pode construir um mapa da topologia da rede de fibra óptica e, com base nos requisitos do usuário, pode empurrar as entradas de fluxo (através do GMPLS ou de uma pura abordagem OpenFlow) para switches para estabelecer conexões transversais no domínio óptico.


  • O protótipo atual é baseado no equipamento ADVA’s FSP 3000 ROADM [ 29 - Computer Networks ], usando a implementação da ADVA do plano de controle GMPLS. Ele pode provisionar caminhos ópticos de dois modos, ou seja, caminhos perdidos e explícitos. Na abordagem integrada Open-Flow-GMPLS, a alocação de recursos é realizada pelo plano de controle GMPLS, mas o controlador OpenFlow pode construir a topologia das mensagens OpenFlow. Dependendo do pedido, o controlador pode emitir solicitações de caminhos perdidos ou explícitos para o plano de controle GMPLS que funciona como um aplicação no topo do controlador. O plano de controle GMPLS cuida da alocação de recursos e do nivelamento de potência e configura o caminho das requisições correspondentes. Esta abordagem permite a utilização dos aspectos do GMPLS Path Computation Element (PCE), como um caminho de computação com deficiências ópticas que não estavam disponíveis em controladores OpenFlow atuais. No período de duração do projeto, uma solução OpenFlow pura stand-alone também foi desenvolvida. Aqui mensagens OpenFlow CFLOW_MOD são usadas ​​para atualizar as tabelas de fluxo, em vez de GMPLS [ 30 - Computer Networks ]. A configuração de fluxo utilizando abordagem OpenFlow pura assume um agente OF em cada Elemento de Rede na rede.O agente OF instancia ou exclui conexões cruzadas apropriadas via SNMP ao receber mensagens CFLOW_MOD. Mensagens OpenFlow extendidas também foram introduzidas para acomodar potência, restrições e recursos impairments do NE. Este desenvolvimento proporcionou a oportunidade de também comparar a abordagem GMPLS-OpenFlow integrado com abordagem OpenFlow puro sobre a facilidade OFELIA.


  • Fatiamento da infra-estrutura óptica usando FlowVisor: Com as extensões OpenFlow no lugar, o próximo objetivo era a integração das soluções mencionadas para a facilidade. Conforme detalhado em outras seções, o OFELIA suporta fatiamento de infra-estrutura usando a ferramenta de virtualização baseada no OpenFlow chamado Optical FlowVisor. O FlowVisor Optical (OFV) [ 15 - Computer Networks ] fornece a habilidade do pesquisador em adicionar também nós ópticos para sua experiência. O FlowVisor óptico foi extendido de tal forma que ele tem visibilidade em ambos os domínios, pacotes e ópticos e que pode fatiar no domínio de circuito baseado nas portas e comprimentos de onda, conforme especificação dos fluxos de circuito.


O Control Framework OFELIA


  • A implementação do Control Framework OFELIA [ 10 - Computer Networks ] foi dividido logicamente em três fases distintas, de acordo com as diferentes etapas: (i) a implementação da primeira versão inicial do Control Framework, com foco na gestão dos recursos locais da ilha, mas tendo em consideração a controle de recursos inter-ilhas; (ii) a segunda fase dedicada a capacitar o Control Framework com mecanismos para alocar recursos através de múltiplas ilhas dentro da mesma fatia (intra-federação), bem como incluindo a melhoria do software de alguns aspectos básicos implementados na Fase I, levando em conta experiências adquiridas a partir dos diferentes usuários das instalações internas e externas; (iii) a terceira fase continua a melhoria global do Control Framework, especialmente tendo em conta os requisitos, sugestões e comentários inferidos a partir dos usuários regulares e as duas parcerias de Open Calls.


  • O desenvolvimento segue uma dinâmica de desenvolvimento de software ágil, continuamente coletando novas requisitos, evoluindo e aperfeiçoando o software. Tudo isso resultou em uma longa lista de lançamentos da série v0.X, a partir da v0.1 até a v0.5 atual, e agora está avança gradativamente para a nova arquitetura da série V1.x.


Pilha do software atual (v0.5)


  • Seguindo a arquitetura da série v0.X mostrada na Fig. 5 (a) da Subseção 2.5.2, a implementação do Control Framework OFELIA conduz para o desenvolvimento e/ou adaptação dos diferentes módulos listados abaixo:
    • Frontend/ClearingHouse: Este componente trabalha duas regras principais. De um lado, se lida com a gestão de usuários, projetos e fatias dentro de cada ilha. A ClearingHouse acessa o LDAP OFELIA para sincronizar contas de usuário e privilégios entre ilhas e proporcionar uma estrutura de autenticação unificada (Single Sign On, ou SSO). Por outro lado, ele também atua como a interface do usuário habilitado para AJAX para a web. A comunicação com os AMs é realizada por meio de plugins específicos desenvolvidos em Python. Cada plug-in fornece os meios para comunicação e traduzem a descrição específica de recursos fornecidos por um AM. A ClearingHouse é baseada no Expedient [ 32 - Computer Networks ], um módulo originalmente desenvolvido pela Universidade de Stanford, mas altamente adaptado e ampliado em áreas como a experiência de work-flow e Web User Interfaces.
    • Gerenciador Agregado da Máquina Virtual: O Gerenciador Agregado VM (AM) lida com o gerenciamento de servidores virtualizados fornecidos pela facilidade OFELIA para hospedar máquinas virtuais dos usuários OFELIA. A implementação atual suporta XEN, embora a concepção e implementação do AM seja inerentemente hypervisor-agnostic. Ele também vem com uma interface Web para proposta de gerenciamento. O VM AM manipula os pedidos e cuida do fornecimento, instanciação e desisntanciação de VMs nos servidores físicos. O OFELIA XEN Agent é um daemon rodando nos servidores físicos, que são responsáveis pelo provisionamento VM e todas as funções relacionadas com o hypervisor incluindo monitorização, através da biblioteca Libvirt.
    • Gerenciador Agregado OpenFlow é atualmente baseado na ferramenta de Stanford Opt-in Manager [ 33 - Computer Networks ]. O principal objetivo deste pacote é controlar e administrar a configuração FlowVisor, a ferramenta responsável por fatiar a rede OpenFlow e multiplexar o uso concorrente. Ele vem com uma interface Web que está disponível apenas para o Island Manager. Ele também fornece um sistema de notificação de e-mail embutido para notificação de requisição ao administrador do testbed.


Implantação dentro das instalações OFELIA FP7


  • A pilha de software OCF foi implantada em todas as ilhas OFELIA e está sendo usada para orquestrar a experimentação. Cada ilha individual constitui um ambiente totalmente funcional onde as (Ilhas) experiências locais podem ser realizadas daqui pra frente. Para cada implantação, o administrador local tem o controle sobre os recursos locais orquestrados através do Control Framework. Além disso, os administradores da ilha são capazes de definir suas próprias políticas sobre instanciação de recursos/alocação, no âmbito da política geral do framework Ofelia. Esses recursos são prorrogados quando Aggregate Managers adotam mecanismos de políticas[ 21 - Computer Networks ] baseados em pyPElib (ainda em versão beta para o VM AM no momento da redação deste documento).


  • Pesquisadores tem a opção de entrar em qualquer um dos frontends OFELIA públicos e criar projetos e fatias. Pelo desenho, como exposto na arquitetura, projeto e estado da fatia residem apenas no frontend usado, independentemente de quais recursos e para quais AMs eles estão alocados.


  • No momento da escrita deste artigo, federações de diferentes ilhas OFELIA geridas pelo OCF foram implantadas em produção. Após a federação, cada frontend da ilha é capaz de se comunicar com todos os Aggregate Managers' dentro da instalação OFELIA. Isto habilita experimentos de qualquer um dos frontends OFELIA a criar projetos com recursos em toda a testbed federada.


Experimentação no testbed OFELIA


  • Como um testbed, o OFELIA tem como objetivo disponibilizar uma ampla plataforma real para a comunidade de pesquisa, a fim de experimentar e testar novas idéias. Desde que o OFELIA foi aberto ao público já recebeu algumas contribuições interessantes. Nas subseções seguintes alguns dos experimentos mais relevantes serão descritos, demonstrando a capacidade de instalação do OFELIA para ajudar nos testes de novos conceitos.


VeRTIGO (ViRtual topologies generalization in OpenFlow networks)


  • FlowVisor é a ferramenta mais popular usada para fatiar uma rede OpenFlow em várias subinstânciass, cada uma atribuída a um controlador diferente. Ele é considerado um padrão de fato para realizar a virtualização de rede, mesmo que ele não permita instanciar topologias de rede virtuais arbitrárias, ou seja, topologias que partem do físico até o nível do substrato. Devido à sua forte integração no âmbito do Control Framework OFELIA, esta é uma grande limitação, pois os pesquisadores dispostos a implementar a sua própria experiência em cima de OFELIA testbed serão forçados a testá-lo em um conjunto muito limitado de topologias de rede. Além disso, em sua implementação atual dentro da OCF, os pesquisadores são forçados a selecionar manualmente as conexões (físicas) e os nós pertencentes à sua instância de rede virtual. O objetivo do VeRTIGO é superar estas limitações, permitindo a instanciação de topologias de rede virtuas generalizadas em cima do testbed OFELIA; em particular, VeRTIGO permite aos usuáros executarem seus experimentos em uma topologia completamente arbitrária que pode abranger várias ilhas OFELIA. Essas topologias são baseados no conceito de virtual links implementados como agregação de vários nós e links físicos. Além disso, uma forte integração de vertigem dentro da OCF permite a configuração automática de qualquer topologia definida por um experimentador (por exemplo, em um dashboard) sobre o Ofelia, graças a um mecanismo que tanto eficientemente incorpora a topologia virtual requisitada dentro de uma topologia física e, em seguida, instancia automaticamente no testbed para permitindo que o experimento seja adequadamente executado (ou seja, sem a necessidade de qualquer manual de provisionamento').




Fig. 10. Arquitetura VeRTIGO


  • A Fig. 10 mostra a arquitetura do VeRTIGO e sua interrelação com o software OCF. Os componentes principais são: (i) o topology monitor que analisa as mensagens OpenFlow e a configuração da topologia virtual, (ii) o port mapper que edita as mensagens switch-to-controller, substituindo os valores de número de porta com alguns consistentes com a configuração de links virtuais, (iii) o link broker, que cria mensagens do protocolo OpenFlow direcionadas para os switches e (iv) a VT Planner, uma ferramenta Virtual Network Embedding que implementa um algoritmo de seleção de caminhos para eficientemente agregar nós e links físicos dentro dos links virtuais. O framework VeRTIGO está sendo integrado ao OCF, no entanto, o mecanismo subjacente substituindo o FlowVisor tem sido fortemente testado, como discutido em [ 23 - Computer Networks ], onde os indicadores chave de desempenho (KPIs), como sobrecarga de latência contra o FlowVisor e capacidade de resposta contra falhas em links físicos têm sido estudados. Estes resultados mostram a eficácia da camada de virtualização de rede proposta que podem fomentar a habilidade dos pesquisadores m testar seus próprios aplicativos experimentais dentro de um ambiente de teste controlado fornecido pela facilidade do testbed OFELIA.


Information-Centric Networking (ICN)


  • Information-Centric Networking (ICN) está recebendo a atenção de uma grande comunidade de pesquisa. A idéia básica por trás do ICN é a reprojetar a camada de rede, a fim de apoiar duas primitivas principais, ou seja, para colocar elemento de conteúdo na rede e buscar elementos de conteúdo da rede, identificando o conteúdo com seu nome próprio.


  • Duas abordagens possíveis foram identificados para suportar ICN usando o paradigma SDN: um long term [ 34 - Computer Networks ] e um short term [ 35 - Computer Networks ]. Focaremos aqui no último, ou seja, suportar ICN sobre OpenFlow 1.0, para que possamos usar o equipamento implantado no testbed OFELIA para nossos experimentos. Partimos de uma solução ICN chamada CONET, definida em [ 36 - Computer Networks ], que por sua vez é derivada do CCN/CCNx [ 2 - Computer Networks ].


  • Nessas soluções, requisições ICN são encaminhadas para os nós a frente que hospedam o conteúdo, que respondem com pacotes de dados. Nós intermediários podem processar pacotes de dados e armazenar em cache o conteúdo solicitado (caching in-network), para que possam atender mais requisições para o mesmo conteúdo. A idéia é usar SDN/OpenFlow para controlar o roteamento de pacotes ICN (Interests and Data) na rede, fornecendo os meios para realizar com eficiência o cache inNetwork.


  • No CONET, os nomes de conteúdo são chamados (ICN-ID) e são caregados dentro de uma opção IP [ 37 - Computer Networks ] recém-definida no cabeçalho do IPv4 ou IPv6. O atual equipamentos OpenFlow 1.0 não suporta o funcionamento com base nas informações carregadas nas opções IP, por isso decidiu mapear o nome de conteúdo em um tag de comprimento fixo (4 bytes) para ser transportada nos campos das portas de fonte e destino UDP. Este mapeamento é realizado por um nó de borda no limite de um domínio baseado em SDN.


  • A configuração do nosso experimento, implantado e executado na ilha do testbed OFELIA em Barcelona, ​​é mostrado na Fig. 11. Só podemos descrever a experiência de alto nível aqui e nós nos referimos ao leitor em [ 38 - Computer Networks ] para os detalhes completos. Um ICN ou uma aplicação content client cria as requsições ICN para um conjunto de elementos de conteúdo. Tais pedidos são inicialmente encaminhados para um ICN ou servidor de conteúdo. Quando o conteúdo solicitado é enviado de volta para o cliente, ele também é copiado por switches OpenFlow intermediários na direção de servidores de cache que são capazes de armazenar o conteúdo e informar ao controlador OpenFlow que o conteúdo está disponível no cache. O controlador OpenFlow, irá então configurar os switches OpenFlow para que outros Content Requests sejam encaminhados para o servidor de cache, em vez de para o servidor CCN original, reduzindo assim a carga da rede.



Fig. 11. A configuração para o experimento ICN no OFELIA


Experimentação do carrier grade OpenFlow dentro do OFELIA no projeto SPARC FP7


  • O projeto FP7 SPARC (SPlit ARchitecture Carrier-Grade Networks) [ 39 - Computer Networks ] estudou as extensões OpenFlow em redes carrier grade, que oferecem alta capacidade para suportar centenas de milhares de usuários e assumir altíssima disponibilidade. Estes têm um requisito para o tráfego a ser recuperado dentro de 50 ms [ 40 - Computer Networks ] depois de uma falha. No projeto, a restauração controller-based esquemas de proteção switch-based foram implementadas. Para a restauração controller-based, um caminho alternativo é estabelecido após a detecção de uma falha. Para proteção switch-based, um caminho alternativo fim-a-fim disjoin é estabelecido antes de ocorrer uma falha de caminho de operação. Quando uma falha é detectada no caminho de operação, o switch de ingresso redireciona o tráfego para o caminho alternativo usando o conceito de tabela de grupos introduzido em OpenFlow v1.1 [ 27 - Computer Networks ]. Experimentos de emulação extensiva [ 41 - Computer Networks ] sobre topologias pan-européias de larga escala à procura de restauração e proteção foram executadas sobre a instalação do OFELIA. Nesses experimentos, falhas em nós e links foram considerados. Em experimentos com falha no link, um dos links entre os switches não foi atingido por desabilitar as interfaces Ethernet deste link; e em experiências de falha do nó um dos switches falhou porque o switch foi desligado. As experiências de falha de ligação foram realizadas para testar a escalabilidade com respeito a um determinado número de fluxos. Nestas experiências, o número de fluxos foi aumentada de 160 a 16.000. Para a restauração, o tempo de recuperação em escala linearmente com o número de fluxos afetados na rede e para proteção, o tempo de recuperação foi mais ou menos o mesmo, independentemente dos fluxos afetados. O valor máximo do tempo de recuperação nos experimentos de falha de link foi de 2,6 s para restauração e 48 ms para proteção. Para experiências de falha do nó, 3200 fluxos diferentes foram considerados na rede. Os resultados foram semelhantes aos experimentos de falha no link em que o tempo de recuperação aumentou linearmente em restauração e se manteve constante para a proteção.


  • A Fig. 12 mostra que OpenFlow pode restaurar o tráfego, mas a sua dependência em relação ao controlador mostra que será difícil alcançar 50 ms para restauração em uma rede de carrier-grade em grande escala. Ele também mostra que o OpenFlow pode alcançar a exigência carrier-grade de um intervalo de 50 ms se a proteção é implementada nessas redes para se recuperar da falha. Outros experimentos, que foram realizadas no testbed OFELIA, foram experimentos de controle in-band [ 42 - Computer Networks ]. Nesses experimentos, tráfego de usuário e de controle (tráfego de ou para o controlador) compartilhando o canal, e switches OpenFlow estabelecem sessões OpenFlow com o controlador por meio de caminhos através dos outros switches da rede. Os experimentos foram realizados em diferentes tipos de topologias: linear, anel, estrela e de malha e o tempo para estabelecer uma sessão entre um switch e o controlador foi calculado. As topologias de malha consideradas foram de topologias pan-européias de grande escala que foram usadas em experimentos de recuperação de falhas. Os resultados com todas as topologias mostraram uma relação linear entre o tempo de conexão do switch e a menor distância entre o switch e o controlador. Para as topologias pan-européias de grande escala foram gastos cerca de 6 s para ligar todos os switches (37 nós) com o controlador.



Fig. 12. Tempos de recuperação de falha no link


Roteamento dependente de energia em redes definidas por software (SDN)



  • Trabalhos anteriores resultando em uma tese de graduação que focou no roteamento dependente de potência em SDN testou novos algoritmos na ilha OFELIA localizada no site do i2CAT. Este trabalho considera o crescente interesse em torno de otimização de redes de computadores com técnicas tais como balanceamento de carga e economia de energia. Aplicando programação linear em um contexto SDN, um novo algoritmo para calcular o custo de energia de uma determinada rota foi elaborado e implementado em C / C + + como um controlador de rede sobre NOX. O modelo de custo de energia foi deduzido tomando medidas reais dos equipamentos utilizados em diferentes condições de carga de inativa para plena carga. O controlador então foi capaz de consultar os switches OpenFlow sobre suas estatísticas de tráfego e mapeá-los com um consumo específico de energia.


  • OFELIA entrou em ação, a fim de testar a eficácia do modelo de roteamento produzido em um cenário quase do mundo real. Usando OFELIA CF a validação do modelo foi realizada por provisionar uma fatia dos recursos disponíveis na infra-estrutura OFELIA do i2CAT composta naquele momento de 5 switches NEC habilitadores no OpenFlow em uma topologia de malha complexa e servidores virtualizados onde os pontos finais e as VMs do controlador foram hospedados. As modificações nas condições da rede foram simuladas por meio de alterações do FlowSpace requisitado em conformidade.


Serviço de balanceamento de carga múltipla com OpenFlow


  • Balanceadores de carga têm um papel decisivo em redes corporativas já que eles servem muitas vezes como um ponto de entrada e têm um grande impacto sobre o desempenho e a disponibilidade da rede. Enquanto os atuais balanceadores de carga são principalmente implementados como componentes específicos e caros de hardware, a implementação utilizada no experimento é baseada nos controladores OpenFlow para lidar com a carga de múltiplos serviços, sem a necessidade de uma parte específica do hardware.



Fig. 13. Mapa de conectividade do OFELIA



  • Múltiplos serviços Load Balancing (LB) com OpenFlow trazem um conceito conhecido e provado para uma nova tecnologia. Esta é uma abordagem para implantar LB flexível e e dinamicamente extensível para múltiplos serviços como é usado hoje em Data Centers, para hardwares que suportam OpenFlow. Alguns benefícios desta nova tecnologia são usados para cobrir demandas específicas de um serviço e são projetados para manter a LB tão efetiva quanto possível. Em outra frente, ele usa o conceitod e LB baseado em NAT que faz com que qualquer operador de rede lide mais facilmente com isso.


  • A facilidade OFELIA foi usada para avaliar o conceito e testar que desempenho é entregue pelos switches em hardware que suportam OpenFlow. Entretanto uma fatia do recurso na ilha TUB foi alocada e conectada para equipamentos específicos de teste de desemepnho do Ixia. O equipamento Ixia foi usado para simular tráfego HTTP real, clientes para servidores bem como avaliar o plugin CH LB NOX desenvolvido no TUB. As conclusões mostraram alguns interessantes resultados de medições quando relacionados às restrições do hardware atual nas ações processadas no OpenFlow, Os conceitos e resultados foram apresentados e publicados [ 43 - Computer Networks ] nas comunidades de pesquisas de rede.


Federação com testbeds externos


  • O interesse para o OpenFlow relacionado à pesquisa é direcionado por novas idéias que envoluem no tempo. A arquitetura do OFELIA foi projetada para fornecer o conjunto de nũcleos de serviço e práticas comuns para interconexão de sites de teste do OpenFlow. Isso permite que federações de locais de testes heterogêneos focalizem em áreas específicas de investigação no contexto do OpenFlow. Atualmente, OFELIA contém uma grande variedade de ilhas e tópicos de pesquisa, tais como: equipamentos de investigação óptica e sem fio e equipamentos de distribuição de mídia, permitindo experimentar uma variedade de campos de pesquisa, como a rede centrada no conteúdo, gerenciamento de topologia virtual ou roteamento (por exemplo, eficiência energética em esquemas de roteamento), entre outros.


  • Nosso objetivo final é uma arquitetura totalmente distribuída que permite a criação independente, operação autônoma e interligação dinâmica de ilhas sem a necessidade de um (ou pelo menos apenas uma mínima) hub central. A arquitetura distribuída também atenua as restrições administrativas do projeto que inevitavelmente existem dentro de todas as atividades baseadas em experimentação. A arquitetura do OFELIA é projetada de modo que a facilidade irá também permanecer após o final do projeto OFELIA. Quando nenhuma das ilhas existentes atender às necessidades da comunidade de pesquisa, encorajaremos outros pesquisadores a construir suas próprias ilhas OpenFlow e se conectarem com o volume de ilhas OpenFlow já existentes.


  • Nos últimos dois anos, temos visto a implantação de vários testbeds e infra-estruturas de teste no contexto de pesquisas para a Internet do Futuro financiadas por várias entidades nacionais ou europeias. Federar estas infra-estruturas de pesquisa é uma dos objetivos mais nebulosos da comunidade do testbed, especialmente quando os casos de uso permanecem obscursos. Uma federação de infra-estruturas de teste pode ser usada para estudar os detalhes de um tema de pesquisa específico com maiores detalhemento dentro de um ambiente isolado. Para OFELIA, esta área de interesse tem sido limitada ao desenvolvimento de arquiteturas e aplicações para Software Defined Networking controle. Pesquisa sobre o protocolo OpenFlow básico está fora do escopo OFELIA (exceto para as extensões ópticas). No entanto, um novo projeto europeu chamado ALIEN FP7 [ 44 - Computer Networks ] é voltado para a investigação sobre o protocolo OpenFlow em si. Alternativamente, estruturas de investigação federadas podem servir como um núcleo para a construção de uma nova Internet do Futuro que incorpore novas tecnologias e princípios arquitetônicos. Redes acadêmicas, bem como os operadores de rede comerciais, podem aderir a esse núcleo, transformando, assim, a Internet existente para a futura Internet, seja lá o que possa parecer no final. Apesar dessa incerteza do objetivo final de uma federação, muitos parceiros e usuários de OFELIA manifestaram interesse em se conectar OFELIA e suas ilhas para outros testbeds OpenFlow. Pode-se pensar em vários estágios de integração de testbeds heterogêneos (com base OpenFlow):


  • 1. Provavelmente, a mais simples das federações é o provisionamento de simples conectividade layer-2 para a troca de tráfego experimental sem qualquer coordenação dos recursos. Isto inclui a necessidade de configuração manual (não-integrado) de recursos em ambos os ambientes do testbed. Esta etapa já é realizado entre as diferentes ilhas OFELIA, através da implementação de túneis L2 dedicados sobre backbones experimentais como GEANT, ou túneis simples através da Internet pública. Qualquer outra instalação pode conectar seus recursos de rede, sendo OpenFlow ou não, ampliando a rede de experimentação.


  • 2. A funcionalidade Clearinghouse compartilhada que permite que as credenciais do usuário comum, pelo menos para autenticação e autorização de acesso aos recursos. As diferentes interfaces residente em cada ilha age como uma entidade autorizada contra os AMs das outras ilhas, permitindo que o experimentador seja capaz de alocar recursos federados.


  • 3. O framework de controle comum para implantação e configuração que oferece aos usuários uma maneira simples de criar um novo experimento. O Control Framework OFELIA é a realização de cada framework de controle, e é projetado para ser facilmente estendido a outros testbeds, através de uma arquitetura de software modular e reutilizável. O Control Framework OFELIA além de proporcionar uma base comum de implementação, chamada AMsoil, para facilitar a criação de AMs para novos tipos de recursos.


  • 4. O framework de gerenciamento de dados comum para descrever experiências, coleta de dados e análise dos resultados.


  • Os primeiros testbeds experimentais foram implantados como ilhas isoladas cada um seguindo o seu próprio fluxxo de processo para implantar e controlar experimentos, finalmente rendendo uma diversidade de frameworks. Uma série de projetos para a harmonização desses frameworks de controle têm sido conduzidos nos últimos anos, mas um framework único controle unificado ainda não está à vista. Embora, um conjunto de princípios comuns de design tenha surgido a partir dessas discussões baseado no SFA inspirado na arquitetura GENI. No âmbito do projecto OFELIA, nós começamos a migrar o Expedient baseado no framework de controle em relação a esses padrões de fato emergentes, tornando os clientes OFELIA capazes de estabelecer comunicação com outros testbeds como GENI e os baseados no SFA.


Colaboração do FIBRE dentro do FIRE


  • FIBRE é um projeto FP7 [ 45 - Computer Networks ] dentro do Future Internet Research and Experimentation (FIRE), que visa a criação de uma facilidade Futuro Research Internet entre Brasil e Europa. Todas as fases para atingir esse objetivo são consideradas dentro do projeto: concepção, implementação e validação. Federação torna-se um objetivo fundamental no FIBRE devido a duas razões. Por um lado, a interconexão das facilidades européias e brasileiras é uma obrigação de fornecer um testbed intercontinental.


  • Por outro lado, a instalação Européia está sendo construída para aperfeiçoar as duas facilidades existentes no Future Internet Research and Experimentation Initiative (FIRE): OFELIA e OneLab. Para moldar instalações da FIBRE, a inter-federação e conexão física de ambas as instalações européias existentes também é um objetivo importante. Nesse sentido, o FIBRE está criando mais duas ilhas, localizadas na Universidade de Bristol e em i2CAT adiciionando mais equipamentos dedicados e interconectando-os às infra-estruturas existentes. O objetivo destas extensões é lidar com o crescente número de usuários provenientes da federação de instalações, e, além disso, o cumprimento dos requisitos para a realização dos showcases propostos pelo FIBRE.


  • Em segundo lugar, como parte das melhorias do FIBRE sobre o framework de controle OFELIA desenvolvido no projeto OFELIA, o OCF está sendo usado como ferramenta para gerenciar as novas ilhas. Este fato vai colocar o software contra novos casos de uso e um uso mais extensivo, proporcionando mais comentários sobre erros detecção ou identificação requisitos. O projeto FIBRE está contribuindo ativamente para o desenvolvimento e a extensão do OFELIA OCF, enriquecendo a comunidade de usuários e desenvolvedores OCF.


Colaboração GENI


  • As primeiras implementações acadêmicas do testbed OpenFlow eram controlados por uma ferramenta chamada Expedient desenvolvido na Universidade de Stanford que seguiu alguns princípios arquitetônicos do SFA em termos de gestão de recursos e controle experimental. Uma série de projetos têm trabalhado em arquiteturas de frameworks de controle para controlar testbeds nos últimos anos. Apesar de seguir os princípios básicos arquitetônicos muito semelhantes, o que levou a uma ampla gama de APIs incompatíveis, principalmente diferindo em detalhes muito específicos, tornando a sua utilização para os pesquisadores uma tarefa tediosa. Nesta situação, decidimos mudar a arquitetura Expedient mais prõxima do cumprimento do SFA. A atividade conjunta de vários parceiros do projeto e liderada pela Universidade de Stanford tem iniciado um movimento em direção a uma implementação compatível com o SFA, incluindo suporte para a GENI API v2 e trabalhar com a implementação da nova classe base Aggregate Manager [ 18 - Computer Networks ] está atualmente em curso, que estará disponível para outros projetos no contexto do FIRE, GENI, e outras além dessas também. Adicionalmente, funcionalidade Expedient’s Clearinghouse enfrentará uma reescrita significativa que servirá como provedoir de identidade, autenticação e autorização. Além do básico GENI APIv2 a classe base AMsoil também apoiará uma versão estendida para necessidades específicas do OFELIA.


  • Cada Aggregate Manager será baseado em uma base de código comum. A classe base AM (chamado AMsoil) consistirá de duas partes: a parte específica de recursos e uma parte comum. A parte específica do recurso implementa a manipulação real de recursos, por exemplo, conversar com um agente e alocar recursos. A parte comum gerencia tarefas que são necessárias para cada AM, tais como identificação, autenticação e autorização, interface de conformidade (por exemplo, GENI AM API v2) e também gerencia as reservas de recursos.


Conexões Internacionais


  • Para troca de tráfego experimental, conectividade da camada 2 plain deve estar disponível. A conexão foi estabelecida via GEANT no ponto de troca aberta MANLAN da Internet2. Isto fornece conectividade de fato para o OpenFloe relacionando testbeds nos EUA, Coreia, Japão e Brasil. Além disso, devido às exigências do projeto FIBRE, OFELIA está adquirindo um link alternativo para o Brasil via RedIRIS e RedCLARA. No entanto, a fim de equilibrar a carga de tráfego experimental, estamos também com o objetivo para o estabelecimento de uma ligação direta via TEIN-3 para as comunidades asiáticas OpenFlow na Coréia e no Japão. A Fig. 13 mostra o mapa de conectividade em OFELIA.


  • OFELIA está disposto a colaborar e incentivar os membros a se tornarem parte da comunidade, quer através do acolhimento de uma ilha OFELIA, criando um projeto como um usuário ou federação com testbeds existentes..


Conclusões


  • A instalação do testbed OFELIA tem sido construída a fim de acolher as experiências multi-camada e multi-tecnologia através de uma estrutura de rede pan-européia, sendo o paradigma SDN a principal filosofia seguida e o protocolo OpenFlow usado como seu elemento-chave.


  • A concepção e implementação do OFELIA é baseada em três pilares fundamentais: flexibilidade e diversidade de recursos para o experimentador, a facilidade de experimentar a orquestração de um lado e facilidade de controle e gerenciamento para os administradores do outro, ambos atingidos pelos uso do OFELIA Controle Framework e finalmente, extensibilidade no contexto de intra e inter-federação. Para implantar o OFELIA muitos desafios relativos a diferentes campos e tipos de tecnologias tiveram que ser estudados e aplicados, por exemplo, virtualização de servidores, SDN e OpenFlow, desenvolvimento de software, engenharia de rede, etc Alguns desses desafios ainda estão em andamento e são esperados novos até o fim do projeto. O testbed OFELIA já sediou com sucesso vários experimentos baseados em OpenFlow interessantes nas áreas de virtualização de rede, rede centrada em informações, as redes de nível de operadora, roteamento power-aware e balanceamento de carga. O OFELIA pretende levar a experimentação um passo adiante através federação com outros testbeds. O objetivo da federação é não só ir além das fronteiras da Europa e expandir o impacto da OFELIA todo o mundo, mas ao mesmo tempo ser capaz de fornecer a comunidade de pesquisa um conjunto amplo de recursos fornecido por diferentes plataformas presentes na Federação. Isto deverá ser realizado com conexões internacionais múltiplas com testbeds tais como FIBRE e GENI.


  • Nossa experiência com o testbed como usuários, administradores das ilhas e desenvolvedores de software mostrou que OFELIA é uma plataforma muito promissora para a experimentação de rede. Esperamos que, em conjunto com o desenvolvimento da própria instalação, o OFELIA seja o campo de testes para vários tópicos de pesquisa orientadas para a evolução da Internet: um verdadeiro farol de experimentação para as redes do futuro.


Referências


Disponível em “http://3.143.69.156/wiki/index.php?title=Computer_Networks_-_Future_Internet_Testbeds_-_Part_I&oldid=29007”