wiki

ETArch Pilot

Revisão de 18h10min de 3 de julho de 2014 por Lclaudio (discussão | contribs) (→1.1 Software Defined Networks e OpenFlow)

MEHAR

  • Mondial Entities Horizontally Addressed by Requirements


Colaboradores


  • Alex Vaz Mendes - 9945-3763 - alexvazmendes@gmail.com
  • Caio Eduardo Cunha Machado Caetano - 9990-8108 - caio@algartelecom.com.br
  • Gabriel Fernandes Machado - 9232-6118 - gfmachado22@gmail.com (Entrada em 22/07/2011)
  • Bruna Lorena Rodrigues Gondin - 8825-2351 - bruna.lorenagondin@gmail.com (Entrada em 28/06/12)
  • Hélvio Pereira de Freitas - 9992-2213 - helvio@algartelecom.com.br (Entrada em 20/02/13)
  • Luiz Cláudio Theodoro - 9976-2676 - lclaudio@algartelecom.com.br
  • Pedro Macedo Leite - 9992-1743 - pedro.larva@gmail.com (Entrada em 11/10/2013)


Estudo


Básico






QoS


  • Aulas de TRC - 2006 - Pitágoras



SDN

NFV

Redes Virtuais



Redes Metro





  • Spanning Tree
    • Spanning Tree Protocol v1.21 – Aaron Balchunas




  • Artigo Redes Metro em Ambientes Telecom:
    • Este artigo apresenta o estudo e aplicação da tecnologia de Redes Metro Ethernet em ambientes de telecom para prover um meio de comunicação em a ltas velocidades baseado no protocolo Ethernet. A partir de uma infraestrutura operacional instalada, este projeto descreve as etapas da implementação dos equipamentos e serviços que poderão ser oferecidos aos clientes da empresa alvo.
    • MetroEthernet
    • Arquivo:Artigo - Redes Medtro em ambientes Telecom.pdf


  • Artigo Metro Ethernet
    • Fraulob, Davi M. Piacentini, Edgar J. Metro Ethernet. Pontifícia Universidade Católica do Paraná. Curitiba. 2006.
    • O mercado tem cada vez mais buscado por soluções de rede que tenham baixo custo e garantam qualidade de serviço, propiciando interconexão entre as redes corporativas geograficamente distribuídas e também com a internet. As redes Metro Ethernet tem se mostrado uma escolha óbvia, por propiciar simples administração, baixo custo, fácil interconexão e boa granularidade de banda. Novos protocolos têm sido propostos de maneira a atribuir a estas redes qualidade de serviço, segurança e robustez, de modo a se aproximar das características das redes de circuito tradicionais, mantendo as vantagens de uma rede de pacotes.
    • Arquivo:Metro Ethernet - 2006.pdf



Visitas


IEEE 802.1



Simulação



Trabalhos relacionados


Computer Networks


  • Future Internet Testbeds - Part I
  • James PG Sterbens, David Hutchinson, Paul Muller and Chip Elliot


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 que tem sido mostrados no projeto e implementação de uma facilidade de testbed é descrita, incluindo o software de gerenciamento OFELIA Control Framework TestBed. Em sequëncia, experiências operacionais recentes desde que foi aberto para o público em geral, fornecendo 5 diferentes testbeds ou ilhas são descritos.


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, o número de redes conectadas a cada dispositivo e a 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) ou Information-Centring Network (ICN) 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 é ficada 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.


  • Portanto validações em facilidades experimentais são um aspecto importante no processo de desenvolvimento destes novos protocolos originando no conceito e indo para a operação. Um processo típico de realização de um conceito pode ser visto na figura 1. Ele começa com o problema e sua descrição, seguido pela geração das idéias e espaço de soluções próprias e o desenvolvimento de algoritmos apropriados. Este algoritmos são tipicamente solucionados posteriormente e potencialmente validados em uma facilidade experimental. Uma aspecto importante é a retroalimentação da indústria para as comunidades e departamento de pesquisa. Normalmente o que existe são alguns feedbacks disponíveis para os problemas e parâmetros de entrada para simulações mas limitado à orientação no projeto de uma plataforam de validação experimental.


1.1 Software Defined Networks e OpenFlow


  • Sofftware Defined-Networking (SDN) é uma abordagem promissora para desenhar caminhos de migração das tecnologias de rede existentes para novos conceitos e protocolos. O aspecto chave do SDN [e a separação de dados e plano de controle. O controlador poderá então estar sendo processado em um computador pessoal (PC) e os elemento do caminho de dados (classicamente, um switch Ethernet) precisa ser menos complexo porque todas as decisões de encaminhamento são feitas pelo controlador externalizado. Um controlador único pode ser conectado agora a múltiplos switches. formando um switch lógico amplo. 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. Um razoável conjunto de frameworks controladores já estão disponíveis, tanto de comunidades de pesquisa (NOX, POX, Floodlight, Beacon, etc) quanto vendedores comerciais (NEC, IBM ,etc). Em 2011, a Open Networking Foundation (ONF) assumiu a liderança no desenvolvimento do protocolo OpenFlow e a padronização deste protocolo mas também funções auxiliares como configuração e gerenciamento de dispositivos. 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 para resolver os problemas desenhados acima existe ainda um gap entre soluções teóricas e a experiência prática com suas implementações chamado OpenFlow.

RINA



  • Conceito:
    • A premissa básico desta arquitetura, ainda numa perspectiva inicial, é que a rede não é um conjunto de camadas com diferentes funções mas, mais que isso, uma camada simples de IPCs - Inter-Proccess Communication distribuído que repete sobre diferentes escopos
    • Cada instância desta camada IPC repetida implementa as mesmas funções/mecanismos mas políticas são otimizadas para operar sobre diferentes intervalos de espaço de performance (capacidade, atraso, loss, etc)
    • OS DAPs - Distributed Application Processes comunicam-se via facilidade IPC e podem também serem IPCs


  • Visão da arquitetura RINA


  • Distributed IPC Facility (DIF) and Distributed Application Facility (DAF)
    • O DIF é um SBB - Service Building Block que pode ser repetido e composto em camadas para construir um amplo conjunto de serviços que encontram seus requisitos
    • Um DIF pode ser pensado como uma rede privada e isto é diferente das definições tradicionais de camada na arquitetura TCP/IP
    • Primeiro, um DIF não executa uma função única ou um pequeno subconjunto de funções pré-determinadas mas um conjunto coordenado de políticas de funções gerenciadas para atingir o serviço IPC desejado
    • Segundo, o DIF naturalmente separa várias questões, incluindo operação sobre escalas de tempo diferentes (transferência de dados de curto prazo e multiplexação versus gerenciamento de conexões de longo prazo e problemas no controle de acesso)
    • Geralmente, chamamos um conjunto de Distributed Application Processes (DAPes) cooperantes para executar uma certa função e um Distributed Application Facility (DAF)
    • Esta função pode ser um serviço de comunicação, serviço de gerenciamento ou outro serviço qualquer
    • Um DIF é um DAF específico cujo trabalho é apenas fornecer serviços de comunicação.


  • Propósito:
    • O protótipo do RINA pode ser usado como ferramenta de rede para habilitar pesquisadores no desenvolvimento e teste de protocolos próprios e aplicações de rede
    • Pesquisadores podem alavancar nossas APIs e usar o protótipo para testar as políticas existentes em seus ambientes customizados
    • Podem adicionar novas regras ou utilizar o serviço de comunicação RINA para escrever aplicações externas
    • Também serve como ferramenta de ensino para ajudar estudantes a entender os princípios básicos ou executar pesquisa avançada nas Redes de Computadores e Sistemas Distribuídos


  • Aspectos:
    • DIF pode ser fácil e rapidamente condigurado e customizado para alavancar os mecanismos fornecidos em seu framework
    • Políticas configuráveis incluem instanciação de vários mecanismos de gerenciamento, ou seja, roteamento e registro
    • Nenhuma das ferramentas de simulação e emulação permite que pesquisadores testem diferentes regras de roteamento em redes privadas diferentes (DIFs), cada uma com seu escopo limitado
    • Arquitetura RINA suporta SDN
    • Usuários podem configurar uma rede virtual privada simplesmente com um DIF de alto nível ou DAF - Distributed Application Facility (DAF)
    • Instancia uma variedade de mecanismos em vez de apenas encaminhar como no OpenFlow
    • Recursão: Outro aspecto que torna a arquitetura RINA única no espectro de testes
    • O mesmo mecanismo (transporte, roteamento e outros mecanismos de gerenciamento) são repetidos sobre diferentes escopos e potencialmente instanciados como diferentes políticas
    • Ambos, tráfego de dados e controle são agregados e transferidos para camadas IPC mais baixas e cada DIF (privado) regula e aloca recursos para o tráfego originado do usuaŕio de DIFs de alto nível ou de aplicações


NVN


  • NetSocket:
    • www.netsocket.com/




Slicing




Documentação

Artigos e Livros









Modelos


Evolução


















Colaborações



Discussões


  1. Como se faz o reenvio e roteamento de pacotes no FINLAN?
  2. Como o FINLAN faz a reordenação dos pacotes?
  3. Existe enfileiramento para uma posterior remontagem?
  4. Como a aplicação conversa com o DTS?
  5. Podemos usar o termo pacote ou seria frame?
  6. O que seriam os títulos?
  7. A quantidade de roteadores pode ser um requisito?
  8. Se foram feitos experimentos com o ETCP, onde o FINLAN vai entrar?


Sites

Entidades


  • IEEE Communications Society [1]
  • Sociedade Brasileira de Telecomunicações [2]
  • W3C [3]
  • W3C Semantic Web Activity [4]


Diversos

Eventos



  • 2014 International Conference on Information Science, Electronics and Electrical Engineering - ISEEE 2014 


SBRC 2012



Reuniões

{{#forminput:form=Reuniao|button text=Crie um nova Reunião}}
ETArch Pilot - 25/06/14
ETArch Pilot - 17/06/14
ETArch Pilot - 04/06/14
ETArch Pilot - 28/05/14
ETArch Pilot - 21/05/14
ETArch Pilot - 14/05/14
ETArch Pilot - 07/03/14
ETArch Pilot - 05/03/14

Disponível em “http://3.143.69.156/wiki/index.php?title=ETArch_Pilot&oldid=28079”