wiki

ETArch Pilot

Revisão de 18h45min de 28 de janeiro de 2015 por Helvio (discussão | contribs) (→Escrevendo Artigo)

MEHAR

  • Mondial Entities Horizontally Addressed by Requirements


Colaboradores


  • Alex Vaz Mendes - 9945-3763 - alexvazmendes@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)
  • 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


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



Escrevendo Artigo


  • Chapters
    • Title
      • 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. 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. continuar

    • 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.
      • Murilo Borges e Alex
      • Instalação OpenvSwitch (OVS) no ubuntu
      • Configuração do OVS
      • Criação de tunel GRE entre 2 OVSs
      • Comprovação através da visualização do protocolo LLDP
      • Mover Estrutura de uma rede local experimental para uma rede MetroEthernet
      • ARTIGOS:
    • Results
      • 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?
      • Mobilidade das entidades?
      • Sinalização de controle?
      • Atuação dinâmica do controlador?
      • Eliminação de elementos?
    • Conclusions
      • Luiz Cláudio e Flávio
    • 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
      • 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


Discussões


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


Sites

Entidades


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


Diversos

Eventos



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


SBRC 2012



Reuniões

{{#forminput:form=Reuniao|button text=Crie um nova Reunião}}

ETArch Pilot - 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=33944”