Redes definidas por software (página 2)

O conceito dessas redes nasceu de um projeto de seis anos desenvolvido em cima de um outro conceito chamado "open source" (código aberto), ou seja, aberto a toda a comunidade dos pesquisadores de tecnologias e soluções de redes, numa colaboração das Universidades de Stanford e Berkeley. Isso significa um grande avanço, por permitir aos utilizadores dessas redes definirem fluxos de dados e de determinarem os caminhos desses fluxos, usando software independentemente do hardware, representando esse fato o principal motivador da proposta da tecnologia das Redes Definidas por Software.

Objetivos

Neste trabalho, os objetivos são mostrar os conceitos principais das Redes Definidas por Software e abordar aspectos relacionados à sua concepção, mostrando as ferramentas e protocolos utilizados para implementação dessa arquitetura. Além disso, o trabalho também aborda os principais fabricantes de soluções em SDN e dá uma visão do mercado e de algumas aplicações.

Estrutura do Trabalho

Este trabalho organiza-se em sete capítulos sendo que este abordou a motivação e seu objetivo. O segundo capítulo aborda a história dos elementos de uma rede SDN e faz uma comparação entre as redes legadas e as Redes Definidas por Software, além de apresentar também o conceito de pilha na arquitetura SDN. O terceiro capítulo fala sobre o protocolo OpenFlow, seus componentes, a sua arquitetura e as suas aplicações. O quarto capítulo apresenta as redes experimentais SDN no mundo, tratando suas particularidades e modelos de implementação. O quinto capítulo discute o mercado de SDN bem como os desenvolvedores de soluções. O sexto capítulo mostra algumas aplicações do uso do SDN como, por exemplo, em "Data Centers". No ultimo capitulo é feita uma análise final do conteúdo apresentando as conclusões.

Redes definidas por Software ou Software Defined Networks (SDN)

• História das Redes Definidas por Software

Apesar da evolução formidável da Internet, em termos de aplicações, sua tecnologia, representada pelo modelo Open Systems Interconnection (OSI) e pelos protocolos do modelo Transmission Control Protocol / Internet Protocol (TCP/IP), não evoluiu o suficientemente nos últimos vinte anos. Nesses, a Internet tornou-se comercial e os equipamentos de rede tornaram-se "caixas pretas", ou seja, são soluções integradas verticalmente baseadas em software fechado rodando em um hardware proprietário. O resultado desse modelo é o já engessamento da Internet.

Em contraste com o modelo atual de arquitetura da Internet, a plataforma de SDN, objeto deste trabalho, nasce de um projeto de seis anos desenvolvido em cima do conceito de "open source", ou seja, aberto a toda a comunidade dos pesquisadores de tecnologias e soluções de redes, numa colaboração entre a Universidade de Stanford e a Universidade da Califórnia em Berkeley [3]. Isso significa um grande avanço por permitir aos utilizadores destas redes definirem fluxos de dados e de determinarem os caminhos destes fluxos usando software independentemente do hardware, ou seja, as redes passam a ser abertas, no sentido de que os utilizadores podem integrar o software de um determinado fabricante ao hardware de outro, criando-se uma forma de abrir a competitividade do mercado, não sendo preciso comprar um determinado software e em conjunto o hardware do mesmo fabricante, representando este fato o principal objetivo dos proponentes da tecnologia de Redes SDN.

Na Arquitetura SDN proposta, tudo o que é inteligência de sistema operativo fica concentrada num sítio, onde haja "visibilidade global" sobre toda a rede. Portanto, em vez de replicar todos os protocolos de roteamento em todos os dispositivos, eles ficam num só lugar. Com este sistema operativo implantado em plataformas abertas de servidores, linguagens e outros sistemas operacionais, a introdução de aplicações e funcionalidades torna-se uma questão de instalação de pequenos programas, elaborados por quem os quiserem programar, podendo ser um fabricante ou um operador da rede.

A Open Networking Foundation (ONF[1]uma fundação constituída de pesquisadores das Redes SDN, afirma enfrentar ainda alguns desafios para elas se difundirem no mercado. As tecnologias saíram do laboratório há pouco tempo, e começam agora a entrar em ambientes de produção. Segundo Dan Pitt, diretor executivo da ONF, empresas como a Google, a Yahoo, e a Deutsche Telekon já utilizam o conceito com a tecnologia proposta pela organização [13][14].

• Arquitetura das Redes Definidas por Software

As Redes Definidas por Software, também são chamadas de Redes Programáticas, são baseadas na separação entre o plano de controle, responsável pelos protocolos e pelas tomadas de decisão que resultam na criação e atualização das tabelas de encaminhamento, e o plano de dados, comumente chamado de plano de encaminhamento, que controla a comutação e o repasse dos pacotes de rede.

Em comparação com as redes existentes hoje, as redes legadas, o plano de controle é executado no próprio equipamento, por meio dos protocolos inseridos em seu sistema operacional (SO), não sendo possível trocar qualquer tomada de decisão que não tenha sido prevista nestes protocolos. Para que seja possível "quebrar" esta restrição, faz-se necessária uma forma de permitir que o equipamento encaminhe os pacotes a partir de protocolos abrigados externamente, de forma que se tenha a separação do plano de controle daquele pré-configurado e não se limite aos protocolos desenvolvidos pelo fabricante.

O Protocolo OpenFlow, proposto por Mckeown, em 2008 [3], assunto que será abordado no Capítulo 3 deste trabalho, é um exemplo de protocolo para se implantar uma Rede Definida por Software, ao estabelecer uma interface de comunicação entre o plano de encaminhamento, que se encontra nos equipamentos de rede, sejam eles, "switches" ou roteadores, e o plano de controle, que no caso das Redes Definidas por Software, fica externo ao dispositivo de rede, alocado numa máquina física ou virtual.

A Figura 1 mostra o intuito destas redes separado em algumas camadas que mostram os detalhes dos elementos da mesma.

Figura 1: Separação dos elementos da Arquitetura de Redes Definidas por Software

• Introdução aos elementos de uma Rede Definida por Software

Basicamente, uma Rede Definida por Software utilizando o protocolo OpenFlow, consiste em elementos de rede habilitados para que o estado das tabelas de encaminhamento possa ser instalado através de um canal seguro, conforme as decisões de um controlador em software. Os componentes da arquitetura destas redes são: a tabela de fluxos, o canal seguro, o protocolo OpenFlow e o controlador.

• Tabelas de Fluxos

A entrada na tabela de fluxos do hardware de uma Rede Definida por Software consiste em regras, ações e contadores. A regra a ser aplicada a um determinado fluxo entrante na rede é formada com referência na definição de um ou mais campos do cabeçalho do pacote. Associa-se a ela um conjunto de ações que definem o modo com que os pacotes devem ser processados e para onde eles devem ser encaminhados. Os contadores são usados com a finalidade de manter estatísticas de utilização e também servem para remover fluxos inativos. As entradas nas tabelas de fluxos podem ser interpretadas como decisões em hardware do plano de controle (software), sendo, portanto, a mínima unidade de informação presente no plano de dados da rede.

• O Canal Seguro

Como a rede é toda desenvolvida em cima de protocolos públicos, ou seja, abertos "open source", é necessário que se tenha um canal para que possa trocar de forma segura informações entre o "switch" e o controlador, sem que sofra ataque de elementos mal-intencionados. A interface de acesso recomendada é o protocolo Secure Socket Layer (SSL). Interfaces alternativas (passivas ou ativas) incluindo-se o TCP são essenciais em ambientes virtuais e experimentais pela facilidade de utilização, pois não necessitam de chaves criptográficas.

• Protocolo OpenFlow

O protocolo OpenFlow é um protocolo aberto utilizado para a comunicação, fazendo uso de uma interface de acesso, para a troca de mensagens entre os equipamentos de rede e os controladores.

• Controlador

É o software responsável por tomar decisões e adicionar e/ou remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. Exerce a função de uma camada de abstração da infraestrutura física, permitindo de forma mais fácil a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. A programação do controlador permite a evolução das tecnologias nos planos de dados e as inovações na lógica das aplicações de controle.

A Figura 2 mostra a estrutura completa da arquitetura das Redes Definidas por Software com todos os elementos discutidos acima.

Fonte: http://yuba.stanford.edu/cs244wiki/index.php/Overview

Figura 2: Elementos de uma Rede Definida por Software

• Redes Legadas versus Redes Definidas por Software

Nas redes legadas, os equipamentos são compostos de duas partes: do software de controle, responsável por todas as tomadas de decisões, e pelo hardware, responsável pela trajetória dos dados "Datapath", atuando no encaminhamento dos pacotes na rede, onde ambos se encontram agregados no mesmo equipamento. Este modelo de equipamento tem desvantagens grandes, pois apresenta um complexo sistema de software com milhares de linhas de código fonte e múltiplas funções complexas integradas em sua infraestrutura física.

Com essa "amarração" estabelecida entre o plano de controle, representado pela entidade de software, e o plano de dados, cuja entidade representa o elemento de camada física (hardware), o mercado de rede é forçado a adquirir uma determinada solução de apenas um fabricante, não sendo possível comprar o hardware de um e o software de outro e, com isso, ele deixa de ser competitivo, devido à forte pressão em massa dos grandes fabricantes sobre os pequenos.

Num contexto paralelo, as Redes Definidas por Software foram elaboradas com o propósito de separar o plano de dados do plano de controle, representando um grande avanço para o futuro das redes de dados. A separação entre os planos de controle e dados permite que a rede possa ser mais eficiente e barata, além de suprimir o problema encontrado nas redes legadas em que um determinado produto deve ser comprado de um mesmo fornecedor por meio de um pacote, contento no mesmo, o hardware e o software [8].

Desta forma, o mercado passa a ser mais aberto, pois um determinado software de uma empresa fornecedora pode interagir com o hardware de outra, sem problema algum. Isso só é possível porque as Redes Definidas por Software usam um protocolo aberto como já citado, o protocolo OpenFlow por exemplo, que permite que a troca de informações entre o hardware e o software seja realizada sem que ambos estejam alocados no mesmo equipamento, de forma totalmente segura.

A Figura 3 mostra a evolução das Redes Legadas para o novo conceito de SDN.

Fonte: http://www.acreo.se/en/Technology-Areas/Broadband-Technology/Expertise/Multi-layer-network-architecture/

Figura 3: Comparação entre as Redes Legadas e SDN

• Pilha SDN

A pilha SDN (Figura 4) é constituída seguindo alguns princípios e fazendo uso das topologias existentes. Na camada de "Switches", têm-se os equipamentos e programas de firmware embarcados em dispositivos, como gateways residenciais e roteadores, bem como desenvolvimento de hardware de código aberto e plataformas de software para permitir a criação rápida de protótipos de dispositivos de rede. Na camada de virtualização existem controladores de propósito especial para controlar o OpenFlow, que atua como um "proxy" transparente entre "switches" OpenFlow e vários controladores.

Existem alguns softwares de controle que já se destacam para serem usados nessa camada controladores, como NOX, POX, Floodlight que é desenvolvido pela Big Switch, Beacon desenvolvido pela Stanford, e vários outros que são desenvolvidos em diversas linguagens e plataformas diferentes.

As aplicações são concebidas como uma plataforma extensível, que pode fornecer a base de muitas interessantes visualizações relacionadas à rede. A interface de usuário é capaz de exibir tanto a topologia da rede, bem como controles personalizados e informações relacionadas ao fluxo, que podem ser consultadas e recebidas de um controlador.

Na última camada são oferecidas ferramentas de depuração, implementando uma estrutura modular para adicionar e executar a implementação, para quantificar o desempenho de um "switch" com uso de programas e testando os controladores com o OpenFlow, emulando vários "switches" que se conectam a eles.

Figura 4: Pilha SDN

OpenFlow

• Contextualização

As redes de computadores já são parte da realidade de bilhões de pessoas, e são compostas por milhares de equipamentos como PCs, "Switches" e Roteadores. Atualmente, as redes de pacotes são compostas por uma pilha de inúmeros protocolos, como exposto na Figura 5, sendo os protocolos abertos RIP, BGP, OSPF, MPLS, NAT, etc. Outro problema enfrentado são os sistemas fechados que fazem uso de CLIs, SNMP, que acabam sujeitos a soluções específicas, exigindo equipamentos com hardware dedicado, geralmente proprietários, para suportar essa gama de protocolos com alto desempenho e segurança para processamento dos pacotes. Isso implica em implementações que exigem um profundo conhecimento para o uso de tais protocolos de forma a montar um verdadeiro quebra-cabeça.

Para facilitar a implantação destas redes, já que existe em um roteador por exemplo, mais de 5700 Request for Comments - (RFCs[2]surgiu uma nova proposta para um protocolo de redes, que seja mais dinâmico e operacional, embora ainda se trate de uma tecnologia experimental. Este protocolo recebeu o nome de OpenFlow.

Fonte:http://sites.google.com/site/routeflow/documents/RouteFlow_SBRC2011_marcelo.pptx?attredirects=0

Figura 5 Modelo de rede atual

O protocolo OpenFlow foi criado como uma solução para utilização em "switches Ethernet" para a construção de uma rede personalizada para experiências acadêmicas [3]. Ele tem por objetivo ser flexível e possibilitar implementações de alto desempenho e baixo custo. Outros benefícios gerados pelo protocolo giram em torno da programação da rede feita pelos operadores, fornecedores de software independentes e por usuários - e não apenas por fabricantes de equipamentos - utilizando ambientes de programação comuns, o que dá a todas as partes, novas oportunidades para gerar receita e diferenciação, aumentar a confiabilidade da rede e da segurança, assim como, uma gestão centralizada e automatizada dos dispositivos da rede, aplicando uma política uniforme, e sujeita a menos erros de configurações [9].

• Linha do tempo para as versões do Protocolo OpenFlow

Figura 6: Linha do tempo de versões do Protocolo OpenFlow

Na linha do tempo do protocolo OpenFlow, mostrada na Figura 6, é possível analisar a evolução do protocolo.

Em março de 2010, o protocolo "OpenFlow 1.0 Standards" foi desenvolvido para atender os requisitos necessários para a criação de "switches" habilitados com o protocolo OpenFlow. Na sucessão temos duas versões do OpenFlow, a versão 1.1 e 1.2, desenvolvidas no ano de 2011 e que são muito utilizadas pelos desenvolvedores e fabricantes de equipamentos das Redes Definidas por Software.

Atualmente, há três linhas do protocolo OpenFlow, a versão "Config 1.0" com suporte a IPv6, as versões 1.3 e "OF-Test 1.0", vistas na Figura 6, todas essas fornecem uma base estável para a próxima geração de Redes Definidas por Software, e para o uso do IPv6, espinha dorsal de tunelamento e QoS, que já está sendo utilizado por diversas empresas. Percebe-se que o protocolo OpenFlow está em constante evolução e futuras versões do mesmo poderão ser criadas e disponibilizadas para a comunidade mundial de profissionais e empresas de soluções em redes, para utilizarem e se beneficiarem dos seus pontos fortes.

• Componentes

O protocolo OpenFlow é um padrão em desenvolvimento para administração de redes LAN e WAN possibilitando assim o controle e a criação de VLANs, roteamentos e qualidade de serviço, oferecendo uma padronização e permitindo que diversos fabricantes usem um conjunto de regras padronizadas, possibilitando a inclusão de novas características e protocolos, independentes do software utilizado no "switch".

Para manejar um fluxo de dados em um "switch" o protocolo OpenFlow utiliza uma tabela de fluxo "flow-table". Permite também criar um grupo de tabelas que define um fluxo com entrada específica representando um método adicional de encaminhamento. É um protocolo que faz uso de um software de controle externo, controlando o caminho dos dados de um "switch". O controlador é quem faz esse gerenciamento das tabelas de roteamento e dos fluxos dos dados e pode ser implementado em um servidor comum. A Figura 7 mostra os principais componentes citados e que serão detalhados abaixo [4].

Adaptado de: https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.0.pdf

Figura 7: Principais componentes do "swicth" habilitado com protocolo OpenFlow

• Tabela de fluxos "Flow table"

Um fluxo tem como definição o conjunto de características entre dois nós em uma rede, e é definido pelos cabeçalhos das camadas de enlace, de rede e de transporte de cada pacote. Uma tabela de fluxo "flow-table" consiste em um banco de dados de entradas de fluxos "flow-entries" com alguns componentes principais, onde algumas ações podem ser destacadas: encaminhar o pacote para a uma porta específica do "switch", descartá-lo, encapsulá-lo e criptografar esse pacote, bem como limitar a banda, etc [5].

Cada entrada de fluxo possui três campos que mostram ao "switch" como proceder a cada fluxo:

• Regra - Consiste em fazer o "match"[3] dos campos nos cabeçalhos dos pacotes. Esta regra faz com que os fluxos sejam definidos, ou seja, os pacotes serão classificados como parte de um fluxo.

• Ação - Define o processamento dos pacotes.

• Estatísticas - Faz o registro dos números de pacotes e bytes que serão dedicados a cada fluxo e o tempo transcorrido desde que o último pacote fez o "match" auxiliando na remoção de fluxos inativos.

A Figura 8 mostra o diagrama da entrada de fluxo em uma tabela de fluxo.

Adaptado de: http://marcial.larces.uece.br/pesquisa/hermesnet

Figura 8. Entrada de fluxo em uma tabela de fluxo

Como citado acima cada entrada de fluxo da tabela de fluxo apresenta um conjunto de ações correspondentes que permitem encaminhar os pacotes, modificar os campos, ou descartar o pacote. Quando um "switch" recebe um pacote que não possui uma entrada em sua tabela de fluxos ele envia esse pacote para o controlador. Este então toma as decisões de como lidar com esse pacote podendo descartá-lo ou adicionar uma entrada de fluxo para encaminhar pacotes semelhantes no futuro.

• Canal de processamento "Pipeline Processing"

Cada "switch" possui múltiplas tabelas de fluxo, cada tabela de fluxo possui múltiplos fluxos de entrada, o canal de processamento define como os pacotes interagem com essas tabelas.

• Grupo de tabelas "Group table"

Os grupos de tabelas são definidos em quatro tipos, e os "switches" não são obrigados a suportar todos eles, apenas aqueles que são marcados como "requeridos". O controlador pode realizar uma consulta ao "switch" para saber qual tipo de grupo "Opcional" ele suporta [5].

• "All" (Requerido) - Realiza todos os tratamentos de dados "bucket[4]dentro desse grupo e é usado para encaminhamentos "broadcast" e "multicast". Se o encaminhamento deste tipo de pacote for direcionado diretamente para a uma porta de saída do "switch" ele será descartado, quando este chegar a porta de entrada deverá receber um tratamento diferenciado, que inclua uma ação de saída para uma porta virtual.

• "Select" (Opcional) - Executa um tratamento nos dados do fluxo. Os pacotes são enviados com um tratamento simples baseado em um algoritmo de seleção, mas que garanta a integridade dos dados. Quando uma porta específica de um grupo fica "down", pode-se desviar o tratamento para o conjunto restante de portas "up" ao invés de descartar os pacotes destinados a porta "down" isso permite que o link desse "switch" não caia.

• "Indirect" (Requerido) Executa o tratamento de fluxo neste grupo. Permite múltiplos fluxos ou um fluxo comum, suportando uma convergência mais rápida e eficiente.

• "Fast failover" (Opcional) - Cada ação de tratamento do fluxo é associada a uma porta específica, controlando seu estado, ativando o encaminhamento sem ter que voltar ao controlador.

• Canal seguro "Secure Channel"

O canal seguro estabelece e finaliza as conexões entre o "switch" e o controlador usando configurações e procedimentos de conexão do tipo SSL[5]que confere segurança na comunicação entre controlador e "switch", permitindo autenticações mutuas através da troca de certificados, fornecendo uma chave privada. Outras aplicações que não necessitam utilização de dados criptografados fazem uso do TCP pela simplicidade de aplicação e são muito úteis em ambientes virtuais.

• Controlador "Controller"

O controlador dispõe de todas as informações necessárias para determinar as funções desempenhadas pelo "switch" como, para qual porta o fluxo deve ser direcionado ou descartar os pacotes. Ele também deve enviar mensagens para todos os "switches" configurando todo o caminho da fonte até o destino.

O controlador pode controlar toda a rede contornando os convencionais problemas encontrados nos protocolos de camadas dois e três e suas configurações, pode também preencher previamente instruções ou enviar instruções dinamicamente como um típico "switch" sem "cache". Tem como principais funções adicionar e remover entradas de fluxo na tabela de fluxo a partir da necessidade do sistema.

O "switch" pode estabelecer a comunicação com um único controlador ou pode fazer isso com vários controladores ao mesmo tempo. Isso aumenta a redundância e diminui as chances de ocorrerem falhas, a troca do controle dos "switches" é feita entre os próprios controladores.

Novas aplicações podem ser facilmente criadas tendo base que o programador da rede pode criá-las a partir de suas necessidades. Os serviços também possuem as mesmas facilidades, fazendo com que o gerenciamento da tabela de fluxo se torne totalmente flexível.

• Estabelecimento de um fluxo

Na Figura 9 podemos acompanhar um exemplo do estabelecimento de um fluxo seguindo os seguintes passos: no primeiro passo é feita uma solicitação de algum conteúdo, como um vídeo por exemplo; no segundo passo essa solicitação é respondida e o fluxo é então encaminhado para o "switch", que consulta as suas tabelas de fluxo e identifica um novo fluxo; no terceiro passo o "switch" envia uma solicitação para o controlador requisitando um caminho por onde ele deve encaminhar o novo fluxo; no quarto passo o controlador, que possui uma visão geral da rede, responde ao "switch" mostrando-lhe o caminho que o fluxo deve seguir; no quinto passo o fluxo é encaminhado para os demais "switches" para estabelecer o fluxo; no sexto passo o fluxo é estabelecido sem novas consultas ao controlador.

Figura 9 Exemplo do estabelecimento de um fluxo

• Mensagens do Protocolo OpenFlow

O protocolo OpenFlow possui três tipos de mensagens, "controller-switch", assíncrona e simétrica. A "controller-switch" é inicializada no controlador e é usada para gerenciar o status do "switch". A assíncrona é gerada no switch e comunica o controlador das eventuais mudanças da rede e o status do "switch". Gerada tanto no controlador como no "switch" a mensagem simétrica é enviada sem solicitação [5].

• Controlador-switch:

• "Features": O controlador pode solicitar os recursos de um "switch" enviando um pedido de suas características e os "switches" devem responder com uma resposta que especifique suas capacidades. Isto é normalmente realizada após o estabelecimento da conexão através do canal seguro.

• "Configuration": O controlador possui a capacidade de definir e consultar as configurações de um "switch".

• "Modify-state": As mensagens de modificação de estados são enviadas aos "switches" a fim de modificar seu estado atual. Tem como objetivo adicionar ou remover as entradas nas tabelas de fluxo e adicionar algumas propriedades em suas portas.

• "Read-state": São mensagens usadas pelo controlador para coletar estatísticas do "switch".

• "Packet-out": Mensagens usadas pelo controlador para enviar pacotes para uma determinada porta do "switch" por onde os pacotes devem ser encaminhados.

• "Barrier": "request/reply" são mensagens utilizadas pelo controlador para garantir que as solicitações foram cumpridas ou receber notificações de operações concluídas.

• "Role-resquest": Essas mensagens são utilizadas pelo controlador para consulta de uma função. É útil quando o "switch" se conecta a vários controladores.

• "Asynchronous-Configuration": As mensagens de configuração assíncrona são usadas pelos controladores para definir filtros adicionais sobre as mensagens assíncronas que são recebidas sem solicitações.

• Assíncrono

Mensagens assíncronas são enviadas de um "switch" sem a solicitação do controlador. Essas mensagens são enviadas para indicar a chegada de novos pacotes, mudanças nos estados do "switch" ou algum respectivo erro. A seguir veremos os principais tipos de mensagens assíncronas:

• "Packet-in": Transfere o controle de um pacote para o controlador, para que este especifique as medidas a serem tomadas, como as portas que o fluxo deve seguir.

• "Flow-removed": Informa o controlador sobre a remoção de uma tabela de entrada. Geralmente são geradas como resultado de uma requisição de exclusão do controlador ou quando o tempo de uma tabela expira.

• "Port-status": Informa o controlador sobre a mudança de estado em uma porta, se essa sofreu mudanças de configurações ou ficou inativa.

• "Error": O "switch" notifica aos controladores algum erro ocorrido.

• Síncrono

Mensagens simétricas são enviadas sem solicitação, em qualquer direção.

• "Hello": Mensagens "Hello" são trocadas entre o "switch" e o controlador na inicialização de conexão.

• "Echo": São utilizadas principalmente para verificar a existência de uma conexão entre o controlador e "switch", e pode também ser usada para medir a sua latência ou sua largura de banda. É semelhante ao comando "ping" utilizado para verificação de conexão da rede, com o uso do protocolo ICMP.

• "Experimenter": Essas mensagens fornecem uma maneira padrão de opções para os "switches" para oferecer funcionalidades adicionais. É uma área destinada para futuras atualizações do protocolo OpenFlow.

Na Tabela 1 pode ser conferido as principais mensagens trocadas entre o controlador e o "switch" e um breve resumo das suas funções [5].

Tabela 1: Principais mensagens trocadas entre o controlador e o "switch"

Mensagem	Tipo	Descrição
Hello	Controlador-> Switch	Como no TCP há uma troca de mensagem entre o controlador e o "switch" como um "handshake".
Hello	Switch-> Controlador	O "switch" responde a solicitação do controlador
Features Request	Controlador-> Switch	O controlador solicita ao "switch" quais portas estão disponíveis
Set Config	Controlador-> Switch	Neste caso o controlador solicita ao switch o envio dos tempos de cada fluxos
Features Reply	Switch-> Controlador	O Switch responde a solicitação do controlador com uma lista de portas, suas velocidades e ações
Port Status	Switch-> Controlador	O "switch" informa ao controlador as mudanças de velocidades nas portas ou na conectividade.
Packet-In	Switch-> Controlador	Um pacote que é recebido e não possui entrada na tabela de fluxo é encaminhado para o controlador.
Packet-Out	Controlador-> Switch	O controlador envia o pacote para uma ou mais portas do "switch"
Flow-Mod	Controlador-> Switch	Faz o "switch" adicionar um fluxo particular em suas tabelas.
Flow-Expired	Switch-> Controlador	Solicita ao controlador para remover o fluxo após um período de inatividade.

• Arquitetura do protocolo OpenFlow

Os "switches" podem ser definidos em dois tipos, o primeiro somente suporta o protocolo OpenFlow em um único tipo de operação através do canal de processamento, não sendo permitido operar em outro modo, e o segundo é o modo híbrido que suporta tanto operações com o OpenFlow e "switches" Ethernet tradicionais de camada dois, que possuem isolamentos por VLANs, ACL e QoS. Na arquitetura atual, os equipamentos são divididos em dois planos, como ilustra a Figura 10;

Figura 10: Estrutura interna de um "Swicth" Ethernet

O "control plane" (plano de controle) é responsável pelas tarefas complexas de gerenciamento de pacotes, podendo ser lento e ter uma latência muito variável. Já o "data plane" (plano de dados) lida com as tarefas comuns dos pacotes, precisa ser rápido em seu funcionamento para processar todos os pacotes. Essas categorias refletem uma divisão entre as tarefas de software e hardware [7][10].

O "data path" de um "switch", com suporte ao protocolo OpenFlow, Figura 11, contêm o que denominamos de "Flow-Table", e as ações associadas com a entrada de cada fluxo existente.

Figura 11: Estrutura do "Swicth" habilitado com protocolo OpenFlow

Existem três ações associadas a cada entrada de fluxo na tabela de fluxo:

• Fazer o encaminhamento dos pacotes do fluxo que chega em uma determinada porta. Isso significa que os pacotes devem ser roteados pela rede e nos "switches" estas ações são efetuadas na velocidade em que o hardware permite.

• Fazer o encapsulamento e transmissão de pacotes deste fluxo para um controlador. Estes pacotes são enviados usando o "Secure Channel". Geralmente, utiliza-se o primeiro pacote de um novo fluxo, encaminhando-o para o controlador decidir se o fluxo será adicionado à tabela de fluxo. Pode também ser configurado o redirecionamento de todos os pacotes para um controlador para que seja realizado algum tipo de processamento.

• Descarte do pacote de um determinado fluxo. Esta ação geralmente é usada por motivos de segurança, contra eventuais ataques ou também para redução de transmissão de mensagens indesejáveis enviadas a partir de "hosts".

• OpenFlow em "Data Centers"

O protocolo OpenFlow foi proposto como base de uma nova tecnologia para as redes do futuro. Uma grande parte das empresas estão procurando esta tecnologia para otimizar suas redes.

A seguir serão descritos alguns dos principais requisitos para uma rede de "Data Centers", e como o uso do OpenFlow pode suprir estes requisitos e o porque da importância de tecnologias "open source".

• Requisitos e soluções OpenFlow para "Data Centers"

Os requisitos para a próxima geração de redes de dados são:

Eficiência - Alcançar maior utilização dos servidores, obtendo uma melhor eficiência energética. Grande parte da ineficiência nos atuais "Data Centers" vem da necessidade de segmentar as redes em VLANs ou sub-redes IP.

Uma Rede Definida por Software com uso do protocolo OpenFlow, permite que os usuários segmentem a rede programando-a, de acordo com as suas necessidades, consistindo na criação de uma rede sob medida, ao invés de redes em tamanhos que são potências de 2 como no caso de uma rede IP.

Escalabilidade - Com a virtualização de servidores, centenas de MVs podem ser instaladas em um único servidor, o que significa que antes um administrador via milhares de endereço de servidores, agora ele vê endereços de maquinas virtuais. É difícil para os administradores de rede conseguir organizar todos esses endereços, mas uma rede definida por software baseada em OpenFlow pode ajudar a controlar centralmente esta explosão de endereços, fornecendo e permitindo que os administradores da rede descrevam as políticas destinadas para todos os "switches" da rede. E mais uma vez, a Rede Definida por Software pode solucionar este problema programando diretamente os seus componentes, permitindo que as mesmas regras sejam aplicadas em toda rede.

Simplicidade - Um das principais vantagens da SDN e do OpenFlow é a sua simplicidade, que permite que todos os requisitos sejam feitos a partir de um ponto central de controle, ou seja, o administrador faz as especificações em toda sua rede, baseado em questões de segurança e regra. Isto faz com que sejam reduzidas as configurações isoladas de centenas ou milhares de dispositivos e se torne uma configuração única e centralizada [2].

• RouteFlow

O RouteFlow é um projeto do CPqD que visa reunir protocolos de roteamento IP e redes com protocolo OpenFlow, visando um desacoplamento efetivo entre o plano de encaminhamento e o plano de controle. É uma ideia simples para executar protocolos IP em plataformas centralizadas fornecendo aos dispositivos habilitados para o OpenFlow um plano de controle. O projeto RouteFlow possui dois objetivos principais: o primeiro é que permite um caminho de migração implantada em SDN oferecendo um controlador com uma abordagem central em uma rede híbrida. O segundo é fornecer uma plataforma para inovação em torno de roteamento IP. O RouteFlow propõe uma arquitetura de roteamento de menor custo-benefício, que combina a flexibilidade do software "open source" e protocolos de roteamento com o desempenho do hardware com suporte ao OpenFlow [6].

Experiências com Redes Definidas por Software

• Contextualização de Redes Experimentais

As redes experimentais foram desenvolvidas com o intuito de permitirem a criação de ambientes compartilhados para auxiliar a validação de novas arquiteturas de redes, permitindo que se possa levar a uma Internet futura com características melhoradas, não permitindo que os mesmos erros que foram ocasionados na década de 70, sejam repetidos.

As limitações de segurança, gerenciamento, disponibilidade e flexibilidade encontradas na estrutura da Internet que temos hoje, frutos do modelo implantado no inicio da mesma, criam uma série de "remendos" na tentativa de resolver problemas pontuais, gerando aumento da complexidade e resultando num sistema menos robusto, cuja operação se torna mais difícil e cara.

A solução que vem sendo adotada pela comunidade de pesquisa de redes para eliminar todos os problemas encontrados na Internet de hoje, vem sendo a elaboração de redes experimentais que permitirão arquiteturas, serviços e aplicações de redes alternativas, em grande escala e em condições reais, permitindo que com o amadurecimento dos protótipos, essas redes possam atender a uma grande comunidade de usuários de forma satisfatória e com qualidade aceitável, por meio de ferramentas extensas de medições e coletas de dados.

Muitos países passaram a desenvolver suas próprias redes, dando a chance para que seus pesquisadores possam realizar testes e validações de protocolos, de arquiteturas e de software de controle, permitindo que protótipos sejam postos no mercado com elevado grau de confiabilidade, sustentados por pesquisas bem embasadas, buscando minimizar falhas futuras que possam surgir nestes produtos.

• Redes Experimentais Definidas por Software no mundo

Vários exemplos de redes experimentais SDN podem ser citados pelo mundo , como o GENI , projeto de iniciativa dos Estados Unidos, por intermédio da "National Science Foundation" (NSF), o FIRE na Europa, e demais projetos que serão apresentados neste capítulo.

• GENI (Estados Unidos)

O GENI consiste em um ambiente global de inovações em redes, partindo de um laboratório virtual onde pesquisadores se unem para realizar experiências e criar novas possibilidades para a Internet do Futuro. O GENI tem como missão abrir caminhos para novas pesquisas em engenharia de redes, e acelerar o potencial das inovações que prometem explorar a Internet do futuro em grande escala, criando oportunidades para uma compreensão da transformação das redes globais e suas interações com a sociedade. Totalmente dinâmica e adaptável, o GENI abre novas perspectivas através da frontreira da ciência, aumentando a oportunidade para um significativo impacto sócio-econômico.

O GENI irá apoiar em grande escala uma análise comum, heterogênia, com uma infra-estrutura altamente instrumentada que permitirá a programação de toda a rede, promovendo inovações, segurança, novas tecnologias, serviços e aplicações, oferencendo ambientes colaborativos e em carácter exploratório para o meio industrial, acadêmico e público.

Uma empresa chamada BBN Technologies[6]foi selecionadao pela NSF para operar o "GENI Project Office" (GPO), que é responsável pela gestão do planejamento e projeto do GENI.

O GPO fornece engenharia de sistemas e experiências em gestão de projetos para orientar e planejar um modelo para o GENI. Os engenheiros de sistemas do GPO ajudam na elaboração de projetos, identificando e controlando os riscos técnicos, capturando e gerenciando os requisitos do sistemas, ajudando também na supervisão e no apoio a grupos de trabalho do GENI.

Existem também os Grupos de Trabalhos (GT) que são locais de trabalhos técnicos necessários para desenvolver o GENI, no que diz respeito a arquitetura, design, política, entre outros. Foram criados para garantir que o projeto GENI ocorra de forma transparente, e são aberto a todos, desde participantes de laboratórios acadêmicos, industrias e governamentais.

Os membros desses grupos fazem revisão do requisitos e dos documentos do projeto, avaliam softwares e serviços contribuídos por membros do GT. A ênfase está na contribuição técnica, incluindo as necessidades da comunidade de pesquisa e casos de uso, independentemente da fonte de apoio financeiro.

Os pesquisadores dividiram suas pesquisas em espirais, sendo que uma espiral consiste em 12 meses de pesquisa. Após terminada a primeira espiral, inicia-se a segunda que perpetuará por mais 12 meses e assim por diante. O que se espera é que a comunidade de pesquisa evolua, combinando as experiências das espirais anteriores e definindo metas específicas para as espirais futuras. A espiral 1 do GENI é a primeira fase exploratória com uma abordagem rápida, que informa os planos técnicos e operacionais para infraestrutura de pesquisa. O principal objetivo da espiral 1 é desenvolver e integrar projetos o mais rápido possível, elaborando protótipos de trabalhos e provendo uma evolução na comunidade de pesquisa. Um protótipo concluído poderá ajudar a comunidade a alcançar suas metas compartilhando uma grande quantidade de dados para futuras discussões.

Novos projetos já estão cotados para a espiral 2 para preencher várias críticas feitas durante a espiral 1. Dando mais atenção a resquisitos de segurança, arquitetura, ferramentas de fluxo, experiências com usuários finais, protótipos para instrumentação e medição. Finalmente, serão lançados dois tipos de campus GENI, um usando somente o protocolo OpenFlow e o outro fazendo uso da tecnologia WiMax em conjunto com o OpenFlow. Os backbones nacionais serão construídos com suporte ao OpenFlow, além disso, ele será também habilitado em roteadores comerciais. Uma forte base acadêmica e industrial será criada pelo GENI afim de habilitar equipamentos comerciais da Arista, Cisco, HP, Juniper e NEC, com o software da AT & T Labs e da Nicira.

O GENI irá habilitar o OpenFlow na construção das LANs, WLANs e equipamentos de backbone em 8 campus universitários e de pesquisas importantes. O protocolo OpenFlow é adicionado como um recurso para os "switches", roteadores e pontos de acesso sem fio, fornecendo um padrão para permitir executar experiências, sem a necessidade dos fornecedores exporem o funcionamento interno de seus dispositivos de rede ou de pesquisadores terem que requerir software específico de controle aos seus fornecedores.

Dentro do contexto do GENI, o OpenFlow abre uma rede para que ela possa ser compartilhada entre a produção de fluxos e a investigação destes, que podem ser gerenciados por um sistema de controle do GENI, criando diferentes ambientes virtuais para pesquisas distintas. Esta possibilidade de multiplos usos são extremamente interessantes para o GENI, porque permite que tal infraestrutura cresça. Em particular, o GENI pretende habilitar o protocolo em LANs existentes nos campus universitários em pontos de acesso WiFi, acelerando a introdução de estudantes neste empreendimento.

Na Figura 12 identificamos os oitos primeiros campus com uso do OpenFlow que serão implementados pelo GENI. Em cada campus os pesquisadores são agrupados em equipes para planejar, implantar, e operar os "switches" com suporte ao OpenFlow e na Figura 13 alguns equipamentos que serão usados por esses campus [30][31].

Fonte: http://www.geni.com

Figura 12: Campos para implementação do OpenFlow na rede GENI

Fonte: http:// www.geni.com

Figura 13: Alguns equipamentos utilizados nas pesquisas nos campus.

• AKARI

O objetivo do projeto AKARI é projetar a rede do futuro, tendo suporte do "National Institute of Information and Communications Technology" (NICT[7]do Japão. O projeto pretende implementar uma rede de ultima geração até 2015, estabelecendo uma arquitetura e criando um projeto de rede com base em tecnologias inovadoras, pesquisando novas arquiteturas de rede, onde não há limitações, com a possibilidade da migração das condições existentes para outras que ainda serão criadas. O objetivo é criar um projeto abrangente que esboce como a rede futura inteira deve ser.

Lançada em 2006 o cronograma de concepção do projeto foi dividido em um primeiro período de cinco anos, até que a nova geração de diagramas de projeto de rede fossem obtidos, e um segundo período de cinco anos para o desenvolvimento de bancos de ensaio com base nesses diagramas, como mostra a Figura 14.

.

Fonte: http://akari-project.nict.go.jp/eng/concept-design/AKARI_fulltext_e_translated_version_1_1.pdf

Figura 14 Concepção de projeto da arquitetura AKARI

No primeiro ano, o conceito do projeto foi criado e princípios de design iniciais foram apresentados. Um projeto detalhado foi realizado durante o segundo ano, enquanto eram revisados os princípios iniciais do design. No terceiro e quarto ano, os protótipos foram desenvolvidos, e diagramas de design foram concluídos no quinto ano, nos próximos anos, serão incorporados os conceitos da rede em alguns testes.

O AKARI irá criar um projeto de uma nova geração de rede para ser incorporado em todo o Japão. Esta rede será baseada em tecnologias de ponta e atuará como base para o apoio a todos os outros serviços de comunicações. O projeto não só será de uma rede de nova geração inteira, mas também um indicador para as indústrias, de quais serão as possíveis novas tecnologias de rede da próxima geração com o qual a rede estará interagindo.

O AKARI avaliará a rede usando bancos de ensaio através da cooperação com universidades e indústrias e levará ao caminho para a normalização no futuro. Para conseguir isso foram identificadas algumas diretrizes como, indicar ações futuras e garantir inovações neutras para as indústrias competitivas, garantir projetos baseados em princípios básicos, que são comuns globalmente, e não dar ênfase em progressos e melhorias em tecnologias de componentes específicos, criando uma visão abrangente, do que a futura rede será em dez anos com base em experiências práticas [32].

• FIRE (Europa)

O objetivo geral da "Future Internet Research and Experimentation" (FIRE) é a combinação da inovação tecnológica e social, pesquisando e experimentando novos paradigmas relacionados à Internet, tanto para arquiteturas de Internet do Futuro quanto para uma abordagem total e multidisciplinar da compreensão da evolução da Internet.

A implementação do FIRE na Europa visa à pesquisa experimental e o financiamento de projetos que produzam infraestruturas para experimentação da Internet do Futuro. Projetos de destaque financiados pela iniciativa FIRE incluem o Onelab, FEDERICA, PII e OFELIA [36].

A iniciativa OneLab desenvolve instalações para a Internet do Futuro. Provendo instalações experimentais, abertas, de propósito gerais e compartilhadas, em larga escala e sustentáveis que permitam à indústria europeia inovar e verificar o desempenho de suas soluções, ideias e inovações. O OneLab possui alguns laboratórios experimentais ao redor do mundo com a definição de "PlanetLab" possuindo projetos na Europa, Coréia, Japão, Estados Unidos e Brasil com o projeto FIBRE.

O projeto FEDERICA tem a intenção de ser neutra quanto ao tipo de protocolos, serviços e aplicações que podem ser testadas. O objetivo do projeto é desenvolver mecanismos que permitam tais experimentos serem executados através de redes de produção existentes, tem criado uma infraestrutura baseada em enlaces Gigabit Ethernet, equipamentos de transmissão e nós de computação (com capacidade de virtualização), para apoiar as atividades de experimentação em novas arquiteturas e protocolos para a Internet do Futuro.

O objetivo principal do projeto PII é criar uma federação de instalações experimentais entre diferentes polos de inovação regional na Europa. Isso permite que as empresas participantes possam testar novos serviços de comunicação e aplicações na Europa como um todo [34][35].

O projeto OFELIA, visa fornecer instalações experimentais com capacidade baseada na tecnologia do OpenFlow para experimentadores, pesquisadores e projetos de maneira geral. A infraestrutura OFELIA inclui "ilhas" OpenFlow na Bélgica, Alemanha, Itália, Espanha, Suíça, Reino Unido e no Brasil, especificamente na cidade de Uberlândia em Minas Gerais, mas que ainda não está em operação. A Figura 15 ilustra os países que possuem as ilhas do projeto OFELIA.

Fonte: http://www.fp7-ofelia.eu/ofelia-facility-and-islands/

Figura 15: Estrutura de uma "ilha" baseada em OpenFlow no projeto OFELIA

O projeto é parecido com o tipo de rede que está sendo implementada no Brasil, mas com algumas diferenças, uma delas é que em todos os países que implementam esse sistema é de forma diferente e de acordo com a sua necessidade e capacidade [33][36].

• FIBRE (Brasil)

O projeto é coordenado pela Universidade Federal do Pará, por intermédio do grupo de pesquisa em redes de computadores e comunicação multimídia. Desta forma o mesmo foi aprovado no edital de chamadas coordenadas no Brasil, pela União Europeia em TIC e do CNPq, além da Austrália. A RNP também tem participação no projeto FIBRE com cooperação internacional e com os parceiros brasileiros CPqD, Universidades Federais de Goiás (UFG), Rio de Janeiro (UFRJ) e São Carlos (UFSCar).

O principal objetivo do projeto é a concepção, a implementação e a avaliação de um ambiente de experimentação compartilhado entre a Europa e o Brasil. As principais atividades são o desenvolvimento em um novo ambiente de experimentação no Brasil, o aprimoramento de dois ambientes de experimentação europeus já consagrados visando a criação de uma única instalação compartilhada desse sistema. Esses experimentos foram realizados em conjunto com pesquisadores europeus e ajudam a desenvolver essa tecnologia adaptando as necessidades brasileiras.

O ambiente brasileiro onde serão realizados todos os testes, terão incluídas estas localidades que serão denominadas ilhas localizadas nos principais colaboradores desse projeto como ilustrado na Figura 16.

Fonte: Revista de Ciência, Tecnologia e Inovação do Estado do Pará, p. 42-43, 2012

Figura 16: Localização e interconexão das instalações no Brasil

Como ilustra a Figura 16, cada ilha terá um núcleo comum de comutadores, conjuntamente com seus controladores, bem como um cluster de servidores de computação e armazenamento e outro cluster de nós sem fio, ambos apropriadamente virtualizados. Cada ilha irá propor suas próprias extensões possíveis, integrando recursos específicos da ilha ao FIBRE, tais como redes de acesso sem fio (WiFi, WiMax, 3G/4G), assim auxiliando o monitoramento na questão do escoamento do tráfego fazendo o encaminhamento para as redes ópticas.

Observa-se ainda que a Internet atual não conseguirá atender todos desafios que são impostos na questão da capacidade. O processo de análise dessa nova arquitetura já começou em muitos países com as tecnologias GENI e FIRE. Neste contexto, a virtualização tornou-se a principal ferramenta para o desenvolvimento, adaptando essa tecnologia em todas as comunicações ou camadas computacionais. Portanto será possível diminuir a complexidade dos recursos físicos existentes e assim apresentar simples interfaces para fácil implementação de qualquer dispositivo de acesso [37].

A colocação dessas novas ilhas experimentais no Brasil através do projeto FIBRE, terá uma valiosa contribuição na questão da infraestrutura, extremamente útil para a avaliação e análise comparativa de algoritmos inovadores entre outras técnicas para colocação dessa tecnologia no mercado atual. Pesquisadores são incentivados a usar a plataforma de experimentação FIBRE para conduzir as pesquisas inovadoras e também para o desenvolvimento de protótipos, isso significa que, ao termino das pesquisas nos equipamentos, não haverá um descarte após o termino do projeto, pelo contrário, contribuirão para o desenvolvimento e pesquisas das redes do futuro.

Vale salientar que os institutos poderão reforçar as suas atividades de pesquisa e aumentar o seu prestígio internacional através da publicação dos resultados do projeto em conferências. Com o auxílio dos acadêmicos poderão oferecer cursos avançados de rede e fornecer aos novos estudantes um material de fácil entendimento e assim ajudar numa crescente experimentação entre os pesquisadores da rede [37].

• A RNP e as Redes Definidas por Software

A Rede Nacional de Ensino e Pesquisa (RNP) é um programa prioritário de Informática da Secretaria de Política de Informática do Ministério da Ciência e Tecnologia (Sepin/MCT) que prevê a manutenção de uma rede acadêmica nacional, com uma infraestrutura de alto desempenho para comunicação entre instituições de ensino e pesquisa, e que conta com um laboratório para testes e desenvolvimento de aplicações e tecnologias de redes avançadas.

A RNP tem se dedicado, desde 2000, à promoção do uso de aplicações e soluções avançadas em redes de computadores e telefonia sobre a rede. Ela apoia o desenvolvimento e o uso da Internet como forma de facilitar o progresso da educação e da ciência em geral. Essa rede nacional foi batizada de rede Ipê, alcançando todos os 26 estados da Federação e o Distrito Federal. Conta com uma capacidade suficiente para viabilizar não só o tráfego da Internet , mas também o uso de serviços e aplicações avançadas e experimentação.

A rede Ipê integra dois tipos de serviços: "backbones" para produção e "backbones" para experimentação. O "backbone" para produção tem a finalidade de conectar todas as Instituições Federais de Ensino Superior (IFES) com os Institutos de Pesquisa do Ministério de Ciência e Tecnologia, e o "backbone" de experimentação serve para dar suporte às aplicações avançadas como a Internet do Futuro e as Redes Definidas por Software (SDN). Com isso a RNP procura auxiliar os pesquisadores e as universidades, criando laboratórios de experimentação para estas novas redes, permitindo que todos possam usufruir de suas instalações, para que se desenvolva a tecnologia nacional. Além disso, ela promove várias palestras e workshops para promover ainda mais o conhecimento, aproximando os pesquisadores, para que estes possam compartilhar suas experiências. Para as redes SDN, a RNP está contribuindo de forma a se dispor totalmente na realização de pesquisas e no desenvolvimento do ambiente de testes necessários para essa tecnologia, bem como na realização de eventos voltados a discussão e analise das soluções que poderão ser utilizadas nestas redes [41].

Uma Visão do Mercado de Redes Definidas por Software

• Introdução ao mercado das Redes Definidas por Software

As Redes Definidas por Software é a ponta do iceberg de um amplo processo, que visa revolucionar a indústria de rede, nos padrões do que representou a migração dos "mainframes"[8] para a área da computação.

Como exemplo, a VMware atraiu os olhares do mercado ao investir US$ 1,26 bilhão na compra da Nicira, uma "startup"[9] especializada em uma tecnologia aberta de gestão de tráfego de rede baseada no padrão do protocolo OpenFlow. Esta aposta bilionária da empresa deixou claro que o mercado de SDN como um todo, no qual o protocolo OpenFlow é a parte mais visível por trás do negócio, deve saltar dos US$ 200 milhões registrados no fim do ano passado para chegar ao valor de US$ 2 bilhões até 2016 como mostrado no Gráfico 1 [15].

Gráfico 1 Estimativa de crescimento do mercado de SDN

O argumento da expansão do mercado de SDN fundamenta-se no fato de que a utilização de padrões abertos, onde se pode citar como exemplo o protocolo OpenFlow, permite a abertura de um campo fértil para a criação de uma elevada gama de aplicativos para segurança, gerência de tráfego, cumprimento de regulações do governo e acesso a sites, que serão os "drivers" de valor dos produtos no futuro [3].

O SDN está deixando de ser uma tecnologia de laboratório para ser usada em grande escala pela indústria de redes. Já está pronta para um crescimento rápido e tem potencial para resolver específicos problemas em negócios de redes corporativas. Empresas de telecomunicações continuam sendo as maiores adeptas do SDN e em termos de regiões a América do Norte possui o maior mercado para as soluções SDN, mas em cinco anos a Ásia poderá se tornar um dos maiores mercados do mundo. Junto com o SDN também cresce o mercado de "Cloud" já que por trás de cada nuvem existe um "Data Center".

Grandes empresas como IBM, HP, NEC, já desenvolvem aplicações que se utilizam dessa tecnologia, que cada vez mais vem ganhando destaque dentro deste cenário de Redes Definidas por Software. Apesar de ser uma tecnologia de rede ainda muito recente, algumas pesquisas revelam que em alguns anos será um negócio de bilhões de dólares. O SDN é uma das coisas mais relevantes da última década em se tratando de infraestrutura de redes, e vem chamando a atenção por sua simplicidade e facilidade de gerenciar e programar as redes.

A principal razão para o crescimento são os ambientes de redes altamente virtualizados que necessitam de Redes Definidas por Softwares e clientes que queiram adotar novas ferramentas de gerenciamento, nas redes atuais existe uma escassez desses recursos ou quase não existem. O OpenFlow e o mercado de SDN como um todo inclui "switching" que é a comutação e "routing" que é o roteamento, bem como serviços e softwares.

Existem hoje basicamente três tipos de mercado em que o SDN pode ser destacado: empresas emergentes "startups" como as americanas Big Switch, Arista; empresas tradicionais na área de redes como Cisco, Juniper, Brocade e a brasileira Datacom; e depois as gigantes em soluções de TI como a IBM, HP, Dell. Todos esses três grupos tendem a lucrar e muito com a revolução do SDN. Em lançamentos recentes de produtos da NEC e da Datacom ganharam destaque por apresentar equipamentos com suporte ao protocolo OpenFlow.

A capacidade de programar a rede é tudo no SDN, mas o OpenFlow não é o único caminho disponível e alguns fabricantes como a Arista e a Brocade fornecem APIs abertas que trabalham em conjunto com SDN. Apesar do OpenFlow e o SDN ser associados como uma única coisa é a programação que determina uma Rede Definida por Software.

Uma tendência que tem afetado muitas redes corporativas é chamada de BYOD "Bring Your Own Device" algo como "traga seu próprio dispositivo", em tradução livre. As empresas estão tomando certo cuidado com o BYOD, pois precisam modificar sua política de criptografia das redes WI-FI e reforçar a segurança dos dados. O SDN permite um controle de acesso e recursos de rede em um nível mais segmentado, podendo programar a rede com características individuais para cada usuário. Também pode ajudar as empresas a lidar com grandes quantidades de dados, dando determinados caminhos para o "Big Data", fazendo uma separação do que são dados locais e o que será remoto.

O protocolo OpenFlow está recebendo muito suporte por parte dos fabricantes, mas é uma ferramenta nova que não está totalmente desenvolvida e precisa ser aprendida para superar os desafios impostos. Empresas prestadoras de serviços e de telecomunicações devem manter seus olhares fixos nessa tecnologia, mesmo que ainda esteja dando seus primeiros passos, as Redes Definidas por Software podem ajudar a automatizar processos manuais em empresas que buscam consolidar e ampliar seus "Data Centers". Há muitos caminhos que essa tecnologia pode trilhar, cabendo as empresas conhecer seus problemas específicos e focar em resolvê-los.

• Desenvolvedores de solução em SDN

Com o surgimento dessa nova tecnologia, as empresas já se movem para oferecer suas soluções ao mercado, definindo suas estratégias e metodologias de negócios. Com aplicações e focos diferentes cria-se um ambiente propício à competitividade e adoções de medidas que visam oferecer a melhor solução para cada caso.

• Cisco

A Cisco adotou o SDN com o objetivo de ganhar uma posição em uma tecnologia emergente que ameaça seu principal negócio. Um ambicioso pacote de ferramentas chamado "Cisco Open Network Environment", ambiente de rede aberta que visa oferecer a provedores de nuvem, prestadores de serviços e acadêmicos suporte abrangente as Redes Definidas por Software em seus produtos. A intenção da empresa é acabar com as especulações a respeito da estratégia da empresa diante do SDN e colocando o foco em cima de seus clientes.

O ambiente de rede aberta possui uma plataforma de desenvolvimento de software, que fornece acesso via APIs ao sistema operacional da Cisco e ao hardware. Possui também um software para controladores, e oferece suporte ao OpenFlow em uma linha de "switches", estendendo sua aplicações ao "OpenStack", "hypervisors" e LANs virtuais através dos seus produtos.

Como essa nova tecnologia permite que as empresas dependam menos de equipamentos proprietários como os feitos pela Cisco, por permitir o desenvolvimento em cima de equipamentos mais baratos, essa ação da empresa marca o movimento das tecnologias "open source" que estão mudando a indústria de redes. A Cisco está ciente da ameaça que o SDN representa e coloca o "Cisco Open Network Environment" como alternativa para responder a ele, oferecendo recursos para enfrentar empresas emergentes e prestadoras de serviços agregando valores a nova plataforma de negócios [16][17][18][19].

• HP

A HP possui o maior portfólio de produtos com suporte ao OpenFlow. Em seus "switches" oferece uma ampla escolha para gerenciamento da rede e atende a requisitos de desempenho, largura de banda e orçamentos. O portfólio abrange 16 modelos incluindo uma série de "switches" e é uma das únicas empresas a oferecer soluções mais completas com suporte ao protocolo OpenFlow. Desde o início do padrão do protocolo OpenFlow a HP foi inovadora em apoiar o desenvolvimento do protocolo apoiando mais de 60 universidades e centros de pesquisas em estudos e práticas para adoção da tecnologia em aplicações para o mundo real. A HP está liderando toda a mudança para criar um padrão do OpenFlow simplificando as redes dos clientes corporativos.

A HP é um dos membros fundadores da ONF e através de seus laboratórios tem desenvolvido as Redes Definidas por Software desde 2008 com publicações de pesquisa sobre a evolução do protocolo com ampla divulgação pelas empresas.

A empresa ofereceu aos seus clientes a possibilidade de habilitar o protocolo OpenFlow gratuitamente através de download, fazendo uma atualização do "firmware". Ela reconhece existir muita confusão sobre o uso de SDN e OpenFlow, reconhecendo-os como uma arquitetura emergente, e que os clientes não estão buscando necessariamente por tecnologias específicas e sim melhores resultados para os negócios. A HP lançou o "Virtual Application Networks" para SDN como parte integrante da "FlexNetwork", que é uma arquitetura criada pela própria empresa, oferecendo um plano de controle robusto com aplicações em "Data Centers", CAN[10]e em outros ramos. O conceito do HP "Virtual Application Networks" leva em consideração o caminho fim-a-fim desde o servidor no "Data Center" ou na nuvem até o usuário final, incluindo a infraestrutura, o plano de controle, aplicações da rede, aplicações corporativas e gerenciamento da rede [23].

• NEC

É uma empresa multinacional de tecnologia da informação que oferece soluções de rede para empresas, provedores de serviços em telecomunicações e governos.

A NEC apresenta em seu portfólio de produtos e serviços, uma solução simples para Redes SDN, o "Programmable Flow", que utiliza uma tecnologia da NEC para o protocolo OpenFlow, para integrar uma topologia de rede aberta, simplificando o gerenciamento da rede, através de forma proativa, aborda desempenho e contribuí para a alta disponibilidade de processos de negócios de missão crítica [12].

"Programmable Flow" é:

• Simples: centraliza o controle da rede, eliminando a necessidade de protocolos distribuídos como "Spanning Tree"[11];

• Rápido: monitora automaticamente o tráfego da rede e define políticas e recursos de rede de forma continuada;

• Escalável: permite gerenciar o tráfego todo da rede em um único ponto.

• Aberto: separa o plano de encaminhamento de dados do plano de controle, permitindo que as organizações possam tomar decisões de investimento de infraestrutura independentes das características da rede que querem implantar [24].

• VMware

A VMware é uma empresa líder em virtualização e infraestrutura em nuvem, fornece soluções que ajudam as organizações de todos os portes a reduzir os custos e melhorarem suas redes, contando com mais de 400.000 clientes e 55.000 parceiros.

Há pouco tempo, a empresa atraiu os olhares do mercado ao investir US$ 1,26 bilhão na compra da Nicira, uma "startup" especializada em uma tecnologia aberta de gestão de tráfego de rede baseada no OpenFlow, se tornando um ícone para as Redes Definidas por Software.

A solução da empresa está em apoiar e continuar os princípios abertos e as tecnologias que fizeram das soluções bem sucedidas da Nicira, incluindo o "OpenvSwitch" para conectar redes físicas e múltiplos "hipervisors", implementando políticas de nível corporativo a partir de qualquer sistema de gerenciamento de nuvem. Com isso a empresa espera possibilitar que, as empresas e os provedores de serviços criem as mais flexíveis topologias de rede, conseguindo atuarem em qualquer ambiente em nuvem.

• Juniper

À medida que o SDN amadurece para suportar novos negócios vale olhar para trás e buscar quais são os erros existentes nas redes atuais, para saber como corrigi-los e assim ajudar as operadoras com o melhor tipo de equipamento em conjunto com o controle do SDN, para reduzir os custos e proporcionar novos negócios. Está é a chave para estratégia da Juniper.

A visão da Juniper para as novas redes já está encaminhada com uma plataforma de rede buscando novas formas de inovar, diminuir os custos operacionais da rede por meio da automatização e despesas de capital. As redes legadas cresceram e se tornaram grandes e complexas, com poucas inovações e custo elevado para construção e manutenção. Mudando a ênfase de manutenção para inovação a plataforma da Juniper junto com o SDN espera mudar as complexidades da redes atuais.

A estratégia inicial da Juniper é o foco do uso de SDN em "Data Centers" e CAN, por achar que os benefícios seriam colhidos em curto prazo já que a infraestrutura é geograficamente concentrada e por se tratar de um mercado onde os danos seriam mínimos se a iniciativa desse errado. Por outro lado está trabalhando para desenvolver um controlador de código aberto como alternativa para os proprietários da Cisco e VMware. Ela espera que o controlador SDN "open source" que está sendo desenvolvido em conjunto com outras empresas se torne um padrão como aconteceu com o Linux e Apache que se tornaram grandes referencias de SO e servidor web. A empresa considera que os controladores de códigos abertos para SDN como o NOX, Beacon, e outros não atingiram ainda esse patamar [20][21][22].

• Big Switch

A Big Switch é uma empresa que está procurando cumprir a promessa da Rede Definida por Software oferecendo aos seus clientes a mais ampla gama de opções no segmento de infraestrutura, tanto física como virtual. Desta forma a Big Switch se destaca na indústria, cobrindo tanto a infraestrutura baseada em virtualização e física, apoiando soluções virtuais e a integração diretamente com "switches" físicos habilitados com OpenFlow [11].

A Figura 17 mostra a forma como a Big Switch utiliza a virtualização da rede para criar e gerenciar o ambiente de Redes Definidas por Software.

Fonte: www.bigswitch.com.br/blog-news/

Figura 17: Controlador SDN da Big Switch

A solução da empresa para a virtualização de rede e construída em conjunto com o controlador Big Switch, que é uma plataforma totalmente convergente com as redes SDN, focada em ferramentas de gerenciamento e alta disponibilidade. O controlador desenvolvido pela empresa o "Floodlight" que é baseado em Java e vem sendo considerado um dos mais promissores e também um dos mais usados em pesquisas. Com isso a Big Switch espera colaborar com os desenvolvedores e gestores de redes de forma simples e eficiente, criando ganhos elevados de eficiência operacional na gestão da infraestrutura de redes [11].

• Brocade

A Brocade oferece soluções de rede inovadoras, começando com software de navegação para os roteadores Brocade, que vai permitir aos clientes se preparar para quando a implantação do SDN começar a se tornar real, sem ter que substituir a infraestrutura de rede existente ou se contentar com um produto de menor porte.

Essa capacidade oferecida pela Brocade cria um modo híbrido que permite aos clientes utilizar o mesmo roteador para redes tradicionais e SDN. Os clientes podem manter o seu encaminhamento tradicional, juntamente com todos os processos operacionais estabelecidos para manter o tráfego fluindo e então ativar seletivamente o OpenFlow sobre os fluxos de dados específicos. Ao contrário das ofertas de alguns outros fornecedores que forçam alguns modos de resposta, esse modo híbrido permite que os clientes introduzam o OpenFlow em seu ambiente de rede no seu próprio ritmo.

A Brocade projeta soluções de rede para os ambientes mais exigentes como resultado, os clientes têm a melhor rede para uso hoje e para a melhor rede num futuro próximo, sem sofrimento através de algumas atualizações sem riscos e preocupações [40].

• IBM

A IBM lançou um controlador para Redes Definidas por Software usando o protocolo OpenFlow para alguns de seus produtos. A empresa foi a primeira a comercializar um "switch" com suporte ao OpenFlow, e agora coloca no mercado uma solução completa de OpenFlow e SDN para agilizar "Data Centers", contribuindo para este novo paradigma em redes. A IBM está mais uma vez demonstrando seu compromisso com a inovação, a fim de atender e superar as necessidades dos clientes para aumentar a eficiência de TI , de negócios, competitividade e criatividade.

• Datacom

A Datacom é uma empresa brasileira com sede no Rio Grande do Sul que conta com mais de 800 colaboradores dos quais a metade trabalha em pesquisa e desenvolvimento. A estratégia da empresa para o suporte do protocolo OpenFlow em seus produtos faz da Datacom a primeira empresa nacional a suportar o SDN. Em um evento realizado em São Paulo no início de novembro de 2012 a Datacom lançou duas novas linhas de "switches" com suporte ao OpenFlow voltados para as novas Redes Definidas por Software.

A solução implementada nas linhas DM4000/DM4100 faz o controle externo através de servidores que utilizam o OpenFlow 1.0. As configurações serão realizadas em servidores que possuam os controladores NOX, FloodLight, entre outros, permitindo que os usuários escolham suas aplicações e tendo o total controle da rede.

Casos de uso de Redes Definidas por Software

• SDN em "Data Centers"

Umas das aplicações mais discutidas é o uso de SDN em "Data Centers" utilizando-se de Máquinas Virtuais (MVs). O uso básico do SDN pode ser estendido para algumas aplicações em uma nuvem privada ou de serviço. Esta extensão significa que o SDN combinado com o uso de computação virtual utilizando MVs e armazenamento virtual, pode emular a alocação de recursos elásticos em cada aplicação, como tem feito a Google e o Facebook.

Redes corporativas de "Data Centers" estão rapidamente chegando a um ponto que não suportam mais expansões. As escalas e complexidades das redes estão chegando ao limite, testando o quanto os equipamentos da rede legada e as operações de TI podem suportar. Os fabricantes de equipamentos de rede têm adicionado desesperadamente novos recursos em seus equipamentos na tentativa de solucionar novos problemas que surgem a todo o momento.

Os "Data Centers" atuais abrigam milhares de dispositivos físicos, servidores virtuais, aplicações comerciais, todos ligados através de redes Ethernet e pacotes IP. Infelizmente isso cria um estado onde os dados não são contínuos, existindo certos requisitos dos "Data Centers" em tratar esses dados. As equipes de TI tentam preencher essas lacunas, mas uma infinidade de operações torna cada vez mais difícil esse trabalho, se tornando um verdadeiro desafio.

Com o novo modelo de rede SDN, juntamente com o protocolo OpenFlow, pode-se fazer uso de software para virtualizar as redes, como "hypervisors"[12], e permitir assim a virtualização de servidores, ajudando a tornar realidade o uso dessas tecnologias que facilitarão o gerenciamento dos "Data Centers".

Podemos destacar algumas dificuldades encontradas hoje com o uso da atual tecnologia nos "Data Centers".

A segmentação e segurança de dados são baseadas em uma combinação de camada dois, com a criação de VLANs e camada três, com a criação de sub-redes IP, tendo como base as ACLs e filtragem de pacotes com uso das regras de "firewall". Esta segmentação da rede e dos controles de segurança não são páreos para os atuais "Data Centers", povoados por MVs e plataformas de computação em nuvem.

A engenharia de tráfego da rede atual tende a seguir um caminho fixo. Qualquer congestionamento do tráfego ou algum problema de hardware tem um efeito cascata e acaba por afetar o desempenho e o atraso de todo o tráfego. O desempenho da rede é ainda mais complicado com expansões de servidores virtuais, mobilidade e as aplicações web que também podem criar gargalos no tráfego.

Enquanto servidores podem ser provisionados de virtualização ou ferramentas de controle da nuvem, equipamentos de "Data Centers" e equipamentos de rede, bem como as políticas de controle de encaminhamento, devem ser configuradas em cada dispositivo. Softwares de controle da rede ajudam, mas são somente uma melhoria das CLIs, pois fornecem uma interface gráfica para o gerenciamento dos dispositivos individuais e do plano de controle. Alterações na configuração da rede continuarão sendo uma tarefa árdua e complicada.

A descontinuidade da rede em "Data Centers" não é uma coisa nova. Tendo isto em vista, alguns fornecedores introduziram uma série de inovações em arquiteturas, convergência das redes e também no hardware. Isso permitiu um melhoramento no modelo de dados existente no "Data Center", mas são produtos proprietários e limitados. Muitos fornecedores tentam emular a flexibilidade da virtualização de servidores através de plataformas como VMware vCenter, isto permite provisionamento automatizado e gestão de política de segurança, mas não ajuda quando as empresas adotam o uso de tecnologia de virtualização de servidor adicional como o "Microsoft Hyper-V" ou experiência com plataformas em nuvem como "OpenStack" [26][27].

Enquanto muitas inovações são limitadas, o SDN vem ganhando força, porque cria um novo paradigma aplicado em "Data Centers", ganhando amplo interesse das empresas de redes, telecomunicações, softwares e de computação em nuvem. O SDN tem potencial para abordar diretamente os problemas de descontinuidade citados anteriormente, centralizando tabelas de fluxos, usando APIs e usando softwares para programar a rede. Isso permite que, as empresas programem suas redes criando segmentos de redes virtuais que poderiam ser usadas para fins diferentes. O SDN possui requisitos dinâmicos e tipos de implementações flexíveis, podendo superar os desafios e limitações enfrentadas hoje pelos equipamentos das redes legadas.

Segmentos de redes virtuais podem ser configurados centralmente e aplicados em toda a rede à distância. Também podem simplificar a arquitetura de segurança da rede, orientando os fluxos de serviços de aplicação da política de segurança, bem como "firewalls", IDS e IPS[13]

Um caminho virtual fim-a-fim pode ser programado na rede. O plano de controle central acrescenta ao core da rede, através de seus dispositivos, uma alta velocidade de transporte e no futuro, as redes serão capazes de tomar decisões de fluxo, com base em análise em tempo real das estatísticas de utilização da rede.

Apesar de alguns produtos com suporte ao SDN e ao OpenFlow já estarem disponíveis para uso. Esta situação mudará, porém, quando os principais fornecedores abraçarem essa tecnologia, adicionando suporte aos seus produtos, e trabalhando em conjunto para conduzir as Redes Definidas por Software a adoção de seus clientes.

• Uso de SDN pela Google

A Google oferece diferentes tipos de serviços, como, busca na web, email, YouTube, mapas e etc. A fim de atender uma gigante base global de usuários com disponibilidade e alta velocidade, grandes volumes de dados precisam ser movidos de uma região para outra fazendo uso de aplicações e serviços utilizando intensivos recursos da rede WAN. Quando se trata de gestão de custos e desempenho as coisas não são necessariamente as mesmas para a WAN. Existe uma variedade de razões para isso, como maior desempenho, melhor tolerância a falhas e capacidade de gerenciamento, que são mais exigidas ao se gerenciar uma WAN como um todo e não apenas como elementos independentes.

A WAN da Google está organizada em dois "backbones" – uma rede interna que transporta o tráfego dos usuários chamada de ("I-scale") e outra que carrega os dados entre "Data Centers" ("G-scale"). Estes dois "backbones" possuem necessidades e características diferentes e é na "G-scale" Figura 18 que a Google tem implantado o OpenFlow alimentado pelo SDN. Quando a Google começou esse projeto não havia nenhum equipamento com suporte ao OpenFlow que atendesse as necessidades nessa escala. A Google então desenvolveu seu próprio "switch" com código aberto e suporte ao OpenFlow utilizando recursos mínimos, mas que foram suficientes. São "switches" que fornecem escalabilidade de largura de banda e tolerância a falhas. Os sites são conectados entre si e os controladores com o OpenFlow comunicam-se com os "switches", vários controladores garantem que não haja nenhum ponto de falha, garantindo assim uma conexão redundante.

Fonte http://opennetsummit.org/talks/ONS2012/hoelzle-tue-openflow.pdf

Figura 18: WAN Implementada pela Google

Nesta WAN a Google construiu um sistema centralizado de engenharia de tráfego. O serviço coleta em tempo real informações da utilização de dados, da topologia da rede subjacente e a demanda por banda a partir de aplicações e serviços. Com esses dados ela calcula as atribuições do caminho para o tráfego do fluxo, e em seguida, programa os caminhos para os switches OpenFlow. No caso de alguma eventual mudança o serviço recalcula as atribuições de caminho e reprograma os switches [29].

Conclusão

A comunidade de TI tem um histórico muito bom quando se trata de mudança de ambientes de dados sempre para melhor. Isso faz parte de uma boa correlação entre a tecnologia e a economia, com boas ideias recompensadas com fluxos de execução e de receita, enquanto os problemas desaparecem.

Ultimamente, porém, parece que os avanços estão tão rápidos que as empresas mal têm tempo para fazer uma análise completa das tecnologias existentes e a próxima já está no ponto de partida. Um exemplo fundamental dessa evolução é o SDN, que já está se preparando para ser a grande transformação no mundo das redes de computadores, mesmo quando a maioria das organizações ainda está tentando focar seus planos em torno das tecnologias em nuvem.

Embora possa parecer que o conceito de separar ambos os planos de controle de software e hardware em resumo seja bastante simples, afinal ele faz maravilhas para a infraestrutura do servidor, o fato é que os diferentes tipos de SDN oferecem capacidades únicas e variadas alterações de hardware na rede existente.

Este trabalho apresentou uma visão de SDN, ou Redes Definidas por Software, incluindo o mercado e produtos de alguns dos principais fabricantes. No momento, a HP e a Cisco parecem estar se sobressaindo sobre o mercado de SDN, com soluções destinadas para utilização dos projetos da VMware, sendo que a Cisco mantém uma relação mais formal com essa empresa, mas isso não quer dizer que a HP não tenha participação. A empresa está divulgando uma série de plataformas de software, incluindo a Interconexão Virtual Ethernet (IVE), solução de rede de sobreposição, como forma de não só virtualizar redes, mas também dinamiza-las. Ela também reivindica mais apoio ao protocolo OpenFlow, que deve ser mais interoperável do que a versão "otimizada" que a Cisco diz estar em desenvolvimento.

Ainda assim HP e Cisco são as que mais aparentam ter alguma estratégia bem definida nesse novo mercado de SDN. A Dell tem trabalhado em sistemas com o OpenFlow também, e a maioria dos projetos desenvolvidos até o momento focam no plano de dados, principalmente switches e roteadores. A abordagem da Dell se deu com a aquisição da Force10 Networks, juntas as empresas seriam capazes de agilizar a pilha de gerenciamento SDN oferecendo uma maneira de integrar os "hypervisors" para uma melhor coordenação entre as topologias de rede dinâmicas e o rápido carregamento de dados, também daria a Dell, uma participação contínua no mercado de SDN, assumindo uma maior responsabilidade para o desempenho das redes e tarefas de configurações levadas ao mercado de hardware de rede.

Estas ações tem deixado de fora algumas empresas que não possuem acordos lucrativos com a VMware. A Brocade, por exemplo, tem investido uma grande quantidade de recursos em suas soluções e não quer vê-las fora do mercado de SDN. Fez uma parceria com a Microsoft e irá apoiar o sistema operacional Windows Server 2012, oferecendo suporte a suas plataformas. Mais uma vez, o nome do jogo aqui é a arquitetura de rede simplificada, que pode ser tanto mais fácil de gerenciar e proporcionar um ambiente mais dinâmico para operações virtuais e nuvem.

Mas colocando toda essa inteligência da rede na camada de software ainda é uma prática amplamente inexperiente e não foi testada. Cisco, HP, VMware e muitas outras estão mais do que dispostas a apostar grandes quantias em dinheiro que poderão render bons frutos, mas não há nada como a experiência do mundo real para tornar uma medida verdadeira, saindo do papel e dos laboratórios. Só então saberemos se o SDN poderá crescer.

Referências

• [1] Software-Defined Networking and Security at VMworld - Disponível em: http://cto.vmware.com/unveiling-sdn-and-sdsec-architectures-at-vmworld-2012/ - Data de acesso 27/08/2012

• [2] The State of Data Center Networking - Disponível em: http://packetpushers.net/the-sad-state-of-data-center-networking/: - Data de acesso 27/08/2012

• [3] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38:69–74.

• [4] OpenFlow- Disponível em: http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2010_2/rodrigo/introducao.html - Data de acesso 03/07/2012

• [5] OpenFlow Switch Specification - Disponível em: https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.0.pdf - Data de Acesso: 06/09/2012

• [6] OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes – Disponível em: http://www.cpqd.com.br/cadernosdetecnologia/Vol7_N1_jul2010_jun2011/pdf/artigo6.pdf - Data de Acesso 06/09/2012

• [7] Comutadores - Disponível em: http://www.comutadores.com.br/o-que-e-openflow/ - Data de acesso 08/09/2012

• [8] A Revolution (Revelation?) in Networking - Disponível em:http://opennetsummit.org/talks/ONS2012/pitt-mon-ons.pdf - Data de acesso 08/09/2012

• [9] O que é OpenFlow - Disponível em: http://www.openflow.org/wp/learnmore/ - Data de acesso 08/09/2012

• [10]  Routing: Data vs Control Plane - Disponível em: http://comp519.cs.rice.edu/images/f/f9/Data- control-plane.pdf - Data de acesso 11/09/2012

• [11] Big Switch Networks - Disponível em: www.bigswitch.com/blogs-news/ - Data de acesso 27/09/2012

• [12] NEC - Disponível em: www.necportugal.pt/index.php?object=2216&article=5507§ion=591&lang=0 - Data de acesso 26/09/2012

• [13] Artigos com marcador Microsoft - Disponível em: www.vidadeti.com.br/index.php/tag/microsoft/ - Data de acesso 26/09/2012

• [14] ONF - Disponível em: www.netevents.org/events-press-coverage/6-Baguete-Jul-25-ONF-Extreme.pdf - Data de acesso 26/09/2012

• [15] SDN a $2 Billion Market by 2016 - Disponível em: http://www.enterprisenetworkingplanet.com/datacenter/idc-sdn-a-2-billion-market-by-2016.html - Data de acesso 18/10/2012

• [16] Cisco enters enemy camp with software-defined networking - Disponível em: http://www.zdnet.com/cisco-enters-enemy-camp-with-software-defined-networking-3040155384/ - Data de acesso 19/09/2012

• [17] Cisco Stock Drops On VMware's SDN Market Plans - Disponível em: http://news.investors.com/technology/072412-619274-cisco-stock-drops-on-vmware-sdn-plans.htm - Data de acesso 19/09/2012

• [18] Cisco + OpenFlow + OpenStack = ONE software-defined network - Disponível em: http://www.theregister.co.uk/2012/06/14/cisco_one_sdn_openflow_openstack/ - Data de Acesso 19/09/2012

• [19] Roundup: Cisco"s Approach to SDN - Disponível em: http://www.datacenterknowledge.com/archives/2012/06/14/roundup-ciscos-approach-to-sdn/ - Data de Acesso 19/09/2012

• [20] Juniper"s Vision for SDN Enables Network Innovation - Disponível em: http://forums.juniper.net/t5/Data-Center-Directions-Michael/Juniper-s-Vision-for-SDN-Enables-Network-Innovation/ba-p/146972 - Data de Acesso 20/09/2012

• [21] Juniper confines SDNs to data center - Disponível em: http://www.networkworld.com/news/2012/061912-juniper-sdn-260342.html - Data de Acesso 20/09/2012

• [22] Juniper plotting open source alternative to Cisco, VMware SDN controllers - Disponível em: http://www.networkworld.com/news/2012/091412-juniper-muglia-262469.html - Data de Acesso 20/09/2012

• [23] HP Simplifies Networking with Broadest Choice of OpenFlow-enabled Switches - Disponível em: http://www8.hp.com/us/en/hp-news/press-release.html?id=1167290#.UGSIXk3A_Mo - Data de acesso 23/09/2012

• [24] Innovative Tools Help NEC, V3 Take Top Honors at Best of Interop Disponível em: http://www.networkcomputing.com/interop/innovative-tools-help-nec-v3-take-top-ho/240000046?itc=nwc_trk_ts_inline - Data de acesso 23/09/2012

• [25] Redes heterogêneas - Disponível em: http://www.linux.ime.usp.br/~cef/mac499-06/monografias/erich/html/ch01s02.html - Data de acesso 24/09/2012

• [26] Hyper-V - Disponível em: http://pt.wikipedia.org/wiki/Hyper-V - Data de acesso 24/09/2012

• [27] Open Stack - Disponível em: http://cloudcomputingforum.com.br/forum/viewforum.php?f=10 - Data de acesso 24/09/2012

• [28] O que significam as siglas IPS e IDS, no contexto de redes de computadores? - Disponível em: http://www.npd.ufes.br/node/87 - Data de acesso 24/09/2012

• [29] WAN OpenFlow criada pela Google - Disponível em: http://opennetsummit.org/talks/ONS2012/hoelzle-tue-openflow.pdf - Data de acesso 25/09/2012

• [30] GENI - Disponível em: http://www.geni.net - Data de acesso em 17/09/2012

• [31] G E N I Global Environment for Network Innovations Spiral 2 Overview Document ID: GENI-INF-PRO-S2-OV-1.1 June 3, 2010 - Data de acesso em 17/09/2012

• [32] AKARI - Disponível em: http://akari-project.nict.go.jp/eng/concept-design/AKARI_fulltext_e_translated_version_1_1.pdf - Data de acesso 27/09/2012

• [33] Future Internet Research and Experimentation- what is fire? European Comission. Disponível em: http://cordis.europa.eu/fp7/ict/fire/. Data de acesso 20/07/2012.

• [34] FEDERICA - Disponível em: http://www.fp7-federica.eu/ - Data de acesso 02/11/2012

• [35] PII - Disponível em: http://www.panlab.net/ - Data de acesso 02/11/2012

• [36] OFELIA - Disponível em: http://www.fp7-ofelia.eu/ - Data de acesso 02/11/2012

• [37] ABELEM, A.J.G. Ambientes Experimentais para Pesquisa, Desenvolvimento e Inovação em Tecnologia da Informação e Comunicação. Revista de Ciência, Tecnologia e Inovação do Estado do Pará, p. 36-45, 2012.

• [38] Pesquisa Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualização e o Framework Open?ow - Disponível em: http://sbrc2011.facom.ufms.br/files/mc/mc1.pdf - Data de Acesso 18/09/2012

• [39] NetEvents EMEA Press and Analyst Summit Algarve, Portugal - Disponível em: http:// www.netevents.org - Data de Acesso 18/09/2012

• [40] Brocade Communities - Disponível em: http://community.brocade.com - Data de Acesso 03/10/2012

• [41] RNP – Disponível em: http://www.rnp.br - Data de Acesso 04/10/2012

• [42] Datacom - Disponível em: http://www.datacom.ind.br - Data de acesso 19/11/2012

AGRADECIMENTOS

Ao professor e orientador Eduardo Cezar Grizendi pela paciência e dedicação e por toda a competência mostrada durante a orientação deste Trabalho de Conclusão de Curso. Nossas reuniões possibilitaram um melhor desenvolvimento do trabalho, permitindo uma perfeita conclusão do mesmo. Agradecemos pela agregação de conhecimentos adquiridos que contribuíram para o nosso desenvolvimento profissional.

Gostaríamos de citar a colaboração de Christian E. Rothenberg do CPqD e Cristiano Monteiro da HP que nos forneceram algumas considerações e informações de suma importância.

Em especial a todos os colegas, professores e funcionários do Inatel – Instituto Nacional de Telecomunicações.

Autor:

Diego Henrique Duque

diegohenriqueduque[arroba]hotmail.com

Edimilson Joaquim do Couto

Marcelo Henrique Pinto

Thiago Leopoldino Magalhães

Curso de Graduação em Engenharia Elétrica

Trabalho de conclusão de curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para obtenção do Título de Engenheiro Eletricista.

ORIENTADOR: Prof. Msc. Eduardo Cezar Grizendi

Santa Rita do Sapucaí

Dezembro de 2012

Instituto Nacional de Telecomunicações

---