Aplicação de técnicas de otimização para encaminhamento de pacotes em redes SDN e análises em cenários emulados

(1)

Faculdade de Engenharia Elétrica e de Computação

Juliane Regina de Oliveira

APLICAÇÃO DE TÉCNICAS DE

OTIMIZAÇÃO PARA ENCAMINHAMENTO

DE PACOTES EM REDES SDN E ANÁLISES

EM CENÁRIOS EMULADOS

Campinas

2019

(2)

UNIVERSIDADE ESTADUAL DE CAMPINAS

Faculdade de Engenharia Elétrica e de Computação

Juliane Regina de Oliveira

APLICAÇÃO DE TÉCNICAS DE OTIMIZAÇÃO PARA

ENCAMINHAMENTO DE PACOTES EM REDES SDN

E ANÁLISES EM CENÁRIOS EMULADOS

Dissertação apresentada à Faculdade de En-genharia Elétrica e de Computação da Uni-versidade Estadual de Campinas como parte dos requisitos exigidos para a obtenção do título de Mestra em Engenharia Elétrica, na Área de Engenharia da Computação.

Orientador: Prof. Dr. Akebo Yamakami

Este exemplar corresponde à ver-são final da tese defendida pela aluna Juliane Regina de Oliveira, e orientada pelo Prof. Dr. Akebo Yamakami

Campinas

2019

(3)

Biblioteca da Área de Engenharia e Arquitetura Rose Meire da Silva - CRB 8/5974

Oliveira, Juliane Regina de,

OL4a OliAplicação de técnicas de otimização para encaminhamento de pacotes em redes SDN e análises em cenários emulados / Juliane Regina de Oliveira. – Campinas, SP : [s.n.], 2019.

OliOrientador: Akebo Yamakami.

OliDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação.

Oli1. Engenharia de tráfego. 2. Otimização. 3. Redes definidas por

software (Tecnologia de rede de computadores). I. Yamakami, Akebo, 1947-. II. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III. Título.

Informações para Biblioteca Digital

Título em outro idioma: Optimization technique applied for packet routing in SDN network

and analysis in emulated scenarios

Palavras-chave em inglês:

Traffic engineering Optimization

Software Defined Networks (Computer Network Technology)

Área de concentração: Engenharia de Computação Titulação: Mestra em Engenharia Elétrica

Banca examinadora:

Akebo Yamakami [Orientador]

Christian Rodolfo Esteve Rothenberg Juliana Freitag Borin

Data de defesa: 11-03-2019

Programa de Pós-Graduação: Engenharia Elétrica

Identificação e informações acadêmicas do(a) aluno(a)

- ORCID do autor: https://orcid.org/0000-0002-0630-3083

- Currículo Lattes do autor: http://buscatextual.cnpq.br/buscatextual/visu

(4)

COMISS ˜AO JULGADORA - DISSERTA ¸C ˜AO DE MESTRADO

Candidata: Juliane Regina de Oliveira - RA: 192717 Data da Defesa: 11 de mar¸co de 2019

T´ıtulo da Disserta¸cão: ”Aplica¸cão de Técnicas de Otimiza¸cão para Encaminha-mento de Pacotes em Redes SDN e Análises em Cenários Emulados”.

Prof. Dr. Akebo Yamakami (Presidente, FEEC/UNICAMP) Profa. Dra. Juliana Freitag Borin (IC/UNICAMP)

Prof. Dr. Christian Rodolfo Esteve Rothenberg (FEEC/UNICAMP)

A ata de defesa, com as respectivas assinaturas dos membros da Comissão Julgadora, encontra-se no SIGA (Sistema de Fluxo de Disserta¸cão/Tese) e na Secretaria de Pós-Gradua¸cão da Faculdade de Engenharia Elétrica e de Computa¸cão.

(5)

(6)

Agradecimentos

A Deus por ter dado saúde e força para superar as dificuldades da vida.

Devo grande agradecimento e gratidão ao meu orientador professor Akebo Yama-kami por ter me aceitado como aluna de mestrado e depositado confiança em mim, pelos ensinamentos e tempo dedicados à dissertação. Tuas palavras são linhas mestres!

Ao professor Christian por ter me apresentado o Mininet-Wifi. Ramon Fontes pelo auxílio técnico da ferramenta Mininet-Wifi.

Aos membros titulares da banca de qualificação e defesa Juliana Freitag Borin e Christian Esteve Rothenberg pelas contribuições e enriquecimentos à dissertação.

Aos meus pais pelo apoio emocional, espiritual, financeiro e incondicional dados a mim. Tudo que sou devo a vocês. Sem sombra de dúvidas agradeço inha irmã Julia Carla por sua alma afetuosa que sempre me alegra e incentiva "Tú é trevo de quatro folhas

..."(Trevo (Tu) - Anavitória). Aos meus familiares pelo amor e incentivo durante os meus

estudos e ida a Campinas.

Aos membros do laboratório de pesquisa LE-16 pela companhia durante os estudos, café e bandejão, momentos de alegria e ajuda durante a caminhada.

(7)

Nunca me esquecerei desse acontecimento Na vida de minhas retinas tão fatigadas Nunca me esquecerei que no meio do caminho Tinha uma pedra Tinha uma pedra no meio do caminho No meio do caminho tinha uma pedra.” (No meio do caminho - Carlos Drummond de Andrade)

(8)

Resumo

Os métodos de engenharia de tráfego oferecem aos usuários das redes de computadores melhor desempenho no decorrer das atividades. A otimização de fluxo em redes apresenta como resultado os caminhos com os menores custos, as principais abordagens são: Dijkstra e o PFCM. A principal característica do paradigma de computação SDN é a separação do plano de controle e dados. Nas redes legadas, os softwares dos equipamentos são embutidos e fechados. A segregação dos planos permite aos administradores das redes melhor controle e gerenciamento da mesma por apresentar plano de controle aberto que possibilita criar regras de acordo com as políticas dos negócios, aumentando a flexibilidade. Os princípios de SDN sugiram nos anos 90 e passaram pelas seguintes etapas: (1) redes ativas, (2) separação do plano de dados e controle, (3) OpenFlow e os sistemas operacionais de rede. Atualmente as redes SDN apresentam evolução e contribuem para a melhora da engenharia de tráfego. Este trabalho pretende avaliar os caminhos obtidos, as taxas de vazão e o tempo de transferência dos fluxos de dados utilizando as seguintes propostas: algoritmo Dijkstra, algoritmo Dijkstra Modificado e o PFCM. Duas redes de computadores foram criadas utilizando uma ferramenta de emulação de redes SDN e um controlador central responsável pela determinação dos caminhos e a instalação das regras de fluxos nos equipamentos com suporte ao protocolo OpenFlow.

(9)

The Traffic engineering methods give computer networks users better performance in the course of their activities. The flow optimization in networks results in the paths with the lowest costs, the main approaches are: Dijkstra and PFCM. The main feature of the SDN computing paradigm is the separation of the control plane and data. In legacy network, the equipment software is embedded and closed. The segregation of the plans allows network administrators to better control and manage the plan by having an open control plan that enables them to create rules according to business policies, increasing flexibility. The principles of SDN suggest in the 1990s and went through the following steps: (1) active networking, (2) separating control and data planes, (3) OpenFlow and network operating systems. Currently SDN networks present evolution and contribution to the improvement of traffic engineering. This work aims to evaluate paths obtained, throughput rates and time of data flows transfer using the following proposals: Dijkstra algorithm, Modified Dijkstra algorithm and PFCM. Two computer networks were created using an SDN network emulation tool and a central controller responsible for determining the paths and the installation of the flow rules in the equipment with OpenFlow protocol support.

(10)

Lista de ilustrações

Figura 1 – Decomposição de Funções de Transporte - Adaptada (FORD et al., 2011) 21 Figura 2 – Middleboxes no novo modelo de Internet - Adaptada (FORD et al., 2011) 22 Figura 3 – Estabelecimento de uma Conexão MPTCP- Adaptada (POL et al., 2012) 23

Figura 4 – Arquitetura SDN - Adaptada (KREUTZ et al., 2015) . . . . 31

Figura 5 – Caminhos Calculados nos Algoritmos . . . 40

Figura 6 – Cenário 1 . . . 42

Figura 7 – Cenários 2 . . . 43

Figura 8 – Descrição do Funcionamento do Controlador . . . 49

Figura 9 – Resultados Dijkstra - Cenário 1 . . . . 51

Figura 10 – Resultados Dijkstra Modificado - Cenário 1 . . . 52

Figura 11 – Resultados PFCM - Cenário 1 . . . 53

Figura 12 – Resultados Dijkstra - Cenário 2 . . . . 54

Figura 13 – Resultados Dijkstra Modificado - Cenário 2 . . . 55

Figura 14 – Resultados PFCM - Cenário 2 . . . 56

Figura 15 – Gráfico Tempo de Transferência de 12000 Mbits Cenários 1 e 2 . . . . . 59

(11)

Tabela 1 – Informações do Grafo . . . 39

Tabela 2 – Informações do Cenário 1 Modificado . . . 44

Tabela 3 – Informações do Cenário 2 Modificado . . . 45

Tabela 4 – Vazão dos Caminhos - Cenário 1 . . . 58

Tabela 5 – Vazão dos Caminhos - Cenário 2 . . . 58

Tabela 6 – Valores de Comparação - Cenário 1 . . . 60

Tabela 7 – Valores de Comparação - Cenário 2 . . . 60

Tabela 8 – Informações do Cenário 1 Novo . . . 63

(12)

Lista de Acrônimos e Abreviações

AA Active Applications

AAA Authentication, Authorization e Accounting API Application Programming Interface

ATM Asynchronous Transfer Mode BGP Border Gateway Protocol

CAPWAP Control And Provisioning of Wireless Access Points CSPF Constrained-Shortest Path First

DCN Data Center Network

DEMS DEcoupled Multipath Scheduler DLB Dynamic Load Balancing

ECMP Equal-Cost Multipath Protocol EE Execution Environment

ET Engenharia de Tráfego

EU FIRE Future Internet Research and Experimentation Inittative GENI Global Environment for Networks Innovations

IETF Internet Engineering Task Force IP Internet Protocol

LBX Load balance X

LLDP Link Layer Discovery Protocol LTE Long Term Evolution

LWAPP Lightweight Access Point Protocol MPLS Multiprotocol Label Switching

(13)

NSF National Science Foundation NSF FIND Future Internet Design PC Personal Computer

PCM Problema de Custo Mínimo

PFCM Problema de Fluxo de Custo Mínimo QoE Quality of Experience

QoS Quality of Service RAN Radio Access Network RCP Routing Control Platform RTT Round Trip Time

SDN Software Defined Network

SDN-SAT Software Defined Naval Network for Satellite Communications SDWN Software Defined Wireless Network

SOL SDN Optimization Layer TCP Transmission Control Protocol TNG Transport Next-Generation ToR Top-of-Rack

ToS Type of Service Wi-Fi Wireless Fidelity

WMN Wireless Mesh Networks WSN Wireless Sensors Network WTR Wireless termination Points

(14)

Sumário

1 Introdução . . . 15

2 Fundamentação Teórica . . . 18

2.1 Engenharia de Tráfego . . . 18

2.2 MPTCP . . . 21

2.3 Redes Definidas por Software . . . 27

2.3.1 SDWN . . . 32

2.4 Problema de Transporte e Otimização de Redes . . . 35

2.4.1 Algoritmo Dijkstra . . . . 35

2.4.2 Algoritmo Dijkstra Modificado . . . . 35

2.4.3 PFCM . . . 37

2.4.4 Aplicação dos algoritmos e PFCM . . . 37

3 Aplicações em SDN . . . 41 3.1 Cenários Analisados . . . 41 3.2 Ferramentas Empregadas . . . 47 3.2.1 Mininet-Wifi . . . 48 3.2.2 Controlador Ryu . . . . 48 3.3 Resultados Obtidos . . . 50

3.4 Novos Cenários Analisados . . . 61

3.5 Resultados Obtidos . . . 65

4 Conclusões . . . 69

(15)

1 Introdução

A manutenção dos níveis aceitáveis de Quality of Service (QoS) nas redes de com-putadores sugere o emprego de otimização de processos de distribuição de tráfego nas redes. A QoS pode ser entendida como uma técnica utilizada para definir as necessidades das aplicações, como também um conjunto de tecnologias que possibilita às redes ofe-recerem garantias de desempenho. A Engenharia de Tráfego (ET) promove às redes de computadores aumento no desempenho na execução de aplicações por apresentarem as seguintes características:

∙ Análise dinâmica do tráfego; ∙ Predição do tráfego;

∙ Abordagem de regulação da transmissão dos dados.

O principal objetivo dos mecanismos de ET é o atendimento da demanda de trá-fego, através da otimização de uma métrica de desempenho. Os principais parâmetros de otimização nesta área são (MENDIOLA et al., 2017):

∙ Congestionamento; ∙ Atraso;

∙ Perda de pacotes; ∙ Consumo de energia;

∙ Quality of Experience (QoE); ∙ Utilização de Recursos.

As antigas técnicas de ET foram apresentadas no final de 1980 até aproximada-mente final de 1990. Estas soluções de ET, são desfavoráveis aos cenários atuais de redes de computadores pela falta de dinamicidade no gerenciamento das redes de computadores. Abaixo são listadas algumas destas técnicas:

∙ Asynchronous Transfer Mode (ATM): resolver o problema de controle de conges-tionamento e o nível de desempenho requeridas das diversas mídias (por exemplo, dados, voz e vídeo) (AKYILDIZ et al., 2014);

(16)

Capítulo 1. Introdução 16

∙ IP-QoS: o objetivo da ET é balancear a distribuição da carga e minimizar o consumo de banda larga. A variedade de multimídias resulta não apenas em diferentes requi-sitos de banda, mas também níveis de QoS, exemplo, atraso, jitter, probabilidade de perda de pacotes e consumo de energia (AKYILDIZ et al., 2014);

∙ Multiprotocol Label Switching (MPLS): o principal intuito da utilização desta técnica é a redução na análise e processamento do cabeçalho IP nos roteadores e assim melhorar o desempenho do roteamento (AKYILDIZ et al., 2014).

O desenvolvimento de Software Defined Network (SDN) é impulsionado para a resolução dos problemas enfrentados em ET (AKYILDIZ et al., 2014). As políticas de SDN para o controle e encaminhamento dos dados são aplicadas para a determinação do caminho que os pacotes percorrerão na rede. Os benefícios apresentados por SDN para a ET são (AKYILDIZ et al., 2014):

∙ Gerenciamento de fluxo de dados; ∙ Tolerância a falhas;

∙ Atualização da topologia; ∙ Análise do tráfego de dados.

Diversos trabalhos da literatura são compostos por ferramentas de SDN que ge-renciam os múltiplos caminhos na rede com a intenção de melhorar os fluxos de dados. Um algoritmo de balanceamento de fluxos, em uma aplicação , que define o caminho de custo mínimo inspirado no algoritmo de Dijkstra para o tráfego dos pacotes (OLI-VEIRA; SALLES, 2016). Mecanismos de balanceamento de carga e controle em redes SDN para múltiplos caminhos (KIM; FEAMSTER, 2013), (ASSUMPÇÃO et al., 2013), (RAMDHANI et al., 2016). Um mecanismo de múltiplos caminhos para arquitetura SDN (REZENDE et al., 2016). Uma ferramenta para a determinação de múltiplos caminhos em redes SDN para a manutenção dos níveis QoS (JINYAO et al., 2015). Um framework para otimização de recursos em redes SDN (HEORHIADI et al., 2016).

Objetivos simples da ET como a redução do congestionamento de enlaces pode ser resolvido através da formulação do fluxo máximo. (HEORHIADI et al., 2016), (DANNA

et al., 2012), (HONG et al., 2013), (JAIN et al., 2013).

O módulo MultiFlow permite que subfluxos de uma conexão Multipath

Transmis-sion Control Protocol (MPTCP) possam ser encaminhados em caminhos disjuntos. A

quantidade de subfluxos utilizados na rede deve ser igual ao número de caminhos disjun-tos disponíveis e todos os subfluxos devem ser roteados em diferentes rotas (SANDRI et

(17)

melhora no desempenho na entrega de vídeos produzidos pelo equipamento. Em redes

Wi-reless Fidelity (Wi-Fi) e Long Term Evolution (LTE) foram implantadas o MPTCP para

o planejamento e desenvolvimento de redes urbanas Wi-Fi (BAE et al., 2015). Em (GUO

et al., 2017), foi proposto o DEcoupled Multipath Scheduler (DEMS) para dispositivos

móveis que realiza o gerenciamento dos múltiplos caminhos.

O objetivo principal deste trabalho é propor a determinação e controle no enca-minhamento dos fluxos de pacotes com o menor custo em uma rede de computadores definida por software através de múltiplos caminhos. Os caminhos calculados pelas técni-cas de otimização de fluxo em rede: Dijkstra, Dijkstra Modificado e PFCM e também as taxas de vazão e o tempo de transferência dos fluxos de dados trafegados pelos caminhos definidos pelas abordagens estudadas serão avaliados e comparados. O controlador central do cenário foi o responsável por calcular os caminhos entre a origem e destino utilizando as abordagens apresentadas e a instalar as regras de encaminhamento nos equipamentos com suporte ao protocolo OpenFlow em cenários de emulação de redes SDN com dife-rentes configurações de redes. Apresentar os fundamentos teóricos empregados para o desenvolvimento do trabalho.

As principais contribuições deste trabalho são:

∙ Estudo das técnicas de otimização de fluxo em redes de computadores empregadas em cenários de redes SDN;

∙ Avaliação das taxas de vazão e tempo de transferência dos fluxos de dados trafegados nos caminhos previamente calculados;

∙ Desenvolvimento do controlador responsável pelo cálculo dos caminhos através das abordagens de otimização de fluxo em rede e instalação das regras de encaminha-mento dos pacotes.

O presente trabalho está organizado da seguinte maneira: capítulo 1, capítulo 2, capítulo 3, capítulo 4 e referências. O capítulo 1 apresenta a introdução de forma minun-ciosa o problema de pesquisa estudado e os objetivos da pesquisa realizada e contribuições teóricas do trabalho. O capítulo 2 é constituído pela fundamentação teórica dos seguintes tópicos: engenharia de tráfego, MPTCP, SDN e SDWN e técnicas de otimização explo-radas no trabalho, assim como um exemplo de aplicação em um grafo. O capítulo 3 é constituído pela apresentação dos cenários de redes SDN e os resultados obtidos nos ex-perimentos realizados. O capítulo 4 contém as conclusões contém as conclusões sobre o trabalho realizado e perspectivas futuras e por fim as Referências com os trabalhos utilizados como referências para o desenvolvimento da dissertação de mestrado.

(18)

18

2 Fundamentação Teórica

2.1 Engenharia de Tráfego

A ET é entendida como um mecanismo responsável por atender à demanda de tráfego dos diversos usuários da rede de computadores e promover QoS aos mesmos. Para atender a demanda de tráfego pode ser empregadas técnicas de otimização de tráfego em redes. Os principais parâmetros utilizados na otimização de redes na ET são listados (MENDIOLA et al., 2017):

∙ A redução do congestionamento e reserva de recursos são atingidas através das seguintes técnicas:

– Compartilhamento de recursos em múltiplos tráfegos por meio da minimização

da utilização dos enlaces da topologia resolvendo um problema tradicional de otimização. O principal objetivo é o balanceamento da carga, que resulta no melhor aproveitamento da rede.

– Negação de acesso para recursos congestionados. O sistema de ET deve detectar

quando a rede estiver congestionada e permitir o acesso aos recursos a medida que os recursos forem liberados.

∙ A diminuição do atraso nas redes de comutadores impacta na QoE. Este parâmetro é crítico principalmente para as aplicações em tempo real. A técnica mais comum é a Constrained-Shortest Path First (CSPF), onde o atraso é uma restrição para a seleção de um caminho na rede.

∙ A minimização da perda de pacotes pode ser obtida através de múltiplos caminhos na rede entre origem e destino do pacote, o tráfego é roteado nos caminhos disponíveis. A perda de pacotes pode ser ocasionada por falhas nos enlaces e dispositivos, desta maneira as técnicas de recuperação das capacidades são indicadas pelos mecanismos de ET;

∙ A redução do consumo de energia . O desempenho é atingido através da adaptação da carga de trabalho oferecida à rede ou reduzindo os recursos disponíveis. A energia é reduzida quando o fluxo da rede é transferido em caminhos menores ou ao desligar os equipamentos não utilizados na rede;

∙ A maximização da QoE: parâmetro que é afetado por todos os elementos envolvidos na transmissão, incluindo os dispositivos finais e fatores ambientais. Este parâmetro

(19)

requer a otimização do desempenho da rede. Maximizar a QoE não implica ne-cessariamente na maximização da taxa de transferência e uma correlação entre os critérios de QoE, os parâmetros de desempenho relacionados à rede precisam ser definidos.

∙ A Otimização da utilização dos recursos: A otimização da utilização de recursos é outro objetivo de desempenho.O espaço de buffer e largura de banda que precisam ser usados eficientemente, podem impactar o congestionamento e outros parâme-tros. A utilização dos recursos ajuda os operadores de rede a aumentar o número de demandas de serviço sem afetar seus custos, resultando uma boa utilização dos recursos de rede que permitem aos operadores de rede alocar uma quantidade maior de tráfego.A intenção é programar as transferências de dados de maneira caracteri-zada, podendo assim, os operadores de rede decidir a transmissão do tráfego entre vários data centers durante a noite, uma vez que mais recursos estão disponíveis na-quele momento sem afetar a disponibilidade de recursos aos usuários finais durante o período de trabalho.

Os principais benefícios da ET em SDN são apontados (AKYILDIZ et al., 2014): ∙ Gerenciamento de fluxo: Um switch OpenFlow ao receber um fluxo que não possui uma regra na entrada de fluxo no switch, o primeiro pacote do fluxo é encaminhado ao controlador. O controlador decide se é necessário instalar uma nova regra na tabela de fluxo do dispositivo de encaminhamento. Durante este processo podem haver alguns gargalos:

– A instalação desta regra de encaminhamento pode levar tempo e gerar atrasos; – A sobrecarga de tráfego no switch pode ocorrer devido a um número elevado

de novos fluxos, sendo necessário para o correto encaminhamento a instalação de regras de todos os fluxos

Algumas técnicas utilizadas para evitar estes problemas:

– balanceamento de carga;

– controle do balanceamento de carga; – tabelas de múltiplos fluxos;

∙ Tolerância à falha: a recuperação de falhas de forma transparente é uma grande missão nas redes de computadores para garantir confiabilidade da topologia. De acordo com as redes de operadoras, os mecanismos da ET devem fornecer rápida recuperação de falhas para detecção e recuperação de incidentes sem prejudicar os usuários. Os desafios para tolerância à falha são:

(20)

Capítulo 2. Fundamentação Teórica 20

– o switch poderia identificar o enlace com falha, e posteriormente definir uma

nova rota para o tráfego do fluxo. Entretanto, este processo deve ser rápido para que não ocorram perdas de pacotes. Os switches não possuem inteligência e conhecimento global da rede para calcular novos caminhos. Para tanto um elemento central, o controlador, é uma ferramenta indispensável para alcançar tolerância à falha;

– No momento, em que o nó com falha volta ao trabalho, ainda será

responsabi-lidade do controlador restabelecer a topologia da rede e as rotas ótimas para o tráfego em andamento.

A seguir uma lista de pesquisas atuais sobre mecanismos de tolerância a falhas em redes SDN:

– Plano de dados para tolerância à falha;

– Fatores que afetam a recuperação rápida de falhas: controlador centralizado e

protocolo OpenFlow;

– Plano de controle para tolerância à falha.

∙ Atualização da topologia: envolve as mudanças planejadas das políticas de redes. As operações gerais de atualização são implementadas da seguinte maneira: cada pacote ou fluxo é identificado ao atualizar a rede da política antiga para a nova política em um ou vários switches e, em seguida, cada pacote ou fluxo individual, pode ser tratado pela política antiga ou pela nova política, mas não pela combinação das duas. Envolvendo o problema de consistência entre: pacote ou fluxo. A consistência de pacote significa que cada pacote será processado por uma única configuração de rede. A consistência de fluxo significa que todos os pacotes no mesmo fluxo são manipulado pela mesma versão da política de fluxo.

Alguns desafios da atualização das regras da rede:

– Entradas de tabelas duplicadas nos switches; – Configuração baseada no tempo;

∙ Análise e caracterização do tráfego: envolve o desenvolvimento e estudo das ferra-mentas de monitoramento e gerenciamento de rede.

Abaixo seguem alguns exemplos de tecnologias para a análise do tráfego:

– Framework para monitoramento; – Verificação de invariante da rede; – Debugging de erros de programação.

(21)

2.2 MPTCP

O MPTCP possui os seguintes objetivos funcionais (FORD et al., 2011):

∙ Melhorar a vazão: o MPTCP suporta o uso simultâneo de múltiplos caminhos. Para atender aos incentivos mínimos de desempenho para implantação, uma conexão MPTCP por vários caminhos não deve alcançar uma pior taxa de transferência em relação a conexão TCP sobre o melhor caminho constituinte;

∙ Melhorar a resiliência: o MPTCP suporta o uso de múltiplos caminhos de forma intercambiável para fins de resiliência, permitindo que segmentos sejam enviados e reenviados em qualquer caminho disponível. No pior dos casos, o protocolo não deve ser menos resiliente do que o TCP de caminho único regular.

Aplicação Transporte Rede Funções de transporte - Application-oriented (Camada Semantic) Funções de transporte - Network-oriented (Camada Flow+Endpoint) TNG Camadas Existentes

Figura 1 – Decomposição de Funções de Transporte - Adaptada (FORD et al., 2011)

A Figura 1 apresenta uma possível arquitetura de transporte que suporta os ob-jetivos do MPTCP. O novo modelo de Internet descrito é baseado em Transport

Next-Generation (TNG). Embora não seja a única que suporta a funcionalidade de múltiplos

caminhos, o TNG separa a camada de transporte em camadas application-oriented e

network-oriented. A camada Semantic orientada a aplicativos implementa funções

orien-tadas a suporte e proteção fim-a- fim da comunicação, enquanto a camada orientada a rede Flow+Endpoint implementa funções como identificação de endpoint (usando número de porta) e controle de congestionamento (FORD et al., 2011).

A Figura 2 mostra os middleboxes interagindo com diferentes camadas dos serviços. Este modelo decomposto da camada de transporte, apresenta as seguintes camadas: a

(22)

Aplicação <--- end-to-end ---> Aplicação

<--- end-to-end --->

Semântica Semântica

Rede Rede Rede Rede

Flow+Endpoint Flow+Endpoint Flow+Endpoint Flow+Endpoint

Host Firewall ou Proxy Host

NAT

Figura 2 – Middleboxes no novo modelo de Internet - Adaptada (FORD et al., 2011)

camada orientada a aplicativo opera de ponta a ponta, enquanto a camada orientada a rede opera segmento por segmento e pode ser interposta por meio de caixas (FORD et

al., 2011).

O MPTCP atua na camada de transporte e visa a transparência para as camadas superior e inferior. Este protocolo apresenta funcionalidades adicionais ao protocolo TCP, que permite aos usuários a criação de subfluxos entre caminhos potencialmente disjuntos. O protocolo descobre o número de caminhos disponíveis e distribui o tráfego entre esses caminhos. As operações de funcionamento do protocolo estão descritas (FORD et al., 2013):

∙ Para um aplicativo não compatível com MPTCP, o MPTCP se comporta como TCP tradicional. APIs estendidas poderiam fornecer controle adicional para aplicações compatíveis com o MPTCP. Uma aplicação começa abrindo um socket TCP no modo normal. Sinalização MPTCP e operação são manipulados pela implementação do MPTCP;

∙ Uma conexão MPTCP começa de forma semelhante a uma conexão TCP regular. A conexão MPTCP é estabelecida entre os endereços do host de origem e destino; ∙ Se houver caminhos extras disponíveis, sessões TCP adicionais (subfluxos) são

cri-ados nesses caminhos e são combincri-ados com a sessão existente, que continua a aparecer como um única conexão com as aplicações em ambas as extremidades;

(23)

∙ MPTCP identifica múltiplos caminhos pela presença de múltiplos endereços em

hosts. Combinações desses múltiplos endereços equivalem aos caminhos adicionais;

∙ A descoberta e configuração de subfluxos adicionais serão alcançados através de um método de gerenciamento de caminho;

∙ MPTCP adiciona números de sequência ao nível da ligação para permitir remon-tagem de segmentos que chegam em múltiplos subfluxos com diferentes atrasos de rede.

SYN: MP_CAPABLE - [KEY - FLAGS]

ACK: MP_CAPABLE - [KEY A - KEY B - FLAGS] SYN ACK: MP_CAPABLE - [KEY - FLAGS]

CLIENTE

_SERVIDOR

IP_A1

_{IP_B1}

IP_A2

SYN ACK: MP_JOIN - [MAC - NONCE - ID - FLAGS]

_{IP_B2}

SYN: MP_JOIN - [TOKEN - NONCE - ID - FLAGS]

ACK: MP_JOIN - [MAC] ACK

Figura 3 – Estabelecimento de uma Conexão MPTCP- Adaptada (POL et al., 2012)

A Figura 3 apresenta o estabelecimento de uma conexão MPTCP. O cliente MPTCP inicia uma conexão de modo similar à conexão TCP com a seguinte sequência: SYN, SYN

ACK e ACK. A diferença é que o cliente e o servidor com funcionalidades MPTCP

adi-ciona a opção MP_CAPABLE à sequência de pacote da inicialização da conexão TCP. Esta opção também contém chave de autenticação (KEY) e algumas FLAGS para indicar se somas de verificação são necessárias e o algoritmo criptográfico para usar. O cliente envia um SYN MP_CAPABLE para o servidor contendo KEY (IP_A1) e FLAGS. O servidor responde com um SYN MP_CAPABLE contendo KEY (IP_B1)e FLAGs. O cliente retorna um ACK MP_CAPABLE com KEY (IP_A1), (IP_B1) e FLAGS (POL

et al., 2012).

Nesta Figura 3 contém o estabelecimento de um novo subfluxo. A inicialização da conexão é de modo similar à conexão TCP com a seguinte sequência: SYN, SYN

ACK e ACK. Entretanto ocorre particularidades em relação a conexão TCP e a opção

MP_CAPABLE, nesta conexão é acrescentada a opção MP_JOIN também são adiciona-das um TOKEN, um MAC, um número randômico (NONCE), um endereço de identifica-ção (ID) e FLAGS. O TOKEN é o responsável por identificar a conexão, este valor é um

hash criptográfico SHA-1, o cliente envia ao servidor para a identificação da conexão. O

MAC é uma mensagem de autenticação hash SHA-1. O NONCE é utilizado para impedir ataques de repetição no processo de autenticação. O ID é um identificador do endereço origem. As FLAGS podem ser usadas pelo remetente para informar ao outro servidor para usar este subfluxo somente para backup quando outros caminhos falharem, ou que o subfluxo deve ser usado imediatamente. O cliente envia inicialmente SYN MP_JOIN

(24)

com TOKEN (IP_A2), NONCE (IP_A2), ID (IP_A2) e FLAGS. Quando o servidor re-cebe o SYN MP_JOIN do cliente, o servidor envia MAC (IP_B2), NONCE (IP_B2), ID (IP_B2). O cliente responde com ACK MP_JOIN MAC (IP_A2). O servidor confirma com ACK (POL et al., 2012).

Em (HUSSEIN et al., 2017), o protocolo MPTCP aumenta o desempenho da trans-ferência dos dados das aplicações para agregar largura de banda em múltiplos caminhos usando subfluxos de uma conexão TCP. O protocolo de múltiplos caminhos apresenta as seguintes limitações:

∙ é um protocolo sem controle sobre as rotas de rede, e os subfluxos podem acabar passando pelos mesmos enlaces;

∙ falta de controle dinâmico na escolha do número de subfluxos para alcançar a má-xima vazão;

∙ a performance pode ser degradada devido ao grande número de fluxos em caminhos heterogêneos atravessados.

Para transferir uma grande quantidade de dados existentes, precisa-se utilizar efi-cientemente a capacidade de rede disponível, a partir de vários caminhos disponíveis. O MPTCP é o responsável, nos hosts finais, por distribuir o tráfego entre os caminhos. O MPTCP é uma nova abordagem para o balanceamento de carga. O protocolo pode ma-nipular caminhos de largura de banda diferentes por causa de um mecanismo de controle de congestionamento nos subfluxos. O mecanismo de controle de congestionamento move o tráfego em um caminhos congestionados para um enlace com menos congestionamento (POL et al., 2012).

A topologia utilizada, em (POL et al., 2012), possui múltiplos caminhos entre os servidores. Os dispositivos de encaminhamento (switches) são controlados pelo OpenFlow por meio de um aplicativo. O aplicativo realiza as seguintes atividades:

∙ Detecta automaticamente a topologia através dos pacotes Link Layer Discovery

Protocol (LLDP) recebidos via OpenFlow;

∙ Calcula caminhos disjuntos entre os servidores. As entradas de encaminhamento ne-cessárias para os caminhos são enviadas aos comutadores. O MPTCP nos servidores pode utilizar vários caminhos simultaneamente.

A topologia de rede e o mecanismo de roteamento interferem no desempenho e latência da rede. A topologia Fat-tree é uma das mais utilizadas para data center. Para alcançar alto desempenho e baixa latência, foi implementado um algoritmo de roteamento

(25)

dinâmico no balanceador de carga baseado no OpenFlow. A tarefa do roteamento dinâ-mico é distribuir o tráfego da rede para que cada caminho alternativo receba a mesma quantidade de tráfego. A topologia de árvore hierárquica de três camadas que consiste em

switches nas camadas core (superior), aggregation (intermediária) e Top-of-Rack (ToR)

(inferior). Os hosts se conectam aos switches na camada ToR. O recurso multipath de redes Fat-Tree permite a distribuição do tráfego de dados em diferentes componentes de rede (LI; PAN, 2013).

O algoritmo Dynamic Load Balancing (DLB), agenda os fluxos com base nas es-tatísticas atuais da rede. Esse algoritmo funciona da seguinte maneira (LI; PAN, 2013):

∙ Quando o controlador OpenFlow recebe um pacote de um switch, ele altera o controle para o balanceador de carga;

∙ Inicialmente, o balanceador de carga analisa as informações: porta de entrada do comutador, endereço de origem e o endereço de destino do pacote;

∙ Depois que os hosts de origem e destino estiverem localizados, o balanceador de carga calcula a camada superior que o fluxo precisa acessar. Um sinalizador de direção de pesquisa é utilizado com dois valores: 1 para cima e 0 para baixo; ∙ O sinalizador é inicializado como 1. Um caminho é criado para salvar uma rota

agrupada por uma lista de comutadores. Um método para a pesquisa de caminhos recursivamente é chamada no algoritmo. O algoritmo de pesquisa apresenta os se-guintes passos:

– Em primeiro lugar, adiciona o switch atual ao caminho. Ele retorna o caminho

se a pesquisa atual atingir a camada inferior. Ele inverte a direção da pesquisa se a pesquisa atual atingir a camada superior;

– Em seguida, ele chama um método que retorna todos os enlaces no switch atual

que estão em direção a corrente de pesquisa. O enlace de pior ajuste com a largura de banda máxima disponível é escolhido. E então o objeto atual do

switch é atualizado;

– O método de pesquisa é chamado recursivamente camada por camada da

ori-gem ao destino. Por fim, o caminho será retornado ao balanceador de carga. As informações do caminho serão usadas para atualizar tabelas de fluxo desses comutadores no caminho.

O MPTCP aumenta a taxa de transferência de dados pela agregação de largura de banda em vários caminhos. O desempenho da rede pode degradar devido ao grande número de pacotes em desordem, principalmente nas situações em que os caminhos têm diferentes atrasos. Como solução do problema, foi proposto um aplicativo capaz alterar

(26)

dinamicamente os múltiplos caminhos com o aproveitamento de SDN. A solução adotada analisa a capacidade disponível dos caminhos conectados e escolhe os caminhos mais apropriados, dependendo das condições da rede. A maximização das taxas de download foi realizada através do ajuste dinâmico do número de caminhos MPTCP dependendo da capacidade disponível no link da rede (NAM et al., 2016).

As redes modernas utilizam o roteamento de múltiplos caminhos para dividir os fluxos entre vários caminhos. Alguns exemplos apresentam os subfluxos direcionados para o mesmo caminho. O roteamento de QoS também apresenta grandes desafios devido à complexidade da otimização de caminhos de múltiplos objetivos e ao tratamento de soli-citações de conexão, garantindo que todos os requisitos sejam atendidos. O procedimento proposto de duas fases para obter caminhos disjuntos de k-max min QoS combinados com o processo de hierarquia analítica em um ambiente SDN (DOSHI; KAMDAR, 2018).

O MPTCP permite que os fluxos de dados sejam trafegados em caminhos dife-rentes. Em diversas redes de computadores o Equal-Cost Multipath Protocol (ECMP) é utilizado para a criação de múltiplos caminhos, entretanto o encaminhamento dos fluxos pode ocorrer no mesmo caminho por utilizar um hashing estatístico, não é garantido conti-nuamente os múltiplos caminhos (SANDRI et al., 2015b). O uso do ECMP em topologias de vários estágios faz com que os fluxos colidam em pelo menos um enlace com alta pro-babilidade. Neste trabalho a utilização do MPTCP se mostrou mais eficiente em relação a uma conexão TCP em DC. Nas topologias com caminhos redundantes e hosts MPTCP, a rápida mudança de roteamento após detecção falhas seja menos crítica (RAICIU et al., 2011).

A implementação do MPTCP foi realizada a partir de uma atualização do kernel Linux.1_{, resultando em uma alteração do protocolo TCP. Esta alteração deve ser realizada}

nos hosts finais da topologia, ou seja, aqueles que devem enviar e receber os dados e que se almeja um melhor desempenho nas transferência de pacotes.

(27)

2.3 Redes Definidas por Software

Os dispositivos tradicionais de rede de computadores de uso comercial possuem as seguintes características: software fechado e hardware proprietário. Este fato causa um grande impacto na evolução da computação. A internet nas últimas décadas sofreu grandes transformações, entretanto, estas mudanças poderiam ser maiores, caso a topologia não fosse engessada. Os equipamentos possuem integração vertical, ou seja, os planos de dados e controle juntos em um mesmo software (ROTHENBERG et al., 2010).

A ideia principal de SDN é a introdução de uma abstração entre os planos de encaminhamento e controle para separá-los e fornecer aplicações com os meios necessários para controlar programaticamente a rede (HALEPLIDIS et al., 2015). A programação de redes de computadores tornou possível a inovação no gerenciamento das redes e a possibilidade da implantação de novos serviços. A história da programação das redes de computadores é dividida da seguinte maneira (FEAMSTER et al., 2014):

∙ Redes ativas;

∙ Separação do plano de dados e controle;

∙ API do OpenFlow e os sistemas operacionais de rede.

As Redes ativas, em meados da década de 1990, a internet obteve um maior público através do tráfego de diversas aplicações: transferência de arquivos, e-mail, entre outras. Todavia, este evento ocasionou a atenção dos pesquisadores para implantação de novas ideias para melhorar o fluxo dos serviços, impulsionando o desenvolvimento de novos protocolos em redes de pequena e grande escala, mas a padronização dos protocolos é um processo lento. Alguns pesquisadores buscaram uma abordagem nativa para o controle da rede baseado na analogia de reprogramar um Personal Computer (PC). A ideia de controle de rede a partir de uma interface de programação que expunha os recursos em nós de redes individuais apoiou a construção de funcionalidades personalizadas para aplicar a um subconjunto de pacotes de um nó.

O programa de redes ativas explorou ações alternativas aos serviços prestados pela tradicional pilha Internet Protocol (IP) ou pelo ATM, comum no período. A rede ativa foi a primeira de uma série de abordagens inovadoras para a arquitetura de rede subsequente aos projetos: Global Environment for Networks Innovations (GENI), Future

Internet Design (NSF FIND), e Future Internet Research and Experimentation Inittative

(EU FIRE). .

A comunidade de redes ativas desenvolveu dois modelos de programação: modelo de cápsula e modelo programável de roteador/switch. O Modelo cápsula é caracterizado por apresentar código transportado em banda nos pacotes de dados a ser executado no

(28)

nós. O segundo modelo é caracterizado por apresentar código estabelecido por mecanismos

out-of-band.

A grande parte da versão inicial do SDN se concentrava na programação do plano de controle, enquanto as redes ativas na programação do plano de dados. A experimen-tação do suporte com vários modelos de programação levou o desenvolvimento da vir-tualização de rede. A rede ativa produziu uma estrutura arquitetônica que descreve os componentes dessa plataforma: Node Operating System (NodeOS) gerencia recursos com-partilhados, Execution Environment (EE) cada um dos quais define uma máquina virtual para operações de pacotes, Active Applications (AA) funciona dentro de um determinado EE para fornecer um serviço de ponta a ponta. Direcionar pacotes para um EE específico depende da correspondência rápida de padrões nos campos do cabeçalho e da desmulti-plexação para o apropriado EE. Exemplo: PlanetLab. Visão de uma arquitetura unificada para orquestração de middlebox, em documentos de projetos iniciais citaram a necessidade de unificar a ampla variedade de funções middlebox com uma estrutura de programação, embora, não sendo possível a criação de uma visão unificada da rede.

No início dos anos 2000, ocorreu o aumento do tráfego de dados e posteriormente um maior destaque na confiabilidade, previsibilidade e desempenho da rede levaram as operadoras de rede a buscarem melhores abordagens para certas funções de gerenciamento de rede, por exemplo controle sobre os caminhos usados para entregar o tráfego, sendo este procedimento chamado ET.

Os protocolos de roteamento utilizados para ET eram simples. Os pesquisado-res exploraram abordagens pragmáticas de curto prazo que eram orientadas por padrões iminentemente implantáveis usando protocolos existentes. Os roteadores e switches con-vencionais incorporaram uma forte integração entre os planos de controle e dados. Esse acoplamento produziu várias funções de gerenciamento de rede, entretanto as seguintes atividades ainda eram desafiadoras: depuração de problemas de configuração e previsão ou controle de comportamento de roteamento. Para enfrentá-los vários esforços para a

separação dos planos de dados e controle começaram a ser desenvolvidos.

O grupo de trabalho do ForCES no Internet Engineering Task Force (IETF) pro-puseram uma interface aberta padrão para o plano de dados para permitir a inovação no software do plano de controle fornecendo o controle logicamente centralizado usando uma interface aberta para o plano de dados. Infelizmente o ForCES não foi adotado pe-los principais fornecedores de roteadores. O Routing Control Platform (RCP) usava um protocolo de plano de controle padrão existente o Border Gateway Protocol (BGP) para instalar entradas de tabela de encaminhamento em roteadores legados, permitindo a im-plantação imediata. O SoftRouter utilizou a Application Programming Interface (API) do ForCES para permitir que um controlador separado instalasse entradas da tabela de enca-minhamento no plano de dados, possibilitando a remoção completa da funcionalidade de

(29)

controle dos roteadores. O OpenFlow também enfrentou desafios de compatibilidade retro-ativa semelhantes e algumas restrições: em particular, a especificação inicial do OpenFlow dependia da compatibilidade retroativa com os recursos de hardware de switches.

Um controlador logicamente centralizado deve ser replicado para lidar com a falha do controlador principal, mas a replicação introduz os potenciais para o estado inconsis-tente entre as réplicas, havendo, desta forma, problemas para o gerenciamento de estado distribuído. No controle de roteamento, as réplicas do controlador não precisavam de um protocolo de gerenciamento de estado geral, pois cada réplica acabaria computando as mesmas rotas. Para melhor escalabilidade, cada instância do controlador poderia ser responsável por uma parte separada da topologia. Essas instâncias do controlador, pode-riam então, trocar informações de roteamento entre si para garantir decisões consistentes. Controladores SDN distribuídos enfrentam o problema muito mais geral de suportar apli-cativos de controladores arbitrários, exigindo sofisticadas soluções para gerenciamento de estado distribuído.

O OpenFlow levou à noção de sistema operacional de rede. Um sistema

operacional de rede é um software capaz de abstrair a instalação de estado em comutadores de rede lógica e aplicativos que controlam o comportamento da rede.

Nos anos 2000, pesquisadores e agências de fomento se interessaram pela ideia de implantação de programação em uma rede de escala maior, incentivados pelo sucesso de infraestruturas experimentais (PlanetLab e Emulab) e pela disponibilidade do financia-mento global. Um exemplo foi a criação do GENI, projeto financiado pelo National Science

Foundation (NSF) e o programa EU FIRE. Em meio a estes ambientes, um grupo de

pes-quisadores de Stanford criou o Programa Clean State e implantou redes em um local com escala tratável: redes de campus (MCKEOWN et al., 2008). Antes do surgimento do

OpenFlow, as ideias subjacentes à SDN enfrentaram uma tensão entre a visão de redes

totalmente programáveis e o pragmatismo que permitiu a implantação no mundo real. O

OpenFlow possibilitou mais funções do que os controladores de rotas e construiu o hard-ware de switch. O desenvolvimento da API do OpenFlow foi seguida rapidamente pelo

design de plataforma de controle como NOX 2 que permitiu a criação de muitos novos

aplicativos de controle.

O switch OpenFlow é constituído pelos seguintes elementos:

∙ Tabela de regras de manipulação de pacotes onde cada regra tem um padrão que corresponde aos bits no cabeçalho do pacote, lista de ações (apagar, inundar, en-caminhar uma interface específica, modificar um campo de cabeçalho ou enviar o pacote para o controlador);

∙ Contadores para rastrear o número de bytes e pacotes;

(30)

∙ Prioridade para desempatar entre as regras com padrões sobrepostos. Ao receber um pacote, um switch OpenFlow identifica a regra de correspondência de maior prioridade, executa as ações associadas e incrementa os contadores.

Anteriormente o controle de rotas se concentrava principalmente no tráfego corres-pondente ao prefixo IP de destino. Em contraste, as regras do OpenFlow podem definir o comportamento de encaminhamento nos fluxos de tráfego com base em qualquer conjunto de 13 cabeçalhos de pacote diferentes. O OpenFlow unificou conceitualmente diferentes dispositivos de rede que diferem apenas em termos de quais campos de cabeçalho eles correspondem e quais ações eles executam.

O OpenFlow também generalizou as técnicas de instalação de regras, permitindo desde a instalação proativa de regras de coarse-grained (ou seja, com "wildcards"para mui-tos campos de cabeçalho) até a instalação reativa de regras de fine-grained, dependendo da aplicação. Ainda assim, o OpenFlow não oferece suporte a planos de dados para inspe-ção profunda de pacotes ou remontagem de conexões, sendo assim o protocolo não pode habilitar de forma eficiente a funcionalidade sofisticada de middlebox.

Decomposição conceitual da operação da rede em três camadas: plano de dados com uma interface aberta; camada de gerenciamento de estado responsável por manter uma visão consistente do estado da rede; lógica de controle que realiza várias operações dependendo de sua visão do estado da rede.

O paradigma de computação SDN desfaz a integração vertical dos planos de dado e controle. A arquitetura SDN apresenta as seguintes camadas (KREUTZ et al., 2015):

∙ Gerenciamento: o conjunto de aplicações que permitem customização ou implemen-tação dos serviços de rede;

∙ Controle: controladores baseados em software que possuem a visão global da rede e que gerenciam as políticas de encaminhamento de pacotes;

∙ Dados: contém o plano de encaminhamento de pacotes e executam as ações dos controladores.

A Figura 4 apresenta de maneira resumida as camadas da arquitetura. A ordenação das camadas da arquitetura é considerada de cima para baixo. A primeira camada repre-senta a camada de Gerenciamento. A segunda camada reprerepre-senta a camada de Controle e a terceira camada a camada de Dados.

O plano de gerenciamento é localizado em um hardware baseado em software, apre-sentando um conjunto de instruções, por exemplo, criação de regras de fluxos responsáveis pela tomada de decisões a respeito dos pacotes recebidos. Estas instruções são construí-das na interface Southbound que fornece a interligação entre os elementos de controle e

(31)

Plano de Gerenciamento

Plano de Controle

Plano de Dados

Figura 4 – Arquitetura SDN - Adaptada (KREUTZ et al., 2015)

encaminhamento. No plano de dados, os dispositivos de encaminhamento são interligados através de cabos ou sem fio. A interface Southbound apresenta um conjunto de instruções dos dispositivos de encaminhamento. O plano de controle é definido como a inteligência da rede de computadores sendo encontrado nas aplicações e controladores. A interface

Northbound realiza a comunicação entre o plano de gerenciamento e o plano de controle

permitindo que aplicações efetuem o controle e o monitoramento das funções de rede. O plano de gerenciamento é o conjunto de aplicativos que implementa controle e opera-ção de rede lógica, por exemplo, roteamento, balanceamento de carga e monitoramento (KREUTZ et al., 2015).

Apresentado em (KIM; FEAMSTER, 2013), o framework de controle de redes de computadores baseado em SDN, denominado Procera, utilizando quatro domínios de controle da rede:

∙ Tempo;

∙ Dados usados;

∙ Status de autenticação; ∙ Tráfego.

O protocolo utilizado para a comunicação entre o controlador Procera e os switches da rede subjacente foi o OpenFlow. Os resultados dos experimentos de validação mostram que o controlador Procera é viável por apresentar possibilidades para a implementação de

(32)

um conjunto mais rico de políticas de rede e reduzir significativamente a complexidade do gerenciamento de rede em uma variedade de configurações de rede e para uma série de políticas de rede.

O método de balanceamento de carga, proposto por (RAMDHANI et al., 2016), possibilita a alta utilização de banda larga nos enlaces, além disso avalia o tráfego na rede e atualiza as informações estatística de cada switch do cenário. O controle de admissão possibilita que um determinado fluxo seja ou não trafegado na rede de computadores, através da análise do fluxo de dados, sendo que, ao exceder a capacidade suportada pelo enlace, o fluxo não seja mais aceito na rede.

O módulo desenvolvido por (REZENDE et al., 2016), ramifica os fluxos de redes de computadores com o intuito de atender à demanda por largura de banda. A vazão e atraso do fluxo são analisados através de consultas aos contadores OpenFlow. O algoritmo de Dijkstra foi utilizado para a determinação de um ou vários caminhos mínimos entre a origem e destino da comunicação. Desta forma, quando um usuário faz uma solicitação de uma taxa de transferência, o algoritmo calcula o caminho e a largura de banda do caminho a serem utilizados, se a largura de banda calculada for menor que a solicitada pelo usuário, então o valor calculado é decrementado do total solicitado, o algoritmo é executado até quando tiver caminhos disponíveis entre a origem e destino ou taxa de transferência solicitada restante.

O gerenciamento de SDN (por exemplo, ET, encadeamento de serviços e reconfi-guração da topologia) envolve otimização complexa de recursos, sendo este o problema central. O framework SDN Optimization Layer (SOL) pode resultar eficientemente em soluções próxima do ótimo e configurar o dispositivo para implementá-las. A resolução do problema de otimização envolve esforço manual e expertise para expressá-lo e computação não-trival para resolução da heurística(HEORHIADI et al., 2016).

O mecanismo, chamado P2PFlow, de balanceamento de carga em redes de compu-tadores SDN par-a-par através de múltiplos caminhos, foi elaborado por (ASSUMPÇÃO

et al., 2013). Nesta abordagem que balanceia a carga utilizando múltiplos caminhos, os

fluxos de informações são quebrados em subfluxos, com o intuito de prover o tráfego destes fluxos menores em diferentes caminhos.

2.3.1 SDWN

As Software Defined Wireless Network (SDWN) apresentam os mesmos aspectos do paradigma SDN cuja característica principal é a separação entre os planos de dados e controle sendo necessário a programação das redes de computadores.

Um fator importante que afeta SDWN é o protocolo OpenFlow, responsável pela comunicação entre as portas dos switches e o controlador, não há especificidade para o

(33)

tratamento das regras de fluxos nas redes sem fio, em que é averiguado vários usuários associados a um ou vários pontos de acessos, dificultando a criação das regras nas tabelas de fluxos que se baseiam em portas de entrada e saída de fluxo.

Vários exemplos de protocolos habilitam a separação entre os planos de dados e controle em redes sem fio, por exemplo, Control And Provisioning of Wireless Access

Points (CAPWAP) e Lightweight Access Point Protocol (LWAPP). O LWAPP é um

proto-colo genérico que define como os Wireless termination Points (WTR) se comunicam com o controlador de acesso. O CAPWAP é um protocolo que possibilita a um controlador de acesso gerenciar uma coleção de WTR.

O Framework Odin introduziu a programação em redes wireless. Este ambiente fornece as seguintes funcionalidades (SURESH et al., 2012):

∙ Authentication, Authorization e Accounting (AAA); ∙ Gerenciamento de políticas;

∙ Mobilidade;

∙ Gerenciamento de interferências; ∙ Balanceamento de carga.

A arquitetura Odin consiste nos seguintes elementos (SURESH et al., 2012): ∙ O nó mestre implementa um controlador OpenFlow (plano de controle). Ele possui

uma visão global dos fluxos na rede, clientes e topologia;

∙ Múltiplos agentes implementados nos pontos de acesso da rede. Uma conexão

Trans-mission Control Protocol (TCP) é estabelecida na inicialização entre o agente e o

mestre. Ele serve como canal de controle e é usado pelo mestre para efetuar coman-dos nos agentes e coletar estatísticas;

∙ As aplicações implementam os serviços de rede através das interfaces expostas pelo mestre.

Em Wireless Sensors Network (WSN), foi proposto uma arquitetura chamada Te-net que propõe a divisão da arquitetura de WSN em camadas que dissocia o plano de controle dos sensores (PAEK et al., 2010). Em (YAP et al., 2010), foi apresentado uma arquitetura OpenSource chamada OpenRoads com uma extensão do OpenFlow incorpo-rando tecnologias wireless: WiMax e Wi-Fi. Esta arquitetura é formada por três camadas: fluxo, slicing e controle. Foi desenvolvido uma arquitetura que integra o OpenFlow em

Wireless Mesh Networks (WMN) e fornece esses recursos de roteamento e

(34)

nova arquitetura para WSN definida por software, cujo objetivo é abordar os principais desafios em relação ao sensor OpenFlow.

Em (JIN et al., 2013), foi proposto o SoftCell uma arquitetura para redes de núcleo cellular. Esta arquitetura é formada pelas seguintes técnicas:

∙ Agregação muti-dimensional: reduz o tamanho das tabelas do switch agregando entradas ao longo das múltiplas dimensões, combinando os benefícios do roteamento baseado em localização e tags;

∙ Borda de acesso smart e borda de gateway dumb: o SoftCell executa toda a classi-ficação de pacotes na borda de acesso, usando software de switches e controladores locais ao invés de classificá-los no gateway de borda. O SoftCell adiciona no cabe-çalho dos pacotes IP um identificador de política no gateway de borda para evitar a reclassificação do tráfego de retorno.

O SoftRAN é um plano de controle centralizado definido por software para redes de acesso de rádio que abstrai todas as estações base em uma área geográfica local como uma estação virtual de base grande. O objetivo principal desta ferramenta é promover as características listadas na Radio Access Network (RAN) (GUDIPATI et al., 2013):

∙ Atribuir recursos de rádio; ∙ Implantar handovers; ∙ Gerenciar interferência;

(35)

2.4 Problema de Transporte e Otimização de Redes

O problema de transporte é uma classe especial de programação linear que trata do envio de uma mercadoria de origens para destinos. O objetivo é determinar a programação que minimize o custo total de expedição e satisfaça os limites de fornecimento e demanda dos vértices. O limite de fornecimento é definido pela capacidade da aresta do grafo, o fluxo a ser transferido não deve ultrapassar este limite configurado. A demanda se refere a quantidade do fluxo de dados que o vértice requisita, ou seja, os vértices origem e destino apresentam uma demanda de tráfego que deve chegar na transferência dos fluxos pelos caminhos calculados. Os exemplos de problema de transporte são: rodoviário, redes de computadores etc.

A otimização de redes fornece a solução de problemas de rede, como por exemplo, Problema de Fluxo de Custo Mínimo (PFCM). O Problema de Custo Mínimo (PCM) pode ser resolvido através do algoritmo Dijkstra, algoritmo Ford-Moore-Bellman e o PFCM através do método simplex.

2.4.1 Algoritmo Dijkstra

O algoritmo foi desenvolvido em 1959 por Edsger Wybe Dijkstra. O algoritmo de

Dijkstra é o responsável por calcular o caminho mínimo entre o nó origem e destino de

uma rede (BAZARAA et al., 2011). O caminho mínimo é o que fornece o menor custo (por exemplo tempo) para a rede. O algoritmo apresenta os seguintes passos:

1. Todas as estimativas de custo dos vértices da rede são inicialmente 𝑖𝑛𝑓 𝑖𝑛𝑖𝑡𝑜 e o vértice origem apresenta estimativa de custo 0.

2. Enquanto houver vértices não visitados:

a) Seja ℎ o vértice com a menor estimativa de custo; b) Incluir ℎ ao conjunto dos nós definitivamente rotulados.

c) Seja 𝑎 todo vértice sucessor de ℎ:

i. Recalcule a estimativa de custo do arco que une ℎ a 𝑎; some o custo da aresta 𝑎, ℎ;

ii. Caso a nova estimativa de custo seja menor que a estimativa anterior para o vértice ℎ, substitua-a e defina 𝑎 como precedente de ℎ.

2.4.2 Algoritmo Dijkstra Modificado

O algoritmo Dijkstra Modificado é uma modificação do Dijkstra para calcular múltiplos caminhos na rede (dois caminhos).

(36)

Foi proposto, por (JINYAO et al., 2015), o HiQoS que promove QoS, em redes SDN, através da utilização de múltiplos caminhos disponíveis entre a fonte e o destino. Este mecanismo fornece garantia de QoS para diferentes tipos de tráfego, reduzindo o atraso e aumentando a vazão. Os parâmetros para a diferenciação do tráfego foram: en-dereço IP origem, porta origem, enen-dereço MAC (diferenciação entre os usuários), Type of

Service (ToS) e classe do tráfego em MPLS. O algoritmo de Dijkstra modificado calcula

os múltiplos caminhos que satisfaçam as restrições de QoS. O componente de roteamento múltiplos caminhos seleciona o caminho ótimo atual dentre os disponíveis e banda larga para o encaminhamento do pacote. Uma importante característica da proposta é a capa-cidade de criar um novo roteamento quando o enlace de comunicação falhar.

O algoritmo Load balance X (LBX) apresentado por (OLIVEIRA; SALLES, 2016) resumidamente apresenta as seguintes etapas para um novo fluxo de dados analisado :

∙ Determina a origem, o destino e o identificador do fluxo;

∙ O banco de dados é analisado, se já existe um caminho mínimo calculado com a origem e destino obtidos.

– Se o caminho existir no banco de dados, o algoritmo proposto verifica se existe

um novo caminho disjunto - utilizando o método específico - que desconsidera a interseção dos enlaces do caminho calculado - LBX;

* Caso exista, o fluxo é enviado pelo novo caminho e armazenado no banco de dados;

* Caso contrário, o fluxo é pelo caminho já existente;

– Caso contrário, o caminho é calculado por meio do algoritmo Djikstra e

arma-zenado no banco de dados.

As etapas realizadas no Dijkstra modificado proposto:

1. Executar duas vezes os seguintes passos:

a) Todas as estimativas de custo dos vértices da rede são inicialmente 𝑖𝑛𝑓 𝑖𝑛𝑖𝑡𝑜 e o vértice origem apresenta estimativa de custo 0;

b) Enquanto houver vértices não visitados:

i. Seja ℎ o vértice com a menor estimativa de custo; ii. Incluir ℎ ao conjunto dos nós definitivamente rotulados. iii. Seja 𝑎 todo vértice sucessor de ℎ:

A. Recalcule a estimativa de custo do arco que une ℎ a 𝑎; some o custo da aresta 𝑎, ℎ;

(37)

B. Caso a nova estimativa de custo seja menor que a estimativa anterior para o vértice ℎ, substitua-a e defina 𝑎 como precedente de ℎ.

c) Caso obtenha um caminho:

i. Após determinar um caminho, as capacidades das arestas são atualizadas. A menor capacidade das arestas é o valor decrementado das arestas obtidas no caminho calculado e o custo da aresta com capacidade do enlace nula é alterada para 𝑖𝑛𝑓 𝑖𝑛𝑖𝑡𝑜, caso contrário o custo permanece o mesmo.

2.4.3 PFCM

O PFCM é um problema de otimização de fluxo em uma rede de transporte. O objetivo do PFCM é minimizar o custo total da rede de enviar um produto da origem ao destino para satisfazer a demanda dada. A formulação do problema é dada por (BAZA-RAA et al., 2011): ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ minimizar 𝑚 ∑︁ 𝑖=1 𝑚 ∑︁ 𝑗=1 𝑐𝑖𝑗𝑥𝑖𝑗 sujeito a 𝑚 ∑︁ 𝑗=1 𝑥𝑖𝑗− 𝑚 ∑︁ 𝑘=1 𝑥𝑘𝑖 = 𝑏𝑖, 𝑖 = 1, ..., 𝑚 0 ≤ 𝑥𝑖𝑗 ≤ 𝑢𝑖𝑗, 𝑖, 𝑗 = 1, ..., 𝑚. (2.1)

Nas equações de conservação, ∑︀𝑚

𝑗=1𝑥𝑖𝑗 representa o fluxo total de saída do nó 𝑖,

enquanto ∑︀𝑚

𝑘=1𝑥𝑘𝑖 indica o fluxo total de entrada do nó 𝑖. (BAZARAA et al., 2011).

Numa rede de computadores, formada por 𝑚 estações de trabalho, considera-se no mínimo um nó de fornecimento (origem) e um nó de demanda (destino). A variável

𝑥𝑖𝑗 representa o fluxo no arco (𝑖𝑗), 𝑐𝑖𝑗 é o custo por unidade de fluxo no arco (𝑖𝑗), 𝑢𝑖𝑗 é a

capacidade de fluxo do arco (𝑖𝑗), ou seja a largura de banda, 𝑏𝑖 representa a demanda ou

oferta de fluxo no nó 𝑖.

2.4.4 Aplicação dos algoritmos e PFCM

A Figura 5 exibe os caminhos calculados nos dois algoritmos e problema apre-sentados neste capítulo nas seções 2.4.1, 2.4.2 e 2.4.3, considerando a origem vértice s e destino vértice k. Os caminhos encontrados estão destacados na cor vermelha. A Figura 5a apresenta o caminho obtido no algoritmo Dijkstra. A Figura 5b apresenta os dois ca-minhos calculados pelo algorimo Dijkstra Modificado, assim como a Figura 5c apresenta os caminhos do PFCM.

A Tabela 1 exibe as informações utilizadas para resolução dos algoritmos e pro-blema no grafo apresentado. A primeira coluna contém as arestas e as próximas colunas são formadas pela capacidade e custo das mesmas. O custo das arestas é formado por

(38)

1/capacidade. O custo é atribuído desta maneira por representar o tempo necessário para trafegar 1 Mbit do fluxo de dados. Entretanto, o mesmo pode ser definido de

várias maneiras, por exemplo, número de saltos e largura de banda disponível.

O PFCM diferente das outras abordagens exige os fluxos dos vértices como entrada para a resolução do problema, ou seja, foi adicionado um vetor como parâmetro de entrada para linprog contendo os fluxos de cada vértice do grafo. Nos resultados apontados a demanda da origem foi 4000 Mbits, demanda de destino -4000 Mbits e o restante dos vértices 0. Para obter a solução do problema foi adicionado um arco de transbordo entre os nós origem e destino com capacidade 4000 e custo 1 . Este arco artificial foi incorporado no grafo como um meio para alcançar o resultado, pois sem o mesmo não é atingido o resultado em razão das capacidades das arestas não totalizar o fluxo total de entrada. Este arco é um método artificial matemático para que todas as equações fiquem em igualdade.

O algoritmo Dijkstra é o responsável por calcular somente um caminho mínimo, ou seja, aquele que possui a somatória do menor custo das arestas para construir o ca-minho entre os nós origem e destino. Este algoritmo apresenta vantagem em relação os demais quando o grafo é formado por apenas um caminho. O algoritmo Dijkstra Modifi-cado determina quando possível dois caminhos mínimos entre a origem e o destino. Neste algoritmo o Dijkstra é executado duas vezes. O PFCM é um problema de fluxo que fornece a solução menos custosa para trafegar o fluxo, desta forma, resultando em determinada situação, quando possível, mais de dois caminhos. O PFCM apresenta vantagem em rela-ção ao Dijkstra Modificado pois o problema obtém de forma direta (com uma execurela-ção) os múltiplos caminhos.

A Figura 5 apresenta os resultados dos algoritmos Dijkstra e Dijkstra Modificado e o PFCM. A Figura 5a apresenta o único caminho mínimo calculado pelo algoritmo

Dijkstra: [s - k], este caminho apresenta custo 0.0015 e capacidade 685. A Figura 5b

contém os dois caminhos calculados pelo Dijkstra Modificado: [s - k] (custo 0.0015) e [s

- l - k] apresenta custo 0.0023, custo total dos dois caminhos é 0.0038 e capacidade total

1512. A Figura 5c exibe os caminhos calculados utilizando o PFCM: [s - k] (custo 0.0015),

[s - l - k] (0.0023) e [s - t - y - k] apresenta custo 0.0045, custo total dos três caminhos

é 0.0083 e capacidade total 2058. Entretanto, apesar do resultado do PFCM conter um custo total maior, em relação às técnicas anteriores, esta técnica apresenta uma maior capacidade de transferência em relação aos algoritmos Dijkstra e Dijkstra Modificado, por totalizar três caminhos entre a origem e destino.

(39)

Tabela 1 – Informações do Grafo

Aresta Capacidade Custo

(l,k) 870 0.0011 (l,v) 887 0.0011 (k,o) 842 0.0012 (y,k) 546 0.0018 (y,s) 539 0.0019 (s,l) 827 0.0012 (s,k) 685 0.0015 (s,t) 989 0.001 (t,y) 598 0.0017

(40)

Capítulo 2. Fundamentação Teórica 40 l k v o y s t s k s k (a) Dijkstra l v k o y s t s k l s k l (b) Dijkstra Modificado l v k o y ss k l t y s k l t y (c) PFCM

(41)

3 Aplicações em SDN

Este capítulo contém os resultados práticos para a comparação dos algoritmos apresentados nas seções: 2.4.1, 2.4.2 e 2.4.3 utilizando cenários de redes SDN.

3.1 Cenários Analisados

Os cenários de redes de computadores apresentados nos experimentos são consti-tuídos por diferentes configurações de redes. Nos primeiros cenários 6a e 7a, as topologias apresentam elementos gateways responsáveis pelo roteamento entre as diferentes redes de computadores configuradas. Nos cenários modificados 6c e 7c não apresentam os

ga-teways. A organização dos dispositivos presentes nos cenários foi inspirada no trabalho

(OLIVEIRA; SALLES, 2016).

Estes cenários 6a e 7a foram escolhidos com estas configurações e dispositivos por apresentar diferentes restrições na escolha dos caminhos em razão dos gateways. Nos cenários 6c e 7c, a escolha dos caminhos pelas abordagens de otimização não apresentam as restrições de tráfego, nestas topologias são apontadas uma maior possibilidade de caminhos possíveis, diferente dos cenários anteriores que o número de caminhos entre as estações origem e destino. Com estas configurações exibidas pelos cenários, as abordagens de otimização são experimentadas com diferentes restrições e sem restrição avaliando a precisão das escolhas de menor custo dos caminhos.

Os cenários utilizados no desenvolvimento dos experimentos podem ser generaliza-dos para topologias com um maior números de caminhos e dispositivos. Os controladores desenvolvidos com as abordagens de otimização devem ser alterados, acrescentando os vér-tices e as arestas de comunicação da topologia e também para as instalações das regras de encaminhamento, as portas conectadas nos dispositivos.

(42)

Capítulo 3. Aplicações em SDN 42

s1

s2 s3

r2 r1

sta1 sta3 sta5

sta2 sta4 sta6 ap1 ap2 ap3 ap4 (a) Cenário 1 sta1 ap1 ap2 ap3 sta2 ap4 sta3 sta4 sta5 sta6 s1 s2 r1 r2 s3 (b) Grafo 1 s2_1 s3 r2 r1

sta1 sta3 sta5

sta2 sta4 sta6 ap1 ap2 ap3 ap4 s2_2 s1_1 s1_2 (c) Cenário 1 Modificado sta1 ap1 ap2 ap3 sta2 ap4 sta3 sta4 sta5 sta6 s1_1 s1_2 s2_1 s2_2 r1 r2 s3 (d) Grafo 1 Modificado Figura 6 – Cenário 1