wiki

ETArch Pilot: mudanças entre as edições

← Edição anterior
Helvio (discussão | contribs)
P&D
8 edições
 
(137 revisões intermediárias por 10 usuários não estão sendo mostradas)
Linha 6: Linha 6:
<br>
<br>


* Alex Vaz Mendes - 9945-3763 - alexvazmendes@gmail.com <br>
* Alex Vaz Mendes - 9 9945-3763 - alexvazmendes@gmail.com
* Lucas Guandalini
* Hugo Barbosa Silva - 9 9769 - 9023 - hugobarbosa@algartelecom.com.br
* Luiz Cláudio Theodoro - 9976-2676 - lclaudio@algartelecom.com.br
* Murilo Borges Machado - 9 8888 2100 - murilo.bgm@gmail.com
* Pedro Henrique Aparecido Damaso de Melo - 9769-2213 - pedroh@algartelecom.com.br
* Rafael Leonardo Ferreira de Aquino - (34) 9 9992-8457 - rafaell@algartelecom.com.br
* Rogério de Freitas Ribeiro - 9 9976-3017 - rogeriofr@gmail.com<br>


* Gabriel Fernandes Machado - 9232-6118 - gfmachado22@gmail.com (Entrada em 22/07/2011)<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)
* 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)  
* 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)
* Pedro Macedo Leite - 9992-1743 - pedro.larva@gmail.com (Entrada em 11/10/2013)
* Pedro Henrique Aparecido Damaso de Melo - 9769-2213 - pedroh@algartelecom.com.br (Entrada em  xx/xx/xxxx)


* Flávio Oliveira Silva - 9971-4589 - flavio@ufu.br
* Flávio Oliveira Silva - 9971-4589 - flavio@ufu.br
Linha 74: Linha 76:
* [[UDP]]
* [[UDP]]
* [[Resumo das RFCs]]
* [[Resumo das RFCs]]
* [[Problemas da Arquitetura TCP/IP]]




Linha 403: Linha 407:
<br>
<br>
* [[Passo a Passo]]
* [[Passo a Passo]]
<br>
* [[Passo a Passo VTUN]]
<br>
* [[VTUN/L2TP e Testes]]
<br>
* [[Testes do Chat]]
<br>
* [[Bridge]]
<br>
* [[GRE]]
<br>
* [[Comutador Virtual]]
<br>
* [[OpenVSwitch]]
<br>
* [[DTSA]]
<br>
* [[Workspace]]
<br>
* [[Entidades/ Título]]


= Artigos e Livros =
= Artigos e Livros =
Linha 516: Linha 540:
** Title Model for Computer Networks Optimization
** Title Model for Computer Networks Optimization
** [[Arquivo:16-FIA Book 2012 - FINLAN.pdf]]
** [[Arquivo:16-FIA Book 2012 - FINLAN.pdf]]
<br>
* '''17-GLOBECOM 2013'''
** Empowering Software Defined Wireless Networks Through Media Independent Handover Management
** [[Arquivo:17-GLOBECOM 2013.pdf]]
<br>
* '''18-WCNC-2014'''
** enabled Entity Title Architecture for Handover Optimization
** [[Arquivo:18-IEEE 802.21-enabled Entity Title Architecture for Handover Optimization.pdf]]
<br>
* '''19-WPEIF-2014'''
** Enabling a Carrier Grade SDN by Using a Top-Down Approach
** [[Arquivo:19-Enabling a Carrier Grade SDN by Using a Top-Down Approach.pdf]]
<br>
* '''20-WPEIF-2014'''
** Quality-oriented Mobility Control Architecture for ETArch Handover Optimization
** [[Arquivo:20-Quality-oriented Mobility Control Architecture for ETArch Handover Optimization.pdf]]
<br>
* '''21-ISCC-2014'''
** Entity Title Architecture Extensions Towards Advanced Quality-oriented Mobility Control Capabilities
** [[Arquivo:21-Entity Title Architecture Extensions Towards Advanced Quality-oriented Mobility Control Capabilities.pdf]]
<br>
* '''22-AICT-2014'''
** Towards a Carrier Grade SDN Controller - Integrating OpenFlow With Telecom Services
** [[Arquivo:22-Towards a Carrier Grade SDN Controller - Integrating OpenFlow With Telecom Services -.pdf]]
<br>
* '''23-AICT-2014'''
** Evolving Future Internet Clean-Slate Entity Title Architecture with Quality-Oriented Control Plane Extensions
** [[Arquivo:23-Evolving Future Internet Clean-Slate Entity Title Architecture with Quality-Oriented Control Plane Extensions.pdf]]
<br>
* '''24-AICT-2014'''
** Extending a 3GPP Prepaid Protocol to Improve Credit Pre-reservation Mechanism
** [[Arquivo:24-Extending a 3GPP Prepaid Protocol to Improve Credit Pre-reservation Mechanism.pdf]]
<br>
* '''25-AICT-2014'''
** Multicast Traffic Aggregation through Entity Title Model
** [[Arquivo:25-Multicast Traffic Aggregation through Entity Title Model.pdf]]
<br>
* '''26-AICT-2014'''
** UML-based Modeling Entity Title Architecture (ETArch) Protocols
** [[Arquivo:26-UML-based Modeling Entity Title Architecture (ETArch) Protocols.pdf]]
<br>
<br>


Linha 526: Linha 607:
<br>
<br>


== Escrevendo Artigo ==
== JEEL ==
<br>
 
=== Título ===
<br>
 
*  Internet do Futuro
<br>
 
=== Conceito ===
<br>
 
* O que é Internet?
* O que são protocolos?
* Exemplos de protocolos
<br>
 
=== Arquitetura da rede atual ===
<br>
 
* Camada de Aplicação
* Camada de Controle
* Camada Física
<br>
 
=== Problemas desta arquitetura ===
<br>
 
* Ossificação
* 4 décadas de vida
* Propósito inicial
* Mobilidade
* Segurança
* Escalablidade
* Etc
<br>
 
=== Desafios ===
<br>
 
* Novas aplicações
* Volume inimaginável de usuários
* Aumento exponencial do tráfego de vídeo
* Internet das Coisas
<br>
 
===  Alguns números ===
<br>
 
* Tráfego
* Usuários
* Dispositivos (Things)
* Sensores
* Aplicações
<br>
 
=== Softwarização ===
<br>
 
* NFV
* SDN
<br>
 
=== Algumas soluções ===
<br>
 
* OpenStack
* OpenFlow
<br>
 
 
 
<br>
 
=== Benefícios ===
<br>
 
* Redução de custos
* Maior eficiência
* Maior controle
* Crescimento natural
* Inovação
<br>
 
== Artigo: Entity Title Architecture Pilot: Deploying a Clean Slate SDN based Network at a Telecom Operator ==
<br>
 
=== Title ===
* Entity Title Architecture Pilot: Deploying a Clean Slate SDN based Network at a Telecom Operator
<br>
 
 
=== Authors ===
<br>
 
\author{\IEEEauthorblockN{~\\[-0.4ex]\large Luiz Cláudio Theodoro\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Electrical Engineering\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email: lclaudio@feelt.ufu.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large  Pedro Henrique A. Damaso de Melo\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email: pedroh@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Alex Vaz Mendes\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\
Uberl\^andia MG Brazil 38400-668
\\
Email: alexvaz@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Hélvio Pereira de Freitas\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\
Uberlandia MG Brazil 38400-668\\
Email: helvio@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Murilo Borges Gomes Machado\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\
Uberlandia MG Brazil 38400-668\\
Email: murilo.bgm@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Pedro Macedo Leite\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty Pitagoras\\
Uberlandia MG Brazil 38400-668\\
Email: pedro.larva@gmail.com}
 
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Flavio de Oliveira Silva\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing,\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email: flavio@facom.ufu.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Joao Henrique de Souza Pereira\\[0.3ex]\normalsize}
\IEEEauthorblockA{Polytechnic School\\ University of S\~{a}o Paulo\\S\~{a}o Paulo, SP, Brazil, 05424-970\\
Email: joaohs@usp.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Pedro Frosi Rosa\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing,\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email: frosi@facom.ufu.br}}
<br>
 
=== Abstract ===
* Luiz Cláudio
 
=== Introduction ===
<br>
 
* Em função do retumbante sucesso da Internet, surgiram necessidades impensáveis para os pioneiros implementadores dos protocolos que hoje suportam a arquitetura desta grande rede mundial. Estes padrões tem desafiado o tempo porque mesmo depois de décadas de utilização sempre se veem desafiados com novas exigências dos usuários. Apesar desta quase ubiquidade, a Internet tem tido dificuldades para atender às novas requisições como mobilidade, segurança e qualidade de serviço, etc. A contribuição dos protocolos desenvolvidos para a arquitetura atual da Internet é notória mas em várias situações, as prioridades dos projetistas não alinharam com as necessidades dos usuários \cite{pan2011survey}. Muitas iniciativas revelam a ânsia pela renovação da arquitetura corrente de forma a prover uma solução definitiva para novos requisitos e assim uma legião de pesquisadores tem se esforçado para trazer propostas interessantes, tanto no modelo híbrido, que mantém uma coexistência com os protocolos legados quanto clean-slate que propõe mudanças drásticas nos padrões atuais \cite{clark2012design} \cite{gavras2007future} .
 
 
* Apesar de várias contribuições a nível global, poucas conseguem se materializar fora do escopo de um laboratório. Implementar experimentos envolvendo pequenos conjuntos de equipamentos com poucos usuários é o um passo importante na instauração de uma pesquisa, porém quando se trata de validação em infraestruturas reais que atendem continuamente usuários em torno de milhões,  a questão se torna crítica. Isto porque as companhias não se arriscam a liberar sua planta e ambientes para serem manipulados por pesquisadores que de alguma forma poderiam afetar os serviços oferecidos ao publico.
 
 
* Este artigo, desenvolvido em parceria com uma operadora comercial mostra a implementação de uma arquitetura inovadora denominada ETArch - Entity Title Architecture \cite{de2012enabling} que garante a possibilidade de se implementar clean-slate SDN based netwotk at a telecom operator  usando o conceito de endereçamento horizontal por meio de títulos. Num cenário tradicional envolvendo clientes residenciais conectados a uma rede comercial é provocada uma alteração no seu método de acesso, de forma diferente da convencional. Tudo isso sem grandes contratempos para o usuário final, onde uma aplicação é executada no ETArch com monitoramento do tráfego entre os participantes.
 
 
* A partir dessa implementação, existe a firme intenção de se montar um testbed que permita uma série de desenvolvimentos que poderão atestar a eficiência e potencialidade desta solução que colabora para que a futura Internet possa responder a uma serie de demandas atuais e futuras.
<br>
 
=== Sections ===
<br>
 
\section{Related Work}
\input{RelatedWork.tex}
\section{Entity Title Architecture (ETArch) Pilot}
\input{ETArch-pilot.tex}
\section{Deployment and Experimentation}
\input{case-study.tex}
\section{Results} \label{sec:results}
\input{results.tex}
\section{Concluding Remarks and Future Works}
\input{conclusion.tex}
<br>
 
=== Related Work ===
<br>
 
* Inúmeros artigos estão focados em propor iniciativas que façam com que a Internet de hoje consiga suportar os novos requisitos que surgiram com o passar do tempo e os que ainda estão por vir. Uma destas \cite{Barath:2012:Software-defined}, aborda duas questões interessantes: qual é o problema da Internet atual e por que os esforços atuais são insuficientes para solucionar tais problemas? Sobre a primeira questão, são apontadas as deficiências da rede atual alegando que nenhuma proposta tem sido efetivamente implementada principalmente porque existe um forte acoplamento entre a arquitetura e a infraestrutura. Sobre a segunda questão, endereça a ideia da necessidade de explorar um modelo clean-slate e isto leva a mudanças significativas para o IP (ou seus sucessores) forçando trocas de roteadores usados para construir a rede. Para prover o desacoplamento, o Open Flow é uma das soluções mas ainda encontra resistência porque pode provocar substancial aumento de custos.
 
* Para isso sugere a necessidade de encontrar formas de desacoplar arquitetura da infraestrutura sempre visando a redução de custos e a minimização do impacto na adoção de uma nova arquitetura e propõe uma aplicação  sistemática de ferramentas que já estão disponíveis atualmente. Dessa forma, considera um projeto onde o plano de dados consiste de um núcleo de rede que usa seu próprio esquema de endereçamento interno e a borda da rede que usa software-forwarding e neste caso, optando por SDN - Software Defined Networks para controlar os roteadores de borda.
 
 
*  O projeto desta nova proposta, chamada de Software-Defined Internet Architecture (SDIA), é baseado em muitas tecnologias disponíveis como SDN, MPLS, middleboxes e software forwarding, todos aplicados de maneira sistemática. O resultado é um projeto flexível e modular onde novos modelos de serviço inter-domínios podem ser implementados em software.
 
 
* O NEBULA \cite{Tom:2012:NEBULA}, uma nova arquitetura para Internet propõe 3 camadas: NCore, o núcleo de rede que conecta data centers entre si, NDP, o NEBULA Data Plane que fornece controle de acesso flexível e defesa contra a disponibilidade de ataques e NEBULA Virtual and Extensible Networking Techniques que oferece aos usuários um espectro flexível e dinâmico de escolhas de conectividade. Esta proposta é baseada no fato de que a cloud computing suportará um grande percentual de carga de aplicações sobre a Internet e que o acesso aos recursos da cloud computing demandarão novos aspectos arquiteturais da rede, isto é, dependabilidade, segurança e outros.
 
 
* Como é baseada em alta performance e alta disponibilidade do core network, um protocolo do plano de dados novo que incorpora primitivas fundamentais exigidas para o controle de acesso e uma nova arquitetura de plano de controle distribuído que provê uma interface com quais recursos da rede podem ser alocados.
 
 
* Em \cite{clark2012design}, o autor aponta a grande utilização dos protocolos desenvolvidos para a arquitetura atual da Internet mas ressalta que não atendem a todas as necessidades atuais dos usuários. Sugere que possa haver um bloco de construção melhor que não seja o datagrama e informam que tem usado a proposta de "fluxos" para caracterizar um novo bloco de construção. Essas iniciativas estão sendo direcionadas e não se pode desprezar a ideia de quem tem fomentado a grande rede mundial deste seu nascimento.
 
 
* Para isso, endereça aspectos de uma nova arquitetura a partir de 3 abordagens:  information-centric networking (ICN), cloud networking, and open connectivity services. Baseado no enorme crescimento da Internet e prevendo muito desafios, descreve opções para fornecer algumas soluções. Com respeito ao ICN, lista problemas relacionados com a arquitetura atual como armazenamento para chaching information e destaca quatro desafios: escalabilidade global, gerenciamento de cache, controle de congestão e questões de implementação.
 
 
* Para Cloud Networking destaca aplicações de rede que podem flutuar rapidamente em popularidade e em quantidade de interações de usuários sendo que, este fenômeno está se tornando uma variável crítica de controle dentro das redes das operadoras que são complexas e diversificadas. Sugere então uma solução que distribua e espalhe a cloud para que fique mais próxima do usuário final reduzindo assim a latência. Até este ponto lança o termo mis computing ao invés de cloud computing.
 
 
* Finalmente, apresenta o problema do transporte da informação devido à inabilidade da rede atual em explorar informação adicional (semântica) que está disponível no final ou no limite dos sistemas já que o transporte depende de encaminhamento sem conexão  de pequenos pacotes de dados. O desafio endereçado, entre outros, focaliza o desenvolvimento de um conceito flow-aware leve através do roteamento e gerenciamento de comunicações multipoint/protocol/path.
 
 
* BeHop tem um objetivo muito interessante de implementar um testbed wireless para Dense WiFi Networks frequentemente encontradas em configurações residenciais e corporativas. O cenário tem um campus como local e registrou 30 usuário como "guinea pigs" onde o principal interesse é estudar e avaliar os pros e contras de novas maneiras de controlar redes WiFi. BeHop fornece um framework de proposta geral para experimentação com um amplo conjunto de técnicas para controle de potência, canal e associação \cite{yiakoumis2014behop}.
 
 
* Como foi feita uma integração entre BeHop e a rede em produção, foi possível mostrar os benefícios de uma implementação no mundo real e enquanto isso manteve-se a desejada flexibilidade para processar experimentos. Neste processo, é essencial estudar e avaliar as estratégias do gerenciamento do WiFi e suas implicações sobre as condições encontradas em uma rede real (diversidade do cliente, mobilidade, interferência com as redes vizinhas). Foi usado um testbed para transportar tráfego real de usuário de dispositivos WiFi conectados e ao mesmo tempo, foi mantido a flexibilidade para aplicar alterações frequentes, atualizações e ocasionalmente forçar a rede a cair, logicamente sem trazer qualquer impacto para a experiência do usuário.
 
 
* O artigo de Yiakoumis \cite{yiakoumis2012putting} tem uma proposta apoiada por vários segmentos, o de colocar o usuário final no controle, não o ISP. Muitos destes últimos, tem criado controvérsias com visões contrárias mas a ideia defendida é a de permitir que a escolha do usuário possa guiar o gerenciamento do tráfego da rede, não apenas dentro das residências mas também dentro do ISP. Duas inovações são feitas para um possível serviço. Primeiro, fornecer agente intuitivo muito fácil de usar que permita usuários leigos expressarem suas escolhas (ou selecionar um perfil) e traduzi-las para semânticas na rede (bit-rate, low-latency, priority, etc. Segundo, a preferência do usuário (em semânticas de rede) precisa ser comunicada para o ISP através de uma abstração simples e estável que ainda precisa ser implementada em um datapath na rede.
 
 
* Como contribuição é construído um protótipo de user-agent e o plano de controle para o ISP que implementa um projeto de rede caseira onde usuários especificam suas escolhas e as sinalizam para o ISP. A divisão do trabalho entre usuários e ISPs são consideradas e descrevem user-agents que traduzem intenções de alto nível do usuário para semânticas de rede de baixo nível. Um slicing, um conjunto isolado de recursos é sugerido e o mapeamento do tráfego para o slice apropriado pode garantir as propriedades desejadas de acordo com os recursos provisionados.
 
 
* Uma implementação interessante foi feita por Hampel, Steiner e Bu em \cite{hampel2013applying} onde propõe o SDN em uma operadora mas em cima da rede IP. Neste caso, Elementos de encaminhamento OpenFlow executam vertical forwarding para interoperar em uma infraestrutura legada usando IP junto com protocolos convencionais de roteamento.
 
 
* Todas essas propostas avaliaram condições onde as soluções pudessem ser implementadas utilizando estruturas de redes atuais com a implantação de serviços onde a arquitetura pudesse estar desacoplada da infraestrutura de rede, permitindo assim a viabilização de novos experimentos envolvendo SDN.
<br>
 
=== Entity Title Architecture (ETArch) Pilot ===
<br>
 
* As inúmeras pesquisas que estão sendo feitas no sentido de redesenhar a arquitetura da Internet colaboram para a evolução dessa grande rede mundial. Juntando-se a esse exército de pesquisadores ao redor do mundo, o grupo do ETArch Pilot pretende plantar sementes que permitirão pesquisas em experimentos futuros extrapolando o espaço de um laboratório ou de um campus.
 
 
* Este trabalho tem como principal objetivo aproximar semanticamente as camadas superiores das camadas inferiores e para isso utiliza a proposta do ETArch - Entity Title Architecture operando sobre uma rede comercial. Prevê neste modelo  a possibilidade de atender aos requisitos da Internet, atuais e futuros. ETArch  é uma arquitetura de rede clean slate onde esquemas de identificação e endereçamento são baseados em uma designação independente de topologia que unicamente identifica uma Entidade, chamada Título e na definição de um canal que unifica múltiplas entidades de comunicação chamadas Workspaces.
 
 
* Entidades no Modelo de Títulos diferem do conceito definido em algumas literaturas e não são consideradas simples recursos em uma rede mas sim elementos cujas necessidades de comunicação devem ser entendidas e suportadas pela Camada de Serviço e posteriormente pelas camadas inferiores como a Física e Enlace. A seguir, são detalhados os principais conceitos e componentes do ETArch.
 
 
* Entidade é um elemento que possui necessidade de se comunicar e capacidades que podem ser entendidas pelas camadas da arquitetura proposta. Uma entidade pode ser um equipamento, um usuário, uma aplicação, uma coisa, etc. Uma entidade possui ao menos um título e uma localização, denominada Ponto de Conexão (PoA - Point of Attachment), um switch é um exemplo de PoA. Do ponto de vista de mobilidade esta separação é importante, pois a localização de uma entidade pode variar ao longo do tempo. Essas entidades podem se relacionar entre si, através dessas relações podem herdar propriedades, exceto o título \cite{de2012enabling} \cite{silva2011domain}.
 
 
* O Título é o que identifica unicamente uma entidade e esta pode possuir vários títulos. Um conjunto de Títulos é agrupado em um Namespace que também deve possuir um título único e esse Namespace é responsável pela relação entre o Titulo e a Entidade. Um Título é definido por uma tupla, cuja especificação é Namespace::Identificação-entidade. Já Workspace é um barramento lógico, independente da topologia, no qual entidades podem se ligar (Attach) para participar de um domínio de comunicação. O endereçamento das entidades são realizadas a nível de aplicação, essas entidades não se comunicam diretamente e sim por meio de um canal.
 
 
* O Workspace pode ser composto de redes cabeadas e redes sem fio, sendo que elas podem se comunicar entre si transparentemente. É identificado por seu título e pode ser distribuído através de um ou mais elementos de rede (NE) possuindo as seguintes propriedades: título que identifica unicamente um Workspace, lista de NEs que registra os títulos dos elementos que fazem parte do Workspace, lista de capacidades que podem ser oferecidas às entidades, lista de requisitos que as entidades devem suportar e por fim, informação do nível de visibilidade, se público ou privado.
 
 
* Um Workspace é criado quando uma entidade produz algum serviço que pode ser consumido por outras entidades como em um compartilhamento de arquivos. Ele é controlado por um DTS (Domain Title Service) que tem como responsabilidade, a resolução de títulos, gerenciamento das entidades e manutenção da relação entre as Entidades e Títulos. O DTS é constituído de DTSAs (DTS Agents) e mantém uma base de conhecimento com informações do ambiente, assim é possível monitorar e controlar os requisitos de uma entidade. Os DTSs gerenciam o ciclo de vida das entidades do inicio ao fim das atividades. A figura \ref {DTS} mostra a visão de um Workspace, controlado por DTSAs que englobam alguns NEs.
 
 
\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.20]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/ETArchPilotDTS}
\caption{Principais Componentes da Arquitetura - DTS, DTSA, Entity, Title e o Workspace.}\label{DTS}
\end{figure}
<br>
<br>


* Chapters
[[Arquivo:ETArchPilotDTS.jpg]]
** Title
<br>
*** A new network architecture on top of a current network MetroEthernet
** Abstract
*** Luiz Cláudio
***
** Introduction
*** Luiz Cláudio
** Related Works
*** Luiz Cláudio
*** A01: Starts with two questions: what is the problem and why are current efforts insufficient? About the first question, points the deficiencies. of the current network know to all and the second question addresses the idea of the decoupling between architecture and infrastructure. To implementation the SDN was chosen like form to provide the software forwarding. Besides this, MPLS is also used because it does a good distinction between the network edge and the network core, and decouples the core from whatever global architecture is deployed. A new designed proposed, named Software-Defined Internet Architecture (SDIA) that is based in many technologies live SDN, MPLS and softare forwarding applied im a systematic manner. The result is a modular and flexible design where new interdomain service models can be implemented in software where ISM is merely a service agreed upon by the domains, and the notion of being able to define a new ISM with merely software deployed on each domain’s edge-controller (which then installs software on the edge router) could make it easier for the domains to support new services
*** A02: Inserts the NEBULA, a new Internet archictecture with three tiers:  NCore, the network core that connects data centers to each other, NDP, the NEBULA Data Plane that provides flexible access control and defense against availability attacks and NVENT, NEBULA Virtual and Extensible Networking Techniques that offers users a dynamic and flexible spectrum of connectivity choices, This proposal is based in fact that the cloud computing will support a large percentage of the application workload upon a Internet and that acesses to  cloud computing resources will demand new architectural features from a network, e.g, dependability, security and others. Despite a big team of the researchers, the project also shows a lack of clarity on exactly what an “architecture” was and has doubts like is an architecture defined by the design goals? The components and the interaction of components? An abstract description of a vision and its realization? Or something else entirely?
*** A03: Catalogs one view of the original objectives of the Internet architecture, and discusses the relation between these goals and the important features of the protocols and highlight that the top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.  Secondary goals: Internet communication must continue despite loss of networks or gateways, the Internet must support multiple types of communications service., the Internet architecture must accommodate a variety of networks, the Internet architecture must permit distributed management of its resources, the Internet architecture must be cost effective, the Internet architecture must permit attachment with a low level of effort and the resources used in the internet architecture must be accountable. This definitions are importants to subsidize new proposals.
*** A04: Addresses aspects of a new architecture, from three approaches: information-centric networking, cloud networking, and open connectivity services. Based on the enormous growth of the Internet and predicting many challenges, describe options to provide some solutions. With respect to  information-centric networking (ICN) lists problems related with the current archiecture like storage for caching information and highlights four challenges: global scalability, cache management, congestion control and deployment issues. Already to Cloud Networking explains about network applications that can fluctuate rapidly in popularity and in terms of the amount of user interaction and this way becoming a highly variable to control when running inside more complex and diverse operator networks. Suggests a solution that distributes the cloud more deeply into the network and disperses the cloud closer to the end user to reduce latency. At the point, launchs the term ''mist computing''  instead cloud computing. At least, approachs the matter of the transport of information because the inability of the current network  to exploit the additional (semantic) information that is available in the end or edge systems since transport relies on connectionless forwarding of small data packets. The challenge addressed, among others, focus in the development of a lightweight flow-aware concept of routing across and managing of multipoint/protocol/path communications.
*** A15: BeHop: A Testbed for Dense WiFi Networks: Be Hop has a objective very interesting, deploy a wireless testbed for dense WiFi networks often seen in residential and enterprise settings. The scenario has a campus like local and invites 30 users for "guinea pigs"  where the principal interest is study and evaluate the pros and cons of new ways of controlling WiFi networks. BeHop provides a general-purpose framework to experiment with a wide range of techniques for channel, power, and association control. As was made a integration between BeHop and the production network, was possilbe show the benefits of a realworld deployment while keeping the desired flexibility to run experiments.  In deployment od the BeHop in a real-world setting is essential to study and evaluate WiFi management strategies and their implications under the conditions found in a real network (client diversity, mobility, interference with neighboring networks). Was used a testbed to carry real traffic of users from any WiFi-connected device; at the same time, was maintained the flexibility to apply frequent changes, upgrade, and occasionally break the network, ideally without any impact on users’ experience.
*** A16: Putting Home Users in Charge of their Network: This paper propose turning the debate about to place the home user firmly in control, not the ISP. Many ISPs have introduced controversial with respect to constrain the applications we use and the intention of this article is advocate that user choice should guide the management of network traffic—not only inside the home but also within the ISP. Two innovations are made for a service possible. First, provide a very easy to use and intuitive agent that allows non-technical users to express their choices (or to pick a profile), and translate them to network semantics (bit-rate, low-latency, priority, etc.). Second, the user preference (in network semantics) needs to be communicated to the ISP through a simple and stable abstraction, which in turn needs to be implemented in the network datapath. Like a contribution is built  a prototype of the user-agent, and the control plane for the ISP that implement a project of the home network where users specify their choices and signal them to the ISP. The division of labor between users and ISPs are considered, and described user-agents, which translate high-level user intentions to low-level network semantics. A slicing, a isolated set of resources and network traffic, is suggested and the mapping traffic to the appropriate slice can ensure desired properties, according to the provisioned resources.
** Entity Title Architecture (ETHArc) Pilot
*** Hélvio e Pedro Damaso
O ETHArch é uma arquitetura proposta para a Internet do Futuro desenvolvida por... . Na implementação do testbed para o desenvolvimento e teste da
arquitetura foram utilizadas diversos ferramentas, entre eles o Openflow, o qual permite que os pesquisdores rodem protocolos experimentais em sua redes.
Assim, uma ilha, nome dado a um domínio ETHArch, é constituido pelo DTSA e seus clientes, os switches OpenFlow e seu respectivo controlador.
O objetivo desse trabalho é propor a implantação de uma rede virtual que permita interligar os vários domínios remotos (ilhas) utilizando a rede IP de uma operadora, possibilitando aos desenvolvedores um ambiente integrado de desenvolvimento e testes mais próximo a um cenário real de uilização.
Em um ambiente local (ilha) padrão os switches Openflow estão diretamente conectados uns aos outros conforme a Fig. 1. Entretanto, na rede da operadora os switches Openflow de cada ilha estarão separados por uma estrutura IP que não implementa essa especificação (Fig. 2).
Numa rede de switches Openflow os switches diretamente conectados são identificados mediante a utilização do protocolo LLDP ( Link layer Discovery Protocol). Entretanto na estrutura proposta, esses swicthes estão geograficamente dispersos. Assim torna-se necessária uma solução para torna esses switches virtualmente adjacentes para que o encaminhamento dos pacotes programados pelo Controlador possa funcionar de maneira apropriada.
A solução proposta para criar as adjacências entre os switches Openflow foi o tunelamento dos frames LLDP usando protocolo GRE (Generic Routing Encapsulation), bastante popular e suportada pelo OpenVswitch, utilizado no nosso cenário.  O OpenvSwitch é um switch virtual multilayer que implementa o protocolo Openflow, além de possuir suporte ao tunlamento GRE. Dessa forma é possível criar uma rede virtual de switches Openflow, sobre a rede IP da operadora, interligando as diversas ilhas de desenvolvedores (Fig 3).


** Deployment and Experimentation
=== Deployment and Experimentation ===
*** O desenvolvimento do ETArch em um ambiente de MetroEthernet, com clientes reais e em pleno funcionamento, traz consigo uma série de dificuldades, dentre elas, usar a estrutura legada baseada na arquitetura TCP/IP não só para o plano de controle, mas para o plano de dados, de forma que não fosse afetado nenhum usuário, ou regra de funcionamento da rede. Para isto, era importante criar túneis, ou formas alterantivas, para que todos elementos da rede que não são controláveis funcionassem como um meio transparente, ou seja, apenas encaminhassem os pacotes e dados provenientes do ETArch até um componente que esteja registrado no controlador, e que pudesse dar as tratativas que estivessem definidas no mesmo.
<br>
*** Murilo Borges e Alex
 
*** Instalação OpenvSwitch (OVS) no ubuntu
* Para mostrar as possibilidades de responder aos grandes desafios atuais e futuros, este trabalho propõe a implementação de um testbed para o desenvolvimento e teste da arquitetura ETArch. Ciente de que uma implementação que venha radicalizar a utilização dos padrões tradicionais precisa trazer o mínimo de esforço para a grande base de usuários no mundo, o ETArch se utiliza de ferramentas atuais como o Openflow, que permite que  pesquisadores rodem protocolos experimentais em sua redes que possam ser também suportadas por estruturas presentes no cenário mundial como a rede MetroEthernet. Para atingir esse objetivo, utiliza o conceito de ilha, nome dado a um domínio ETArch que é constituído pelo controlador denominado DTSA e seus clientes e os switches OpenFlow rodando em cima de uma rede MetroEthernet tradicional servida por uma operadora comercial de telecom.
*** Configuração do OVS
 
*** Criação de tunel GRE entre 2 OVSs
* A estrutura da operadora segue a arquitetura de anel, com anéis primários que são os centrais e anéis secundários que abordam o cliente, similar à figura ~\ref{RedeMetroFigure}:
*** Comprovação através da visualização do protocolo LLDP
 
*** Mover Estrutura de uma rede local experimental para uma rede MetroEthernet
\begin{figure}[htbp]
*** ARTIGOS:  
\centering %
**** http://www.icsi.berkeley.edu/pubs/networking/extendingnetworking09.pdf
\includegraphics[scale=0.35]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/Rede_metro_1}
**** http://sbrt.org.br/sbrt2012/publicacoes/99845_1.pdf
\caption{MetroEthernet Topology}\label{RedeMetroFigure}
** Results
\end{figure}
*** Alex Vaz, Murilo e Luiz Cláudio
 
*** Comunicação baseada em Workspaces -> Menor Uso de Banda se comparada a arquitetura atual (a diferença aumenta com o acréscimo de clientes)
 
*** Controlador Centralizado -> Definição das rotas, maior QoS?
* Os anéis primários são equipamentos distribuídos pela área de atuação. Estes equipamentos em sua grande maioria operam com SDH  (Synchronous Digital Hierarchy) e DWDM (Dense Wavelength Division Multiplexing) [A35] \cite{huynh2007metropolitan}. Outra característica dos anéis primários é sua grande capacidade de transporte, pois chegam a operar com taxas de superiores a 100 Gb/s. Os anéis secundários são caracterizados por um raio geográfico menor e capacidades de transporte menores. As taxas de anéis secundários não passam de 40 Gb/s.
*** Mobilidade das entidades?
 
*** Sinalização de controle?
* O objetivo desse trabalho, portanto, é propor a implantação de uma rede virtual que permita interligar os vários domínios remotos (ilhas) utilizando a rede IP de uma operadora, possibilitando aos desenvolvedores um ambiente integrado de desenvolvimento e testes mais próximo a um cenário real de utilização. Em um ambiente local () padrão, os switches Openflow estão diretamente conectados uns aos outros, conforme a figura 2. Entretanto, como mostrado, na rede da operadora, os switches Openflow de cada ilha estariam separados por uma estrutura IP que não implementa essa especificação conforme figura \ref{RedeOpenFlowFigure}.
*** Atuação dinâmica do controlador?  
<br>
*** Eliminação de elementos?
 
** Conclusions
 
*** Luiz Cláudio e Flávio
[[Arquivo:RedeOpenFlow.jpg]]
** References
 
*** A01 - Software-defined internet architecture: decoupling architecture from infrastructure since the control plane is separated from data plane.  
 
*** A02 - NEBULA - A Future Internet That Supports Trustworthy Cloud Computing
\begin{figure}[htbp]
*** A03 - The design philosophy of the DARPA internet protocols1988
\centering %
*** A04 - Content, connectivity, and cloud: ingredients for the network of the future
\includegraphics[scale=0.35]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/RedeOpenFlow}
*** A05 - Standardizing a reference model and autonomic network architectures for the self-managing future internet
\caption{Rede OpenFlow}\label{RedeOpenFlowFigure}
*** A06 - Developing Information Networking Further_ From PSIRP to PURSUIT - Springer
\end{figure}
*** A07 - Illustrating a publish-subscribe Internet architecture
 
*** A08 - Optical Network Virtualization
 
*** A09 - Scalable Service Deployment on SDN
* O desenvolvimento do ETArch sobre a infraestrutura de uma rede MetroEthernet, com clientes reais e em pleno funcionamento, traz consigo uma série de dificuldades, dentre elas, usar a estrutura legada baseada na arquitetura TCP/IP não só para o plano de controle, mas também para o plano de dados, de forma a não afetar nenhum usuário ou regra de funcionamento da rede. Para isto, era importante criar formas alternativas, para que todos elementos da rede que não são controláveis funcionassem como um meio transparente, ou seja, apenas encaminhassem os pacotes e dados provenientes do ETArch até um componente que estivesse registrado no controlador, e que pudesse dar as tratativas que estivessem pré-definidas. Em suma, em um ambiente local (ilha) padrão, os switches Openflow estão diretamente conectados uns aos outros conforme figura \ref{RedeOpenFlowFigure}.  
*** A10 - HIP Based Network Access Protocol in Operator Network Deployments
 
*** A11 - Optical FlowVisor: An OpenFlow-based Optical Network Virtualization Approach
 
*** A12 - Identifying standardization opportunities of an operator-driven, framework for unifying autonomic network and service management
* Numa rede de switches Openflow, os switches diretamente conectados são identificados mediante a utilização do protocolo LLDP ( Link layer Discovery Protocol) \cite{congdon2002link}. Entretanto na estrutura proposta, esses switches estão geograficamente dispersos. Assim torna-se necessária uma solução para tornar esses switches virtualmente adjacentes para que o encaminhamento dos pacotes programados pelo Controlador possa funcionar de maneira apropriada. A solução proposta para criar as adjacências entre os switches Openflow foi o tunelamento dos frames LLDP usando protocolo GRE (Generic Routing Encapsulation) \cite{hanks2000generic}, bastante popular pela sua simplicidade e compatibilidade. Dessa forma é possível criar uma rede virtual de switches Openflow, sobre a rede IP da operadora, interligando as diversas ilhas de desenvolvedores.
*** A13 - The Future of Telecom Operators: Capabilities for Rapid Change
 
*** A14 - IP Broadband Architecture for Service Experience
 
*** A15 - BeHop : A testbed for dense WiFi networks
[[Arquivo:RedeOperadora.jpg]]
*** A16 - Putting home users in charge of their network
 
*** A17 - Slicing home networks
 
*** A18 - SDN and Tunneling for Mobile Networks
\begin{figure}[htbp]
*** A19 - Virtualized Network Isolation Using SDN.
\centering %
*** A20 - Network Virtualization with Cloud  Virtual Switch
\includegraphics[scale=0.25]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/RedeOperadora}
*** A21 - Extending Networking into the Virtualization Layer
\caption{Rede da Operadora}\label{RedeOperadoraFigure}
\end{figure}
 
 
* Além da criação de túneis, para que a arquitetura funcione é necessário que existam elementos controláveis ao longo da rede. Devido a estrutura em funcionamento não apresentar estes elementos, optamos por utilizar nas pontas (próximo ao cliente e ao controlador) um equipamento virtual que possibilitasse a conexão com o controlador e que servisse de conexão para o cliente. Para tal propósito, optamos pelo OpenvSwitch (OVS), que pode facilmente ser instalado em um hardware simples, como a maioria dos PCs. Os  switches virtuais providos pelo OpenVSwitch, que estão dispersos na rede, aliados aos túneis, fazem uma estrutura controlável virtualmente adjacente.
 
 
* Para abordar os clientes, a operadora oferece ADSL (Asymmetric Digital Subscriber Line), VDSL (Very-high-bit-rate Digital Subscriber Line)  e FTTH (Fiber To The Home) \cite{tanenbaumredes}. Esta abordagem em sua grande maioria parte de um anel secundário, porem quando há uma concentração de tráfego muito grande, por exemplo, em condomínios fechados, prédios comerciais ou grandes empresas  esta abordagem pode partir direto de um anel primário.
 
 
* Segundo o relatório [A36] emitido publicamente pela empresa, no terceiro semestre de 2014, existiam 498 mil clientes ativos do serviço de  comunicação de dados, sendo que pouco mais de 400 mil clientes estavam usando a tecnologia ADSL e o restante estava distribuído entre VDSL e FTTH, tendo portanto grande capacidade de tráfego. Também conta com uma rede de backbones de alta capacidade espalhada pelo sudeste do país sendo assim uma grande fornecedora de interligação entre operadoras e de last mile.
 
 
* Devido ao grande uso do ADSL, os testes foram feitos usando esta tecnologia, logo, nos testes citados abaixo, foram usadas máquinas interligadas via ADSL igual aos clientes comuns, passando por concentradores, por DSLAMs (Digital subscriber line access multiplexer) e por toda a infraestrutura usada nesta tecnologia.
 
 
* Para a implementação, primeiramente, o controlador desenvolvido para o ETArch foi instalado em um servidor de uma rede local. Na mesma rede, foram inseridos dois PCs, ambos com sistema operacional Ubuntu Linux (14.04), os quais faziam o papel de clientes e switches, ou seja, executavam tanto o switch virtual, quanto a aplicação utilizada para os testes.
 
 
* Para a instalação do OpenVSwitch, foram usados os comandos:
 
 
* \begin{itemize}
* \item apt-get update; apt-get install openvswitch-switch
* \end{itemize}
 
 
* O primeiro atualiza a lista de pacotes disponíveis nos repositórios oficiais para instalação, o segundo efetiva a instalação do OVS. A partir deste ponto é necessário iniciar o serviço e configurá-lo:
 
 
\begin{itemize}
\item service openvswitch-switch start 
\item ovs-vsctl add-br br0 
\item ovs-vsctl set-controller br0 tcp:\textless ServerIP:Port\textgreater
\end{itemize}
 
 
* Feito isso, em ambas as máquinas, o switch já possui uma bridge adicionada e já está registrado no controlador. Para a conexão das duas máquinas, portanto dos switches, foi utilizado um túnel GRE, pois o mesmo oferece um túnel, simulando um enlace entre dois pontos de uma rede, utilizando um endereço IP, o que atende a proposta inicial. E mais, o próprio OVS já é capaz criar este tipo de túnel internamente. Para isto é utilizado o comando:
 
 
\begin{itemize}
\item ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote\_ip=\textless hostIP\textgreater
\end{itemize}
 
 
* Em cada uma das máquinas o hostIP representa a outra máquina, ou seja, um túnel é definido entre as duas, e portanto a estrutura de configuração do OpenvSwitch com GRE e a interação entre as entidades, inclusive o controlador, fica definida sobre a estrutura real como proposto.
<br>
 
=== Results ===
<br>
 
* Para atender aos objetivos inicialmente propostos, a comprovação pode ser demonstrada a partir da montagem e configuração da estrutura da rede e na posterior troca de dados e informações entre as entidades através de processos e aplicativos desenvolvidos especificamente para a rede ETArch.
 
 
* O primeiro modo de confirmação é baseado na implementação do controlador ETArch, que força todos os switches registrados a enviarem regularmente um pacote LLDP (Link Layer Discovery Protocol). Este protocolo é muito importante para o mapeamento da rede em si, sinalizando quais são os switches e os caminhos entre os mesmos, para que o controlador tenha a visão total da rede. Sabendo disso e usando uma ferramente de monitoramento de pacotes (tcpdump), observamos a troca de informações entre os switches, especificamente o LLDP anteriormente citado, encapsulado no GRE, conforme a figura \ref{LLDPFigure}.
 
[[Arquivo:LLDPARTIGO.png|center|frame|Checagem LLDP]]
 
 
\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.4]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/LLDPARTIGO}
\caption{Monitoring LLDP}\label{LLDPFigure}
\end{figure}
 
 
* Esta informação sinaliza que estes switches estão virtualmente adjacentes, ou seja, a estrutura legada permaneceu presente no cenário da rede laboratorial, onde foi inicialmente aplicado e de forma transparente, não exigindo alterações sensíveis nas práticas em curso na operadora.
 
 
* A partir da confirmação do funcionamento de toda a estrutura, o controlador e as máquinas foram migrados para o ambiente MetroEthernet. Neste ambiente, o controlador passa a ter um IP válido. Cada um dos clientes foi conectado, utilizando a rede legada, isso quer dizer que nesta situação estes clientes estariam separados do controlador e entre si, por vários elementos de rede, como switches, DSLAMs, e até o próprio modem de acesso. Para a construção dos túneis GRE, os OVSs precisam ter um IP válido e por este motivo o próprio cliente precisa efetuar a conexão PPPoE diretamente com o ISP.
 
 
* O processo de configuração dos OVSs é repetido, substituindo os IPs anteriores pelos novos obtidos na rede, e assim, toda a estrutura legada não influenciaria no controle e conexão entre os clientes. O controlador enxerga apenas os switches controláveis e entre eles, um enlace direto. Para comprovação desta etapa, o processo é o mesmo, pela visualização dos pacotes LLDP e suas respectivas respostas mostrando que a implementação apresentou sucesso.
 
 
* Para finalmente, comprovar que o ambiente preparado para a nova arquitetura é capaz de suportar aplicações que usam a nova arquitetura, envolvendo as entidades e a comunicação no ETArch, sem realizar alterações adicionais, foi executado um aplicativo de chat desenvolvido anteriormente para funcionar nesta nova proposta implicando na não utilização dos processos tradicionais (TCP/IP).
 
 
* O aplicativo é chat desenvolvido em python e  executado diretamente do terminal possuindo parâmetros como o nome da Entidade e o Workspace. Executando-o em ambas as máquinas, cada uma com um título diferente e atachadas ao mesmo workspace, foi observado que conforme o conceito definido na arquitetura, ambas puderam visualizar o conteúdo inserido neste workspace (w1), conforme a figura ~\ref{CHATFigure}. Isto valida a implementação e mostra como resultado o funcionamento pleno da arquitetura no ambiente proposto.
 
 
[[Arquivo:CHATARTIGO.png|center|frame|Execução do chat]]
<br>
 
\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.6]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/CHATARTIGO}
\caption{Running Chat}\label{CHATFigure}
\end{figure}
<br>
 
=== Conclusion ===
<br>
 
 
* Observando o que foi descrito nos capítulos anteriores, pode-se comprovar a capacidade de utilização do ETArch Pilot na rede legada, possibilitando uma implantação gradual sem necessidades de altos investimentos na troca de equipamentos, alterações em ambientes e treinamento de pessoas em um ISP.
 
\begin{itemize}
\item Responder ao artigo SDIA: what is the problem and why are current efforts insufficient?
\item Comunicação baseada em Workspaces ->  
\item Menor Uso de Banda se comparada a arquitetura atual (a diferença aumenta com o acréscimo de clientes)
\item Controlador Centralizado -> Definição das rotas, maior QoS?
\item Mobilidade das entidades?
\item Sinalização de controle?
\item Atuação dinâmica do controlador?
\item Eliminação de elementos?
\end{itemize}
 
 
* Como trabalhos futuros, existem várias frentes como por exemplo:
\begin{itemize}
\item Aumentos de clientes e switches do OpenFlow
\item Comprovação da eficiência do modelo de Workspaces através de streaming de vídeo
\item Eliminar algum elemento da rede legada
\item Análise comparativa à exclusão ou inclusão de uma ou mais rotas, eficiência no encaminhamento de pacotes, reposicionamento das entidas e QoS, QoS
\end{itemize}
 
<br>
 
=== Acknowledgment ===
<br>
 
* This work has been partially funded by the European Community's Seventh Framework Programme, under grant agreement n. 258365 (OFELIA project), by the Brazilian agencies: CAPES, CNPq and FAPEMIG and also by PROPP/UFU.
<br>
 
=== [[References]] ===
<br>
 
== ICN 2017 ==
<br>
 
* Finalização: 01/12/2016
* Submissão: 05/12/2016
* Data do evento: 23 a 27/05/2017 - Veneza - Itália
<br>
 
=== Testers ===
<br>
 
# - Alex Vaz
# - Ernélio
# - Vinicius
# - Eduardo Freire
# - Tiago
# - Abadio
# - Daniel
# - Lucas Carvalho
# - Tayro
# - Douglas
 
 
# - Luiz Cláudio  
# - Matheus Silva Santos
# - Eustáquio Fernandes Júnior
# - Júlia Rizza
# - Rafael Marra
# - Marc Sué Pires Morais Junior
# - Laércio Lopes Pereira Lima
# - Lincoln Borges Ferreira
# - Pedro Henrique da Costa Avelar
# - Matheus Cunha Reis
# - Lucas Correia Bernardes
# - Leandro de Medeiros Ferreira
# - Alunos de GSI003
# - Alunos de GSI009
 
 
# - Pedro Damaso
# - Diego
# - Caio
# - João Ludovico
# - John Martinez
# - Juan
 
# - Rogério
# -
 
 
<br>
 
== ICC 2017 ==
<br>
 
* Finalização: 02/10/2016
* Submissão: 14/10/2016
<br>
 
* 11/09/2016 - Entrega dos trabalhos relacionados, tunelamento, ETArch
* 18/09/2016 - Implementação e revisão dos anteriores
** Distribuição geográfica
** Diversificação de ambientes
** Capilaridade dos usuários
* 25/09/2016 - Conclusão e revisão da implementação
* 02/10/2016 - Artigo completo incluindo introdução
* 12/10/2016 - Tradução e revisão final
<br>
 
== Revisões ==
<br>
 
* Revisão v6 - Luiz Cláudio
** III. ENTITY TITLE ARCHITECTURE (ETARCH ) PILOT  => espero contribuição do Pedro Damaso
*** Paragráfo 1: Relacionar artigo do ETArch que mostra os primeiros resultados em laboratório.
*** Paragráfo 2: Relacionar artigo do ETArch que mostra as definições de Título e Workspace
*** Paragráfo 3: Não ficou claro o que é Camada de Serviço. Incluir explicação no parágrafo anterior.
*** Paragráfo 7: Inclusão da referência 11 => Favor conferir se o que está escrito no texto está condizente com a referência.
*** Último Paragráfo:  Explicar no mesmo ou em um novo parágrafo, o exemplo mostrado na imagem.
**** Não se preocupe com a posição da figura, depois que tivermos o texto mais completo, acertaremos o lugar certo.
** IV. DEPLOYMENT AND EXPERIMENTATION => espero contribuição do Pedro Macedo, Hélvio e Murilo
*** Paragráfo 1: Não está legal o final do parágrafo. Quando se começa a frase: "Para isso, temos o conceito de ilha, nome dado a um domínio ETArch, .." está totalmente deslocado do conteúdo anterior. É necessário, rever esta parte e criar uma frase que conecte a proposta do ETArch com o Rede Metro e OpenFlow.
*** Paragráfo 2: Falta a figura 2. No final do parágrafo ("os switches Openflow de cada ilha estarao separados por uma estrutura IP que não implementa essa especificação (Fig. 3)"). Esta figura 2 é a figura da Rede Metro?
*** Paragráfo 3: Confirmar as figuras de acordo com o final deste parágrafo.
*** Paragráfo 5: Está meio confuso, o OpenVSwitch foi apresentado no parágrafo anterior e neste de novo este elemento é sugerido como se não tivesse sido referenciado antes. Desenvolver o texto de forma que fique coerente o que foi escrito no parágrafo 4 com a menção ao OpenVSwitch neste parágrafo.
*** Paragráfo 6: Avaliar aqui se é melhor referenciar o Tanembaum (nesse cas é necessário referência em inglês e as páginas do livro) ou um artigo ou documento referente ao SDW e DWDM.
*** Paragráfo 7: Idem.
*** Paragráfo 8: Verificar relatório em inglês.
*** Último Paragráfo: Falta um fechamento deste capítulo explicando que a estrutura montada possibilitará os resultados do próximo capítulo.
** V. RESULTS => espero contribuição do Pedro Macedo, Hélvio e Murilo
*** Último Paragráfo: Criar um novo parágrafo a partir de "Isto  valida ..." mostrando mais claramente a diferença entre a implementação do piloto e o mundo tradicional, por exemplo, que este experimento pode ser expandido para dezenas, centenas ou mais de clientes com pouco trabalho em montar a configuração caseira.
*** Imagens e referências em todos os capítulos => => espero contribuição do Gabriel.
* Atualização - v7
** O que foi feito?
*** Inclusão da introdução
*** Inserção das palavras-chave
*** Revisão de todo o texto e correção do Portguês (mesmo que tenhamos que passar para o Inglês é interessante deixá-lo certinho na nossa língua)
*** Anexação e alteração dos labels das imagens
*** Inclusão da referência 11 => Favor conferir se o que está escrito no texto está condizente com a referência.
<br>
<br>


Linha 612: Linha 1 149:
# Se foram feitos experimentos com o ETCP, onde o FINLAN vai entrar?
# Se foram feitos experimentos com o ETCP, onde o FINLAN vai entrar?
<br>
<br>
* A01 - Software-defined internet architecture: decoupling architecture from infrastructure since the control plane is separated from data plane.
* A02 - NEBULA - A Future Internet That Supports Trustworthy Cloud Computing
* A03 - The design philosophy of the DARPA internet protocols1988
* A04 - Content, connectivity, and cloud: ingredients for the network of the future
* A05 - Standardizing a reference model and autonomic network architectures for the self-managing future internet
* A06 - Developing Information Networking Further_ From PSIRP to PURSUIT - Springer
* A07 - Illustrating a publish-subscribe Internet architecture
* A08 - Optical Network Virtualization
* A09 - Scalable Service Deployment on SDN
* A10 - HIP Based Network Access Protocol in Operator Network Deployments
* A11 - Optical FlowVisor: An OpenFlow-based Optical Network Virtualization Approach
* A12 - Identifying standardization opportunities of an operator-driven, framework for unifying autonomic network and service management
* A13 - The Future of Telecom Operators: Capabilities for Rapid Change
* A14 - IP Broadband Architecture for Service Experience
* A15 - BeHop : A testbed for dense WiFi networks
* A16 - Putting home users in charge of their network
* A17 - Slicing home networks
* A18 - SDN and Tunneling for Mobile Networks
* A19 - Virtualized Network Isolation Using SDN.
* A20 - Network Virtualization with Cloud  Virtual Switch
* A21 - Extending Networking into the Virtualization Layer
* A30 - www.openvswitch.org
* A31 - Link layer discovery protocol and MIB. P Congdon - V1. 0 May 20. 2002, http://www. IEEE802, 2002 - ieee802.org
* A32 - RFC 2890. GRE (Generic Routing Encapsulation)
* A33 - Pfaff, Ben, Pettit, J., Koponen, T., Amidon, K., Casado, M. Open vSwitch: Extending Networking into the Virtualization Layer.  Nicira Networks. UC Berkeley, Computer Science Division.
* A34 - RFC 7047. The Open vSwitch Database Management Protocol
** http://sbrt.org.br/sbrt2012/publicacoes/99845_1.pdf => Gostei de artigo mas creio que será útil na próxima seção
* A35 - TANENBAUM, Andrew S. Redes de Computadores. Editora Campus, 4Edição. 2002.
* A36 - Relatorio aos investidores "Release de resultados 3T14", disponível em "www.algartelecom.com.br/ri"
<br>
* [[ICC2017]]


= Sites =
= Sites =
Linha 628: Linha 1 201:
*Academic Earth [http://academicearth.org/]
*Academic Earth [http://academicearth.org/]
* [[TED - Web Semantic]]
* [[TED - Web Semantic]]
= Reuniões =
'''ETArch Pilot'''
* 20/10/2016
** Pauta:
*** Luiz Cláudio:
**** Discutir submissão do artigo
*** Flávio: Sugeriu aumentarmos o número de participantes no Chat e compararmos com processo tradicional
<br>
* 10/06/2016
** Pauta:
*** Luiz Cláudio:
**** Avaliar submissão para http://www.ceel.eletrica.ufu.br/
*** Lucas:
**** Apresentação 1o. experimento de uma rede SDN na rede da Algar Telecom
*** Alex e Murilo:
**** Status dos testes =>  Necessidade de colaboração do Pedro Damaso
* 13/05/2016
** Pauta:
*** Avaliar evento ICWMC 2016 || November 13 - 17, 2016 - Barcelona, Spain
*** Atualizar Status teste feito por Alex e Murilo
*** Entender linha de estudo do Pedro Damaso
*** Atualizar criação do LiveCD
** '''Próximas atividades''':
*** Rafael: Liberar portas novamente
*** Alex, Pedro e Murilo: Testar Chat e DTSA no Lab CA - 2a. feira - 08h30
*** Rogério, Luiz Cláudio e Pedro: Comparar LDAP e Radius na linha de estudo do Pedro
*** Rogério: Continuar montando LiveCD
*** Luiz Cláudio: Discutir com Flávio sobre submissão para próximo evento
** Participantes:
*** Pedro Damaso
*** Rogério Freitas
*** Luiz Cláudio Theodoro
*** Murilo (Viva Voz)
*** Rafael Leonardo (Viva Voz)
<br>
* 13/05/2016
** Pauta:
*** Discussão sobre requisitos pendentes
*** Testes preliminares
** Atividades:
*** Murilo e Alex:
**** 6a. feira:
**** Finalização dos testes de streaming
*** Rafael:
**** Associar interface com Internet na maquina virtual Algar
**** Liberar as portas
*** Luiz Cláudio:
**** Pesquisar eventos para submissão
**** Convidar Adailson para atualizar iniciativas
**** Aprovar solicitação de rede no CTI
*** Rogério:
**** Sugestão de criação de um liveCD
**** Instalação do OpenStack no LIT
**** Conclusão da rede UFU - FEELT
*** Lucas:
**** Aprofundar no piloto do Adailson
**** Próxima reunião:
**** Status testes de streaming
**** Discussão de tópicos
*** Participantes:
**** Pedro Henrique Aparecido Damaso de Melo
**** Rogerio de Freitas Ribeiro
**** Rafael Leonardo Ferreira de Aquino
**** Luiz Cláudio Theodoro
**** Lucas Guandalini
**** Murilo Borges Gomes Machado
<br>


= Eventos =
= Eventos =
Linha 665: Linha 1 312:




= Reuniões =
== Próximas Atividades ==
{{#forminput:form=Reuniao|button text=Crie um nova Reunião}}
 
<br>
[[ETArch Pilot - 29/04/16]] <br>
[[ETArch Pilot - 18/03/16]] <br>
[[ETArch Pilot - 22/01/16]] <br>
 
[[ETArch Pilot - 08/01/15]] <br>
[[ETArch Pilot - 18/12/15]] <br>
[[ETArch Pilot - 09/10/15]] <br>
[[ETArch Pilot - 02/10/15]] <br>


[[ETArch Pilot - 24/04/15]] <br>
[[ETArch Pilot - 10/04/15]] <br>
[[ETArch Pilot - 13/03/15]] <br>
[[ETArch Pilot - 06/03/15]] <br>
[[ETArch Pilot - 10/10/14]] <br>
[[ETArch Pilot - 10/10/14]] <br>
[[ETArch Pilot - 03/10/14]] <br>
[[ETArch Pilot - 03/10/14]] <br>

Edição atual tal como às 20h34min de 7 de novembro de 2016

MEHAR

  • Mondial Entities Horizontally Addressed by Requirements


Colaboradores


  • Alex Vaz Mendes - 9 9945-3763 - alexvazmendes@gmail.com
  • Lucas Guandalini
  • Hugo Barbosa Silva - 9 9769 - 9023 - hugobarbosa@algartelecom.com.br
  • Luiz Cláudio Theodoro - 9976-2676 - lclaudio@algartelecom.com.br
  • Murilo Borges Machado - 9 8888 2100 - murilo.bgm@gmail.com
  • Pedro Henrique Aparecido Damaso de Melo - 9769-2213 - pedroh@algartelecom.com.br
  • Rafael Leonardo Ferreira de Aquino - (34) 9 9992-8457 - rafaell@algartelecom.com.br
  • Rogério de Freitas Ribeiro - 9 9976-3017 - rogeriofr@gmail.com
  • 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)
  • Pedro Macedo Leite - 9992-1743 - pedro.larva@gmail.com (Entrada em 11/10/2013)
  • Flávio Oliveira Silva - 9971-4589 - flavio@ufu.br
  • Ronaldo José Ferreira - 9992-0378 - ronaldo@algartelecom.com.br


Horários de Estudo


Dia SEGUNDA TERÇA QUARTA QUINTA SEXTA
Horário 07-09-11-13-15-17-19-21 07-09-11-13-15-17-19-21 07-09-11-13-15-17-19-21 07-09-11-13-15-17-19-21 07-09-11-13-15-17-19-21
Luiz Cláudio Theodoro . . . . .
Alex Vaz Mendes . . . . .
Bruna Lorena Rodrigues Gondin . 20-22h 20-22h . .
Pedro Henrique Aparecido Damaso de Melo . . . . .
Gabriel Fernandes Machado . . . . .


  • Cronograma de Estudo - Bruna Lorena
    • 01. 10/10//2014
    • 02. 17/10//2014
    • 03. 24/10//2014
    • 04. 31/10//2014
    • 05. 07/11//2014
    • 06. 14/11//2014
    • 07. 21/11//2014
    • 08. 28/11//2014
    • 09. 05/12//2014
    • 10. 12/12//2014
    • 11. 19/12//2014

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


Controladores


Virtualização/Simulação




Trabalhos relacionados


Para Leitura


  • A01. HIP Based Network Access Protocol in Operator Network Deployments
    • http://www.rinta-aho.org/papers/M2NM_napi.pdf
      • Host Identity Protocol based Network Attachment Protocol assume autenticação de acesso e suporta criação de associação de autenticação de segurança para serviços de terceiros.


  • A02. IP Broadband Architecture for Service Experience
    • http://www.huawei.com/br/static/HW-081061.pdf
      • Solução integrada da Huawei que pretende implementar ALL IP em FMC. Basicamente uma evolução de NGN-IMS com facilidades para a operadora em termos de controle, gerenciamento, QoS. Implementa aspectos de QoE.


  • A03. The Future of Telecom Operators: Capabilities for Rapid Change
    • http://www.strategyand.pwc.com/global/home/what-we-think/reports-white-papers/article-display/future-telecom-operators-capabilities-rapid
      • Três tendências estão forçando a evolução da indústria de telecom: demanda por conectividade ubíqua, a ascensão de tecnologia modulares e o aumento da competição fora da indústria.
      • Operadoras deve repensar os requerimentos necessários para ter sucesso através de sua cadeia de valor
      • Operadoras podem escolher seus direcionamentos estratégicos baseados em modelos de negócios como: Network guarantor, Business Enablers, Experience Creator and Global Multimaker
      • Cadeia de valor da telecom: Gerenciamento da infraestrutura bit-pipe, Serviços de Acesso e Provisionamento, Desenvolvimento e Entrega de Aplicações e Interação do Usuário Final.
      • Inovação e dedicação profunda para as necessidades do usuário serão críticas para criadores de experiência


  • A04. Content, connectivity, and cloud: ingredients for the network of the future
    • http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5936156
      • Information-centric networking: Armazenamento para informações de caching é parte da infraestrutura básica da rede, um serviço de rede pode ser definido em termos de objetos de informação nomeados, por exemplo, páginas web, imagens, vídeos ou documentos de texto.
      • Cloud Networking é a integração de gerenciamento de recursos da rede com Cloud Computing ou ainda, o provisionamento de recursos da nuvem distribuídos com os serviços rede para conectar cada recurso distribuído de forma confiável a uma qualidade requerida
      • Open Connectivity soluciona problemas reais como a introdução de novos serviços que geram um processo pesado devido a complexidade de configurações necessárias para acordos de roaming, por exemplo.
      • Conceitos: CCN, NetInf, PSIRP e Dona
      • NetInf ICN Architecture desenvolvido no projeto 4WARD tres componentes principais: esquema de nomeação para objetos de informação (IOs), resolução de nome e sistema de roteamento e armazenamento in-network para caching
      • Open Connectivity Services pode ser mostrado por meio de uma arquitetura de transporte multi-camadas e interfaces (UNI: user-to-network interface e NNI: network-to-network interface)


  • A05. Standardizing a reference model and autonomic network architectures for the self-managing future internet
    • http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6085642
      • Um ISG (Industry Specification Group), sob a tutela do ETSI (European Telecommunications Standard Institute) foi formado para padronizar princípios do Self-Managing Future Internet. Existe um esforço para estabelecer uma visão comum entre procedimentos autonômicos e abordagem unificada para engenharia de rede de ambas as propostas. São trabalhos relacionados com “Scenarios, Use Cases, and Requirements for Autonomic/Self Managing Future Internet” e “Architectural Reference Model for Autonomic Networking and Self-Management.” Deve continuar com um novo item de trabalho denominado "Requirements Analysis and Specification of Implementation-oriented Solutions for Autonomicity and Self-Management.”
      • Alguns SDOs (Standards Developing Organizations) estão começando a incorporar conceitos de auto-gerenciamento. De fato, a aliança NGMN (Next Generation Mobile Network) tem desenhado requisitos e casos de uso para o SON (Self-Organizing Network) enquanto o 3GPP (3rd Generation Partnership Project) tem avaliado como isto pode ser incorporado às futuras redes móveis.
      • Tecnologias emergentes como IMS, NGN, LTE, EPC, FI, IoT, M2M e IaaS/NaaS são direcionadores chaves que demandar a evolução da arquitetura de rede subjacente, denominada de “flat architecture” que pretende reduzir os custos de OPEX.
      • A abordagem proposta baseia-se na criação e manutenção autonômica de uma topologia sobreposta que logicamente interconecta todos os nós/objetos participantes da rede física. Funcionalidades Self-configuration, self-optimization, and self-healing são suportadas.
      • A AFI tem ligações com as seguintes organizações externas: 3GPP e NGMN, TMF, ITU-T FGFN group, BroadBand Forum, IETF, ETSI TISPAN.


  • A06. Developing Information Networking Further: From PSIRP to PURSUIT (Este projeto assim como o IRATI pode ser uma referência de projeto europeu. Neste caso o objetivo é o deploy do PSIRP)
    • http://link.springer.com/chapter/10.1007/978-3-642-30376-0_1
      • PSIRP (PublishSubscribe Internet Routing Paradigm) é um projecto financiado pela UE FP7 que desenvolveu uma Arquitetura CleanSlate para a Internet do Futuro, com base nas primitivas PublishSubscribe. A visao do PSIRP é uma pura arquitetura de Internet information-centric e alguns dos princípios usados são: Identidades Content-based, aplicação recursiva de idéias., técnicas criptográficas e Trust-To-Trust.








Testbed OFELIA Facility






RINA



Overwiew


  • Direcionado pelos requisitos das redes e aplicações emergentes, a Internet tem se tornado uma miscelânea arquitetural com crescente complexidade que se esforça para lidar com as mudanças. A Lei de Moore impediu-nos de reconhecer que o problema não se esconde nas grandes exigências de aplicações de hoje mas sim nas falhas do projeto original da Internet. A Internet precisa mover-se além do TCP/IP para ter longa vida, TCP/IP efetivamente perdeu sua utilidade.


  • A Recursive InterNetwork Architecture (RINA) é uma nova arquitetura Inter-redes cujo principio fundamental é que a rede é apenas um comunicação inter-processos (IPC). RINA reconstrói a estrutura global da Internet, formando um modelo que compreende uma única camada de repetição, o DIF (Distributed IPC Facility) que é o conjunto mínimo de componentes exigidos para permitir IPC distribuídos entre processos de aplicação. RINA suporta inerentemente e sem a necessidade de mecanismos extras de mobilidade, multi-homing e QoS, fornece um ambiente seguro e configurável, motiva um mercado mais competitivo e permite uma adoção gradual.
  • RINA é a melhor escolha para as redes de próxima geração devido à teoria, simplicidade e aspectos que habilita.



Introdução


  • O resultado é, em essência, a primeira "teoria unificada da rede", e leva a uma infra-estrutura de rede mais simples, mais poderosa e, acima de tudo, mais escalável. O livro, estabelece as bases para a forma de explorar o resultado na concepção, desenvolvimento, gestão e à medida que avançamos para além das limitações da Internet.
    • Mostra como muitos mecanismos complexos na Internet de hoje (multihoming, mobilidade e multicast) estão em colapso, simplesmente cmo consequência da estrutura original
  • A conclusão inevitável é que a Internet é uma demonstração inacabada, e que tem vivido na Lei de Moore de 30 anos por meio de remendos.
    • Derivaçã o conceito de que a rede é a comunicação entre processos (IPC) produzindo um modelo IPC distribuído que se repete com diferentes alcances e faixas de operação.

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 ser 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 (DAPs) 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 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 configurado 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


IRATI


Objetivos


  • Aperfeiçoar as especificações e o modelo de referência da arquitetura RINA com foco nos DIFs sobre Ethernet: O aperfeiçoamento das especificações RINA realizados dentro do IRATI serão direcionados por 3 forças principais: i) a especificação de um DIF sobre Ethernet como o meio físico subjacente, (ii) a realização das especificações que habilitam o RINA a fornecer um nível de serviço similar à Internet atual (baixa segurança, melhor esforço) e (iii) o projeto usa caso objetivando cenários ambiciosos que estão desafiando as redes TCP/IP atuais (buscando aspectos como multi-homing, segurança ou QoS). Os parceiros industriais em consórcio lideral a elaboração dos casos de uso com a entrada do External Advisory Board.

NVN


  • NetSocket:
    • www.netsocket.com/




Slicing




Documentação















Artigos e Livros









Modelos


Evolução



































Colaborações



JEEL


Título


  • Internet do Futuro


Conceito


  • O que é Internet?
  • O que são protocolos?
  • Exemplos de protocolos


Arquitetura da rede atual


  • Camada de Aplicação
  • Camada de Controle
  • Camada Física


Problemas desta arquitetura


  • Ossificação
  • 4 décadas de vida
  • Propósito inicial
  • Mobilidade
  • Segurança
  • Escalablidade
  • Etc


Desafios


  • Novas aplicações
  • Volume inimaginável de usuários
  • Aumento exponencial do tráfego de vídeo
  • Internet das Coisas


Alguns números


  • Tráfego
  • Usuários
  • Dispositivos (Things)
  • Sensores
  • Aplicações


Softwarização


  • NFV
  • SDN


Algumas soluções


  • OpenStack
  • OpenFlow




Benefícios


  • Redução de custos
  • Maior eficiência
  • Maior controle
  • Crescimento natural
  • Inovação


Artigo: Entity Title Architecture Pilot: Deploying a Clean Slate SDN based Network at a Telecom Operator


Title

  • Entity Title Architecture Pilot: Deploying a Clean Slate SDN based Network at a Telecom Operator



Authors


\author{\IEEEauthorblockN{~\\[-0.4ex]\large Luiz Cláudio Theodoro\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Electrical Engineering\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email: lclaudio@feelt.ufu.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large  Pedro Henrique A. Damaso de Melo\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing\\ Federal University of Uberl\^andia\\ 
Uberl\^andia, MG, Brazil, 38400-902\\
Email: pedroh@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Alex Vaz Mendes\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\
Uberl\^andia MG Brazil 38400-668 
\\
Email: alexvaz@algartelecom.com.br}
\and

\IEEEauthorblockN{~\\[-0.4ex]\large Hélvio Pereira de Freitas\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\
Uberlandia MG Brazil 38400-668\\
Email: helvio@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Murilo Borges Gomes Machado\\[0.3ex]\normalsize}
\IEEEauthorblockA{Algar Telecom\\ 
Uberlandia MG Brazil 38400-668\\
Email: murilo.bgm@algartelecom.com.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Pedro Macedo Leite\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty Pitagoras\\
Uberlandia MG Brazil 38400-668\\
Email: pedro.larva@gmail.com}

\and
\IEEEauthorblockN{~\\[-0.4ex]\large Flavio de Oliveira Silva\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing,\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email:	flavio@facom.ufu.br}
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Joao Henrique de Souza Pereira\\[0.3ex]\normalsize}
\IEEEauthorblockA{Polytechnic School\\ University of S\~{a}o Paulo\\S\~{a}o Paulo, SP, Brazil, 05424-970\\ 
Email: joaohs@usp.br}	
\and
\IEEEauthorblockN{~\\[-0.4ex]\large Pedro Frosi Rosa\\[0.3ex]\normalsize}
\IEEEauthorblockA{Faculty of Computing,\\ Federal University of Uberl\^andia\\
Uberl\^andia, MG, Brazil, 38400-902\\
Email:	frosi@facom.ufu.br}}


Abstract

  • Luiz Cláudio

Introduction


  • Em função do retumbante sucesso da Internet, surgiram necessidades impensáveis para os pioneiros implementadores dos protocolos que hoje suportam a arquitetura desta grande rede mundial. Estes padrões tem desafiado o tempo porque mesmo depois de décadas de utilização sempre se veem desafiados com novas exigências dos usuários. Apesar desta quase ubiquidade, a Internet tem tido dificuldades para atender às novas requisições como mobilidade, segurança e qualidade de serviço, etc. A contribuição dos protocolos desenvolvidos para a arquitetura atual da Internet é notória mas em várias situações, as prioridades dos projetistas não alinharam com as necessidades dos usuários \cite{pan2011survey}. Muitas iniciativas revelam a ânsia pela renovação da arquitetura corrente de forma a prover uma solução definitiva para novos requisitos e assim uma legião de pesquisadores tem se esforçado para trazer propostas interessantes, tanto no modelo híbrido, que mantém uma coexistência com os protocolos legados quanto clean-slate que propõe mudanças drásticas nos padrões atuais \cite{clark2012design} \cite{gavras2007future} .


  • Apesar de várias contribuições a nível global, poucas conseguem se materializar fora do escopo de um laboratório. Implementar experimentos envolvendo pequenos conjuntos de equipamentos com poucos usuários é o um passo importante na instauração de uma pesquisa, porém quando se trata de validação em infraestruturas reais que atendem continuamente usuários em torno de milhões, a questão se torna crítica. Isto porque as companhias não se arriscam a liberar sua planta e ambientes para serem manipulados por pesquisadores que de alguma forma poderiam afetar os serviços oferecidos ao publico.


  • Este artigo, desenvolvido em parceria com uma operadora comercial mostra a implementação de uma arquitetura inovadora denominada ETArch - Entity Title Architecture \cite{de2012enabling} que garante a possibilidade de se implementar clean-slate SDN based netwotk at a telecom operator usando o conceito de endereçamento horizontal por meio de títulos. Num cenário tradicional envolvendo clientes residenciais conectados a uma rede comercial é provocada uma alteração no seu método de acesso, de forma diferente da convencional. Tudo isso sem grandes contratempos para o usuário final, onde uma aplicação é executada no ETArch com monitoramento do tráfego entre os participantes.


  • A partir dessa implementação, existe a firme intenção de se montar um testbed que permita uma série de desenvolvimentos que poderão atestar a eficiência e potencialidade desta solução que colabora para que a futura Internet possa responder a uma serie de demandas atuais e futuras.


Sections


\section{Related Work}
\input{RelatedWork.tex}
\section{Entity Title Architecture (ETArch) Pilot}
\input{ETArch-pilot.tex}
\section{Deployment and Experimentation}
\input{case-study.tex}
\section{Results} \label{sec:results}
\input{results.tex}
\section{Concluding Remarks and Future Works}
\input{conclusion.tex}



  • Inúmeros artigos estão focados em propor iniciativas que façam com que a Internet de hoje consiga suportar os novos requisitos que surgiram com o passar do tempo e os que ainda estão por vir. Uma destas \cite{Barath:2012:Software-defined}, aborda duas questões interessantes: qual é o problema da Internet atual e por que os esforços atuais são insuficientes para solucionar tais problemas? Sobre a primeira questão, são apontadas as deficiências da rede atual alegando que nenhuma proposta tem sido efetivamente implementada principalmente porque existe um forte acoplamento entre a arquitetura e a infraestrutura. Sobre a segunda questão, endereça a ideia da necessidade de explorar um modelo clean-slate e isto leva a mudanças significativas para o IP (ou seus sucessores) forçando trocas de roteadores usados para construir a rede. Para prover o desacoplamento, o Open Flow é uma das soluções mas ainda encontra resistência porque pode provocar substancial aumento de custos.


  • Para isso sugere a necessidade de encontrar formas de desacoplar arquitetura da infraestrutura sempre visando a redução de custos e a minimização do impacto na adoção de uma nova arquitetura e propõe uma aplicação sistemática de ferramentas que já estão disponíveis atualmente. Dessa forma, considera um projeto onde o plano de dados consiste de um núcleo de rede que usa seu próprio esquema de endereçamento interno e a borda da rede que usa software-forwarding e neste caso, optando por SDN - Software Defined Networks para controlar os roteadores de borda.


  • O projeto desta nova proposta, chamada de Software-Defined Internet Architecture (SDIA), é baseado em muitas tecnologias disponíveis como SDN, MPLS, middleboxes e software forwarding, todos aplicados de maneira sistemática. O resultado é um projeto flexível e modular onde novos modelos de serviço inter-domínios podem ser implementados em software.


  • O NEBULA \cite{Tom:2012:NEBULA}, uma nova arquitetura para Internet propõe 3 camadas: NCore, o núcleo de rede que conecta data centers entre si, NDP, o NEBULA Data Plane que fornece controle de acesso flexível e defesa contra a disponibilidade de ataques e NEBULA Virtual and Extensible Networking Techniques que oferece aos usuários um espectro flexível e dinâmico de escolhas de conectividade. Esta proposta é baseada no fato de que a cloud computing suportará um grande percentual de carga de aplicações sobre a Internet e que o acesso aos recursos da cloud computing demandarão novos aspectos arquiteturais da rede, isto é, dependabilidade, segurança e outros.


  • Como é baseada em alta performance e alta disponibilidade do core network, um protocolo do plano de dados novo que incorpora primitivas fundamentais exigidas para o controle de acesso e uma nova arquitetura de plano de controle distribuído que provê uma interface com quais recursos da rede podem ser alocados.


  • Em \cite{clark2012design}, o autor aponta a grande utilização dos protocolos desenvolvidos para a arquitetura atual da Internet mas ressalta que não atendem a todas as necessidades atuais dos usuários. Sugere que possa haver um bloco de construção melhor que não seja o datagrama e informam que tem usado a proposta de "fluxos" para caracterizar um novo bloco de construção. Essas iniciativas estão sendo direcionadas e não se pode desprezar a ideia de quem tem fomentado a grande rede mundial deste seu nascimento.


  • Para isso, endereça aspectos de uma nova arquitetura a partir de 3 abordagens: information-centric networking (ICN), cloud networking, and open connectivity services. Baseado no enorme crescimento da Internet e prevendo muito desafios, descreve opções para fornecer algumas soluções. Com respeito ao ICN, lista problemas relacionados com a arquitetura atual como armazenamento para chaching information e destaca quatro desafios: escalabilidade global, gerenciamento de cache, controle de congestão e questões de implementação.


  • Para Cloud Networking destaca aplicações de rede que podem flutuar rapidamente em popularidade e em quantidade de interações de usuários sendo que, este fenômeno está se tornando uma variável crítica de controle dentro das redes das operadoras que são complexas e diversificadas. Sugere então uma solução que distribua e espalhe a cloud para que fique mais próxima do usuário final reduzindo assim a latência. Até este ponto lança o termo mis computing ao invés de cloud computing.


  • Finalmente, apresenta o problema do transporte da informação devido à inabilidade da rede atual em explorar informação adicional (semântica) que está disponível no final ou no limite dos sistemas já que o transporte depende de encaminhamento sem conexão de pequenos pacotes de dados. O desafio endereçado, entre outros, focaliza o desenvolvimento de um conceito flow-aware leve através do roteamento e gerenciamento de comunicações multipoint/protocol/path.


  • BeHop tem um objetivo muito interessante de implementar um testbed wireless para Dense WiFi Networks frequentemente encontradas em configurações residenciais e corporativas. O cenário tem um campus como local e registrou 30 usuário como "guinea pigs" onde o principal interesse é estudar e avaliar os pros e contras de novas maneiras de controlar redes WiFi. BeHop fornece um framework de proposta geral para experimentação com um amplo conjunto de técnicas para controle de potência, canal e associação \cite{yiakoumis2014behop}.


  • Como foi feita uma integração entre BeHop e a rede em produção, foi possível mostrar os benefícios de uma implementação no mundo real e enquanto isso manteve-se a desejada flexibilidade para processar experimentos. Neste processo, é essencial estudar e avaliar as estratégias do gerenciamento do WiFi e suas implicações sobre as condições encontradas em uma rede real (diversidade do cliente, mobilidade, interferência com as redes vizinhas). Foi usado um testbed para transportar tráfego real de usuário de dispositivos WiFi conectados e ao mesmo tempo, foi mantido a flexibilidade para aplicar alterações frequentes, atualizações e ocasionalmente forçar a rede a cair, logicamente sem trazer qualquer impacto para a experiência do usuário.


  • O artigo de Yiakoumis \cite{yiakoumis2012putting} tem uma proposta apoiada por vários segmentos, o de colocar o usuário final no controle, não o ISP. Muitos destes últimos, tem criado controvérsias com visões contrárias mas a ideia defendida é a de permitir que a escolha do usuário possa guiar o gerenciamento do tráfego da rede, não apenas dentro das residências mas também dentro do ISP. Duas inovações são feitas para um possível serviço. Primeiro, fornecer agente intuitivo muito fácil de usar que permita usuários leigos expressarem suas escolhas (ou selecionar um perfil) e traduzi-las para semânticas na rede (bit-rate, low-latency, priority, etc. Segundo, a preferência do usuário (em semânticas de rede) precisa ser comunicada para o ISP através de uma abstração simples e estável que ainda precisa ser implementada em um datapath na rede.


  • Como contribuição é construído um protótipo de user-agent e o plano de controle para o ISP que implementa um projeto de rede caseira onde usuários especificam suas escolhas e as sinalizam para o ISP. A divisão do trabalho entre usuários e ISPs são consideradas e descrevem user-agents que traduzem intenções de alto nível do usuário para semânticas de rede de baixo nível. Um slicing, um conjunto isolado de recursos é sugerido e o mapeamento do tráfego para o slice apropriado pode garantir as propriedades desejadas de acordo com os recursos provisionados.


  • Uma implementação interessante foi feita por Hampel, Steiner e Bu em \cite{hampel2013applying} onde propõe o SDN em uma operadora mas em cima da rede IP. Neste caso, Elementos de encaminhamento OpenFlow executam vertical forwarding para interoperar em uma infraestrutura legada usando IP junto com protocolos convencionais de roteamento.


  • Todas essas propostas avaliaram condições onde as soluções pudessem ser implementadas utilizando estruturas de redes atuais com a implantação de serviços onde a arquitetura pudesse estar desacoplada da infraestrutura de rede, permitindo assim a viabilização de novos experimentos envolvendo SDN.


Entity Title Architecture (ETArch) Pilot


  • As inúmeras pesquisas que estão sendo feitas no sentido de redesenhar a arquitetura da Internet colaboram para a evolução dessa grande rede mundial. Juntando-se a esse exército de pesquisadores ao redor do mundo, o grupo do ETArch Pilot pretende plantar sementes que permitirão pesquisas em experimentos futuros extrapolando o espaço de um laboratório ou de um campus.


  • Este trabalho tem como principal objetivo aproximar semanticamente as camadas superiores das camadas inferiores e para isso utiliza a proposta do ETArch - Entity Title Architecture operando sobre uma rede comercial. Prevê neste modelo a possibilidade de atender aos requisitos da Internet, atuais e futuros. ETArch é uma arquitetura de rede clean slate onde esquemas de identificação e endereçamento são baseados em uma designação independente de topologia que unicamente identifica uma Entidade, chamada Título e na definição de um canal que unifica múltiplas entidades de comunicação chamadas Workspaces.


  • Entidades no Modelo de Títulos diferem do conceito definido em algumas literaturas e não são consideradas simples recursos em uma rede mas sim elementos cujas necessidades de comunicação devem ser entendidas e suportadas pela Camada de Serviço e posteriormente pelas camadas inferiores como a Física e Enlace. A seguir, são detalhados os principais conceitos e componentes do ETArch.


  • Entidade é um elemento que possui necessidade de se comunicar e capacidades que podem ser entendidas pelas camadas da arquitetura proposta. Uma entidade pode ser um equipamento, um usuário, uma aplicação, uma coisa, etc. Uma entidade possui ao menos um título e uma localização, denominada Ponto de Conexão (PoA - Point of Attachment), um switch é um exemplo de PoA. Do ponto de vista de mobilidade esta separação é importante, pois a localização de uma entidade pode variar ao longo do tempo. Essas entidades podem se relacionar entre si, através dessas relações podem herdar propriedades, exceto o título \cite{de2012enabling} \cite{silva2011domain}.


  • O Título é o que identifica unicamente uma entidade e esta pode possuir vários títulos. Um conjunto de Títulos é agrupado em um Namespace que também deve possuir um título único e esse Namespace é responsável pela relação entre o Titulo e a Entidade. Um Título é definido por uma tupla, cuja especificação é Namespace::Identificação-entidade. Já Workspace é um barramento lógico, independente da topologia, no qual entidades podem se ligar (Attach) para participar de um domínio de comunicação. O endereçamento das entidades são realizadas a nível de aplicação, essas entidades não se comunicam diretamente e sim por meio de um canal.


  • O Workspace pode ser composto de redes cabeadas e redes sem fio, sendo que elas podem se comunicar entre si transparentemente. É identificado por seu título e pode ser distribuído através de um ou mais elementos de rede (NE) possuindo as seguintes propriedades: título que identifica unicamente um Workspace, lista de NEs que registra os títulos dos elementos que fazem parte do Workspace, lista de capacidades que podem ser oferecidas às entidades, lista de requisitos que as entidades devem suportar e por fim, informação do nível de visibilidade, se público ou privado.


  • Um Workspace é criado quando uma entidade produz algum serviço que pode ser consumido por outras entidades como em um compartilhamento de arquivos. Ele é controlado por um DTS (Domain Title Service) que tem como responsabilidade, a resolução de títulos, gerenciamento das entidades e manutenção da relação entre as Entidades e Títulos. O DTS é constituído de DTSAs (DTS Agents) e mantém uma base de conhecimento com informações do ambiente, assim é possível monitorar e controlar os requisitos de uma entidade. Os DTSs gerenciam o ciclo de vida das entidades do inicio ao fim das atividades. A figura \ref {DTS} mostra a visão de um Workspace, controlado por DTSAs que englobam alguns NEs.


\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.20]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/ETArchPilotDTS}
\caption{Principais Componentes da Arquitetura - DTS, DTSA, Entity, Title e o Workspace.}\label{DTS}
\end{figure}



Deployment and Experimentation


  • Para mostrar as possibilidades de responder aos grandes desafios atuais e futuros, este trabalho propõe a implementação de um testbed para o desenvolvimento e teste da arquitetura ETArch. Ciente de que uma implementação que venha radicalizar a utilização dos padrões tradicionais precisa trazer o mínimo de esforço para a grande base de usuários no mundo, o ETArch se utiliza de ferramentas atuais como o Openflow, que permite que pesquisadores rodem protocolos experimentais em sua redes que possam ser também suportadas por estruturas presentes no cenário mundial como a rede MetroEthernet. Para atingir esse objetivo, utiliza o conceito de ilha, nome dado a um domínio ETArch que é constituído pelo controlador denominado DTSA e seus clientes e os switches OpenFlow rodando em cima de uma rede MetroEthernet tradicional servida por uma operadora comercial de telecom.
  • A estrutura da operadora segue a arquitetura de anel, com anéis primários que são os centrais e anéis secundários que abordam o cliente, similar à figura ~\ref{RedeMetroFigure}:
\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.35]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/Rede_metro_1}
\caption{MetroEthernet Topology}\label{RedeMetroFigure}
\end{figure}


  • Os anéis primários são equipamentos distribuídos pela área de atuação. Estes equipamentos em sua grande maioria operam com SDH (Synchronous Digital Hierarchy) e DWDM (Dense Wavelength Division Multiplexing) [A35] \cite{huynh2007metropolitan}. Outra característica dos anéis primários é sua grande capacidade de transporte, pois chegam a operar com taxas de superiores a 100 Gb/s. Os anéis secundários são caracterizados por um raio geográfico menor e capacidades de transporte menores. As taxas de anéis secundários não passam de 40 Gb/s.
  • O objetivo desse trabalho, portanto, é propor a implantação de uma rede virtual que permita interligar os vários domínios remotos (ilhas) utilizando a rede IP de uma operadora, possibilitando aos desenvolvedores um ambiente integrado de desenvolvimento e testes mais próximo a um cenário real de utilização. Em um ambiente local () padrão, os switches Openflow estão diretamente conectados uns aos outros, conforme a figura 2. Entretanto, como mostrado, na rede da operadora, os switches Openflow de cada ilha estariam separados por uma estrutura IP que não implementa essa especificação conforme figura \ref{RedeOpenFlowFigure}.




\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.35]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/RedeOpenFlow}
\caption{Rede OpenFlow}\label{RedeOpenFlowFigure}
\end{figure}


  • O desenvolvimento do ETArch sobre a infraestrutura de uma rede MetroEthernet, com clientes reais e em pleno funcionamento, traz consigo uma série de dificuldades, dentre elas, usar a estrutura legada baseada na arquitetura TCP/IP não só para o plano de controle, mas também para o plano de dados, de forma a não afetar nenhum usuário ou regra de funcionamento da rede. Para isto, era importante criar formas alternativas, para que todos elementos da rede que não são controláveis funcionassem como um meio transparente, ou seja, apenas encaminhassem os pacotes e dados provenientes do ETArch até um componente que estivesse registrado no controlador, e que pudesse dar as tratativas que estivessem pré-definidas. Em suma, em um ambiente local (ilha) padrão, os switches Openflow estão diretamente conectados uns aos outros conforme figura \ref{RedeOpenFlowFigure}.


  • Numa rede de switches Openflow, os switches diretamente conectados são identificados mediante a utilização do protocolo LLDP ( Link layer Discovery Protocol) \cite{congdon2002link}. Entretanto na estrutura proposta, esses switches estão geograficamente dispersos. Assim torna-se necessária uma solução para tornar esses switches virtualmente adjacentes para que o encaminhamento dos pacotes programados pelo Controlador possa funcionar de maneira apropriada. A solução proposta para criar as adjacências entre os switches Openflow foi o tunelamento dos frames LLDP usando protocolo GRE (Generic Routing Encapsulation) \cite{hanks2000generic}, bastante popular pela sua simplicidade e compatibilidade. Dessa forma é possível criar uma rede virtual de switches Openflow, sobre a rede IP da operadora, interligando as diversas ilhas de desenvolvedores.



\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.25]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/RedeOperadora}
\caption{Rede da Operadora}\label{RedeOperadoraFigure}
\end{figure}


  • Além da criação de túneis, para que a arquitetura funcione é necessário que existam elementos controláveis ao longo da rede. Devido a estrutura em funcionamento não apresentar estes elementos, optamos por utilizar nas pontas (próximo ao cliente e ao controlador) um equipamento virtual que possibilitasse a conexão com o controlador e que servisse de conexão para o cliente. Para tal propósito, optamos pelo OpenvSwitch (OVS), que pode facilmente ser instalado em um hardware simples, como a maioria dos PCs. Os switches virtuais providos pelo OpenVSwitch, que estão dispersos na rede, aliados aos túneis, fazem uma estrutura controlável virtualmente adjacente.


  • Para abordar os clientes, a operadora oferece ADSL (Asymmetric Digital Subscriber Line), VDSL (Very-high-bit-rate Digital Subscriber Line) e FTTH (Fiber To The Home) \cite{tanenbaumredes}. Esta abordagem em sua grande maioria parte de um anel secundário, porem quando há uma concentração de tráfego muito grande, por exemplo, em condomínios fechados, prédios comerciais ou grandes empresas esta abordagem pode partir direto de um anel primário.


  • Segundo o relatório [A36] emitido publicamente pela empresa, no terceiro semestre de 2014, existiam 498 mil clientes ativos do serviço de comunicação de dados, sendo que pouco mais de 400 mil clientes estavam usando a tecnologia ADSL e o restante estava distribuído entre VDSL e FTTH, tendo portanto grande capacidade de tráfego. Também conta com uma rede de backbones de alta capacidade espalhada pelo sudeste do país sendo assim uma grande fornecedora de interligação entre operadoras e de last mile.


  • Devido ao grande uso do ADSL, os testes foram feitos usando esta tecnologia, logo, nos testes citados abaixo, foram usadas máquinas interligadas via ADSL igual aos clientes comuns, passando por concentradores, por DSLAMs (Digital subscriber line access multiplexer) e por toda a infraestrutura usada nesta tecnologia.


  • Para a implementação, primeiramente, o controlador desenvolvido para o ETArch foi instalado em um servidor de uma rede local. Na mesma rede, foram inseridos dois PCs, ambos com sistema operacional Ubuntu Linux (14.04), os quais faziam o papel de clientes e switches, ou seja, executavam tanto o switch virtual, quanto a aplicação utilizada para os testes.


  • Para a instalação do OpenVSwitch, foram usados os comandos:


  • \begin{itemize}
  • \item apt-get update; apt-get install openvswitch-switch
  • \end{itemize}


  • O primeiro atualiza a lista de pacotes disponíveis nos repositórios oficiais para instalação, o segundo efetiva a instalação do OVS. A partir deste ponto é necessário iniciar o serviço e configurá-lo:


\begin{itemize}
\item service openvswitch-switch start  
\item ovs-vsctl add-br br0  
\item ovs-vsctl set-controller br0 tcp:\textless ServerIP:Port\textgreater 
\end{itemize}


  • Feito isso, em ambas as máquinas, o switch já possui uma bridge adicionada e já está registrado no controlador. Para a conexão das duas máquinas, portanto dos switches, foi utilizado um túnel GRE, pois o mesmo oferece um túnel, simulando um enlace entre dois pontos de uma rede, utilizando um endereço IP, o que atende a proposta inicial. E mais, o próprio OVS já é capaz criar este tipo de túnel internamente. Para isto é utilizado o comando:


\begin{itemize}
\item ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote\_ip=\textless hostIP\textgreater
\end{itemize}


  • Em cada uma das máquinas o hostIP representa a outra máquina, ou seja, um túnel é definido entre as duas, e portanto a estrutura de configuração do OpenvSwitch com GRE e a interação entre as entidades, inclusive o controlador, fica definida sobre a estrutura real como proposto.


Results


  • Para atender aos objetivos inicialmente propostos, a comprovação pode ser demonstrada a partir da montagem e configuração da estrutura da rede e na posterior troca de dados e informações entre as entidades através de processos e aplicativos desenvolvidos especificamente para a rede ETArch.


  • O primeiro modo de confirmação é baseado na implementação do controlador ETArch, que força todos os switches registrados a enviarem regularmente um pacote LLDP (Link Layer Discovery Protocol). Este protocolo é muito importante para o mapeamento da rede em si, sinalizando quais são os switches e os caminhos entre os mesmos, para que o controlador tenha a visão total da rede. Sabendo disso e usando uma ferramente de monitoramento de pacotes (tcpdump), observamos a troca de informações entre os switches, especificamente o LLDP anteriormente citado, encapsulado no GRE, conforme a figura \ref{LLDPFigure}.


Checagem LLDP


\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.4]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/LLDPARTIGO}
\caption{Monitoring LLDP}\label{LLDPFigure}
\end{figure}


  • Esta informação sinaliza que estes switches estão virtualmente adjacentes, ou seja, a estrutura legada permaneceu presente no cenário da rede laboratorial, onde foi inicialmente aplicado e de forma transparente, não exigindo alterações sensíveis nas práticas em curso na operadora.


  • A partir da confirmação do funcionamento de toda a estrutura, o controlador e as máquinas foram migrados para o ambiente MetroEthernet. Neste ambiente, o controlador passa a ter um IP válido. Cada um dos clientes foi conectado, utilizando a rede legada, isso quer dizer que nesta situação estes clientes estariam separados do controlador e entre si, por vários elementos de rede, como switches, DSLAMs, e até o próprio modem de acesso. Para a construção dos túneis GRE, os OVSs precisam ter um IP válido e por este motivo o próprio cliente precisa efetuar a conexão PPPoE diretamente com o ISP.


  • O processo de configuração dos OVSs é repetido, substituindo os IPs anteriores pelos novos obtidos na rede, e assim, toda a estrutura legada não influenciaria no controle e conexão entre os clientes. O controlador enxerga apenas os switches controláveis e entre eles, um enlace direto. Para comprovação desta etapa, o processo é o mesmo, pela visualização dos pacotes LLDP e suas respectivas respostas mostrando que a implementação apresentou sucesso.


  • Para finalmente, comprovar que o ambiente preparado para a nova arquitetura é capaz de suportar aplicações que usam a nova arquitetura, envolvendo as entidades e a comunicação no ETArch, sem realizar alterações adicionais, foi executado um aplicativo de chat desenvolvido anteriormente para funcionar nesta nova proposta implicando na não utilização dos processos tradicionais (TCP/IP).


  • O aplicativo é chat desenvolvido em python e executado diretamente do terminal possuindo parâmetros como o nome da Entidade e o Workspace. Executando-o em ambas as máquinas, cada uma com um título diferente e atachadas ao mesmo workspace, foi observado que conforme o conceito definido na arquitetura, ambas puderam visualizar o conteúdo inserido neste workspace (w1), conforme a figura ~\ref{CHATFigure}. Isto valida a implementação e mostra como resultado o funcionamento pleno da arquitetura no ambiente proposto.


Execução do chat


\begin{figure}[htbp]
\centering %
\includegraphics[scale=0.6]{../../../../../../../../../../../home/lclaudio/Documentos/ImagensETArch/CHATARTIGO}
\caption{Running Chat}\label{CHATFigure}
\end{figure}


Conclusion



  • Observando o que foi descrito nos capítulos anteriores, pode-se comprovar a capacidade de utilização do ETArch Pilot na rede legada, possibilitando uma implantação gradual sem necessidades de altos investimentos na troca de equipamentos, alterações em ambientes e treinamento de pessoas em um ISP.
\begin{itemize}
\item Responder ao artigo SDIA: what is the problem and why are current efforts insufficient?
\item Comunicação baseada em Workspaces -> 
\item Menor Uso de Banda se comparada a arquitetura atual (a diferença aumenta com o acréscimo de clientes)
\item Controlador Centralizado -> Definição das rotas, maior QoS?
\item Mobilidade das entidades?
\item Sinalização de controle?
\item Atuação dinâmica do controlador?
\item Eliminação de elementos?
\end{itemize}


  • Como trabalhos futuros, existem várias frentes como por exemplo:
\begin{itemize}
\item Aumentos de clientes e switches do OpenFlow
\item Comprovação da eficiência do modelo de Workspaces através de streaming de vídeo
\item Eliminar algum elemento da rede legada
\item Análise comparativa à exclusão ou inclusão de uma ou mais rotas, eficiência no encaminhamento de pacotes, reposicionamento das entidas e QoS, QoS
\end{itemize}


Acknowledgment


  • This work has been partially funded by the European Community's Seventh Framework Programme, under grant agreement n. 258365 (OFELIA project), by the Brazilian agencies: CAPES, CNPq and FAPEMIG and also by PROPP/UFU.


References


ICN 2017


  • Finalização: 01/12/2016
  • Submissão: 05/12/2016
  • Data do evento: 23 a 27/05/2017 - Veneza - Itália


Testers


  1. - Alex Vaz
  2. - Ernélio
  3. - Vinicius
  4. - Eduardo Freire
  5. - Tiago
  6. - Abadio
  7. - Daniel
  8. - Lucas Carvalho
  9. - Tayro
  10. - Douglas


  1. - Luiz Cláudio
  2. - Matheus Silva Santos
  3. - Eustáquio Fernandes Júnior
  4. - Júlia Rizza
  5. - Rafael Marra
  6. - Marc Sué Pires Morais Junior
  7. - Laércio Lopes Pereira Lima
  8. - Lincoln Borges Ferreira
  9. - Pedro Henrique da Costa Avelar
  10. - Matheus Cunha Reis
  11. - Lucas Correia Bernardes
  12. - Leandro de Medeiros Ferreira
  13. - Alunos de GSI003
  14. - Alunos de GSI009


  1. - Pedro Damaso
  2. - Diego
  3. - Caio
  4. - João Ludovico
  5. - John Martinez
  6. - Juan
  1. - Rogério
  2. -



ICC 2017


  • Finalização: 02/10/2016
  • Submissão: 14/10/2016


  • 11/09/2016 - Entrega dos trabalhos relacionados, tunelamento, ETArch
  • 18/09/2016 - Implementação e revisão dos anteriores
    • Distribuição geográfica
    • Diversificação de ambientes
    • Capilaridade dos usuários
  • 25/09/2016 - Conclusão e revisão da implementação
  • 02/10/2016 - Artigo completo incluindo introdução
  • 12/10/2016 - Tradução e revisão final


Revisões


  • Revisão v6 - Luiz Cláudio
    • III. ENTITY TITLE ARCHITECTURE (ETARCH ) PILOT => espero contribuição do Pedro Damaso
      • Paragráfo 1: Relacionar artigo do ETArch que mostra os primeiros resultados em laboratório.
      • Paragráfo 2: Relacionar artigo do ETArch que mostra as definições de Título e Workspace
      • Paragráfo 3: Não ficou claro o que é Camada de Serviço. Incluir explicação no parágrafo anterior.
      • Paragráfo 7: Inclusão da referência 11 => Favor conferir se o que está escrito no texto está condizente com a referência.
      • Último Paragráfo: Explicar no mesmo ou em um novo parágrafo, o exemplo mostrado na imagem.
        • Não se preocupe com a posição da figura, depois que tivermos o texto mais completo, acertaremos o lugar certo.
    • IV. DEPLOYMENT AND EXPERIMENTATION => espero contribuição do Pedro Macedo, Hélvio e Murilo
      • Paragráfo 1: Não está legal o final do parágrafo. Quando se começa a frase: "Para isso, temos o conceito de ilha, nome dado a um domínio ETArch, .." está totalmente deslocado do conteúdo anterior. É necessário, rever esta parte e criar uma frase que conecte a proposta do ETArch com o Rede Metro e OpenFlow.
      • Paragráfo 2: Falta a figura 2. No final do parágrafo ("os switches Openflow de cada ilha estarao separados por uma estrutura IP que não implementa essa especificação (Fig. 3)"). Esta figura 2 é a figura da Rede Metro?
      • Paragráfo 3: Confirmar as figuras de acordo com o final deste parágrafo.
      • Paragráfo 5: Está meio confuso, o OpenVSwitch foi apresentado no parágrafo anterior e neste de novo este elemento é sugerido como se não tivesse sido referenciado antes. Desenvolver o texto de forma que fique coerente o que foi escrito no parágrafo 4 com a menção ao OpenVSwitch neste parágrafo.
      • Paragráfo 6: Avaliar aqui se é melhor referenciar o Tanembaum (nesse cas é necessário referência em inglês e as páginas do livro) ou um artigo ou documento referente ao SDW e DWDM.
      • Paragráfo 7: Idem.
      • Paragráfo 8: Verificar relatório em inglês.
      • Último Paragráfo: Falta um fechamento deste capítulo explicando que a estrutura montada possibilitará os resultados do próximo capítulo.
    • V. RESULTS => espero contribuição do Pedro Macedo, Hélvio e Murilo
      • Último Paragráfo: Criar um novo parágrafo a partir de "Isto valida ..." mostrando mais claramente a diferença entre a implementação do piloto e o mundo tradicional, por exemplo, que este experimento pode ser expandido para dezenas, centenas ou mais de clientes com pouco trabalho em montar a configuração caseira.
      • Imagens e referências em todos os capítulos => => espero contribuição do Gabriel.
  • Atualização - v7
    • O que foi feito?
      • Inclusão da introdução
      • Inserção das palavras-chave
      • Revisão de todo o texto e correção do Portguês (mesmo que tenhamos que passar para o Inglês é interessante deixá-lo certinho na nossa língua)
      • Anexação e alteração dos labels das imagens
      • Inclusão da referência 11 => Favor conferir se o que está escrito no texto está condizente com a referência.


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?



  • A01 - Software-defined internet architecture: decoupling architecture from infrastructure since the control plane is separated from data plane.
  • A02 - NEBULA - A Future Internet That Supports Trustworthy Cloud Computing
  • A03 - The design philosophy of the DARPA internet protocols1988
  • A04 - Content, connectivity, and cloud: ingredients for the network of the future
  • A05 - Standardizing a reference model and autonomic network architectures for the self-managing future internet
  • A06 - Developing Information Networking Further_ From PSIRP to PURSUIT - Springer
  • A07 - Illustrating a publish-subscribe Internet architecture
  • A08 - Optical Network Virtualization
  • A09 - Scalable Service Deployment on SDN
  • A10 - HIP Based Network Access Protocol in Operator Network Deployments
  • A11 - Optical FlowVisor: An OpenFlow-based Optical Network Virtualization Approach
  • A12 - Identifying standardization opportunities of an operator-driven, framework for unifying autonomic network and service management
  • A13 - The Future of Telecom Operators: Capabilities for Rapid Change
  • A14 - IP Broadband Architecture for Service Experience
  • A15 - BeHop : A testbed for dense WiFi networks
  • A16 - Putting home users in charge of their network
  • A17 - Slicing home networks
  • A18 - SDN and Tunneling for Mobile Networks
  • A19 - Virtualized Network Isolation Using SDN.
  • A20 - Network Virtualization with Cloud Virtual Switch
  • A21 - Extending Networking into the Virtualization Layer


  • A30 - www.openvswitch.org
  • A31 - Link layer discovery protocol and MIB. P Congdon - V1. 0 May 20. 2002, http://www. IEEE802, 2002 - ieee802.org
  • A32 - RFC 2890. GRE (Generic Routing Encapsulation)
  • A33 - Pfaff, Ben, Pettit, J., Koponen, T., Amidon, K., Casado, M. Open vSwitch: Extending Networking into the Virtualization Layer. Nicira Networks. UC Berkeley, Computer Science Division.
  • A34 - RFC 7047. The Open vSwitch Database Management Protocol
  • A35 - TANENBAUM, Andrew S. Redes de Computadores. Editora Campus, 4Edição. 2002.
  • A36 - Relatorio aos investidores "Release de resultados 3T14", disponível em "www.algartelecom.com.br/ri"


Sites

Entidades


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


Diversos

Reuniões

ETArch Pilot
  • 20/10/2016
    • Pauta:
      • Luiz Cláudio:
        • Discutir submissão do artigo
      • Flávio: Sugeriu aumentarmos o número de participantes no Chat e compararmos com processo tradicional



  • 10/06/2016
    • Pauta:
      • Luiz Cláudio:
      • Lucas:
        • Apresentação 1o. experimento de uma rede SDN na rede da Algar Telecom
      • Alex e Murilo:
        • Status dos testes => Necessidade de colaboração do Pedro Damaso


  • 13/05/2016
    • Pauta:
      • Avaliar evento ICWMC 2016 || November 13 - 17, 2016 - Barcelona, Spain
      • Atualizar Status teste feito por Alex e Murilo
      • Entender linha de estudo do Pedro Damaso
      • Atualizar criação do LiveCD
    • Próximas atividades:
      • Rafael: Liberar portas novamente
      • Alex, Pedro e Murilo: Testar Chat e DTSA no Lab CA - 2a. feira - 08h30
      • Rogério, Luiz Cláudio e Pedro: Comparar LDAP e Radius na linha de estudo do Pedro
      • Rogério: Continuar montando LiveCD
      • Luiz Cláudio: Discutir com Flávio sobre submissão para próximo evento
    • Participantes:
      • Pedro Damaso
      • Rogério Freitas
      • Luiz Cláudio Theodoro
      • Murilo (Viva Voz)
      • Rafael Leonardo (Viva Voz)


  • 13/05/2016
    • Pauta:
      • Discussão sobre requisitos pendentes
      • Testes preliminares
    • Atividades:
      • Murilo e Alex:
        • 6a. feira:
        • Finalização dos testes de streaming
      • Rafael:
        • Associar interface com Internet na maquina virtual Algar
        • Liberar as portas
      • Luiz Cláudio:
        • Pesquisar eventos para submissão
        • Convidar Adailson para atualizar iniciativas
        • Aprovar solicitação de rede no CTI
      • Rogério:
        • Sugestão de criação de um liveCD
        • Instalação do OpenStack no LIT
        • Conclusão da rede UFU - FEELT
      • Lucas:
        • Aprofundar no piloto do Adailson
        • Próxima reunião:
        • Status testes de streaming
        • Discussão de tópicos
      • Participantes:
        • Pedro Henrique Aparecido Damaso de Melo
        • Rogerio de Freitas Ribeiro
        • Rafael Leonardo Ferreira de Aquino
        • Luiz Cláudio Theodoro
        • Lucas Guandalini
        • Murilo Borges Gomes Machado


Eventos



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


SBRC 2012



Próximas Atividades

ETArch Pilot - 29/04/16
ETArch Pilot - 18/03/16
ETArch Pilot - 22/01/16

ETArch Pilot - 08/01/15
ETArch Pilot - 18/12/15
ETArch Pilot - 09/10/15
ETArch Pilot - 02/10/15

ETArch Pilot - 24/04/15
ETArch Pilot - 10/04/15
ETArch Pilot - 13/03/15
ETArch Pilot - 06/03/15
ETArch Pilot - 10/10/14
ETArch Pilot - 03/10/14
ETArch Pilot - 05/09/14
ETArch Pilot - 02/09/14
ETArch Pilot - 29/08/14
ETArch Pilot - 06/08/14
ETArch Pilot - 30/07/14
ETArch Pilot - 23/07/14
ETArch Pilot - 16/07/14
ETArch Pilot - 09/07/14
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=46848”