Exibir código-fonte para ETArch Pilot

'''MEHAR'''
* Mondial Entities Horizontally Addressed by Requirements
<br>

= Colaboradores =
<br>

* Alex Vaz Mendes - 9945-3763 - alexvazmendes@gmail.com <br>

* Gabriel Fernandes Machado - 9232-6118 - gfmachado22@gmail.com (Entrada em 22/07/2011)<br>

* Bruna Lorena Rodrigues Gondin - 8825-2351 - bruna.lorenagondin@gmail.com (Entrada em 28/06/12) 

* Hélvio Pereira de Freitas - 9992-2213 - helvio@algartelecom.com.br (Entrada em 20/02/13) 

* Luiz Cláudio Theodoro - 9976-2676 - lclaudio@algartelecom.com.br

* Pedro Macedo Leite - 9992-1743 - pedro.larva@gmail.com (Entrada em 11/10/2013)

* 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

* Ronaldo José Ferreira -  9992-0378 - ronaldo@algartelecom.com.br

<br>

= Horários de Estudo =
<br>

{| class="wikitable"
|-
!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||.||.||.||.||.
|-
|}
<br>

* 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 =
<br>

==  Básico ==
<br>

* [[Camada de Enlace]]

* [[IPv4/IPv6]]
* [[Entendendo números IPs]]
* [[TCP]]
* [[UDP]]
* [[Resumo das RFCs]]


* [[CLI]]
* [[SNMP]]


* [[MPLS]]



* [[Overview OWL]]
* [[RDF]]
* [[XML]]
* [[LaTeX]]
<br>

==  QoS ==
<br>

* Aulas de TRC - 2006 - Pitágoras
<br>

* [[Arquivo:TRC23 - Aula 02 - Definição.pdf]]
* [[Arquivo:TRC23 - Aula 03 - Parâmetros.pdf]]
* [[Arquivo:TRC23 - Aula 04 - Aplicações Multimídia.pdf]]
* [[Arquivo:TRC23 - Aula 05 - Warriors of the net.pdf]]
* [[Arquivo:TRC23 - Aula 06 - Técnicas de QoS.pdf]]
* [[Arquivo:TRC23 - Aula 07 - Enfileiramento.pdf]]
* [[Arquivo:TRC23 - Aula 08 - Exemplos de Serviço com COS.pdf]]
* [[Arquivo:TRC23 - Aula 08 - Modelos de QoS.pdf]]
* [[Arquivo:TRC23 - Aula 09 - RSVP.pdf]]
* [[Arquivo:TRC23 - Aula 10 - RootNet.pdf]]
* [[Arquivo:TRC23 - Aula 10 - Tráfego de Rede.pdf]]
<br>

== SDN ==

* [[Introdução SDN]]
* [[Projetos SDN]]
* [[SDN]]
* [[OpenFlow]]
* [[RouteFlow]]
* [[Workspace]]
* [[Edobra]]
* [[FlowVisor]]
* [[FINLAN]]
* [[Ofelia]]
* [[Testbed Brazil]]

== NFV ==

* [[NFV ou SDN]]
* [[NFV]]

== Redes Virtuais ==
<br>

* [[Mininet]]

* [[OFlops]]
<br>

== Redes Metro ==
<br>

* [[MPLS]]
<br>

* Apresentação Expansão MetroEthernet
** [[Arquivo:Apresentação projeto rede metro de 10Giga em MPLS.ppt]]
<br>

* Treinamento Básico - MetroEthernet
** [[Arquivo:Treinamento_CTBC_Basico_Plus_Rev02.ppt]]
<br>

* Spanning Tree
** Spanning Tree Protocol v1.21 – Aaron Balchunas
<br>

* Roteadores
** [[Interação com roteadores]]
** Thiago Mundim
<br>

* [[Interação com switch]]
<br>

* 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]]
<br>

* 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]]
<br>

* Cisco - Especificação Técnica - Metro Ethernet
** [[Arquivo:Cisco - Metro Ethernet - Technical Specifications.pdf]]
<br>

== Visitas ==
* [[Manutenção e Ativação]]
<br>

== Controladores ==
* [[Floodlight]]
<br>

== Virtualização/Simulação ==
<br>

* [[Mininet]]
** An Instant Virtual Network
<br>

* [[Open vSwitch]]
<br>

= Trabalhos relacionados =
<br>

== Para Leitura ==
<br>

* 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.

 
* A07. Illustrating a publish-subscribe Internet architecture
** http://link.springer.com/article/10.1007/s11235-011-9432-5

 
* A08. Optical network virtualization
** http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5753389


* A09. Scalable Service Deployment on Software-Defined Networks
** http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6094010
 

* A10. Software-defined internet architecture: decoupling architecture from infrastructure
** http://dl.acm.org/citation.cfm?id=2390239
 

* A11. Optical FlowVisor: An OpenFlow-based Optical Network Virtualization Approach
** http://www.opticsinfobase.org/abstract.cfm?uri=NFOEC-2012-JTh2A.41
 

* A12. Identifying standardization opportunities of an operator-driven, framework for unifying autonomic network and service management
** http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6364850
<br>

== Testbed OFELIA Facility ==
<br>


* Artigo Original:
** [[Arquivo:OFELIA Facility in Computer Networks.pdf]]
<br>

* Artigo reescrito:
** [[Computer Networks - Future Internet Testbeds - Part I]]
*** Special Issue
*** Future Internet Testbeds - Part I
** James PG Sterbenz
** David Hutchinson
** Paul Muller
** Chip Elliot
<br>
<br>

== RINA ==
<br>

* Artigos:
** The Last Waltz and move beyond TCP/IP
*** http://rina.tssg.org/docs/ITP_vol5_p3_42-50.pdf
<br>

=== Overwiew ===
<br>

* 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.
<br>


=== Introdução ===
<br>

*  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 ===
<br>

** 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
<br>

=== Visão da arquitetura RINA ===

<br>

* 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
<br>

* 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
<br>

==  IRATI ==
<br>

* http://irati.eu/overview/#
* 

=== Objetivos ===
<br>

* 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 ==
<br>

* NetSocket: 
** www.netsocket.com/ 
<br>

* Case: Data Center
** [[NVN - Service Provider Data Center]]
<br>

* Case: Escritório
** [[NVN - Branch Office]]
<br>

== Slicing ==
<br>

* [[Slicing Home Networks]]
<br>

* [[Putting Home Users in Charge of their Network]]
<br>

= Documentação =
<br>
* [[Esquema - GRE Tunnel]]
<br>
* [[Estrutura - Primeiro Teste]]
<br>
* [[Instalação do Servidor]]
<br>
* [[Passo a Passo]]

= Artigos e Livros =
<br>

* EDOBRA:
** [[Arquivo:Ponto_de_Rede_na_UFU.pdf]]
<br>

* SDN:
** [[Artigo - Código SDN]]
** [[Artigos SDN]]
** [[Arquivo:SDN - NVN - Whitepaper.pdf]]
<br>

* Artigo FIABook:
** [[Arquivo:ArtigoMeetingServices-FIABook.pdf]]
<br>

* Tânia Tronco:
** [[Livro: New Networks Architectures]] 
<br>


* Iniciação Científica
** [[IC - Versão Oficial]] 
<br>


Modelos
* [[Media:Projeto IC - Ana Lúcia - UFU.pdf|Projeto Modelo de Iniciação Científica da UFU]]
<br>

== Evolução ==
<br>

* 1-OntoBra-artigo-Po1
** Ontologia em Redes de Computadores
** [[Arquivo:1-OntoBra-artigo-Po1.pdf]]
<br>

* 2-NTMS-IEEE-069-073-PID992592
** Distributed Systems Ontology
** [[Arquivo:2-NTMS-IEEE-069-073-PID992592.pdf]]
<br>

* 3-NTMS-IEEE-116-121-PID992662
** Horizontal Address Ontology in Internet Architecture
** [[Arquivo:3-NTMS-IEEE-116-121-PID992662.pdf]]
<br>

* 4-I2TS-62789
** Implementação do Protocolo FINLAN
** [[Arquivo:4-I2TS-62789.pdf]]
<br>

* 5-I2TS-62641
** Proposal for Hybrid Communication in Local Networks
** [[Arquivo:5-I2TS-62641.pdf]]
<br>

* 6-I2TS-62677
** Horizontal Address by Title in the Internet Architecture
** [[Arquivo:6-I2TS-62677.pdf]]
<br>

* 7-ICNS-IEEE-ICNS-10142-3969a007
** Horizontal Addressing by Title in a Next Generation Internet 
** [[Arquivo:7-ICNS-IEEE-ICNS-10142-3969a007.pdf]]
<br>

* 8-CNS-IEEE-ICNS-10193-3969a018
** Optimization Proposal for Communication Structure in Local Networks
** [[Arquivo:8-CNS-IEEE-ICNS-10193-3969a018.pdf]]
<br>

* 9-ICNS-IEEE-ICNS-10249-3969a032
** FINLAN Packet Delivery Proposal in a Next Generation Internet
** [[Arquivo:9-ICNS-IEEE-ICNS-10249-3969a032.pdf]]
<br>

* 10-Versao-Publicada-I2TS2010-78152_1
** Network Headers Optimization for Distributed Programming
** [[Arquivo:10-Versao-Publicada-I2TS2010-78152_1.pdf]]
<br>

* 11-Publicacao-Journal-IARIA
** Layers Optimization Proposal in a Post-IP Network
** [[Arquivo:11-Publicacao-Journal-IARIA.pdf]]
<br>

* 12-FIA Bool 2011 - Meeting Services
** Meeting Services and Networks in the Future Internet
** [[Arquivo:12-FIA Bool 2011 - Meeting Services.pdf]]
<br>

* 13-'''FIA Bool 2011 - Title Model'''
** Title Model Ontology for Future Internet Networks
** [[Arquivo:13-FIA Bool 2011 - Title Model.pdf]]
<br>

* 14-IEEE-Transactions-9TLA2_12SouzaPereira
** Title Model for Computer Networks Optimization
** [[Arquivo:14-IEEE-Transactions-9TLA2_12SouzaPereira.pdf]]
<br>

* 15-Versao-Publicada-SBRC-2011-ST02_4
** Domain Title Service for Future Internet Networks
** [[Arquivo:15-Versao-Publicada-SBRC-2011-ST02_4.pdf]]
<br>

* '''16-FIA Book 2012 - FINLAN'''
** Title Model for Computer Networks Optimization
** [[Arquivo:16-FIA Book 2012 - FINLAN.pdf]]
<br>

== Colaborações ==
<br>

* A01 - OpenFlow-main-1-Felippe
** Avaliação do impacto no desempenho do OpenFlow eXtensible Match
** [[Arquivo:A01 - OpenFlow-main-1-Felippe.pdf]]
<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>

[[Arquivo:ETArchPilotDTS.jpg]]
<br>

=== Deployment and Experimentation ===
<br>

* 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}.
<br>


[[Arquivo:RedeOpenFlow.jpg]]


 \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.


[[Arquivo:RedeOperadora.jpg]]


 \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. 
<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>

== 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> 




== Discussões ==
<br>

# Como se faz o reenvio e roteamento de pacotes no FINLAN?
# Como o FINLAN faz a reordenação dos pacotes?
# Existe enfileiramento para uma posterior remontagem?
# Como a aplicação conversa com o DTS?
# Podemos usar o termo pacote ou seria frame? 
# O que seriam os títulos?
# A quantidade de roteadores pode ser um requisito?
# Se foram feitos experimentos com o ETCP, onde o FINLAN vai entrar?
<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>

= Sites =

 Entidades 
<br>

*IEEE Communications Society [http://www.comsoc.org/]
*Sociedade Brasileira de Telecomunicações [http://www.sbrt.org.br/]
*W3C [http://w3c.org/]
*W3C Semantic Web Activity [http://www.w3.org/2001/sw/]
<br>

 Diversos 
*TED [http://ted.com/]
*Academic Earth [http://academicearth.org/]
* [[TED - Web Semantic]]

= Eventos =

* [[Doutorado-FutureInternet]] 
<br>

* The Fifth International Conference on Access Networks ACCESS 2014
** 1st CfP: ACCESS 2014 || June 22 - 26, 2014 - Seville, Spain
**  http://www.iaria.org/conferences2014/ACCESS14.html
<br>

* 2014 International Conference on Information Science, Electronics and Electrical Engineering - ISEEE 2014
** April 26-28, 2014
** Sapporo City, Hokkaido, Japan
** http://www.iseee.org/submission.asp
<br>

 SBRC 2012 

*XXX Brazilian Symposium on Computer Networks and Distribued Systems
**[[Mini-Curso 1: Grandes Massas de Dados na Nuvem: Desafios e Técnicas para Inovação]]
**[[Tutorial: Internet Routing]]
**[[Palestra: Medindo a Qualidade dos Backbones entre os Sistemas Autônomos Brasileiros: Rastreamento de Problemas]]
**[[Palestra: Challenges in Content Distribution: the Cloud vs. the crowd]]
**[[Sessão Técnica 4: Sistemas Peer-to-Peer]]
**[[Palestra: Multilayer Networks, Network Virtualization, and System Stability]]
**[[Palestra: Tracking the Internet into the 21st Century]]
**[[Palestra: Pocket Switched Networks: Mobility at Work]]
**[[Sessão Técnica 11: Virtualização]]
**[[Salão de Ferramentas]]
**[[Palestra: Software Defined Networks: History, Hype and Hope]]
**[[Palestra: Petrobras: Caracterização, Controle e Planejamento de Tráfego em Redes de Missão Crítica]]
**[[Sessão Técnica: Grades Computacionais e Computação em Nuvem]]
**[[WPEIF: III Workshop de Pesquisa Experimental da Internet do Futuro]]
<br>


= Reuniões =
{{#forminput:form=Reuniao|button text=Crie um nova Reunião}}
<br>

[[ETArch Pilot - 13/03/15]] <br>
[[ETArch Pilot - 06/03/15]] <br>
[[ETArch Pilot - 10/10/14]] <br>
[[ETArch Pilot - 03/10/14]] <br>
[[ETArch Pilot - 05/09/14]] <br>
[[ETArch Pilot - 02/09/14]] <br>
[[ETArch Pilot - 29/08/14]] <br>
[[ETArch Pilot - 06/08/14]] <br>
[[ETArch Pilot - 30/07/14]] <br>
[[ETArch Pilot - 23/07/14]] <br>
[[ETArch Pilot - 16/07/14]] <br>
[[ETArch Pilot - 09/07/14]] <br>
[[ETArch Pilot - 25/06/14]] <br>
[[ETArch Pilot - 17/06/14]] <br>
[[ETArch Pilot - 04/06/14]] <br>
[[ETArch Pilot - 28/05/14]] <br>
[[ETArch Pilot - 21/05/14]] <br>
[[ETArch Pilot - 14/05/14]] <br>
[[ETArch Pilot - 07/03/14]] <br>
[[ETArch Pilot - 05/03/14]] <br>