Implementação e Avaliação de Plano de Controle Baseado em Recursos Superdimensionados para Redes Softwarizadas

UNIVERSIDADE​ ​FEDERAL​ ​DO​ ​RIO​ ​GRANDE​ ​DO​ ​NORTE  CENTRO​ ​DE​ ​CIÊNCIAS​ ​EXATAS​ ​E​ ​DA​ ​TERRA 

DEPARTAMENTO​ ​DE​ ​INFORMÁTICA​ ​E​ ​MATEMÁTICA​ ​APLICADA  BACHARELADO​ ​EM​ ​CIÊNCIA​ ​DA​ ​COMPUTAÇÃO 

Implementação​ ​e​ ​Avaliação​ ​de​ ​Plano​ ​de 

Controle​ ​Baseado​ ​em​ ​Recursos 

Superdimensionados​ ​para​ ​Redes 

Softwarizadas 

Douglas​ ​Braz​ ​Maciel

Natal-RN 

Douglas​ ​Braz​ ​Maciel 

Implementação​ ​e​ ​Avaliação​ ​de​ ​Plano​ ​de​ ​Controle 

Baseado​ ​em​ ​Recursos​ ​Superdimensionados​ ​para 

Redes​ ​Softwarizadas 

Monografia de Graduação apresentada ao          Departamento de Informática e Matemática          Aplicada do Centro de Ciências Exatas e da        Terra da Universidade Federal do Rio Grande        do Norte como requisito parcial para a        obtenção do grau de bacharel em Ciência da        Computação.          Orientador(a) 

Prof.​ ​Dr.​ ​Augusto​ ​José​ ​Venâncio​ ​Neto 

Universidade​ ​Federal​ ​do​ ​Rio​ ​Grande​ ​do​ ​Norte​ ​–​ ​UFRN  Departamento​ ​de​ ​Informática​ ​e​ ​Matemática​ ​Aplicada​ ​–​ ​DIMAp 

Natal-RN  Agosto,​ ​2017   

Monografia de Graduação sob o título ​Implementação e Avaliação de Plano de                  Controle  Baseado  em  Recursos  Superdimensionados  para  Redes  Softwarizadas apresentada por Douglas Braz Maciel e aceita pelo        Departamento de Informática e Matemática Aplicada do Centro de Ciências        Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo        aprovada​ ​por​ ​todos​ ​os​ ​membros​ ​da​ ​banca​ ​examinadora​ ​abaixo​ ​especificada: 

__________________________________________  Dr.​ ​Augusto​ ​José​ ​Venâncio​ ​Neto 

Departamento​ ​de​ ​Informática​ ​e​ ​Matemática​ ​Aplicada​ ​(DIMAp)  Universidade​ ​Federal​ ​do​ ​Rio​ ​Grande​ ​do​ ​Norte 

__________________________________________  Dr.​ ​Marcos​ ​Cesar​ ​Madruga​ ​Alves​ ​Pinheiro 

Departamento​ ​de​ ​Informática​ ​e​ ​Matemática​ ​Aplicada​ ​(DIMAp)  Universidade​ ​Federal​ ​do​ ​Rio​ ​Grande​ ​do​ ​Norte 

__________________________________________  Dr.​ ​Edson​ ​Moreira​ ​Silva​ ​Neto 

Escola​ ​Agrícola​ ​de​ ​Jundiaí 

Universidade​ ​Federal​ ​do​ ​Rio​ ​Grande​ ​do​ ​Norte             

Natal-RN,​ ​data​ ​de​ ​aprovação​ ​(por​ ​extenso).                                                   

Agradecimentos 

Agradeço primeiramente a Deus por sempre me mostrar o caminho        certo das coisas, aos meus pais, irmão e familiares por sempre estarem por        perto, me motivando e apoiando nos melhores e piores momentos. Agradeço        também ao meu orientador por sempre estar me guiando e instruindo no        meio acadêmico, além também de todos os amigos que sempre estiveram por        perto​ ​me​ ​apontando​ ​os​ ​Bugs​ ​e​ ​ajudando​ ​na​ ​implementação​ ​da​ ​vida. 

Implementação​ ​e​ ​Avaliação​ ​de​ ​Plano​ ​de​ ​Controle 

Baseado​ ​em​ ​Recursos​ ​Superdimensionados​ ​para 

Redes​ ​Softwarizadas 

Autor:​ ​Douglas​ ​Braz​ ​Maciel    Orientador(a):​ ​Prof.​ ​Dr.​ ​Augusto​ ​José​ ​Venâncio​ ​Neto 

R

O presente trabalho apresenta o plano de implementação de um protótipo        para o controlador de recursos superdimensionados em redes softwarizadas        com OpenFlow. O controlador resultante, tem como principal objetivo aplicar        plano de controle de recursos otimizado na rede ​softwarizada​, visando plano        de dados mais eficiente para obter serviço de transporte com qualidade        garantida. Os resultados obtidos com a prototipação demonstram a        viabilidade e eficiência do plano de controle, sugerindo melhoria significativa        frente a modelos clássicos da Internet quanto ao número de objetos móveis        simultaneamente conectados, sobre-reserva de recursos e vazão de dados        por​ ​classe​ ​de​ ​serviço. 

Palavras-chave: Redes Softwarizadas, OpenFlow, Alocação de Recursos        Superdimensionados,​ ​Qualidade​ ​de​ ​Serviço. 

Implementation​ ​and​ ​Evaluation​ ​of​ ​the 

Overprovisioned-based​ ​Resource​ ​Control​ ​Plane​ ​for 

Softwarized​ ​Networks 

Author:​ ​Douglas​ ​Braz​ ​Maciel    Advisor:​ ​Prof.​ ​Dr.​ ​Augusto​ ​José​ ​Venâncio​ ​Neto 

A

The present work aims at introducing the implementation plan for        prototyping the oversized resources controller tailored to softwarized        networks featuring the OpenFlow southbound API. The resulting controller        has as primary objective to apply an optimized resource control plan in the        softwarized network, in order to obtain efficient-enhanced data plan in terms        to quality-guaranteed transport service. The results obtained through the        prototyping demonstrate the feasibility and efficiency of the resulting control        plan, suggesting a significant improvement over classic Internet models,        regarding overall mobile objects admissions, resources over-reservation and        data​ ​throughput​ ​per​ ​class​ ​of​ ​service.  

Keywords: Softwarized Networks, OpenFlow, Allocation of Oversized        Resources,​ ​Quality​ ​of​ ​Service. 

Lista​ ​de​ ​figuras 

Figura​ ​2​ ​Arquitetura​ ​ONF​ ​para​ ​as​ ​Redes​ ​Definidas​ ​por​ ​Software(SDN)...​ ​24 

Figura​ ​2.1​ ​Funcionamento​ ​de​ ​um​ ​Switch​ ​OpenFlow……….​ ​28 

Figura​ ​2.2​ ​Arquitetura​ ​de​ ​um​ ​switch​ ​tradicional………​ ​29 

Figura​ ​2.3​ ​Campos​ ​de​ ​cabeçalho​ ​em​ ​um​ ​fluxo​ ​OpenFlow………​ ​31 

Figura 2.4 Fluxograma do processamento de pacotes em switches        OpenFlow………​ ​41 

Figura​ ​2.5​ ​Primeiras​ ​mensagens​ ​trocadas​ ​entre​ ​o​ ​switch​ ​e​ ​o​ ​controlador..​ ​49 

Figura​ ​3​ ​Arquitetura​ ​geral​ ​do​ ​sistema​ ​SDWiNeMo………..​ ​58 

Figura​ ​3.1​ ​Estabelecimento​ ​de​ ​uma​ ​nova​ ​conexão​ ​na​ ​rede………..​ ​62 

Figura​ ​3.2​ ​Sinalização​ ​feita​ ​na​ ​Predição​ ​de​ ​mobilidade​ ​e​ ​handover.……….​ ​67 

Figura 3.3 Diagrama de sinalizações no momento do balanceamento da        carga……….​ ​68 

Figura 4 Fluxograma de execução dos mecanismos de admissão e alocação        de​ ​recursos……….​ ​72 

Figura​ ​5​ ​Organização​ ​da​ ​topologia​ ​empregada​ ​para​ ​os​ ​testes.………​ ​77 

Figura 5.1. Porcentagem de chance para admissão de um objeto móvel na        rede.……….​ ​79 

Figura​ ​5.2.​ ​Reserva​ ​das​ ​CoS​ ​após​ ​reajustes………..​ ​81 

Figura​ ​5.3​ ​vazão​ ​de​ ​dados​ ​por​ ​CoS………...​ ​82   

Lista​ ​de​ ​tabelas 

Tabela​ ​1​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.1...​ ​34 

Tabela​ ​2​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.2...​ ​36 

Tabela​ ​3​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.3...​ ​37 

Tabela​ ​4​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.4...​ ​38 

Tabela​ ​5​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.5...​ ​39   

Lista​ ​de​ ​abreviaturas​ ​e​ ​siglas 

UFRN​ ​-​ ​Universidade​ ​Federal​ ​do​ ​Rio​ ​Grande​ ​do​ ​Norte 

DIMAp​ ​-​ ​Departamento​ ​de​ ​Informática​ ​e​ ​Matemática​ ​Aplicada 

SMART - Suporte Confiável de Sessões Móveis Multimídia com Alta        Demanda​ ​de​ ​Recursos​ ​de​ ​Transporte 

SDWiNeMo​ ​-​ ​Software​ ​Defined​ ​Wireless​ ​Networking​ ​for​ ​Moving​ ​Objects  MO​ ​-​ ​Moving​ ​Object 

IEEE​ ​-​ ​Institute​ ​of​ ​Electrical​ ​and​ ​Electronics​ ​Engineers  CoS​ ​-​ ​Class​ ​of​ ​Service 

PoA​ ​-​ ​Point​ ​of​ ​Access 

MIH​ ​-​ ​Media​ ​Independent​ ​Handover   QoS​ ​-​ ​Quality​ ​of​ ​Service 

ONF​ ​-​ ​Open​ ​Network​ ​Foundation 

API​ ​-​ ​Application​ ​Programming​ ​Interfaces  REST​ ​-​ ​Representative​ ​State​ ​Transfer  IP​ ​-​ ​Internet​ ​Protocol 

MPLS​ ​-​ ​Multiprotocol​ ​Label​ ​Switching​ ​Architecture  OXM​ ​-​ ​OpenFlow​ ​Extensible​ ​Match 

OF-Config​ ​-​ ​OpenFlow​ ​Configuration​ ​and​ ​Management​ ​Protocol  TCP​ ​-​ ​Transmission​ ​Control​ ​Protocol 

UDP​ ​-​ ​User​ ​Datagram​ ​Protocol  TLS​ ​-​ ​Transport​ ​Layer​ ​Security  DPID​ ​-​ ​OpenFlow​ ​Datapath​ ​ID 

Diffserv​ ​-​ ​Differentiated​ ​services  RFC​ ​-​ ​Request​ ​for​ ​Comments 

RSVP​ ​-​ ​Resource​ ​reSerVation​ ​Protocol  IETF​ ​-​ ​Internet​ ​Engineering​ ​Task​ ​Force  SLA​ ​-​ ​Service​ ​Level​ ​Agreement 

DSCP​ ​-​ ​Differentiated​ ​Services​ ​Code​ ​Point  ToS​ ​-​ ​Type​ ​of​ ​Service 

PHB​ ​-​ ​Per​ ​Hop​ ​Behavior  LTE​ ​-​ ​Long​ ​Term​ ​Evolution 

UMTS​ ​-​ ​Universal​ ​Mobile​ ​Telecommunications​ ​System  ANCE​ ​-​ ​Access​ ​Network​ ​Control​ ​Entity 

MCE​ ​-​ ​Mobility​ ​Control​ ​Entity  NPI​ ​-​ ​Network​ ​Protocol​ ​Interface  RMO​ ​-​ ​Requester​ ​Moving​ ​Object 

RSSI​ ​-​ ​Received​ ​Signal​ ​Strength​ ​Indicator  PoAT​ ​-​ ​PoA​ ​Target 

PoAC​ ​-​ ​PoA​ ​candidate   

Sumário

1.5​ ​Organização​ ​do​ ​trabalho 21 

2​ ​Fundamentação​ ​Teórica 22 

2.1​ ​Redes​ ​Definidas​ ​por​ ​Software​ ​(SDN) 22 

2.1.2​ ​Protocolos​ ​para​ ​Redes​ ​SDN 26 

2.2​ ​OpenFlow 27 

2.2.1​ ​Tabela​ ​de​ ​Fluxos 29 

2.2.2​ ​Versões​ ​do​ ​Protocolo​ ​OpenFlow 33  2.2.3​ ​Emparelhamento​ ​entre​ ​Pacotes​ ​e​ ​Fluxos​ ​de​ ​Entrada 40 

2.2.4​ ​Controlador​ ​OpenFlow 44 

2.2.5​ ​Comunicação​ ​entre​ ​Controlador​ ​e​ ​Switch​ ​OpenFlow 46 

2.2.5.1​ ​Controlador​ ​para​ ​Switch 47 

2.2.5.2​ ​Mensagens​ ​Assíncronas 48 

2.2.5.3​ ​Mensagens​ ​Simétricas 48 

2.2.5.4​ ​Conexão​ ​entre​ ​o​ ​Controlador​ ​e​ ​o​ ​Switch 49 

2.3​ ​Qualidade​ ​de​ ​serviço​ ​(QoS) 51 

2.3.1​ ​Abordagens​ ​de​ ​QoS 51 

2.3.1.1​ ​Serviços​ ​de​ ​Integração​ ​(IntServ) 51  2.3.1.2​ ​Serviço​ ​Diferenciado​ ​(DiffServ) 52  2.3.2​ ​Alocação​ ​de​ ​Recursos​ ​de​ ​QoS 54  2.3.2.1​ ​Alocação​ ​Estática​ ​de​ ​Recursos 54  2.3.2.2​ ​Alocação​ ​de​ ​Recursos​ ​Por​ ​fluxo 54  2.3.2.3​ ​Alocação​ ​de​ ​Recursos​ ​Superdimensionados 55 

2.4​ ​Resumo​ ​do​ ​Capítulo 55 

3​ ​Visão​ ​Geral​ ​do​ ​Sistema​ ​SDWiNeMO 56 

3.2​ ​Arquitetura 58  3.2.1​ ​Access​ ​Network​ ​Control​ ​Entity​ ​(ANCE) 59 

3.2.1.1​ ​Controle​ ​da​ ​Topologia 62 

3.2.1.2​ ​Controle​ ​de​ ​Admissão 63 

3.2.1.3​ ​Controle​ ​para​ ​Alocação​ ​de​ ​Recursos 63  3.2.2​ ​Mobility​ ​Control​ ​Entity​ ​(MCE) 64  3.2.2.1​ ​Mobilidade​ ​Antecipada​ ​do​ ​Objeto​ ​Móvel 68  3.2.2.2​ ​Controle​ ​para​ ​Seleção​ ​do​ ​Ponto​ ​de​ ​Acesso(PoA) 69  3.2.2.3​ ​Balanço​ ​de​ ​Carga​ ​Baseado​ ​em​ ​Mobilidade 70 

4​ ​Implementação 71 

4.1​ ​Fluxograma​ ​de​ ​Execução 71 

5​ ​Avaliação​ ​do​ ​SDWiNeMO 76 

6​ ​Conclusão 82 

Referências 84

1​ ​Introdução 

Este  capítulo  descreve  as  motivações  encontradas  para o    desenvolvimento deste trabalho, apresentando alguns dos principais        problemas existentes atualmente nos ambientes de rede, os objetivos        alcançados ao final do desenvolvimento da ferramenta, além também das        contribuições que este trabalho apresenta, onde estas foram ocasionadas        pelo desenvolvimento dos mecanismos expostos neste documento, e por fim,        é descrito os resultados obtidos, onde estes são mostrados através de        publicações​ ​em​ ​congressos​ ​internacionais.  

1.1​ ​Contexto 

Com o decorrer dos anos, o acesso aos dispositivos móveis tornou-se        mais fácil, tais como smartphones, smartwatches, dispositivos corporais, e        outros, devido ao barateamento das tecnologias móveis. Hoje em dia é difícil        encontrar uma pessoa que não possua pelo menos um smartphone, por        exemplo. Estudos indicam que até 2021 aproximadamente 27.1 bilhões de        dispositivos estarão conectados na rede[12], enquanto que em 2016 haviam        apenas 17.1 bilhões, sendo que cada indivíduo, em 2021, possuirá pelo        menos 3 dispositivos com acesso à internet, enquanto que em 2016, cada        pessoa possuía aproximadamente 2 dispositivos com capacidade de acesso à        rede. Tendo isto em mente, a consequência deste crescimento é refletido no        consumo da rede, onde de acordo com a Cisco, somente o tráfego de vídeo        circulante na internet, será de aproximadamente 187.4 exabyte,        apresentando uma elevação cerca de 379,3% quando se comparado a 2016,        onde neste o tráfego girava em torno de 49.4 exabyte. Além disso, o conteúdo        que será mais fortemente consumido, pelos usuários, será o de vídeos, onde        este​ ​representará​ ​cerca​ ​de​ ​80%​ ​do​ ​tráfego​ ​total​ ​na​ ​internet. 

Esta quantidade imensa de dados trafegados é proveniente de diversas        aplicações embarcadas em dispositivos móveis, onde cada uma dessas        necessita de garantia de qualidade em um conjunto de requisitos,        especificados por essas, para fornecer um serviço de qualidade para os        usuários. Entretanto, a internet nos dias de hoje encontra-se engessada,        apresentando inúmeras dificuldades e até mesmo incapacidades de        encontrar uma solução para o cenário apresentado pela Cisco para 2021.        Alguns desses problemas estão relacionados a confiabilidade, escalabilidade        e a falta de flexibilidade, visto que é muito complexo integrar uma nova        tecnologia na rede, devido à dificuldades encontradas tanto na testabilidade        do novo mecanismo quanto pela atual internet ser composta por dispositivos        proprietários, onde somente os fabricantes possuem acesso ao código fonte        do dispositivo da rede, tais como roteadores e switches, para integração de        novas​ ​funcionalidades.  

As redes definidas por software (Software Defined Network - SDN) é        uma abordagem projetada para solucionar os problemas apresentados        acima, onde os dispositivos de rede (switches, roteadores, pontos de acesso)        não mais são implementados por softwares proprietários, mas sim por        pesquisadores e administradores da rede, no qual, através de um        controlador, novos protocolos e algoritmos são facilmente capazes de serem        inseridos​ ​na​ ​rede. 

Esse trabalho foi desenvolvido no âmbito do projeto SMART (Suporte        Confiável de Sessões Móveis Multimídia com Alta Demanda de Recursos de        Transporte), onde a aplicação dos conceitos do SMART já encontravam-se        em desenvolvimento no âmbito de um trabalho de mestrado. O SMART segue        um modelo disruptivo, onde o foco está na inovação tecnológica ao invés da        evolução das tecnologias já existentes no cenário atual, no qual para isto        utiliza a abordagem das redes definidas por software para o desenvolvimento        de mecanismos de comunicação revolucionários. A idéia ao final do projeto        era o de fornecer um sistema robusto, capaz de suportar diferentes        aplicações e tecnologias de rede heterogêneas, provendo qualidade de serviço       

para as aplicações, através da alocação de recursos, definidos previamente        pelas aplicações, com a finalidade de atingir o nível de satisfação dos        usuários. O SMART visava fornecer as seguintes inovações: (i) especificação        de requisitos de QoS para cada aplicação móvel; (ii) criação de novas        mensagens OpenFlow, voltadas para o âmbito do projeto; (iii) predição de        mobilidade baseando-se na queda dos padrões de QoS estabelecidos para        cada aplicação; (iv) seleção do(s) ponto(s) de acesso mais adequado(s) para        acomodar requisições de associação na rede; (v) balanceamento de carga        entre pontos de acesso, de forma a garantir a estabilidade da rede. Com isto        em mente, foi desenvolvido o sistema SDWiNeMo (Software Defined Wireless        Networking for Moving Objects). Este sistema é um framework destinado a        oferecer serviços de transporte com garantia de QoS para as diversas        aplicações móveis, além também de prover transparentemente, aos nós        móveis, mobilidade entre pontos de acesso caso os recursos requisitado        pelas​ ​aplicações​ ​não​ ​estejam​ ​sendo​ ​atendidos​ ​adequadamente.  

1.2​ ​Objetivos 

Existe uma diversidade imensa de tipos de objetos móveis (Moving        Objects - MO), onde estes podem ser tanto smartphones, smartwatches, e        diversos outros dispositivos. Sendo assim, uma infraestrutura ótima deve        fornecer serviços diferenciados que aprimorem o desempenho e a usabilidade        da rede, de forma que seja proporcionado escalabilidade, confiabilidade,        agilidade e flexibilidade, além também da capacidade de suportar qualquer        tecnologia de comunicação sem fio utilizada por estes MOs, tais como IEEE        802.11​ ​e​ ​4​ ​G,​ ​visando​ ​sempre​ ​mantê-los​ ​com​ ​a​ ​conexão​ ​possível.  

O framework SDWiNeMo foi desenvolvido visando fornecer garantia de        qualidade de serviço, desde a origem até o destino do canal de comunicação,        para as aplicações embarcadas nos MOs que requisitarem conexão na rede.        Cada aplicação necessita de um conjunto diferente de requisitos para        oferecer uma boa experiência de uso para os usuários, e sendo assim, o        SDWiNeMo, no momento da requisição, procura identificar os recursos       

desejados pela aplicação, tais como latência máxima, largura de banda ideal,        e outros. Esta extração de informações é necessária para o controlador        descobrir a classe de serviço (CoS) que melhor representa determinada        aplicação, sendo que cada CoS oferece diferentes garantias de recursos. As        classes de serviço são criadas no momento da inicialização da rede, após a        descoberta dos melhores caminhos presentes entre a entrada e a saída da        rede, e configuradas em cada interface pertencente aos caminhos        previamente escolhidos, presente nos PoAs, sendo que a largura máxima        suportada por cada interface destas é dividida entre as diversas classes de        serviço gerenciadas pelo controlador. Entretanto, a largura máxima de        banda disponibilizada para uma determinada classe, não é liberada de        imediato, pois apenas uma parte desta é liberada de início, enquanto que o        restante é liberado gradativamente, através de reajustes na banda        sobre-reservada para uma determinada classe, com o aumento das        requisições realizadas a um PoA e mapeadas para uma determinada CoS. A        idéia da divisão das interfaces dos PoAs em classes, permitiu o        desenvolvimento de mecanismos capazes de aprimorar o desempenho da        rede. 

O objetivo do SDWiNeMo é fornecer um conjunto de serviços        diferenciados, focando sempre em prover a melhor conexão possível para os        MOs. O SDWiNeMo, configura inicialmente uma sobre-reserva de banda nas        classes de serviço pertencentes às interfaces de rede dos PoAs, para que        assim seja transmitido um menor número de sinalizações na rede. O        mapeamento de MOs para estas classes é feito por um módulo de controle de        acesso, onde este é o responsável pela inserção de fluxos nos PoAs        pertencentes a um dado caminho previamente selecionado. Além disso, para        tratar adequadamente cada admissão realizada na rede, o SDWiNeMo conta        com o controlador de alocação de recursos que é responsável por armazenar        informações sobre a quantidade de banda utilizada e disponível em cada        classe, além também de ser o encarregado por executar reajustes tanto na        sobre-reserva de recursos das classes quanto reajustes entre as próprias       

classes, fazendo transferência de recursos ociosos, em uma ou mais classes,        para  a  classe  que  encontra-se  momentaneamente  saturada.  A  interoperabilidade realizada entre estes dois controladores é fundamental        para a maximização do uso dos recursos presentes nos PoAs, pois isto        permite a minimização da quantidade de recursos ociosos e o consequente        incremento​ ​do​ ​número​ ​de​ ​MOs​ ​conectados​ ​na​ ​rede.  

Além disso, o SDWiNeMo possui mecanismos para predição de        mobilidade, onde através do protocolo IEEE 802.21 Media Independent        Handover (MIH), o controlador mantém-se atualizado sobre as condições da        conexão de cada MO conectado na rede. O MIH é um agente embarcado nos        MOs, que é responsável por executar medições nos parâmetros de qualidade        da conexão, tais como taxa de perda de pacotes, latência, força do sinal        entre o MO e o PoA, e sendo assim, periodicamente repassa para o        controlador estas informações coletadas. Quando o MO encontra-se        apresentando altas taxas de perda de pacote, latência ou em outras        palavras, os parâmetros de QoS não encontram-se sendo atendidos no        momento, o controlador envia um comando para a execução de um handover        para o MIH. O handover consiste em transferir o MO, atualmente conectado        a um PoA, para outro PoA que encontre-se apto para acomodar todas as        aplicações​ ​associadas​ ​a​ ​este​ ​MO.  

Uma das principais características do SDWiNeMO é o poder que este        possui para balancear a carga presente na rede. Através do trabalho em        conjunto do controlador com o MIH, foi possível desenvolver um mecanismo        ágil e eficiente capaz de realizar distribuição de MOs, previamente        conectados, entre diferentes PoAs. Este balanceamento é acionado quando        uma nova requisição é feita para um PoA saturado, onde este encontra-se        incapaz de reajustar a sobre-reserva das classes e de realizar reajustes entre        classes, e sendo assim, para permitir acomodação de novos MOs, é        necessário executar o mecanismo de handover em um ou mais MOs        conectados nesse PoA, para que seja liberado recursos previamente alocados       

para estes e posteriormente disponibilizados novamente para acomodação de        novas​ ​requisições. 

Este trabalho foi desenvolvido no âmbito de um projeto de mestrado e        objetiva apresentar a implementação dos mecanismos para controle de        admissão e alocação de recursos, e também a técnica de validação utilizada        para analisar o desempenho e a correta execução dos mecanismos        implementados. O controlador SDN utilizado na implementação foi o Pox.        Apesar de existir diferentes tipos de controlador SDN no mercado, tais como        Floodlight, Ryu e o OpenDaylight, o Pox foi escolhido pelo fato deste ser de        conhecimento da equipe e ter sido desenvolvido em Python, além também de        apresentar​ ​uma​ ​boa​ ​documentação. 

Para testar algumas das funcionalidades do controlador, foi        primeiramente utilizado a ferramenta de emulação chamada de Mininet[25].        Esta ferramenta permite a criação personalizada de hosts e switches        OpenFlow para gerar uma topologia de rede virtualizada. Cada switch é        configurado para no momento da inicialização estabelecer um canal de        comunicação com o controlador, através do endereço IP especificado pelo        desenvolvedor da topologia. Sendo assim, para a execução de testes dos        controles de admissão e de alocação de recursos, esta ferramenta foi        suficiente para proporcionar resultados favoráveis. Entretanto, para a        execução dos testes que envolvem mobilidade, como a predição e o        balanceamento de carga, foi utilizada a ferramenta Mininet-WiFi [21], pois        nesta é integrada o protocolo IEEE 802.11, e sendo assim foi possível        realizar testes realísticos simulando ambientes de rede sem fio com presença        de perda de pacotes, variação de latência, handover entre pontos de acesso,        entre outros. O Mininet-WiFi é uma extensão do Mininet, e sendo assim os        mesmos resultados obtidos com os testes no Mininet também foram obtidos        quando​ ​testados​ ​no​ ​Mininet-WiFi.   

1.3​ ​Contribuições 

As principais contribuições fornecidas pelo desenvolvimento dos        mecanismos propostos para este trabalho foram: (i) implementação de um        serviço para controle de QoS em caminhos selecionados; (ii) implementação        de um mecanismo de controle de admissão baseado em alocação de recursos        de rede; (iii) apresentação dos resultados obtidos em artigos científicos        internacionais.   

1.4​ ​Resultados 

Além desse trabalho de conclusão de curso, os resultados obtidos com        o desenvolvimento e a validação do mecanismo SDWiNeMO conduziu às        seguintes​ ​publicações​ ​produzidas​ ​no​ ​decorrer​ ​do​ ​desenvolvimento: 

1. Felipe  Sampaio  Dantas  da  Silva,  "​Controle de Mobilidade      Infraestruturado e Orientado à Qualidade para Maximização de                Admissões em Sistemas WiNeMO: Uma Abordagem Definida por                Software​". Dissertação de Mestrado do Programa de Pós Graduação        em Sistemas e Computação, Universidade Federal do Rio Grande do        Norte.​​ ​Defendida​ ​em​ ​18​ ​de​ ​Dezembro​ ​de​ ​2015; 

2. SILVA, FELIPE S. DANTAS; NETO, AUGUSTO VENÂNCIO; MACIEL​,        DOUGLAS; CASTILLO-LEMA, JOSÉ; SILVA, FLÁVIO; FROSI, PEDRO;        Cerqueira,  Eduardo. "​An innovative software-defined WiNeMO          architecture for advanced QoS-guaranteed mobile service transport            ​".  Computer​ ​Networks​ ​(1999),​ ​v.​ ​107,​ ​p.​ ​270-291,​ ​2016. 

3. SILVA, FELIPE S. DANTAS; NETO, AUGUSTO J.V.; MACIEL,        DOUGLAS BRAZ; CASTILLO-LEMA, JOSE; SILVA, FLÁVIO DE        OLIVEIRA; ROSA, PEDRO FROSI. "​SDN Based Control Plane                Extensions for Mobility Management Improvement in Next Generation                ETArch Networks  ​". 18th ACM International Conference on Modeling,       

Analysis and Simulation of Wireless and Mobile Systems - MSWiM '15,        Cancun,​ ​2015,​ ​p.​ ​189-193; 

4. DANTAS, FELIPE; NETO, A.; BRAZ, D​.​; CASTILLO-LEMA, JOSE;        SILVA, FLAVIO. "​Infrastructured Mobility Management Approach for              Future Internet ETArch Networks      ​". International Conference on        Wireless​ ​Networks​ ​(ICWN),​ ​2015,​ ​Las​ ​Vegas,​ ​p.​ ​39-45. 

Vale ressaltar que os resultados apresentados por este trabalho foram objeto        da publicação de número 2, na qual essa apresenta o sistema SDWiNeMo        que é o framework resultante dos mecanismos desenvolvidos durante o        projeto​ ​SMART. 

1.5​ ​Organização​ ​do​ ​trabalho 

O restante deste documento encontra-se organizado da seguinte        maneira: Seção 2 apresenta um embasamento teórico sobre as tecnologias        abordadas no desenvolvimento do sistema. Seção 3 descreve o        funcionamento do SDWiNeMo, apresentando seus principais objetivos e a        organização interna da sua arquitetura. Seção 4 apresenta um fluxograma        de execução do sistema SDWiNeMo, onde este demonstra o andamento,        desde o início até o fim, de uma requisição dirigida ao sistema. A seção 5        apresenta o ambiente de testes utilizado, onde este abrange a topologia e        ferramenta de emulação utilizada, bem como configurações realizadas no        ambiente de testes. A seção 6 mostra os resultados obtidos e análises        obtidas na emulação. E por fim, a seção 7 apresenta a conclusão do        trabalho.  

2​ ​Fundamentação​ ​Teórica 

Neste capítulo será apresentado uma visão detalhada do conceito de        SDN, bem como algumas tecnologias desenvolvidas para operar sob este        novo conceito, como é o caso do protocolo OpenFlow e também do Mininet,        embora o Mininet tenha sido projetado para atuar sob redes convencionais        também. 

2.1​ ​Redes​ ​Definidas​ ​por​ ​Software​ ​(SDN) 

As Redes Definidas por Software (SDN, do inglês Software-Defined        Networking) [REF RFC 7426], são infraestruturas de rede que permitem        programabilidade de seus recursos em tempo de execução. Trata-se de uma        nova abordagem de programação, em software, voltado à redes, que permite        o desenvolvimento de mecanismos capazes de gerenciar e controlar os        recursos presentes na rede, tais como garantia de largura de banda mínima,        baixa latência e perda de pacotes. Firewalls, distribuição de carga entre        equipamentos de rede, qualidade de serviço(QoS), gerência de tráfego, são        exemplos de aplicações de rede que podem ser desenvolvidos utilizando-se        da​ ​abordagem​ ​SDN. 

Para a abordagem SDN poder entrar de vez em vigor, teve-se que        executar a padronização do mesmo. Isto deu-se através da ONF (Open        Network Foundation)[11]. A ONF foi criado por um conglomerado de        empresas, que dentre elas estão presentes: Google, Facebook, Microsoft e        algumas​ ​outras,​ ​em​ ​21​ ​de​ ​março​ ​de​ ​2011.  

A arquitetura proposta para padronização pela ONF é apresentada na        figura 2. Nela é possível ver a existência de três camadas: camada de        aplicação, camada de controle e camada de dados, cada uma com um papel        distinto. A terceira camada, chamada de plano de dados, é responsável pelo        transportes dos dados que trafegam pela rede. Nesta camada é descrito os       

protocolos e algoritmos usados para permitir que pacotes Ip sejam        repassados dentro da rede, desde sua origem até o destino. A segunda        camada é chamada de plano de controle, pois é responsável pela gerência da        rede. É nesta camada que se encontra os controladores da rede responsáveis        por orquestrar o plano de dados, de forma que a rede se comporte de acordo        com a maneira que os desenvolvedores da rede projetaram. Esta arquitetura        permite que o controle da rede seja centralizado, permitindo e facilitando a        coleta da grande quantidade de informações que trafegam pela rede.        Diversos controladores podem operar simultaneamente sobre um mesmo        ambiente de rede, mais precisamente sobre os mesmos dispositivos        presentes na rede, onde cada controlador torna-se responsável por        orquestrar uma ou mais funcionalidades, como por exemplo, um controlador        “A” tem a tarefa de realizar o balanceamento de carga entre diferentes        dispositivos de rede, enquanto que um controlador “B” é implantado para        atuar protegendo a rede de possíveis intrusões, em outras palavras, atuando        como um firewall. Além disto, cada controlador pode trocar informações com        outros​ ​presentes​ ​na​ ​rede. 

Por fim, na primeira camada é onde fica localizada todas as aplicações        utilizadas pelos clientes, bem como os requisitos necessários para sua        operação, como por exemplo, espaço para armazenamento, segurança e        gerenciamento das aplicações. É nesta camada que se encontra toda a        programabilidade das aplicações e também informações referentes às        necessidades de cada aplicação perante à rede, como por exemplo, uma        determinada aplicação “A” necessita de um canal para comunicação que        possua latência inferior a 50 ms, enquanto que uma outra aplicação “B”        necessita de 300kb/s de banda disponível para fornecer um bom        funcionamento​ ​para​ ​o​ ​cliente. 

Figura​ ​2.​​ ​Arquitetura​ ​ONF​ ​para​ ​as​ ​Redes​ ​Definidas​ ​por​ ​Software(SDN) 

Fonte:​ ​Próprio​ ​autor. 

A imagem apresentada pela Figura 2 mostra como é definida pela ONF        a arquitetura SDN. O SDN tem como principal característica separar o plano        de dados do plano de controle, o software do hardware, ou seja, o controle        lógico da rede é extraído dos dispositivos de rede é transferido para        elementos centralizadores ou controladores SDN. Com esta separação, os        dispositivos de rede tornam-se simples encaminhadores de pacotes. Para        gerenciar estes encaminhadores de pacotes, o controlador cria então uma       

abstração da rede, com a finalidade de coletar informações referentes às        conexões existentes entre dispositivos encaminhadores, e também estabelece        um canal de comunicação seguro com cada um destes dispositivos. Este        canal é criado exclusivamente para trafegar mensagens trocadas entre o        controlador e os dispositivos, como por exemplo, mensagens de comando ou        eventos gerados pelos switches, enquanto que os pacotes de dados        convencionais trafegam apenas entre os links existentes entre os        encaminhadores de pacotes. O termo “switch” é comumente usado para        representar nós OpenFlow, pois os caminhos são definidos pelo controlador,        o que torna então estes dispositivos apenas encaminhadores de pacotes,        eliminando assim, de suas obrigações, a tarefa de gerenciar os caminhos na        rede. O protocolo OpenFlow será detalhado nas próximas seções deste        documento.  

Existem duas interfaces principais de comunicação no controlador        chamadas de Northbound API (Application Programming Interfaces) e        Southbound API. A interface Southbound é a interface que o controlador usa        para configurar os dispositivos de rede, desde o envio de comandos até a        coleta de estatísticas, geralmente utilizando o protocolo OpenFlow para        transmissão dos comandos, enquanto que a interface Northbound estabelece        ligação entre o controlador e a camada de aplicação. Por esta interface        passam informações pertinente às necessidades das aplicações para que        assim o controlador possa gerenciar a rede da melhor maneira possível,        sempre visando prover o melhor serviço para as aplicações, como qualidade        de serviço (QoS) e segurança adequada. O protocolo comumente utilizado        para transmissão dos dados nesta interface é o REST (Representative State        Transfer)​ ​API. 

Além das interfaces citadas anteriormente, existem duas outras        interfaces chamadas de Westbound API e Eastbound API. A interface        Eastbound permite que dois ou mais controladores do mesmo tipo        comuniquem-se entre si para tomada de decisões em conjunto. Já a        interface Westbound possui a mesma função que a Eastbound, com a       

diferença de essa permitir a comunicação entre controladores compatíveis        que estejam em sub-redes diferentes. Estas interfaces são muito utilizadas        em ambientes rede que necessitem de vários controladores para poder        administrá-los. 

2.1.2​ ​Protocolos​ ​para​ ​Redes​ ​SDN 

Com o surgimento do SDN, diversos protocolos foram propostos para        operar sob este novo paradigma. Entre estes destacam-se: OpenFlow,        VXLAN,​ ​TRILL​ ​e​ ​LISP. 

O OpenFlow é um protocolo de comunicação utilizado para transportar        mensagens de comando entre controladores SDN e switches OpenFlow. Nos        switches OpenFlow ficam localizadas regras para repasse dos pacotes. Estas        regras são usadas pelos switches para casamento de padrões, ou seja, cada        pacote que chega ao switch é analisado baseando-se nas regras conhecidas        pelo switch, que foram previamente inseridas pelo controlador ou pelo        administrador da rede, e caso o switch conheça uma regra que case com este        pacote que acabou de ingressar ao switch, este então desempenha ações        sobre este pacote, como por exemplo, repassando-o para alguma interface de        rede​ ​ou​ ​simplesmente​ ​descartando-o. 

O protocolo VXLAN(Virtual eXtensible Lan) foi desenvolvido pela Cisco

e VMware para solucionar o problema da limitação existente nas VLANs, pois        estas suportam até um máximo de 4096 VLANs por haver apenas 12 bits        disponíveis para uso, e permitir a comunicação entre datacenters localizados        em diferentes sub-redes, utilizando do mesmo bloco de endereçamento IP.        Com o uso do VXLAN é possível chegar a 16 milhões de zonas de        identificação. O VXLAN funciona acrescentando um cabeçalho contendo um        VNI (VXLAN Network Id), que é um identificador, ao quadro ethernet que        uma máquina virtual disseminaria naturalmente para outra máquina        presente na mesma sub-rede IP. Após feito isto, este pacote, contendo o VNI,        é inserido como sendo apenas dados ao cabeçalho UDP presente em outro        quadro ethernet, onde neste novo quadro contém informações de origem e       

destino entre dois datacenters diferentes, por exemplo. Ao chegar no destino,        é extraído do pacote o quadro mais externo e o identificador VNI, sobrando        assim apenas o quadro interno, gerado pela máquina virtual. Assim sendo,        este quadro que sobrou pode ser então roteado para a máquina virtual        destinatária,​ ​recomeçando​ ​assim​ ​todo​ ​o​ ​ciclo​ ​novamente. 

O LISP (Locator/Identifier Separation Protocol) foi desenvolvido para        facilitar o transporte de máquinas virtuais de um datacenter para outro sem        alterar o endereço IP das que já encontra-se configurado nas máquinas        virtuais. Para isto funcionar é necessário realizar a divisão entre o endereço        que identifica a máquina virtual e o endereço que será utilizado para o        roteamento entre os datacenters. O LISP faz uso tanto do endereço associado        à máquina destinatária, o EID (Endpoint ID), quanto o endereço usado para        roteamento, o RLOC (Routing-Locator). Quando uma máquina cliente inicia        comunicação com uma máquina servidora, o tráfego é interceptado pelo iTR        (ingress Tunnel Router), que nada mais é que o túnel de entrada dos        pacotes, ou roteador de borda de entrada. O iTR é responsável por localizar o        RLOC no qual a máquina servidora encontra-se associada através do        endereço EID pertencente a esta máquina. Após a identificação do RLOC de        destino, o roteamento até este é feito através do eTR (egress Tunnel Router),        ou roteador de borda de saída, que consultará um diretório de serviços,        chamado de EID-RLOC, para obter informações de rotas que direcionam ao        RLOC do destinatário. Tudo isto é feito de maneira invisível para as        entidades​ ​envolvidas​ ​na​ ​comunicação. 

2.2​ ​OpenFlow 

A especificação do OpenFlow foi criada e, inicialmente, desenvolvida        por um grupo de pessoas da universidade de Stanford, Califórnia, e desde        então vem sendo aperfeiçoada a cada ano. Em um primeiro instante, a        organização sem fins lucrativos openflow.org foi criada, em 2008, com a        finalidade de suportar e promover o protocolo OpenFlow. Este domínio era        usado para centralizar a especificação do protocolo, como documentação e       

artigos publicados. O objetivo inicial do OpenFlow era o de fornecer uma        plataforma de redes experimental para pesquisadores da área, apesar de        também visar uma futura possível comercialização de equipamentos        embarcados com o OpenFlow. A primeira versão do OpenFlow foi lançada em        31 de dezembro de 2009, embora partes da documentação já se        encontrassem disponíveis na internet antes mesmo do seu lançamento        oficial. A organização openflow.org gerenciou o desenvolvimento da        especificação do OpenFlow até a versão 1.1.0, enquanto que versões        posteriores a esta foram desenvolvidas e gerenciadas pela ONF, para acelerar        a​ ​implantação​ ​e​ ​desenvolvimento​ ​do​ ​OpenFlow​ ​em​ ​ambientes​ ​SDN.  

Como dito anteriormente, o OpenFlow é um protocolo de comunicação        usado para que controladores SDN modifiquem o comportamento dos        switches SDN, bem como também permitir a realização da coleta de        informações. Em outras palavras, o OpenFlow define o que um switch é        capaz de fazer quando possui este protocolo embarcado. Nas duas figuras a        seguir, pode-se visualizar as principais diferenças existentes na arquitetura        dos​ ​switches​ ​OpenFlow​ ​e​ ​dos​ ​switches​ ​regulares. 

Figura​ ​2.1.​​ ​Funcionamento​ ​de​ ​um​ ​Switch​ ​OpenFlow. 

Figura​ ​2.2.​​ ​Arquitetura​ ​de​ ​um​ ​switch​ ​tradicional. 

Fonte:​ ​Próprio​ ​autor. 

A figura 2.2 representa a arquitetura dos switches regulares.        Observa-se que o plano de dados encontra-se associado ao plano de        controle, ou seja, o switch é responsável por gerenciar sua própria lógica de        repasse dos pacotes, enquanto que a figura 2.1 representa a arquitetura        geral dos switches OpenFlow. Nota-se nesta imagem que o plano de controle        foi dissociado do plano de dados, passando a responsabilidade do controle        do switch para um elemento externo, chamado controlador SDN. Nesta        mesma figura observa-se a existência de tabelas de fluxos. Estas tabelas são        responsáveis por armazenar informações referentes a lógica de tratamento        dos pacotes que chegam ao switch, onde cada fluxo representa uma regra e        cada regra é responsável por desencadear uma determinada ação, como por        exemplo, encaminhar todo pacote que entrar pela porta 1 para a porta 2.        Observa-se também na figura 2.1 que switches OpenFlow repassam os        pacotes que não possuem regras específicas de tratamento para o        controlador, que após receber o pacote, retornará para o switch um conjunto        de regras e ações para operar sobre pacotes semelhantes a este. Tabelas de        fluxo​ ​e​ ​ações​ ​serão​ ​discutidas​ ​com​ ​mais​ ​detalhes​ ​na​ ​seção​ ​2.3.3. 

2.2.1

_{​ ​Tabela​ ​de​ ​Fluxos}

O principal componente dos switches OpenFlow são as tabelas de        fluxos. Em um switch pode existir várias tabelas de fluxo, na qual cada uma       

armazena várias entradas de fluxos. A quantidade de fluxos e tabelas        suportados​ ​por​ ​um​ ​switch​ ​dependerá​ ​da​ ​robustez​ ​do​ ​equipamento.  

Um switch OpenFlow precisa necessariamente possuir pelo menos        uma tabela de entrada de fluxos, na qual esta primeira tabela, será a        responsável por tratar, em um primeiro momento, todos os pacotes de        entrada no switch, enquanto que as demais tabelas somente serão acionadas        caso um dos fluxos desta primeira tabela direcione o pacote de entrada para        uma segunda tabela. As tabelas possuem identificadores representados por        números inteiros. A cada tabela é atribuído um número positivo, no qual a        tabela que possuir o número 0 como identificador será a que terá maior        prioridade internamente ao switch. Uma tabela somente poderá encaminhar        um pacote para outra tabela que possuir identificador numérico maior que o        seu próprio identificador. Vale ressaltar que é opcional para a tabela 0 o        redirecionamento de um pacote para uma outra tabela, pois um determinado        fluxo pode apresentar a instrução de enviar o pacote diretamente para uma        porta​ ​de​ ​saída. 

Quando acontece de não haver casamento entre um pacote e as        entradas de fluxo existentes em uma tabela, um fluxo pré-configurado para        tratar deste caso é então acionado. Este fenômeno é chamado de “table        miss”. O comportamento do fluxo que trata de um “table miss” depende do        modo em que foi configurado na tabela. Algumas das instruções atribuídas a        este fluxo envolvem descartar o pacote, encaminhar o pacote para outra        tabela de fluxos e repassar o pacote para o controlador. Neste último caso        será gerado um evento chamado Packet-in, que será detalhado mais adiante.        Caso não exista o fluxo que trate do “table miss”, por padrão o pacote será        descartado. 

Um fluxo de entrada em uma tabela é formado por sete campos:        Campo de regras, contadores, ações, campo de prioridade, campo para        tempo de esgotamento, campo de identificação dos fluxos, ou cookie, e por        fim, o campo flags. Para correto funcionamento dos fluxos, apenas os três        primeiros são essenciais. Apesar destes quatro últimos campos serem       

opcionais, ou seja, sua ausência não acarreta na inserção incorreta de um        fluxo, estes campos são de grande importância para o casamento,        gerenciamento e identificação dos fluxos e pacotes. Na figura 2.3 é possível        visualizar​ ​o​ ​formato​ ​de​ ​um​ ​fluxo​ ​OpenFlow. 

Figura​ ​2.3.​​ ​Campos​ ​de​ ​cabeçalho​ ​em​ ​um​ ​fluxo​ ​OpenFlow. 

Fonte:​ ​Próprio​ ​autor. 

Nesta figura é possível visualizar uma tabela de fluxos contendo N        fluxos inseridos, bem como alguns dos principais campos presentes em um        fluxo. Cada campo destes não necessariamente deve fazer parte de um fluxo,        pois​ ​cada​ ​fluxo​ ​pode​ ​fazer​ ​uso​ ​de​ ​um​ ​número​ ​variável​ ​de​ ​campos.  

O campo de contadores têm a função de calcular quantos pacotes        foram emparelhados com determinado fluxo, onde ao valor deste campo é        acrescido uma unidade para cada pacote que coincidir com um fluxo. Além        disso, os contadores podem ser utilizados para atuar não somente sobre os       

fluxos de dados, mas também sobre tabelas de fluxo, portas de um switch,        filas de entrada e saída, grupos e alguns outros. Com isto, é possível        contabilizar a quantidade de pacotes casados, número de entradas ativas,        em uma tabela, calcular a quantidade de pacotes transmitidos e recebidos,        quantidade de bytes enviados e recebidos. Estes dados podem ser utilizados        para a realização de cálculos mais sofisticados, que servirão de estudo para        o​ ​melhoramento​ ​contínuo​ ​da​ ​rede. 

O campo de prioridades define a ordem na qual os fluxos serão        analisados no momento da chegada de um pacote no switch. Números        inteiros positivos são atribuídos a este campo e quanto maior for seu valor        numérico, maior precedência este fluxo terá internamente ao switch. O        primeiro fluxo que casar com um determinado pacote será o utilizado para        tratamento, enquanto que fluxos que possuírem prioridade inferior a este,        não chegarão a ser analisados. O fluxo que trata do caso de “table miss”        possui prioridade 0, pois este fluxo somente deve ser acionado em último        caso. 

Os Temporizadores são utilizados para definir o período de vida de um        fluxo. Fluxos podem ser eliminados de uma tabela através do uso de três        maneiras diferentes: requisição realizada pelo controlador, tempo ocioso e        tempo máximo de vida. No primeiro caso, o controlador será o agente        responsável por eliminar um ou vários fluxos de uma tabela, isto pode        acontecer, por exemplo, quando uma máquina se desconecta da rede. A        segunda maneira, chamada de “​idle_timeout”, está relacionada ao tempo        ocioso de um fluxo. O switch registra o momento da chegada do último        pacote a um determinado fluxo e logo em seguida inicia a contagem, em        segundos, do seu tempo de inatividade. Caso este valor atinja um número        pré-definido, o fluxo é então removido do switch. O terceiro e último caso,        chamado de “​hard_timeout”, ocorre quando o tempo de vida máximo de um        fluxo, cronometrado desde sua criação, é atingido. Fluxos configurados com        “​hard_timeout​” são removidos independentemente de estarem sendo        utilizados ou não. Para evitar a remoção indesejada de um fluxo devido ao       

fator tempo, configura-se os valores do “​idle_timeout​” e do “​hard_timeout​”        para zero. Isto instrui o switch a não remover fluxos baseando-se pelo        tempo. Entretanto, ainda é possível remover fluxos através de mensagens de        remoção​ ​vindas​ ​diretamente​ ​do​ ​controlador​ ​para​ ​o​ ​switch.   

Cookies são valores definidos pelo controlador para filtrar fluxos de        entrada. A cada fluxo pode ser atribuído um cookie. Isto permite ao        controlador realizar modificações e remoções de fluxo usando apenas seus        identificadores,​ ​além​ ​de​ ​possibilitar​ ​a​ ​coleta​ ​de​ ​dados​ ​estatísticos.  

As flags são usadas para informar como os fluxos de entrada são        gerenciados, como por exemplo, a flag “​OFPFF_SEND_FLOW_REM”,       ​aciona  mensagens​ ​de​ ​remoção​ ​para​ ​um​ ​determinado​ ​fluxo​ ​de​ ​entrada. 

O campo ação engloba um conjunto de passos que devem ser        realizados, pelo switch, para completar o ciclo de processamento do pacote.        Alguns exemplos de ações são: encaminhar ou descartar pacotes, inserir ou        remover​ ​tags,​ ​como​ ​vlans​ ​e​ ​mpls,​ ​etc.  

2.2.2

_{​ ​Versões​ ​do​ ​Protocolo​ ​OpenFlow}

No momento da escrita deste documento, o protocolo OpenFlow        encontra-se na versão 1.5.1, estando na iminência da liberação da versão        1.6. O OpenFlow vem continuamente evoluindo com o decorrer dos anos. A        cada versão, novas funcionalidades são integradas ao protocolo, o que        acarreta na necessidade da atualização de switches OpenFlow, pelos        fabricantes, para permitir o uso destas novas funcionalidades. Um switch        OpenFlow pode suportar diversas versões do OpenFlow que serão utilizadas        na negociação com o controlador. Por padrão, a versão OpenFlow que um        switch utilizará será a maior versão suportada tanto pelo controlador quanto        pelo switch em si. Caso haja falha na negociação da versão, a comunicação        não é estabelecida entre o controlador e o switch, ocasionando assim um        erro. Nas tabelas abaixo são apresentados as principais funcionalidades        adicionadas com o passar das versões OpenFlow. Não será detalhado neste        documento todas as funcionalidades acrescentadas, apenas algumas delas,       

pois estas informações podem ser encontradas facilmente na especificação        oficial​ ​do​ ​OpenFlow[1]. 

Tabela​ ​1.​​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.1 

Principais​ ​Recursos​ ​Adicionados​ ​na​ ​versão​ ​OpenFlow​ ​1.1   Múltiplas​ ​tabelas​ ​de​ ​Fluxo 

Tabelas​ ​de​ ​Grupo 

Suporte​ ​para​ ​tags​ ​MPLS​ ​e​ ​VLAN  Portas​ ​Virtuais 

A versão 1.1 do OpenFlow permitiu a elaboração mais detalhada do        processamento de pacotes, visto que esta nova versão possibilitou o uso de        múltiplas tabelas de fluxo, onde cada pacote poderia ser encaminhado para        uma outra tabela. Sendo assim, diversas instruções poderiam ser        empregadas sobre um mesmo pacote, onde cada instrução faria parte de        fluxos​ ​presentes​ ​em​ ​diferentes​ ​tabelas.  

As tabelas de grupo são formadas por ​action buckets​. Cada ​action              Bucket ​contém uma lista de ações a serem processadas. Quando um pacote        é direcionado para um determinado grupo, uma ou várias ​action buckets​, são            acionados e consequentemente cada uma das ações presentes nestes        buckets são processadas. A introdução desta nova funcionalidade permite,        como por exemplo, a implementação do mecanismo de multicast para        repasse dos pacotes, visto que um grupo poderia ser formado por diversas        ações na qual cada uma direcionasse um mesmo pacote para diferentes        portas de saída. Existem quatro tipos de grupos, cada um fornecendo uma        mecanismo diferente de execução dos ​action buckets​. Este quatro tipos de              grupos​ ​são​ ​apresentados​ ​a​ ​seguir. 

● _{ALL​: Executa todas as action buckets pertencentes um determinado}        grupo. O pacote ingressante é clonado para cada bucket. Este tipo de       

grupo é comumente usado para encaminhamento de pacotes multicast        ou​ ​broadcast.  

● _{Indirect​: Apenas uma action bucket pode fazer parte do grupo, sendo}        proibido​ ​a​ ​criação​ ​de​ ​outros​ ​buckets. 

● _{Select​: O grupo pode conter diversos buckets, mas apenas um destes}        será executado, onde a seleção do escolhido é feita através de        algoritmos externos ao OpenFlow, implementados pelo fabricante do        switch,​ ​como​ ​por​ ​exemplo,​ ​hash​ ​e​ ​round​ ​robin. 

● _{Fast Failover​: Processa o primeiro bucket que encontra-se apto para}        execução. Cada bucket contém um parâmetro especial que é associado        a uma porta e/ou grupo que monitora determinada porta. Se a porta        na qual o bucket encontra-se agregado não estiver ativa, este bucket        não é executado e assim sendo o bucket seguinte é verificado. Caso a        porta presente no bucket esteja levantada, este bucket será então        usado. Apenas um bucket pode ser executado no grupo, e este bucket        será​ ​executado​ ​até​ ​que​ ​a​ ​porta​ ​associada​ ​a​ ​ele​ ​encontre-se​ ​derrubada.  O acréscimo de tags VLAN e MPLS também foi introduzido nesta        versão. Instruções como inserção e remoção de tags a um cabeçalho        OpenFlow são reconhecidos por switches que suportem versões do protocolo        à​ ​partir​ ​da​ ​1.1. 

Embora o conceito de portas virtuais já existisse na versão 1.0 do        protocolo, o suporte a estas portas foi incrementado. As principais portas        virtuais​ ​reservadas​ ​para​ ​uso​ ​são: 

● _{ALL​. Este é um mecanismo usado para enviar um pacote para todas}        as portas presentes em um switch, com exceção da porta por onde o        pacote​ ​entrou. 

● _{CONTROLLER​. Encaminha um pacote diretamente para o controlador}        através de uma mensagem OpenFlow. Esta mensagem será tratada        como​ ​um​ ​evento​ ​de​ ​​Packet-In​​ ​no​ ​controlador. 

Tabela​ ​2.​​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.2 

Principais​ ​Recursos​ ​Adicionados​ ​na​ ​versão​ ​OpenFlow​ ​1.2  Extensão​ ​para​ ​casamento​ ​de​ ​padrões 

Extensão​ ​para​ ​reescrita​ ​de​ ​pacotes  Suporte​ ​ao​ ​IPv6 

Melhorias​ ​no​ ​Uso​ ​de​ ​Múltiplos​ ​Controladores   

Esta versão foi responsável por enriquecer o processo de casamento        dos pacotes, que se dá através do uso de um novo descritor chamado de       

OpenFlow Extensible Match    ​(OXM). Com o OXM é possível tratar vários novos        campos presentes no cabeçalho de um pacote que não eram tratáveis nas        versões anteriores. A nova lista de campos tratáveis é muito grande para ser        descrita neste documento, mas no geral qualquer campo utilizado para casar        com pacotes ethernet, como as VLANs, MPLS, IPV4 e IPv6 pode ser        facilmente​ ​manipulado​ ​e​ ​seus​ ​valores​ ​configurados​ ​com​ ​o​ ​uso​ ​do​ ​OXM. 

Nas versões anteriores, existia um suporte muito limitado para o uso        de múltiplos controladores. Quando um switch perdia conexão com um        controlador, este entrava em modo seguro de falhas ao invés de tentar        estabelecer conexão com um segundo controlador. Nesta versão é possível        que  um  switch estabeleça conexão com múltiplos controladores        simultaneamente, mas para que isto ocorra sem falhas, o switch deve        assegurar que apenas o controlador responsável por enviar um determinado        comando​ ​receba​ ​as​ ​mensagens​ ​desencadeadas​ ​pelo​ ​uso​ ​deste​ ​comando.   

Tabela​ ​3.​​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.3 

Principais​ ​Recursos​ ​Adicionados​ ​na​ ​versão​ ​OpenFlow​ ​1.3  Refatoramento​ ​da​ ​Negociação​ ​das​ ​Capacidades​ ​de​ ​um​ ​Switch  Suporte​ ​mais​ ​Flexível​ ​ao​ ​Table​ ​Miss  

Acréscimo​ ​de​ ​Campos​ ​Manipuláveis​ ​em​ ​um​ ​Cabeçalho​ ​IPv6  Métricas​ ​por​ ​Fluxo 

Suporte​ ​à​ ​Identificação​ ​de​ ​Fluxos​ ​via​ ​Cookies   

A refatoração da negociação teve como finalidade tornar mais flexível        as tabelas de um switch. Após este refatoramento, o switch que suportar a        versão 1.3 estará apto a utilizar métricas para medições, fluxos        especialmente criados para tratar pacotes que não foram emparelhados com        nenhum​ ​outro​ ​fluxo​ ​de​ ​uma​ ​tabela,​ ​ou​ ​​table​ ​miss​,​ ​entre​ ​outras. 

As métricas por fluxo são utilizadas para medir e controlar o fluxo de        pacotes que trafegam por uma determinada entrada da tabela. Uma das        suas principais aplicações está em limitar o tráfego que circula por um        determinado fluxo, onde pacotes serão descartados caso um determinado        valor,​ ​definido​ ​na​ ​configuração​ ​da​ ​métrica,​ ​seja​ ​atingido. 

O campo Cookie foi adicionado às mensagens de Packet-In com a        finalidade de facilitar na identificação do fluxo responsável por encaminhar        um​ ​determinado​ ​pacote​ ​para​ ​o​ ​controlador.  

Tabela​ ​4.​​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.4 

Principais​ ​Recursos​ ​Adicionados​ ​na​ ​versão​ ​OpenFlow​ ​1.4  Melhoramento​ ​na​ ​Descrição​ ​das​ ​Razões​ ​de​ ​um​ ​Packet-In 

Monitoramento​ ​de​ ​Fluxos 

Remoção​ ​Automática​ ​de​ ​Fluxos​ ​em​ ​Casos​ ​de​ ​Tabela​ ​Cheia  Sinalização​ ​de​ ​Avisos​ ​sobre​ ​Tabela​ ​Cheia   

Acréscimo​ ​de​ ​Novos​ ​Códigos​ ​de​ ​Erro   

Nas versões anteriores, o controlador recebia mensagens de Packet-In        vindas do switch, mas não havia descrição precisa sobre o motivo pelo qual o        pacote foi encaminhado para o controlador. Nesta versão, foi introduzido        quatro novos motivos para a geração de um Packet-In, além do caso de ​table        miss​. Alguns dos novos valores usados como argumento para um evento de        Packet-In​ ​são: 

● _{​ ​​OFPR_TABLE_MISS​:​ ​Usado​ ​quando​ ​ocorre​ ​um​ ​​table​ ​miss​.} 

● _{OFPR_APPLY_ACTION​: Valor configurado quando uma determinada}        ação determina o encaminhamento do pacote diretamente para o        controlador. 

● _{OFPR_INVALID_TTL​: O evento é gerado devido a existência de um}        TTL(Time​ ​to​ ​Live)​ ​inválido. 

● _{OFPR_GROUP​: O pacote foi encaminhado para o controlador após ter}        passado​ ​por​ ​um​ ​grupo​ ​de​ ​ações. 

Na versão 1.4 também foi introduzido o conceito de monitoramento de        fluxos. Esta nova habilidade permite o monitoramento, em tempo real, de        mudanças feitas por outros controladores a um conjunto de fluxos, que        foram definidos para monitoramento por um controlador. Quando qualquer        modificação ocorre em uma tabela ou conjunto de fluxos, o controlador que        encontra-se​ ​realizando​ ​o​ ​monitoramento​ ​é​ ​então​ ​informado. 

Todo switch é limitado a uma certa quantidade de entradas em uma        tabela de fluxos. Nas versões anteriores, quando este limite era atingido, o        switch ficava incapaz de incorporar novos fluxos, retornando assim um erro        para o controlador. Com esta versão 1.4, as tabelas de fluxo podem ser        configuradas, através do comando ​OFPTC_EVICTION​, para comportarem-se        de maneira diferente, eliminando fluxos com baixa prioridade para a        inclusão de novos fluxos. Além disso, a versão 1.4 também permite a        configuração das tabelas para geração de mensagens de aviso no momento        em​ ​que​ ​uma​ ​certa​ ​quantidade​ ​de​ ​fluxos​ ​for​ ​atingida. 

Tabela​ ​5.​​ ​Recursos​ ​extras​ ​na​ ​versão​ ​1.5 

Principais​ ​Recursos​ ​Adicionados​ ​na​ ​versão​ ​OpenFlow​ ​1.5  Tabelas​ ​de​ ​Saída 

Extensão​ ​das​ ​Estatísticas​ ​dos​ ​Fluxos​ ​de​ ​Entrada  Gatilho​ ​para​ ​Envio​ ​de​ ​Dados​ ​Estatísticos   

Comandos​ ​para​ ​Manipulação​ ​de​ ​Grupos     

Nas versões anteriores, o processamento dos pacotes ocorria no        contexto da porta de entrada. Com a introdução deste novo recurso, quando        um pacote for encaminhado para uma dada porta de saída, este irá ingressar        na primeira tabela de saída, e assim sendo, um novo processamento atuará        sobre o pacote. Uma tabela de saída pode redirecionar o pacote para outras        tabelas​ ​de​ ​saída,​ ​similarmente​ ​ao​ ​que​ ​ocorre​ ​às​ ​tabelas​ ​de​ ​entrada. 

A versão 1.5 introduziu novos parâmetros para o cálculo estatístico,        como por exemplo, a possibilidade de contabilizar o tempo ocioso dos fluxos,        bem como a quantidade de fluxos removidos em uma tabela. Consultas de        estatísticas consomem recursos e podem gerar sobrecarga nos switches.        Para tentar contornar isto, foi introduzido o conceito de acionamento        automático do envio de dados estatísticos direcionados para o controlador.       

Isto ocorre quando um ou mais limiares definidos pelo controlador são        alcançados. 

Nas versões anteriores a 1.5, as operações sobre os grupos alteravam o        conjunto inteiro de Buckets existentes internamente a um grupo. Com esta        versão, agora é possível inserir e remover Buckets específicos, ao invés de ter        que configurar toda vez um novo conjunto, que contivesse tanto Buckets        antigos quanto Buckets recém criados, para inserir ou remover        determinados Buckets. O comando OpenFlow usado para inserção de novos        Buckets é o ​OFPGC_INSERT_BUCKET enquanto que para remoção       

OFPGC_REMOVE_BUCKET​.  

2.2.3

_{​ ​Emparelhamento​ ​entre​ ​Pacotes​ ​e​ ​Fluxos​ ​de​ ​Entrada}

A figura 2.4 mostra a sequência de execução que um switch realiza        sobre o pacote de entrada. Cada campo presente no pacote é analisado e        emparelhado com cada fluxo pertencente a primeira tabela de entrada. Como        descrito na figura 2.3, diversos campos podem ser utilizados para análise,        onde no momento em que um pacote casa com um fluxo, um conjunto de        ações podem atuar sobre este pacote, onde cada ação dessa poderá alterar        campos de cabeçalho do pacote e empurrar o pacote para uma porta de        saída, por exemplo. O conjunto de ações designados para um pacote deve ser        responsável por desencadear uma mensagem de saída, repassando este        pacote para alguma porta de saída, pois caso contrário, ao final da execução        de todas as ações, o pacote será simplesmente descartado. Na figura abaixo        é possível visualizar todo o caminho seguido por um pacote, desde a sua        entrada​ ​até​ ​a​ ​saída.   

Figura​ ​2.4.​​ ​Fluxograma​ ​do​ ​processamento​ ​de​ ​pacotes​ ​em​ ​switches​ ​OpenFlow. 

  Fonte:​ ​Próprio​ ​autor. 

Nesta imagem é possível notar a presença de três cores de setas        diferentes. As setas com cor azul representam o caminho percorrido por        pacotes provenientes de uma tabela de entrada, ou seja, o caminho