VII SRST –SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES
INSTITUTO NACIONAL DE TELECOMUNICAÇÕES –INATEL
ISSN2358-1913 SETEMBRO DE 2017
Abstract - SDN (Software Defined Networking) presents a new concept for the traditional computer network architecture model. This new paradigm has gained tremendous relevance in the academic community and networking industry resulting in new research, standardization and market solutions. This article introduces the SDN concept to its architecture and the benefits offered by this new approach.
Index Terms: OpenFlow, Redes de Computadores, SDN, Software.
Resumo – As SDN apresentam um novo conceito para o tradicional modelo de arquitetura de redes de computadores. Esse novo paradigma tem se tornado relevante na comunidade acadêmica e na indústria de redes resultando em novas pesquisas, padronizações e soluções de mercado.
Palavras chave: OpenFlow, Redes de Computadores, SDN, Software.
I. INTRODUÇÃO
As redes de computadores experimentaram grandes avanços tecnológicos durante décadas. Tais avanços proporcionaram uma nova era de informações para os diferentes níveis da sociedade. A crescente demanda de novas aplicações, serviços, tecnologias, dispositivos e uma enorme massa de informações para o consumo, tornou o atual modelo de arquitetura de rede de dados um tanto quanto complexo, interferindo na eficiência do gerenciamento, escalabilidade e também nos custos.
As limitações das arquiteturas de redes tradicionais estão se tornando significantes. Atualmente, as redes já não otimizam os custos capital expenditure (despesas de capital) e operational expenditure (despesas operacionais). Além disso, as redes não
são ágeis, pois o tempo de desenvolvimento de novos produtos é longo e as técnicas de provisionamento não são rápidas o suficiente [1].
A arquitetura SDN tem chamado a atenção da comunidade acadêmica e da indústria, nos níveis experimentais e comerciais, por propor um novo modelo de arquitetura de redes que é capaz de tratar dificuldades e desafios observados no modelo atual.
Esse artigo aborda conceitos, arquitetura, benefícios e casos de usos desta nova solução, e está organizado da seguinte forma: a seção II descreve o conceito de SDN, apresentando uma visão geral da tecnologia, sua arquitetura e o protocolo
OpenFlow. A seção III descreve os principais benefícios
Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações. Orientador: Prof. Francine Oliveira. Trabalho aprovado em 07/2017.
fornecidos pelas redes definidas por software. A seção IV aborda os principais casos de uso desta tecnologia. Por fim, na seção V, a conclusão do artigo mostra as direções futuras da SDN.
II. CONCEITO E ARQUITETURA SDN
A. Conceito
Nas redes tradicionais, os planos de controle e dados são combinados em um elemento de rede. O plano de controle é responsável pela configuração do elemento de rede e pela programação dos caminhos que serão utilizados pelos fluxos de dados. Uma vez que esses caminhos tenham sido determinados, eles são encaminhados para o plano de dados [2] que também é conhecido como plano de encaminhamento. Este é responsável por mover os bits recebidos em uma porta de entrada para uma porta de saída [3].
Nesta abordagem tradicional, uma vez que o gerenciamento do fluxo (política de encaminhamento) tenha sido definido, a única maneira de fazer um ajuste nessa política é através de mudanças na configuração dos dispositivos de rede [2].
A ideia principal de redes definidas por software é separar as funções de encaminhamento de dados na rede, executadas pelo plano de dados, das funções de controle de rede, executadas pelo plano de controle. Essa abordagem permite a virtualização da rede e o gerenciamento e controle se tornam mais flexíveis [4].
Basicamente, SDN é caracterizada pela existência de um sistema de controle, realizado por software, que gerencia o mecanismo de encaminhamento de dados nos elementos de comutação da rede, por meio de uma interface de programação bem definida. De forma mais específica, os elementos de comutação exportam uma interface de programação que permite ao software inspecionar, definir e alterar entradas da tabela de roteamento do comutador como ocorre, por exemplo, com comutadores OpenFlow que será detalhado mais à frente [5].
B. Arquitetura
A ONF (Open Network Foundation), organização não-lucrativa que promove a padronização de SDN, propõe o modelo de arquitetura em três camadas distintas [6]:
Glaucio França Giesen
1, Francine Cássia de Oliveira
2Abordagem SDN: uma mudança de
a) Camada de Aplicação: consiste nas aplicações dos usuários finais que consomem os serviços SDN. A comunicação entre a camada de aplicação e a camada de controle é realizada através de API (Application
Programming Interface), cuja finalidade é simplificar a
implementação de serviços de rede comuns, por exemplo, roteamento, multicast, segurança, controle de acesso, gerenciamento de largura de banda, engenharia de tráfego, QoS, eficiência energética, entre outros;
b) Camada de Controle: fornece a funcionalidade de controle logicamente centralizado que supervisiona o comportamento de encaminhamento de dados através de uma interface aberta;
c) Camada de Infraestrutura: consiste nos elementos de rede e dispositivos que realizam a troca e o encaminhamento de pacotes.
A Figura 1 ilustra como o software opera nas camadas de aplicação, de controle e de infraestrutura.
Fig. 1. Camadas do modelo SDN [6].
A comunicação entre as camadas da arquitetura SDN é realizada por meio das seguintes APIs [7]:
Southbound-API - Representa a interface de comunicação entre
o plano de controle e o plano de dados, ou seja, a comunicação entre a camada de controle (control layer) e camada de infraestrutura (infrastructure layer).
Northbound-API - SDN permite a troca de informações com
aplicações que estão sendo executadas. Esta troca de informações é realizada por meio da interface Northbound-API, existente entre o controlador SDN e o plano de controle da camada de aplicação. Ainda não há uma padronização para esta interface.
Westbound-API - Esta interface executa funções de um canal
de informação entre os planos de controle SDN de diferentes domínios. Isto permite que a troca de informações de estado de rede influencie as decisões de roteamento em cada controlador, porém, ao mesmo tempo, faz com que fluxos de rede sejam configurados corretamente para múltiplos domínios. Para a
troca de informações entre domínios (Inter domain), o protocolo de roteamento BGP (Border Gateway Protocol) poderia ser utilizado.
Eastbound-API – responsável pela comunicação entre os
planos de controle de domínios não SDN.
A Figura 2 ilustra diferentes tipos de APIs e suas aplicações.
Fig. 2. Tipos de APIs [7].
C. Protocolo Openflow
Um dos elementos fundamentais na construção das redes definidas por software é o protocolo OpenFlow. Proposto pela universidade de Stanford é um protocolo de comunicação que separa as camadas de controle (controlador) da camada de infraestrutura (plano de dados) em uma arquitetura SDN. Ele permite a manipulação das tabelas de fluxos dos dispositivos da rede, como roteadores e comutadores [5].
A Figura 3 ilustra o comutador do modelo atual e do modelo programável. No modelo atual, tanto o plano de controle (software), o plano de dados (hardware de encaminhamento de pacotes) e a API são proprietários e estão presentes fisicamente no mesmo dispositivo de rede. Já no modelo programável, o plano de controle e plano de dados são entidades fisicamente separadas e a comunicação entre essas camadas é realizada por meio de uma API aberta.
Fig. 3. Comparativo entre o modelo atual e modelo programável OpenFlow [8].
Um comutador habilitado com OpenFlow possui pelo menos três partes. Uma tabela de fluxos, com uma ação associada com cada fluxo; um canal seguro que conecta o comutador ao controlador remoto permitindo que comandos e pacotes sejam trocados entre eles e o protocolo OpenFlow, utilizado como padrão de comunicação entre o controlador e um ou mais comutadores [8] [9].
•
Tabela de fluxos: Essa tabela corresponde aos pacotes recebidos para determinado fluxo e especifica as funções que devem ser executadas no pacote. Essas funções consistem de regra, ações e contadores. A regra é gerada com base na definição do valor de determinados campos do cabeçalho do pacote e é associada a um conjunto de ações. Estas ações definem o modo como os pacotes devem ser processados e para onde devem ser encaminhados. Os contadores têm a função de reter estatísticas de utilização e também de remover fluxos inativos. Asentradas da tabela de fluxos podem ser interpretadas como decisões em cache (hardware) do plano de controle (software), sendo, portanto, a mínima unidade de informação no plano de dados da rede [8]. Um fluxo é gerado pela combinação de campos do cabeçalho do pacote a ser processado pelo dispositivo, conforme ilustrado na Figura 4. Esta combinação pode ser formada por campos das camadas de enlace, de rede ou de transporte, segundo o modelo TCP/IP (Transmission Control Protocol / Internet Protocol) [8].Fig. 4. Campos disponíveis no OpenFlow [8].
As ações associadas aos fluxos incluem [8]:
- Encaminhamento do fluxo de pacotes para determinada porta (ou portas);
- Modificação dos campos do cabeçalho;
- Encapsulamento e transmissão do pacote para o controlador;
- Descarte dos dados como medida de segurança com a implementação de firewalls, ou ainda para inibir ataques de negação de serviço;
- Encaminhamento do pacote para o processamento normal do equipamento nas camadas 2 ou 3.
•
Canal Seguro: Com intuito de garantir a confiabilidade e evitar ataques de elementos mal-intencionados na troca de informações entre o switch e o controlador, é necessário um canal seguro. O protocolo SSL (Secure Socket Layer) pode ser utilizado como interface de acesso para esse canal de comunicação. Interfaces alternativas (passivas ou ativas) incluem os protocolos TCP e PCAP (Packet Capture), e são especialmente úteis em ambientes virtuais e experimentais pela simplicidade de utilização, pois não necessitam de chaves criptográficas.•
Controlador: O
controlador da rede SDN é uma entidadelogicamente centralizada, isto é, pode ser constituído de múltiplas instâncias físicas ou virtuais, porém se comporta como um componente único [7]. Para [8], é o software responsável por tomar decisões, adicionar e remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. O controlador exerce a função de uma camada de abstração da infraestrutura física, facilitando a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. Esse modelo assemelha-se a outros sistemas de
software que proveem abstração do hardware e
funcionalidade reutilizável. Dessa forma, o controlador
OpenFlow atua como um sistema operacional para
gerenciamento e controle das redes, e oferece uma plataforma com base na reutilização de componentes e na definição de níveis de abstração (comandos da API). A programação do controlador permite a evolução em paralelo das tecnologias nos planos de dados e as inovações na lógica das aplicações de controle. A Figura 5 ilustra uma abstração de uma rede com OpenFlow e o controlador NOX (Network Operating System) [10], executando inúmeras aplicações que necessitam de uma visibilidade do estado da rede (network view). Esta visibilidade pode ser armazenada, por exemplo, em um simples banco de dados executado localmente ou em um servidor remoto.
Fig. 5. Elementos de uma rede OpenFlow [4].
D) Operação Openflow
No momento em que um pacote é recebido em um elemento de rede com OpenFlow habilitado, os cabeçalhos desse pacote são comparados com as regras das entradas das tabelas de fluxo, os contadores são atualizados e ações são realizadas de acordo com o modo o qual o pacote dever ser processado e encaminhando. Caso não ocorra uma correspondência entre o pacote recebido e alguma entrada da tabela de fluxos, o pacote completo, o cabeçalho e a carga de dados, são encaminhados diretamente ao controlador. Alternativamente, apenas o cabeçalho é encaminhado ao controlador mantendo o pacote armazenado no buffer do hardware. Também é possível incluir uma regra no switch para que todos os pacotes de determinado fluxo sejam enviados ao controlador para serem tratados individualmente. Esse último caso corresponde, em geral, a pacotes de controle ICMP (Internet Control Message Protocol), DNS (Domain Name System), DHCP (Dynamic Host
Configuration Protocol) ou de protocolos de roteamento OSPF
(Open Shortest Path First), BGP (Border Gateway Protocol) [8].
A Figura 6, ilustra a comunicação entre o controlador e o comutador com OpenFlow habilitado.
Figura. 6. Comunicação entre controlador e comutador com OpenFlow habilitado [11].
III. BENEFÍCIOS
As redes definidas por software propõem resolver diversos problemas enfrentados no modelo de arquitetura de redes convencionais. A ONF descreve os benefícios que este novo modelo de arquitetura promete trazer para a comunidade acadêmica.
•
Diretamente programável: O controle de rede é diretamente programável devido ao desmembramento das funções de encaminhamento [6];• Agilidade: A abstração do plano de controle do plano de dados permite aos administradores ajustar dinamicamente o fluxo de tráfego de redes, conforme as necessidades de mudanças [6];
• Gerenciamento centralizado: A inteligência da rede é (logicamente) centralizada em controladoras com
software baseado em SDN, as quais mantem uma
visão global da rede e se apresentam para aplicações e políticas da rede como um único switch lógico [6]; • Programaticamente configurável: SDN permite que
administradores de rede configurem, gerenciem, protejam e otimizem recursos de rede rapidamente e de forma dinâmica, através de programas SDN automatizados. Estes programas permitem que os própriosadministradores escrevam estas tarefas, uma vez que não são dependentes de software [6];
• Padrão aberto e independente de fabricante: Uma vez implementada com padrões abertos, a SDN simplifica as operações e desenhos da rede, pois as instruções são fornecidas por controladores SDN, ao invés de múltiplos protocolos e dispositivos de diferentes fabricantes [6].
IV. CASOS DE USO
A tecnologia SDN é aplicável em diversos cenários, dentre estes, podemos destacar alguns casos de uso promissores:
a) Orquestração de nuvem:
ao longo da última década, os serviços em nuvem se desenvolveram em um ritmo acelerado. No entanto, a inovação neste campo foi principalmente confinada aos servidores, aplicações e
data centers. Isso fez com que as redes se tornassem
um obstáculo para operações na nuvem devido ao gerenciamento, tanto das redes como dos servidores, ser realizado de forma individual. Para que as aplicações na nuvem sejam provisionadas e operadas de forma rápida e automatizada, é necessário que o gerenciamento dessas estruturas esteja integrado. SDN oferece uma maneira viável para alcançar esta integração, uma vez que, a controladora SDN e o orquestrador são softwares. Desta forma, seria facilmente possível desenvolver uma interface de comunicação (API) realizar este feito [7].
b) Balanceamento de carga: Outro serviço necessário para uma operação bem-sucedida nos serviços online hospedados em data centers, é o balanceamento de carga. Em geral, um balanceador de carga é tipicamente uma função implementada separadamente em uma rede de dados, cuja função é distribuir a carga entre redes e elementos do data center. As soluções atuais para balanceadores de carga são eficientes, porém, com flexibilidade limitada em termos de customização. Outro ponto relevante é o custo elevado desta solução. Ao usar tecnologia SDN, o balanceamento de carga pode ser integrado em qualquer elemento de encaminhamento de dados na rede, evitando a necessidade de dispositivos separados. Além disso, SDN permite ao balanceamento de carga operar em qualquer granularidade de fluxo [7].
c) Roteamento: A API entre o plano de dados e o plano de controle nas redes SDN fornece grande oportunidade para adaptações de protocolos de roteamento, o qual é uma tarefa difícil no atual esquema descentralizado de roteamento de rede. Os serviços de roteamento poderiam ser implementados através de módulos de programação em controladores OpenFlow, flexibilizando a seleção de caminhos na rede por otimização do fluxo de tráfego e migrações para novas versões de protocolos [7].
d) Gerenciamento de redes: As atuais políticas de gerenciamento de rede são geralmente definidas pelos administradores e posteriormente configuradas em cada elemento da rede. Quanto maior a rede, maior o esforço para a sua configuração. Essas políticas são raramente modificadas, o que torna a operação das redes muitas vezes ineficiente. Para modificar este cenário, a rede precisa ser capaz de se adaptar às políticas de forma dinâmica e automática tendo como base uma variedade de informações. O plano de controle logicamente centralizado da tecnologia SDN permite, de forma adequada, endereçar as dificuldades mencionadas.
V. CONCLUSÕES
As redes definidas por software apresentam uma proposta inovadora para o modelo de arquitetura de redes convencionais. As melhorias e facilidades propostas pela SDN vêm ao encontro da necessidade de agilizar o gerenciamento e aperfeiçoar recursos de redes de computadores que estão cada vez mais escassos pela complexidade de aplicações e serviços.
Com base no sucesso que o paradigma vem apresentando, novas pesquisas e experimentos estão por vir para este novo modelo de rede baseado em software, podendo ser considerada uma tecnologia disruptiva, a qual promoverá mudanças nas soluções para redes de computadores, seja como ferramenta para o desenvolvimento de novos serviços e aplicações, seja como alvo de estudos sobre novas abstrações e soluções de implementação. Certamente, novos trabalhos e modelos de negócios surgirão a partir desse novo paradigma.
REFERÊNCIAS
[1] Guy Pujolle, “Software Networks – Virtualization, SDN, 5G and Security”, Vol. 1, 2015, pp 16.
[2] Sakir Sezer, Sandra Scott-Hayward, Pushpinder Kaur Chouhan, Barbara Fraser, David Lake, Jim Finnegan, Niel Viljoen, Marc Miller and Navneet Rao, “Are We Ready for SDN?”, IEEE Communications Magazine, 2013. [3] Siriam Subramanian, Sreenivas Voruganti, “Software-Defined
Networking (SDN) with OpenStack”, 2016.
[4] Fei Hu, “Network Inovation through OpenFlow and SDN”, 2014. [5] Dorgival Guedes, “Redes Definidas por Software: uma abordagem
sistêmica para o desenvolvimento de pesquisas em Redes de Computadores”, XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2012, Cap. 4.
[6] OpenFlow-enabled SDN and Network Functions Virtualization, ONF Solution Brief, 2014.
[7] M. Jarschel, T. Zinner, T. Hoßfeld, P. Tran-Gia, and W. Kellerer, “Interfaces, attributes, and use cases: A compass for SDN,” IEEE Communications Magazine, 2014.
[8] Cristian E. Rothemberg, “OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes” Cad. CPqD Tecnologia, Campinas, v. 7, n.1, p. 65-76, jul. 2010/jun. 2011.
[9] Nick McKeown, “OpenFlow: Enabling Innovation in Campus Networks”, 2008.
[10] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker. NOX: Towards an Operating System for Networks. SIGCOMM Comput. Commun. Rev., 2008.
[11] Bruno Nunes Astuto, Marc Mendonça, Xuan Nam Nguyen, Katia Obraczka, and Thierry Turletti, “A survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks” IEEE Communications Society, 2014.
Glaucio França Giesen nasceu em Oiapoque, AP em 07 de abril de 1979. Graduado em Engenheira da Computação pela UNIDERP – Universidade para o Desenvolvimento do Estado e Região do Pantanal em dezembro de 2003 e Pós-Graduado em Engenharia de Redes e Sistemas de Telecomunicações pelo INATEL – Instituto Nacional de Telecomunicações em 2017. Atualmente trabalha como Arquiteto de Soluções Sr na empresa Logicalis. Possui as seguintes certificações do fabricante Cisco Systems: CCNA, CCNP e CCIE Routing and Switching.
Francine Cássia de Oliveira nasceu em Santa Rita do Sapucaí, MG em 11 de agosto de 1988. Técnica em Telecomunicações pela Escola Técnica de Eletrônica Francisco Moreira da Costa em 2005, graduada em Engenheira Elétrica com ênfase em Telecomunicações pelo INATEL - Instituto Nacional de Telecomunicações em julho de 2011 e Especialista em Gerenciamento de Projetos formada pela Fundação Getúlio Vargas em 2013. Atualmente trabalha como Especialista em Sistemas na área de Educação Continuada do ICC - Inatel Competence Center. Ministra cursos voltados para Comunicações Móveis: GSM, GPRS/EDGE, WCDMA, HSDPA, HSUPA, HSPA+, LTE, LTE-A e IMS. Possui certificação HCNA-LTE e ministra cursos preparatórios para esta certificação Huawei. Ministra disciplina referente à Comunicações Móveis no programa de Pós Graduação do Inatel.
