Proposta de suporte à qualidade de serviço baseada em SDN: um estudo de caso para instituições de ensino federal

(1)

David Carlos Pereira da Cunha

PROPOSTA DE SUPORTE À QUALIDADE DE SERVIÇO BASEADA

EM SDN: UM ESTUDO DE CASO PARA INSTITUIÇÕES DE ENSINO

FEDERAL

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE 2017

(2)

David Carlos Pereira da Cunha

PROPOSTA DE SUPORTE À QUALIDADE DE SERVIÇO BASEADA

EM SDN: UM ESTUDO DE CASO PARA INSTITUIÇÕES DE ENSINO

FEDERAL

Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientador: Kelvin Lopes Dias

RECIFE 2017

(3)

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

C972p Cunha, David Carlos Pereira da

Proposta de suporte à qualidade de serviço baseada em SDN: um estudo de caso para instituições de ensino federal / David Carlos Pereira da Cunha. – 2017.

97 f.: il., fig., tab.

Orientador: Kelvin Lopes Dias.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.

Inclui referências e apêndice.

1. Redes de computadores. 2. Redes definidas por software. I. Dias, Kelvin Lopes (orientador). II. Título.

004.6 CDD (23. ed.) UFPE- MEI 2017-237

(4)

David Carlos Pereira da Cunha

Proposta de suporte à qualidade de serviço baseada em SDN: um

estudo de caso para instituições de ensino federal.

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 12 de julho de 2017.

Aprovado em: 12 / 07 / 2017.

BANCA EXAMINADORA

__________________________________________ Prof. Carlos André Guimarães Ferraz

Centro de Informática / UFPE

__________________________________________ Prof. Andson Marreiros Balieiro

Universidade de Pernambuco

__________________________________________ Prof. Kelvin Lopes Dias

Centro de Informática / UFPE (Orientador)

(5)

Dedico essa dissertação à minha família, em especial aos meus pais, irmã, esposa, avó e madrinha. À minha avó Rosa Pacheco (in memorian), tio Lamartine Bezerra (in memorian) e padrinho Moacir Pessoa (in memorian).

(6)

AGRADECIMENTOS

Agradeço a Deus por ter me permitido realizar esse grande sonho, principalmente por tê-lo feito com saúde e tendo compartilhado os mais nobres sentimentos com tantas pessoas queridas.

Com amor, aos meus pais Juvita Pereira e João Carlos, à minha irmã Juliana Pereira, eles que sempre participaram ativamente da minha vida, me deram todo suporte familiar e são responsáveis pela minha formação, pessoal e acadêmica. À minha amada esposa Silvia Kellyne, pelo incentivo e companheirismo em todos os dias dessa desafiadora jornada.

Ao professor Kelvin Lopes Dias pela confiança e orientação exemplar. Por tornar tudo possível, consequência natural de sua competência e disponibilidade em ajudar do início ao fim, sobretudo nas horas mais difíceis.

Aos familiares (tios, primos e sogra) pelo apoio e torcida. Aos amigos aqui representados por Gabriel Vasconcelos, Edson Valença, Cláudio Bline, José Henrique, Péricles Gomes, Marcos Roberto, Denio Brasileiro e Pedro Chaves. A força da amizade, da ajuda e das palavras de vocês teve o poder de renovar minha motivação para seguir em frente em vários momentos dessa caminhada.

Aos amigos conquistados de tantos lugares desse Brasil nessa turma de mestrado, em especial a Danyel, Leonardo, Paula, Rony e Willamys, do nosso colaborativo e nordestino grupo de tantos trabalhos apresentados. Ao pessoal do grupo "Os Originais", que seguiram sempre consonantes com seu lema "ninguém fica pra trás". Ao pessoal do grupo de mensagens "SDN - MPROF", dos grandes parceiros Eric, Igor, Janiel e Johnathan. A troca de conhecimentos e

culturas nessa turma foi uma experiência única.

No CIn, a todos os professores e equipe administrativa, todos foram fundamentais nessa formação. Tive a honrosa oportunidade de absorver um pouco do conhecimento e da experiência de tantos profissionais de excelência em suas áreas.

Na UFPE, agradeço pelo auxílio de Edivaldo (atualmente na UFRN), ao amigo Lucindo do campus Caruaru, assim como Anderson e Adalberto do NTI em Recife. Também a todos os aconselhamentos dos estimados professores Décio Fonseca, Carlos Ferraz, Auxiliadora Padilha, Marcos Galindo e César Giusti.

Aos amigos do trabalho na Coordenação de EaD da UFPE, em especial a Georgina, Cynthia, Libório, Danilo, Silvio, Letícia, Haíra, Marco, Wanderson, Breno e Clóvis. Aos meus coordenadores e colegas de todos os dias que acompanharam todo esse percurso, sem vocês seria ainda mais complicada essa difícil missão de conciliar pesquisa e trabalho.

Enfim, deixo minha cordial gratidão a todos que colaboraram direta ou indiretamente para esta conquista!

(7)

Eu não tenho nenhum talento especial. Sou apenas apaixonadamente curioso. —ALBERT EINSTEIN

(8)

RESUMO

Um estudo especializado recente sobre tendências para 2021 mostra que o tráfego de vídeo (ao vivo e sob demanda) na internet deve ultrapassar 80% do tráfego global IP e é esperado um crescimento da qualidade dos vídeos devido ao aumento dos conteúdos em resoluções em ultra alta definição (4K ou 8K). Comportamento semelhante foi previsto para o cenário corporativo, que chegará a 70%. Motivados por essa tendência, também observamos, em especial nas instituições de ensino, que nem sempre o consumo principal é conteúdo educacional. A concorrência de tráfego, algo comum nos sistemas multimídia, pode trazer prejuízo ao desempenho das aplicações educacionais. Nesse cenário, o grande desafio é, ao mesmo tempo, incentivar a utilização das aplicações institucionais e suportar o tráfego gerado por plataformas como Youtube, Hangouts, Vimeo e Facebook live. O aumento da demanda e dos requisitos dos novos serviços críticos como vídeo monitoramento, telemedicina, videoconferência, VoIP e streaming, já não é suportado. E essas instituições têm concentrado esforços na melhoria das redes de acesso e aumento de largura de banda, o que ainda é complexo e custoso. A arquitetura tradicional das redes dificulta a distinção e priorização de serviços, além disso, outras necessidades surgem, como: controle de fluxo, processamento e controle de qualidade. As Software-defined Network (SDN) apresentam um novo paradigma de redes, fornecendo controle centralizado e programável para tomada decisões de controle sob o tráfego. O objetivo desta pesquisa é propor uma solução baseada em SDN para melhorar a QoS e QoE no tráfego multimídia educacional. Nos propusemos a estudar problemas relevantes e que são vivenciados em infraestruturas, principalmente de instituições de ensino federal. Uma consequência esperada é proporcionar uma melhoria qualitativa do conteúdo de vídeo disponibilizado, aumentando a presença institucional de aplicações avançadas como a telemedicina, monitoramento de campi e de sensores, videoconferências para EaD e streaming em tempo real. Desta forma, vislumbrando o crescimento do tráfego de vídeo na UFPE, o nosso ambiente precisa avaliar as soluções de Quality of Service (QoS) e Quality of Experience (QoE) com atenção especial para a modalidade Educação a Distância (EaD). Propusemos uma solução para classificação de tráfego priorização de serviços e como prova de conceito, construímos um ambiente experimental e avaliamos a eficácia em termos das métricas de vazão, jitter, PSNR, VQM e SSIM para tráfego de vídeo em tempo real. Os resultados obtidos indicaram melhorias de até 49% em relação à perda de quadros, 85% em relação à variação de atraso e vazão mínima garantida e estável quando da adoção da proposta num cenário de alto congestionamento.

Palavras-chave: Qualidade de Serviço. Qualidade de Experiência. Open vSwitch. OpenFlow. Redes Definidas por Software.

(9)

ABSTRACT

A recent expert study on trends for 2021 shows that video traffic (live and on demand) on the Internet should exceed 80% of the global IP traffic and video quality growth is expected due to increased content in Ultra HD resolutions (4K). Similar behavior was predicted for the corporate scenario that will reach 70%. Motivated by this tendency, we also observe, especially in educational institutions, that the main consumption is not always educational content. Traffic competition, which is common in multimedia systems, can adversely affect the performance of educational applications. In this scenario, the challenge is at the same time to encourage the use of institutional applications and support the traffic generated by platforms such as Youtube, Hangouts, Vimeo and Facebook live. The increased demand and requirements of critical new services such as video monitoring, telemedicine, videoconferencing, VoIP and streaming are no longer supported. And these institutions have concentrated on improving access networks and increasing bandwidth, which is still complex and costly. The traditional architecture of the networks makes it difficult to distinguish and prioritize services; in addition, other needs arise, such as: flow control, processing and quality control. Software-defined networks (SDN) present a new network paradigm, providing centralized and programmable control for making control decisions under traffic. The purpose of this research is to propose an SDN based solution to improve QoS and QoE in educational multimedia traffic. We set out to study relevant problems that are experienced in infrastructures, mainly from federal educational institutions. An expected consequence is to provide a qualitative improvement of the video content made available, increasing the institutional presence of advanced applications such as telemedicine, monitoring of campuses and sensors, videoconferences for EaD and real time streaming. Thus, with a view to the growth of video traffic in UFPE, our environment needs to evaluate QoS and QoE solutions with special attention to the E-learning. We proposed a solution for traffic classification ande prioritization of services and as proof of concept, we built an experimental environment and evaluated the effectiveness of throughput, jitter, PSNR, VQM and SSIM metrics for real-time video traffic. The results obtained indicated improvements of up to 49% in relation to the frame loss, 85% in relation to the delay variation and minimum throughput guaranteed and stable when adopting the proposal in a scenario of high congestion.

Keywords: Quality of Service. Quality of experience. Open vSwitch. OpenFlow. Software Defined Network.

(10)

LISTA DE FIGURAS

2.1 Arquitetura tradicional vs. SDN . . . 25

2.2 Arquitetura tradicional vs. SDN . . . 26

2.3 Arquitetura em camadas SDN . . . 27

2.4 Arquitetura em 3 camadas . . . 28

2.5 Componentes de um switch openflow . . . 29

2.6 Fluxo do pacote no pipeline de processamento . . . 30

2.7 Fluxograma do pacote através do switch OF . . . 32

2.8 Sequência de mensagens de filas OF . . . 33

2.9 Estrutura das filas . . . 33

2.10 Elementos e recursos do OvS . . . 35

2.11 Arquitetura do Controlador Ryu . . . 38

2.12 Arquitetura baseada em eventos de uma aplicação Ryu . . . 39

3.1 Visão gera da proposta de QoS . . . 56

4.1 Visão geral da topologia do experimento . . . 64

4.2 Detalhes da topologia . . . 70

4.3 Visão geral das filas . . . 71

5.1 Visão geral da rede real . . . 75

5.2 Gráfico: Relação Configuração da vazão vs. Perda: Inter-campi . . . 76

5.3 Gráficos de RTT: Inter-campi . . . 77

5.4 Gráficos de Vazão: Inter-campi . . . 77

5.5 Gráficos de Perdas (de Pacotes e de Quadros): Inter-campi . . . 78

5.6 Gráficos de jitter: Inter-campi . . . 79

5.7 Gráfico de vazão (Mbps): Experimentos AEV . . . 80

5.8 Gráficos de jitter: Experimentos AEV . . . 81

5.9 Intervalos de jitter (95% IC): Experimentos AEV . . . 81

5.10 Gráfico de Perdas: Experimentos AEV . . . 82

5.11 Intervalos de Perda (95% IC): Experimentos AEV . . . 82

5.12 Gráficos de Peak Signal-to-Noise Ratio (PSNR): Experimentos AEV . . . 83

5.13 Gráficos Video Quality Metric (VQM): Experimentos AEV . . . 83

(11)

LISTA DE QUADROS

2.1 Componentes de um fluxo . . . 31

2.2 Controladores abertos populares . . . 37

2.3 Subclasses e probabilidades de descarte AF PHB . . . 41

2.4 Detalhes dos trabalhos relacionados . . . 43

3.1 Classes Per-hop behaviour (PHB) . . . 55

4.1 Experimentos dos trabalhos relacionados . . . 63

4.2 Software nos servidores . . . 65

4.3 Software nos clientes . . . 65

4.4 Softwares nos switches . . . 66

4.5 Softwares no Controlador . . . 66

4.6 Redes virtuais Esxi . . . 67

4.7 Especificações de Hardware . . . 67

4.8 Especificações de Hardware . . . 68

4.9 Configuração do tráfego de fundo: AEV . . . 68

4.10 Configuração do link: AEV . . . 69

(12)

LISTA DE ACRÔNIMOS

SDN Software-defined Network . . . 18

QoS Quality of Service . . . 18

QoE Quality of Experience . . . 18

ODL Opendaylight . . . 87

API Application Programming Interface . . . 18

OvS Openvswitch . . . 32

OF Openflow . . . 21

PSNR Peak Signal-to-Noise Ratio . . . 41

VoD Video On Demand . . . 42

SSIM Structural Similarity . . . 59

VQM Video Quality Metric . . . 59

FIFO First In, First Out . . . 38

REST Representational State Transfer . . . 36

VM Voice over Internet Protocol . . . 51

VoIP Voz sobre IP . . . 18

ToS Type of Service . . . 55

DSCP Differentiated Services Code Point . . . 34

RFC Request for Comments . . . 27

UDP User Datagram Protocol . . . 67

TCP Transmission Control Protocol . . . 67

RTP Real-time Transport Protocol . . . 22

HTTP Hypertext Transfer Protocol . . . 17

AVI Audio Video Interleave . . . 69

OPEX Operational Expenditure . . . 51

CAPEX Capital Expenditure . . . 19

DoE Design of Experiments . . . 22

FTP File Transfer Protocol . . . 17

HD High Definition . . . 19

(13)

3D Three-dimensional . . . 19

TE Traffic Engineering . . . 18

AEV Ambiente Experimentação Virtual . . . 22

UFPE Universidade Federal de Pernambuco . . . 20

TC Traffic Control . . . 46

EaD Educação a Distância . . . 20

Diffserv Differentiated services . . . 34

Intserv Integrated Services . . . 40

CDN Content Delivery Network . . . 18

OTT Over The Top . . . 44

RTT Round Trip Time . . . 76

SVC Scalable Video Coding . . . 18

DPI Deep Packet Inspection . . . 88

RNP Rede Nacional de Pesquisa . . . 20

Gbps Gigabits por segundo . . . 20

Mbps Megabits por segundo . . . 20

PHB Per-hop behaviour . . . 40

BE Best Effort . . . 40

EF Expedited Forwarding . . . 40

AF Assured Forwarding . . . 40

CS Class Selector . . . 40

CPU Central Processing Unit . . . 46

GENI Global Environment for Network Innovations . . . 47

ms Milissegundos . . . 39

FPS Frames per Second . . . 48

ROIA Real-Time Online Interactive Applications . . . 48

DOL Opendaylight . . . 87

MOS Mean Opinion Score . . . 51

ABR Average Bit Rate . . . 18

POP Point of Presence . . . 20

(14)

Netem Network Emulator . . . 69

TBF Token Bucket Filter . . . 69

HAS HTTP Adaptive Streaming . . . 18

(15)

SUMÁRIO

1 INTRODUÇÃO 17 1.1 MOTIVAÇÃO . . . 19 1.2 OBJETIVOS . . . 21 1.3 PRESSUPOSTOS DE PESQUISA . . . 21 1.4 METODOLOGIA ADOTADA . . . 22 1.5 ORGANIZAÇÃO DO DOCUMENTO . . . 23 2 REFERENCIAL TEÓRICO 24 2.1 CONCEITOS . . . 24 2.1.1 A Comutação Tradicional . . . 24 2.1.2 Os Planos . . . 25

2.1.3 Redes definidas por software . . . 26

2.1.4 O protocolo Openflow . . . 29

2.1.5 Tabelas e pipeline Openflow . . . 30

2.1.6 As entradas de fluxo . . . 30

2.1.7 Correspondência . . . 31

2.1.8 Recursos para QoS Openflow . . . 32

2.1.8.1 Filas . . . 32

2.1.8.2 Os Medidores . . . 34

2.1.9 OpenvSwitch . . . 34

2.1.10 O Controlador de rede . . . 36

2.1.10.1 O controlador de rede Ryu . . . 38

2.1.11 Métricas de Qualidade de Serviço . . . 39

2.1.12 As Métricas de avaliação de Qualidade de Vídeo . . . 41

2.2 TRABALHOS RELACIONADOS . . . 42

2.3 QUALIDADE DE SERVIÇO (QOS) EM SDN . . . 46

2.4 QOS E A QUALIDADE DE EXPERIÊNCIA (QOE) EM SDN . . . 49

2.5 DISCUSSÕES SOBRE OS TRABALHOS . . . 51

3 PROPOSTA DE CONTROLE 53 3.1 PRIORIZAÇÃO . . . 53

3.2 PROCEDIMENTO DE ADMISSÃO NO CONTROLADOR . . . 53

3.3 GARANTIA DE LARGURA DE BANDA NO SWITCH . . . 54

3.4 AGREGAÇÃO DE TRÁFEGO . . . 54

3.5 CLASSES DE SERVIÇO . . . 54

(16)

3.7 MÚLTIPLAS TABELAS DE FLUXO . . . 55

3.8 MÓDULOS BÁSICOS . . . 55

3.8.1 Módulo de controle de QoS . . . 56

3.8.2 Módulo de Monitoramento . . . 56

3.8.3 Módulo de Gerenciamento . . . 57

3.9 CONSIDERAÇÕES DE IMPLANTAÇÃO . . . 57

3.10 DELIMITAÇÃO DO ESCOPO PARA TESTES . . . 58

3.10.1 Experimentação . . . 59 3.10.2 Proposta . . . 59 4 AMBIENTE DE EXPERIMENTAÇÃO 61 4.1 VISÃO GERAL . . . 64 4.2 OS CLIENTES . . . 65 4.3 OS SERVIDORES . . . 65 4.4 SWITCHES . . . 65 4.5 O CONTROLADOR . . . 66 4.6 AS REDES . . . 66 4.7 A VIRTUALIZAÇÃO . . . 67 4.8 O TRÁFEGO DE FUNDO . . . 67 4.9 O TRÁFEGO PRIORITÁRIO . . . 68 4.10 O LINK . . . 69 4.11 OS CENÁRIOS . . . 69

4.11.1 As configurações de QoS e filas . . . 71

4.12 AS FERRAMENTAS DE GERAÇÃO E COLETA . . . 72

4.13 CONSIDERAÇÕES GERAIS . . . 73

5 ANÁLISE E APRESENTAÇÃO DOS DADOS 74 5.1 CENÁRIO REAL INTER-CAMPI . . . 74

5.1.1 Atraso . . . 76

5.1.2 Rede real inter-campi: Vazão . . . 77

5.1.3 Rede real inter-campi: Perdas . . . 78

5.1.4 Rede real inter-campi: jitter . . . 78

5.2 CENÁRIOS DO AEV . . . 79

5.2.1 Comparação Cenários SQ vs. SQ: Vazão . . . 79

5.2.2 Comparação Cenários SQ vs. SQ: jitter . . . 80

5.2.3 Comparação Cenários SQ vs. SQ: Perdas . . . 81

5.2.4 Comparação Cenários SQ vs. SQ: PSNR . . . 81

5.2.5 Comparação Cenários SQ vs. SQ: VQM . . . 82

(17)

6 CONCLUSÕES 85 6.1 PERGUNTAS DE PESQUISA . . . 86 6.2 OBJETIVOS ALCANÇADOS . . . 86 6.3 LIMITAÇÕES DO TRABALHO . . . 87 6.4 DIFICULDADES ENCONTRADAS . . . 87 6.5 TRABALHOS FUTUROS . . . 88 6.6 CONSIDERAÇÕES FINAIS . . . 89 REFERÊNCIAS 90

(18)

17 17 17

1

INTRODUÇÃO

As previsões apontam para um grande crescimento do tráfego de vídeo na internet nos próximos anos, que deve atingir volume superior a 80% do tráfego total até 2021 segundo CISCO AND AFFILIATES (2017a), tendo alcançado 73% em 2016. Sem o devido tratamento, durante os picos de utilização da rede poderão ocorrer congestionamentos, reduzindo o desempenho geral das aplicações. Por isso, várias técnicas têm sido propostas para tentar manter a taxa de transferência de vídeo elevada e constante. Comportamento similar acontece nas redes corporativas, a parcela de tráfego de vídeo consumido na internet chega a 70% do tráfego, segundo CISCO AND AFFILIATES (2017b).

Nas redes corporativas, destacam-se dois tipos de transmissão de vídeo, o streaming de vídeo sobre o Hypertext Transfer Protocol (HTTP), que utiliza a transmissão direta unicast, de um remetente para um destinatário; e a videoconferência, que é capaz de realizar a transmissão multicast, de um para muitos destinatários. O tráfego de vídeo sobre HTTP também possui forte presença nas principais aplicações na internet móvel. Em poucos anos, muitas aplicações foram desenvolvidas o que fez aumentar também o tráfego médio por usuário, que segundo a CISCO, chegará aos 35 Gigabytes por pessoa por mês em 2021. Muito desse volume se deve à popularização de aplicações de vídeo sobre HTTP disponíveis na internet, tais como YouTube1, Vimeo2, e Dailymotion3.

Na arquitetura tradicional de comunicação em redes de computadores utiliza-se o cha-mado paradigma do melhor esforço para transmitir dados. É importante destacar que nele, independentemente do tipo de informação contida, os dados recebem o mesmo tratamento da rede. Segundo o modelo de comunicação em 4 camadas TCP/IP (SOCOLOFSKY; KALE, 1991), as camadas superiores, mais próximas do usuário, leem as informações e classificam

serviços como e-mail, HTTP e File Transfer Protocol (FTP). Uma rota entre origem e destino é criada utilizando-se a visão do próximo dispositivo na rede, ou seja, não há uma visão global da rede, cada dispositivo utiliza um protocolo de roteamento para estabelecer a topologia da rede e o algoritmo de roteamento calcula o próximo salto. Apesar de limitada, essa estrutura tem funcionado e facilitou a expansão da Internet.

1_{http://www.youtube.com} 2_{http://vimeo.com}

(19)

CAPÍTULO 1. INTRODUÇÃO 18

Multimídia tem sido definida como a combinação digital entre um meio estático (texto e imagens) e outro meio dinâmico (vídeo, áudio, animação). Tais aplicações se tornaram as mais populares da Internet, o que trouxe um grande desafio devido ao grande volume de dados. Embora utilizando o roteamento tradicional não seja possível garantir largura de banda, nem limitar o atraso dos pacotes, estas aplicações atendem uma grande quantidade de usuários. O desempenho de aplicações de Streaming de vídeo nessa arquitetura tradicional é aceitável graças às técnicas avançadas de transmissão, principalmente as que reduzem o volume dos dados usando Scalable Video Coding (SVC) e multicast, como em LAGA et al. (2014), TANG; HUA; WANG (2014) e TSUNG-FENG; WANG; HSU (2015); trazem o conteúdo para próximo do cliente usando Content Delivery Network (CDN), caching e roteamento, como em LIU et al. (2013), NAM et al. (2014), WANG et al. (2014), II; DURRESI (2015) e GEORGOPOULOS et al. (2015); realizam adaptação dinâmica de taxas, Average Bit Rate (ABR) e HTTP Adaptive Streaming (HAS), como utilizado em LAGA et al. (2014) e UZAKGIDER; CETINKAYA; SAYIT (2015).

A ampliação da gama de dispositivos conectados à Internet e o desenvolvimento de novos serviços como Voz sobre IP (VoIP), Streaming de vídeo, Internet das Coisas, Computação em Nuvem, trouxeram consigo desafios para a arquitetura rígida atual. Aplicações diferentes demandam requisitos diferentes da rede, que por sua vez deveria tratar especificamente cada tipo.

Nas redes tradicionais, os serviços requisitados têm sido integrados ao núcleo da rede por meio de inúmeras tecnologias proprietárias, nas quais o acesso do administrador fica limitado a poucas opções de configuração. Modificações adicionam complexidade aos dispositivos de rede (memória, processamento e energia) e novos serviços podem requerer a reconfiguração da rede ou troca de equipamentos em produção. Tais limitações revelam a necessidade de se flexibilizar a personalização das redes, é preciso permitir a adaptação às especificidades de cada cenário. Esse problema das redes tradicionais tem sido conhecido como ossificação, referindo-se ao processo na vida humana de substituição das cartilagens (flexíveis) por ossos.

Software-defined Network (SDN) apresenta um novo paradigma para a comunicação em redes de computadores, é uma arquitetura de rede que separa o plano de controle do plano de dados. O plano de controle, das decisões, é centralizado em um elemento da rede chamado controlador SDN, que é executado em um servidor comum. O controlador possui um sistema operacional de rede onde são programadas e executadas as aplicações de rede, como Traffic En-gineering (TE), Quality of Service (QoS), Quality of Experience (QoE), segurança, virtualização e roteamento. O plano de dados, ou de encaminhamento, permanece na rede e é executado em simples comutadores (switches), que executam o encaminhamento de pacotes e outras ações, baseadas em instruções do controlador.

SDN proporciona uma forma inovadora para permitir que os administradores de rede tenham controle central e programável sobre tráfego global da rede. SDN fornece abstrações para construção de verdadeiros sistemas de redes. Assim, pode-se aproveitar uma Application Programming Interface (API) comum e os controladores para gerenciar fluxos de tráfego, o que

(20)

inclui aplicações de multimídia, e em especial o tráfego de vídeo.

1.1 MOTIVAÇÃO

Atualmente, observa-se o aumento constante da demanda e dos requisitos para transmis-são de vídeo em alta resolução, inclusive em aplicações educacionais. Isso já vem motivando o aperfeiçoamento das técnicas de transmissão, compressão e codificação, além da melhoria na qualidade dos canais de comunicação e redes de acesso à Internet. Vários serviços críticos atuais como o videomonitoramento, telemedicina, videoconferência, streaming, vídeos em alta resolução (High Definition (HD), Three-dimensional (3D) e Ultra High Definition (UHD)), são responsáveis por gerar essa demanda.

O desenho tradicional de redes de computadores não é capaz de atender às necessidades dos serviços como controle do fluxo de tráfego, processamento de rede intermediário, QoS e QoE, requisitos comuns dos serviços de multimídia. A arquitetura de redes de computadores precisa ser completamente transformada para atender a essa Internet do futuro.

Já o tráfego de aplicações de streaming de vídeo tem dominando a internet. Sabe-se que, geralmente, o streaming de vídeo ao vivo precisa ser distribuído para vários usuários, quando seria ideal usar multicast. No entanto, multicast não é popular, já que exige o suporte dos roteadores, e/ou equipamentos específicos, o que pode elevar principalmente o Capital Expenditure (CAPEX) necessário para habilitar a tecnologia nas redes. Com o desenvolvimento das redes móveis, de telecomunicações, internet e TV, as redes se tornaram ambientes mais heterogêneos e com a popularização dos laptops, tablets e smartphones, dispositivos com várias capacidades de transmissão podem estar envolvidos numa mesma sessão de Streaming. Essa heterogeneidade torna mais complexo viabilizar a comunicação de streaming em multicast.

Skype4 e Google Hangouts5, por exemplo, já oferecem serviços de vídeo ao vivo via HTTP em unicast, ainda que com limitações. Os principais desafios da transmissão de streaming tem sido a interação em tempo real entre muitos usuários, já que a grande quantidade de tráfego deve ocasionar problemas de largura de banda e congestionamento; e a escalabilidade e flexibilidade do serviço ao enviar sob demanda cada fluxo de vídeo por múltiplos caminhos de forma eficiente. Conclui-se que é necessário aumentar as taxas de transmissão de vídeo e mantê-las constantes, e esses desafios seriam bem difíceis de superar sem SDN.

Este trabalho pretende mostrar factível e viável a resolução de problemas vivenciados nas organizações. No âmbito das tecnologias educacionais, uma importante consequência deve ser motivar o desenvolvimento e a distribuição de conteúdo de vídeo para uso serviços como aulas, palestras, conferências, reuniões acadêmicas. Além disso, que o conteúdo e os recursos sejam cada vez mais utilizados e produzidos em melhor qualidade, estando presentes na rede através de aplicações como as de Telemedicina, Monitoramento de campi e de sensores, videoconferências

4_{https://www.skype.com} 5_{https://hangouts.google.com}

(21)

para Educação a Distância (EaD) e streaming em tempo real.

Para NUNES et al. (2014), as empresas executam grandes redes, e possuem requisitos rigorosos de segurança e desempenho. As redes universitárias podem ser consideradas um caso especial, pois em um ambiente, muitos dispositivos de conexão são temporários e não controlados pela Universidade, além disso, necessitam maior segurança e alocação de recursos. As universidades muitas vezes precisam dar suporte a testes de pesquisa e protocolos externos. O gerenciamento adequado é extremamente importante e SDN pode ser usada para implementar e ajustar políticas de rede, além de ajudar no monitoramento e ajustes de desempenho.

Desde análise inicial da infraestrutura da Universidade Federal de Pernambuco (UFPE), durante o planejamento e coleta de informações básicas, já percebemos a ausência de mecanismos de controle bem definidos e eficientes na instituição. Por exemplo, não foi possível coletar informações de perfil de tráfego de aplicações na rede no dispositivo proprietário existente; não foi possível coletar métricas de experiência do usuário na aplicação institucional de conferências via web. Percebemos um certo estágio de ossificação da rede, portanto qualquer que fosse a solução a ser abordada, teria que ser baseada na adoção de SDN, pois permitiria aproveitar benefícios, descritos em XIA et al. (2015), como a visão global da rede, programabilidade, inteligência na rede, interface aberta de controle centralizado e padronizado, independente de fabricantes e facilidade de inovação, o que é desejável numa instituição com missão de ensino e pesquisa.

Percebemos na UFPE que os produtores de conteúdo não confiavam na rede, eles acabam optando por gerar conteúdo leve e de baixa qualidade. A EaD na universidade vem acompanhando uma tendência de crescimento mundial, também chegando a um estágio em que um novo passo qualitativo deve ser dado. A comunidade acadêmica deseja utilizar novas ferramentas, como as de tempo real e conteúdo em UHD, deseja vivenciar uma nova experiência em termos da qualidade de conteúdo dos cursos. É uma demanda emergente e para que isso seja possível, a instituição deverá se preparar para ter esse controle refinado sob o tráfego de rede.

Apesar da capacidade de 10 Gigabits por segundo (Gbps) de saída ao Point of Presence (POP), em Recife, a conexão inter-campi ainda está limitada a 100 Megabits por segundo (Mbps) para os Campi Vitória e Caruaru. Estes links são fornecidos pela Rede Nacional de Pesquisa (RNP). Em princípio, o backbone do campus Recife possui capacidade suficiente para o crescimento da demanda de tráfego, contudo o suporte à QoS também precisa ser estruturado uma vez que sobreprovisionamento não necessariamente garante qualidade nas transmissões em momentos de pico e com tráfego interferente. Para que alcancemos o objetivo de proporcionar uma qualidade equânime para todos os campi, é necessário utilizar mecanismos de controle centralizados, que permitam o monitoramento voltado para a tomada de decisão.

E se levarmos em consideração a estrutura da EaD, as estruturas dos Polos de apoio presencial aos cursos, localizados em cidades do interior do estado, ficando a até 800 Km da capital, nesses pontos temos condições e experiência do usuário ainda piores. Tudo isso acaba impactando na percepção de qualidade dos cursos da instituição, como um todo.

(22)

Independente-CAPÍTULO 1. INTRODUÇÃO 21

mente de ser polo, interior ou capital, é o acesso ao serviço prestado pela instituição que está em questão. Supondo-se a definição de uma solução SDN institucional, através da implantação de dispositivos com suporte a Openflow (OF), tal solução institucional poderia ser incorporada aos polos. Na UFPE já houve iniciativas para se projetar uma estrutura de monitoramento das redes dos polos onde há cursos da UFPE, o que hoje já poderia ser feito baseado em SDN, mesmo que parcialmente.

1.2 OBJETIVOS

O objetivo geral da pesquisa é propor e analisar o desempenho de uma solução baseada no paradigma SDN e em recursos do protocolo OF que permita o desenvolvimento de uma aplicação para adaptação dinâmica da rede baseada no monitoramento de métricas e aplicação de políticas de QoS, para priorização de tráfego em redes corporativas.

Os objetivos específicos são:

Construir um ambiente de experimentação específico, adequado a SDN e flexível o suficiente para permitir a criação de experimentos que utilizem: conteúdo e tráfego real, manipulação de tráfego concorrente não prioritário, análise distinta dos dois tipos de tráfego, que seja facilmente replicado;

Analisar características de transmissão de vídeo em tempo real inter-campi na UFPE, de modo a permitir a definição de parâmetros para emulação das características de rede no experimento.

Analisar as principais técnicas de transmissão e codificação, e métricas de QoS e QoE em fluxos de vídeo que sejam adequados à aplicação em ambientes SDN; Analisar as características objetivas da rede em transmissões de conteúdo real,

uti-lizando uma aplicação real de streaming de Vídeo em tempo real, baseando-se em métricas de QoS e QoE;

Propor uma solução prática de controle de QoS, com maior compatibilidade possível com a rede atual;

Verificar se a estratégia de enfileiramento por prioridade baseada em SDN melhora as métricas de QoS e QoE do vídeo em tempo real.

1.3 PRESSUPOSTOS DE PESQUISA

Nesta pesquisa, e antes de definir a metodologia, a partir de conhecimento prévio e de problemas detectados e vivenciados num ambiente institucional educacional, partiremos dos seguintes pressupostos teóricos:

(23)

P1: é complexo ter um monitoramento efetivo e tratamento diferenciado de tráfego de missão crítica sem SDN;

P2: é complexo avaliar as métricas de QoS para aplicações de vídeo em tempo real; P3: não há mecanismos na instituição para avaliar a QoE percebida pelos usuários; P4: é simples e eficaz construir um sistema de priorização de tráfego baseado em

SDN.

E ao longo do trabalho testaremos as seguintes hipóteses:

H1: Com um ambiente de experimentação baseado em virtualização é possível avaliar o tráfego de vídeo em tempo real de redes em produção.

H2: Com um sistema simples baseado em SDN e recursos do protocolo OF é possível controlar as métricas de QoS e melhorar a QoE da rede.

Temos então uma pergunta pesquisa que buscaremos responder: é eficaz fornecer o controle de QoS, através de priorização de tráfego institucional em redes definidas por software, avaliando QoE em ambientes em produção?

1.4 METODOLOGIA ADOTADA

Para atingir os objetivos de pesquisa, foi adotada a metodologia descrita a seguir: Em primeiro lugar, para que as questões e definições sobre os métodos a serem adotados fossem logo resolvidas, foi realizada uma pesquisa exploratória a respeito dos vários temas envolvidos, e em seguida outra mais aprofundada sobre os principais e mais recentes trabalhos que abordam conceitos relacionados. Foi realizada uma análise crítica resumida sobre a essência dos principais e mais recentes artigos e técnicas empregadas, em partes: a) relacionados às últimas abordagens que utilizam SDN para resolver problemas gerais do tráfego de vídeo; b) focados nas técnicas de QoS em SDN; c) com foco nas métricas de QoS e o reflexo em QoE.

Em seguida foi concebida e demonstrada uma proposta para uma aplicação de classi-ficação e priorização de tráfego de forma dinâmica, em SDN. Tal proposta foi apresentada em formato descritivo, mostrando especificações gerais de software e configurações para o Controlador de rede.

Em seguida, foi realizada a coleta de dados de tráfego na rede em produção numa comunicação de vídeo em tempo real usando o protocolo Real-time Transport Protocol (RTP), cenário real que foi chamado de inter-campi. Foram coletados os dados e calculadas as métricas objetivas. Foi feita então a caracterização básica da rede desse cenário real inter-campi.

De posse das características da rede, foi definido o Ambiente Experimentação Virtual (AEV) e cenários de teste. No planejamento dos experimentos, apenas para verificar a coerência dos testes, foram consultados conceitos básicos de Design of Experiments (DoE), expostos de

(24)

forma mais prática em COLEMAN (2014). Foram estabelecidos os recursos e softwares a serem utilizados em todo o processo, foi delimitado o escopo dos testes reais. O produto desta etapa é a seção de descrição e desenho do ambiente de experimentação.

Com a definição do ambiente, o mesmo foi construído e em seguida foi aplicada ao link virtual a modelagem baseada nos parâmetros obtidos da caracterização inter-campi. Toda a execução dos experimentos nos cenários foi programada em scripts de modo a armazenar os dados de forma organizada em diretórios.

O grande volume de arquivos contendo dados das medições foram tabulados, o que exigiu um processamento parcialmente manual dos arquivos e a criação de vários scripts para automatizar os cálculos. Em seguida, os dados foram analisados com o auxílio de mais scripts e ferramentas específicas para cálculo estatístico e geração de gráficos. No final foram extraídas as métricas de avaliação.

Na análise dos resultados, depois de tabulados, os dados coletados foram apresentados na forma de gráficos seriais baseado na sequência de experimentos, e em gráficos de intervalos de confiança, com níveis de confiança de 95%. A análise e apresentação dos gráficos foi realizada para cada métrica comparando a evolução entre os cenários. Os gráficos foram gerados e nas análises foi realizada uma avaliação empírica e análise crítica dos reflexos das métricas nas situações reais de uso.

Por fim foi realizada uma análise geral da pesquisa e dos resultados. Foram respondidas as perguntas de pesquisa e justificado o alcance dos objetivos inicialmente propostos. Também foram mencionadas as limitações do trabalho e desafios em aberto.

1.5 ORGANIZAÇÃO DO DOCUMENTO

Este documento está organizado da seguinte forma:

No primeiro capítulo é realizada uma introdução ao tema central e ao problema.

O segundo capítulo aborda a teoria envolvida no trabalho, são descritas as principais referências conceituais e analisados os principais trabalhos relacionados.

No terceiro capítulo é apresentada uma proposta para classificação e priorização de tráfego baseado em SDN.

No quarto capítulo são descritos os detalhes do ambiente de experimentação e cená-rios utilizados na prova de conceito. São abordados aqui todos os aspectos envolvidos no planejamento, montagem e execução dos experimentos.

No quinto capítulo, os dados são apresentados graficamente e são analisados os experi-mentos em termos das métricas utilizadas.

No sexto e último capítulo são feitas as considerações finais. São descritas as conclusões sobre a pesquisa, sobre a proposta e sobre a análise de tráfego. São apresentadas as limitações do trabalho e trazidos à luz os desafios que permanecem em aberto.

(25)

24 24 24

2

REFERENCIAL TEÓRICO

Dada a quantidade de subtemas que permeiam o tema central e que são fundamentais para a compreensão da abordagem proposta, é feita, a seguir, a fundamentação teórica e conceitual. Em seguida realizamos uma análise crítica e discussão comparativa dos principais trabalhos relacionados e utilizados na pesquisa. Primeiro analisaremos os trabalhos relacionados às abordagens que utilizam SDN para resolver problemas de QoS e QoE de vídeo, em seguida os dirigidos às técnicas de QoS em SDN, e por último os que têm foco nas métricas de QoS e o reflexo na qualidade de experiência do usuário.

2.1 CONCEITOS

GORANSSON; BLACK (2014) nos ajudam a entender os conceitos iniciais de SDN e planos. Inicialmente, confirmam que SDN representa uma nova abordagem que tenta atacar as fraquezas do paradigma tradicional de redes baseadas em melhor esforço, sendo uma nova maneira de programar os switches nas redes atuais. O movimento de SDN para uma arquitetura de controle de rede altamente escalável e centralizada é ainda mais eficiente em grandes redes onde prevalecem os centros de dados de larga escala. O interesse em SDN vai muito além das comunidades de pesquisa e engenharia intrigadas com essa nova tecnologia de comutação para Internet. Eles mencionam o potencial que as SDN possuem para proporcionar uma enorme mudança na indústria de redes, já que os operadores históricos da indústria poderiam ser destituídos e despencariam os custos para o consumidor final. No entanto, o documento também alerta para a necessidade de se compreender as limitações desse modelo.

2.1.1 A Comutação Tradicional

Os autores explicam que as diversas funções de comutação são tradicionalmente separa-das em três categorias distintas. Como cada categoria pode realizar comunicação horizontal com pares em entidades adjacentes, em uma topologia, e também pode realizar a comunicação vertical com as outras categorias, tornou-se comum representar estas categorias como camadas ou planos. Comunicações em pares ocorrem no mesmo plano, e mensagens de categorias cruzadas ocorrem em terceira dimensão, entre os planos. São definidos os planos de dados, controle e

(26)

gerencia-CAPÍTULO 2. REFERENCIAL TEÓRICO 25

mento, em switches tradicionais. A Figura 2.1 compara em alto nível as arquiteturas, tradicional e SDN. Percebe-se à esquerda um comutador rede que acumula funções, e à direita, em SDN, a presença de um controlador de rede que pode gerenciar vários comutadores. O sistema de

Figura 2.1: Arquitetura tradicional vs. SDN

Fonte: Adaptado de GORANSSON; BLACK (2014)

controle em redes tradicionais IP é distribuído, cada elemento de rede é uma entidade autônoma separada com seus próprios planos de controle e de encaminhamento. Os operadores de rede precisam acessar e configurar cada switch numa grande rede. As decisões de encaminhamento são baseadas nas informações compartilhadas entre outros dispositivos.

2.1.2 Os Planos

É importante destacar que a grande maioria dos pacotes manipulados pelo switch só são manipulados pelo plano de dados. O plano de dados é composto por várias portas que são utilizadas para a recepção e transmissão de pacotes, e uma tabela de encaminhamento com sua lógica associada. O plano de dados assume a responsabilidade pelo buffering e agendamento de pacotes, modificação cabeçalho e encaminhamento. Se as informações do cabeçalho de um pacote de dados que chega são encontradas na tabela de encaminhamento (o que é chamado de correspondência ou match), ele pode sofrer modificações de campo em seu cabeçalho e, em seguida, será encaminhado sem qualquer intervenção dos outros dois planos. Mas nem todos os

(27)

CAPÍTULO 2. REFERENCIAL TEÓRICO 26

pacotes serão manipulados no plano de dados, a informação do pacote pode não estar na tabela, ou ele pode pertencer a um protocolo de controle que será processado pelo plano de controle.

A Figura 2.2 dá uma visão geral do funcionamento da arquitetura de planos:

Figura 2.2: Arquitetura tradicional vs. SDN

Fonte: Adaptado de GORANSSON; BLACK (2014)

O plano de controle está envolvido em muitas atividades. O seu papel principal é manter a atualizada a informação da tabela de encaminhamento para que o plano de dados possa lidar de forma independente com a maior quantidade de tráfego possível. O plano de controle é responsável pelo processamento de diferentes protocolos de controle que podem afetar a tabela de encaminhamento, dependendo da configuração e tipo do switch. Estes protocolos de controle são corresponsáveis pelo gerenciamento da topologia ativa da rede. Eles são suficientemente complexos para exigir o uso de microprocessadores e software de acompanhamento do plano de controle.

O terceiro é o plano de Gerenciamento. Os administradores de rede configuram e controlam os switches através deste plano, que por sua vez, extrai a informação ou modifica os planos de controle e de dados de forma apropriada. Os administradores usam um sistema de gerenciamento de rede para se comunicar com o plano de gerenciamento de um switch.

2.1.3 Redes definidas por software

Ainda tomando como base os conceitos de GORANSSON; BLACK (2014), pode-se resumir que em sua essência, SDN é uma arquitetura de rede inovadora que desacopla plano

(28)

de controle e plano de dados, abstraindo a função de controle para um controlador de rede, logicamente centralizado. O controlador SDN mantém uma visão global da rede e fornece aplicações e políticas, com visão de único comutador lógico. SDN simplifica muito o design e operação de rede já que as instruções são fornecidas pelo controlador SDN em vez de vários dispositivos e protocolos de fornecedores. Atualmente, o protocolo OF (OPEN NETWORKING FOUNDATION, 2015a) é o mais utilizado como protocolo de comunicação entre plano de controle e de dados. O protocolo OF tem sido o responsável por viabilizar o suporte a SDN nos switches.

Várias pesquisas procuram consolidar os conceitos de SDN, entre elas o Request for Comments (RFC) do Internet Research Task Force (IRTF), da categoria informacional, HALE-PLIDIS et al. (2015) descreve as especificações de arquiteturas e camadas SDN. Ele define SDN como um paradigma para programação em redes, que habilita a capacidade de inicializar, controlar, alterar e gerenciar o comportamento da rede dinamicamente através de interfaces abertas. A RFC confirma que um dos princípios fundamentais de SDN é a separação entre os Planos de dados e controle, o que permite reduzir a complexidade e um ciclo de inovação mais rápido nos planos. Nesse conceito de separação, SDN estabelece uma relação entre uma entidade controladora e uma entidade controlada através de interfaces. A Figura 2.3 nos dá uma visão geral da arquitetura em camadas de SDN. Percebe-se aqui a presença das API entre os planos, divididas em norte (para aplicações mais externas, normalmente aplicações de monitoramento, gerenciamento e orquestração) e sul (para atuação de protocolos internos, para aplicações de controle, como OF).

Figura 2.3: Arquitetura em camadas SDN

(29)

Segundo OPEN NETWORKING FOUNDATION (2012), a arquitetura SDN tem algu-mas características mais importantes:

Programabilidade direta: O controle está desacoplado das funções de encaminha-mento;

Agilidade: o controle do encaminhamento permite aos administradores ajustar dina-micamente o fluxo da rede para atender necessidades específicas;

Gerenciamento centralizado: a inteligência é centralizada em controladores baseados em software que mantêm uma visão global da rede como único switch lógico; Configuração programática: SDN permite aos administradores configurar, gerenciar,

proteger e otimizar recursos de rede rapidamente por meio de programas dinâmicos e automatizados;

Padronização aberta livre fornecedor: simplifica o projeto e operação da rede porque as instruções são fornecidas pelos controladores SDN em vez de vários dispositivos e protocolos de fornecedores.

A Figura 2.4 consegue ilustrar bem a arquitetura SDN em suas três camadas. A camada de aplicação é onde são executadas as aplicações comerciais diversas. Na de controle está o plano de controle com os serviços de rede. E na de infraestrutura temos o plano de dados nos switches. Percebe-se na imagem as setas duplas que representam as API’s norte e sul (nesta se encontra o OF). OPEN NETWORKING FOUNDATION (2012) também mencionam OF como protocolo fundamental nas soluções SDN implementadas na atualidade.

Figura 2.4: Arquitetura em 3 camadas

(30)

2.1.4 O protocolo Openflow

OF é um padrão aberto que permite a implementação de protocolos de rede inovadores. O suporte ao protocolo vem sendo adicionado em switches comerciais. A especificação mais recente do protocolo descreve componentes e funções básicas do OF, ilustrado na Figura 2.5, onde o switch se comunica com um controlador através do protocolo OF. Segundo a especificação, um switch OF consiste em tabelas e grupos de tabelas para encaminhamento de pacotes, além de canais OF que o conecta a um ou mais controladores externos. Usando o protocolo OF, o controlador pode manipular (adicionar, atualizar e excluir) entradas nas tabelas de fluxo, reativamente ou proativamente (OPEN NETWORKING FOUNDATION, 2015a).

Figura 2.5: Componentes de um switch openflow

Fonte: Adaptado de OPEN NETWORKING FOUNDATION (2015a)

Quando um novo fluxo chega, o switch verifica a sua tabela de fluxos, caso não encontre uma entrada correspondente a este fluxo em seus registros, ele envia o pacote para o controlador através de uma mensagem "packet_in". Baseado em sua aplicação, o controlador decide o que fazer com o fluxo (encaminhar, descartar, enviar de volta) e o controlador informa ao switch instalando um novo fluxo em suas tabelas.

A procura por correspondência começa na primeira tabela de fluxos (Tabela 0) e pode continuar por tabelas adicionais formando um pipeline (conjunto de tabelas de fluxo logicamente conectadas para prover correspondência, encaminhamento e modificação de pacotes num switch OF). As entradas de fluxo testam a correspondência dos pacotes por ordem de prioridade, e utilizam a primeira entrada correspondente em cada tabela. Ao encontrar uma entrada correspon-dente, as instruções associadas a essa entrada são executadas. Se nenhuma correspondência for encontrada em uma tabela, o resultado depende da configuração da entrada de fluxo "table-miss", nesse caso o pacote pode ser encaminhado ao controlador pelo canal OF, descartado, ou pode seguir para a próxima tabela. As instruções de processamento do pipeline permitem que os pacotes sejam enviados por tabelas subsequentes. O processamento do pipeline encerra quando

(31)

as instruções não especificam mais uma próxima tabela, finalmente o pacote é modificado e encaminhado. Entradas de fluxos são encaminhados para uma porta do switch.

A Figura 2.6 mostra o processamento geral do pipeline. O pipeline OF de cada switch possui uma ou mais tabelas de fluxo. O processamento de pipeline OF define como os pacotes interagem com essas tabelas. Um switch OF precisa ter pelo menos uma tabela de ingresso, as tabelas são sequencialmente numeradas começando por 0.

2.1.5 Tabelas e pipeline Openflow

Figura 2.6: Fluxo do pacote no pipeline de processamento

Fonte: Adaptado de OPEN NETWORKING FOUNDATION (2015a)

As instruções executadas quando ocorre uma correspondência podem direcionar explici-tamente o pacote para outra tabela usando uma instrução "goto", e o mesmo processo de teste de correspondência vai se repetindo. Uma entrada de fluxo só pode direcionar um pacote para uma tabela de número maior do que o seu, ou seja, o processamento do pipeline só pode avançar. E, logicamente, os fluxos da última tabela de um pipeline não possuem a instrução "goto". Se a entrada de fluxo correspondente não direcionar pacotes para outra tabela, o processamento de pipelinefinaliza nessa tabela, o pacote é processado com seu conjunto de ações associadas e normalmente transmitido.

2.1.6 As entradas de fluxo

Uma tabela de fluxos é composta de entradas de fluxos, o Quadro 2.1 exibe os campos de uma entrada de fluxo.

Match fields: campos para corresponder com os pacotes. Estes consistem em porta de ingresso e cabeçalhos de pacotes, e, opcionalmente, outros campos de pipeline, como os metadados especificados por uma tabela anterior.

(32)

CAPÍTULO 2. REFERENCIAL TEÓRICO 31 Quadro 2.1: Componentes de um fluxo

Match Fields Priority Counters Instructions Timeouts Cookie Flags Fonte: OPEN NETWORKING FOUNDATION (2015a)

Priority: precedência de correspondência de fluxo.

Contadores: atualizados quando os pacotes são correspondidos.

Instruções: para modificar um conjunto de ações ou processamento de pipeline. Timeouts: quantidade máxima de tempo ou tempo ocioso antes que o fluxo seja

expirado pelo switch.

Cookie: valor escolhido pelo controlador. Pode ser usado pelo controlador para filtrar entradas de fluxo afetadas por requisições de estatísticas, modificação e de exclusão de fluxos. Não é usado no processamento dos pacotes;

Flags: alteram a forma como as entradas de fluxo são gerenciadas, por exemplo, a flag OFPFF_SEND_FLOW_REM gera mensagens de fluxo removido para essa entrada de fluxo.

Uma entrada na tabela de fluxo é identificada por seus campos de correspondência e prioridade. Os campos de correspondência e prioridade identificam uma entrada única em uma tabela específica. A entrada de fluxo em que todos os campos são omitidos e tem prioridade igual a 0 é chamada de entrada de fluxo "table-miss".

2.1.7 Correspondência

O pacote segue um fluxo básico através de um switch OF, como ilustra a Figura 2.7, no recebimento de um pacote (packet in), o switch executa um conjunto de ações. A primeira tabela (0) é inicialmente consultada e de acordo com o processamento do pipeline, pode consultar outras tabelas.

Campos de correspondência são extraídos do pacote. Esses campos usados para consultas em tabelas, dependem do tipo de pacote e tipicamente incluem vários campos de cabeçalho, como endereço Ethernet de origem ou o endereço de destino IPv4. Os metadados também podem ser usados para passar informações entre tabelas de um switch. Os campos de correspondência representam o pacote em seu estado atual, se as ações aplicadas em uma tabela anterior usando a instrução apply-actions mudar os cabeçalhos de pacotes, essas alterações são refletidas nos campos de correspondência.

(33)

Figura 2.7: Fluxograma do pacote através do switch OF

Fonte: Adaptado de OPEN NETWORKING FOUNDATION (2015a) 2.1.8 Recursos para QoS Openflow

Falando-se em implementação prática de QoS em SDN é importante conhecer os princi-pais recursos disponibilizados nas versões do protocolo OF. As principrinci-pais ferramentas são as Filas (Queues) e os Medidores (Meters). Tais recursos são formas simples de se obter QoS em SDN.

2.1.8.1 Filas

A especificação OF versão 1.0 já define o conceito de filas. Um switch OF fornece suporte limitado a QoS através de um mecanismo de enfileiramento simples. Uma ou mais filas podem ser associadas a uma porta e podem ser usadas para mapear fluxos nelas. Fluxos mapeados para um fila específica serão tratados de acordo com a configuração de fila (por exemplo, taxa mínima). Como mencionado, desde a versão inicial do OF que há suporte para filas, onde podem ser configurados limites de taxa de saída de pacotes por uma porta do switch para a implementação de QoS. As filas são projetadas para fornecer uma garantia de taxa de fluxo de pacotes colocados na fila. Assim, filas diferentes a taxas diferentes podem ser usadas para priorizar um tráfego "especial"sobre um tráfego "normal", ou limitar tráfegos "gananciosos". OF 1.0 e 1.1 suportam filas com a propriedade de taxa mínima, enquanto OF 1.2 e superiores adicionam a configuração de taxa máxima. É possível implementar Filas com Openvswitch (OvS). Alguns switches legados (não SDN) também suportam a configuração de filas em nível de sistema operacional ou através de interfaces proprietárias.

(34)

As Filas não podem ser configuradas diretamente através do protocolo OF, o que pode ser feito através de outros protocolos de configuração do switch, como OF-Config ou Open vSwitch Database (OVSDB), no entanto, suas estatísticas podem ser consultadas pelo OF. O objetivo desta sequência de mensagens, ilustrada na Figura 2.8, é permitir ao controlador consultar o estado de filas associadas a várias portas no switch OF, na versão 1.3.

Figura 2.8: Sequência de mensagens de filas OF

Fonte: Adaptado do site Flowgramable1

A estrutura mostrada na Figura 2.9 começa com um identificador "queue_id", que identifica unicamente uma fila. A estrutura primária termina com uma sequência de estruturas de propriedades. As propriedades vão indicar o tipo de carga útil presente nas propriedades. Inicialmente, existia apenas um tipo, a propriedade “MinRate”. OF 1.2 incluiu um identificador "port", que indica a porta da qual fila faz parte. Além disso, os tipos de propriedade foram aumentados com “Max Rate”, e “experimenter”. A carga útil do “experimenter” termina com um campo de dados de comprimento variável, e que pode ser utilizado para recursos de aplicações específicas.

Figura 2.9: Estrutura das filas

Fonte: Adaptado do site Flowgramable2

(35)

2.1.8.2 Os Medidores

A especificação do Openflow versão 1.3 já introduz o conceito de Medidor. OPEN NETWORKING FOUNDATION (2015a) define uma tabela de medidor consiste em entradas de medidor, definindo medidores por fluxo. Isso permite que o OF implemente técnicas de QoSsimples, restringindo um conjunto de fluxos a uma banda específica. Também permitem aplicação de políticas de QoS mais complexas, como a medição baseada em Differentiated Services Code Point (DSCP) que pode classificar um conjunto de pacotes em categorias com base na sua taxa. Medidores (por fluxo) podem ser combinadas com as filas (por porta) para implementar estruturas de QoS complexas, como Differentiated services (Diffserv).

Ainda com base no que diz OPEN NETWORKING FOUNDATION (2015a), pode-se concluir que um Medidor é um elemento de comutação que pode medir o tráfego na entrada e controlar a taxa de saída de pacotes. Cada medidor pode ter várias bandas de medidor que são usadas para definir o comportamento dos medidores em vários intervalos de taxa. Uma banda de medidor é ativada se a taxa de pacotes ou de bytes passante exceder um limite pré-determinado. É possível realizar dois tipos de operações baseadas nas taxas de fluxo: o descarte (banda limitadora de taxa); ou a remarcação de bits do campo DSCP dos pacotes. Desta forma, os fluxos podem orientar a execução de ações baseadas na taxa de pacotes recebidos.

É importante dizer que as estruturas de Medidores e Filas se complementam. Apesar de, por serem mais rígidas e necessitarem implementação pelo administrador da rede no switch (usando comandos OvS) em modo "out-of-band", há uma certa diferença em relação aos Medido-res, que podem ser instalados, modificados e removidos, em tempo de execução usando OF. Os Medidores podem ser manipulados de modo semelhante aos fluxos: eles recebem pacotes como entrada e podem enviar pacotes como saída. Atualmente, apenas no ofsoftswitch (CPqD; ERICS-SON INNOVATION CENTER, 2012) e outros switches de hardware proprietário suportam medidores OF completamente. O OvS não suporta medidores OF (PROJECT FLOODLIGHT, 2016).

Em resumo, Medidores e filas permitem que as redes criem perfis de largura de banda, estabelecendo limites e garantias sobre o tráfego de classes específicas. Com SDN, esses limites não são fixos como parte de uma topologia estática, o provisionamento baseado em políticas pode ser implantado de forma dinâmica, e o hardware flexível em SDN pode ajustar dinamicamente associações de Medidores e filas.

2.1.9 OpenvSwitch

Segundo LINUX FOUNDATION (2009), o OvS é uma plataforma aberta multicamada, de comutação virtual de qualidade para produção. OvS foi projetado para permitir automação de rede em massa, mantendo compatibilidade com outros protocolos. Ele suporta gerenciamento padrão das interfaces e abre as funções de encaminhamento para controle e extensão programática. O OvS é bem adequado para funcionar como um switch virtual em ambientes virtualizados.

(36)

Além disso ele foi projetado para suportar a distribuição através de múltiplos servidores físicos, ideal para hipervisores. Esses ambientes são caracterizados pelo comportamento dinâmico dos pontos; necessidade de manutenção das abstrações lógicas; necessidade de integração ou descarga para hardware de comutação especial. A Figura 2.10 ilustra recursos do OvS. Por questões de desempenho, um dos objetivos do OvS é manter o código do seu núcleo o menor possível e reaproveitar subsistemas existentes, (como QoS). Atualmente, o OvS e seus pacotes de utilitários para o espaço de usuário estão disponíveis nas distribuições Linux mais populares. O OvS, naturalmente, também é bastante utilizado na maioria dos experimentos que envolvem comutação baseada em SDN, fazendo parte, inclusive, da instalação padrão do Mininet3.

Figura 2.10: Elementos e recursos do OvS

Fonte: Adaptado de LINUX FOUNDATION (2009) Os principais componentes do OvS são:

ovs-vswitchd: implementa um comutador junto com módulo de kernel (núcleo) Linux para comutação baseada em fluxos;

ovsdb-server: um servidor de banco de dados leve que o ovs-vswitchd consulta para obter sua configuração;

ovs-dpctl: ferramenta para configurar o núcleo do switch; ovs-vsctl: consulta e atualização do ovs-vswitchd;4

ovs-appctl: envio de comandos de execução de daemons (processo em plano de fundo) OvS;

ovs-ofctl: consulta e controle de switches e controladores;

3_{http://mininet.org/}

4_{A maioria dos comandos de configuração de QoS foram feitos neste trabalho acessando diretamente a}

(37)

ovs-pki: criar e gerenciar chaves públicas; ovs-testcontroller: simples controlador OF;

O suporte a QoS está disponível no OvS. Para o tráfego ingressante, o OvS suporta a aplicação de políticas de QoS. Quando o tráfego sai do switch, o OvS pode realizar a moldagem do tráfego. A aplicação de políticas é uma forma simples de QoS, onde basicamente os pacotes que são recebidos em excesso (em relação a uma taxa geral configurada) são descartados. Por essa simplicidade, é geralmente realizado o controle de QoS na saída, onde os pacotes são enfileirados nas portas do switch.

Além do OvS, outras plataformas estão disponíveis para o padrão OF, com características específicas:

Open vSwitch: implementado em C e Python, com foco em plataforma de comu-tação para ambientes de servidores virtuais. Suporta gerenciamento de interfaces e programação das funções de encaminhamento. Pode ser instalado em switches ASICs;

Pantou/OpenWRT: escrito em C, transforma um roteador comercial ou Ponto de acesso, num switch OF;

ofsoftswitch 1.3: implementação em C/C++ compatível com o protocolo 1.3 em espaço do usuário.

Indigo: implementação em C aberta do OpenlFlow que roda em switches físicos e usa recursos de hardware dos switches Ethernet ASICs para rodar o OF.

2.1.10 O Controlador de rede

Para NUNES et al. (2014), o controlador é o elemento da rede SDN que fornece uma interface programável para a rede. Ele pode ser usado para implementar tarefas de gerenciamento e fornecer novas funcionalidades. Com a lógica de controle separada, como um sistema opera-cional de rede, aplicações podem ser construídas para programar a rede. Esse modelo permite que SDN atenda a uma gama de aplicações, tecnologias heterogêneas e meios de comunicação como ethernet, wifi, e redes óticas. As aplicações podem ser escritas em várias linguagens, a depender da implementação do controlador, como Java, C/C++, Python, podendo interagir com uma API do tipo Representational State Transfer (REST). Um controlador pode ter arquiteturas centralizadas ou distribuídas.

Tipicamente, a unidade básica em redes é o pacote, que por sua vez possui as informações para a tomada de decisões de roteamento por um comutador. No entanto, as aplicações enviam dados em forma de fluxos de vários pacotes agregados por características comuns. Essa agregação pode ser baseada em informações como origem, destino, aplicação, ou por combinações destes. Uma rede pode fornecer QoS realizando o controle baseado em fluxo.

(38)

Ainda segundo NUNES et al. (2014), numa SDN, onde os elementos da rede são controlados remotamente, uma sobrecarga é gerada pelo tráfego entre o plano de dados e de controle. Um controle granular no nível de pacote geraria um atraso importante, pois o controlador teria que tomar uma decisão para cada pacote ingressante. No controle por fluxos, a decisão tomada no primeiro pacote desse fluxo é aplicada aos subsequentes. A sobrecarga pode ser ainda menor utilizando-se agrupamentos de fluxos.

Segundo LIU et al. (2015), um controlador pode trabalhar com implantação de regras em modo reativo ou proativo.

No modo reativo, os elementos de encaminhamento devem consultar o controlador, enviando eventos, sempre que uma decisão precise ser tomada, por exemplo, quando um pacote de um novo fluxo chega ao switch. Haverá sempre uma pequena perda de desempenho na entrada do primeiro pacote de um fluxo, pois ele precisará ser encaminhado ao controlador para tomar a decisão. O controlador cria e instala uma regra na entrada de fluxo para o pacote correspondente somente se requisitado. Segundo MOSHREF et al. (2014), o modo reativo suporta aplicações mais dinâmicas, mas possui baixo desempenho devido à sobrecarga computacional significativa (CPU, memória), maior degradação da rede (atraso, vazão) e problemas de escalabilidade devido ao canal de comunicação limitado entre controlador e switches.

O controle proativo aborda a implantação de políticas do controlador para os switches. O controlador preenche as entradas de fluxo para todas as correspondências de tráfego possíveis antes dos fluxos chegarem ao switch. Desta forma, o controlador raramente precisará ser consultado sobre novos fluxos e o tráfego é mantido no plano de dados. O quadro 2.2 lista os controladores abertos mais populares:

Quadro 2.2: Controladores abertos populares

Controlador Linguagem Desenvolvedor

POX Python Nicira

NOX Python/C++ Nicira

MUL C Kulcloud

Trema Ruby/C NEC

Beacon Java Stanford

Floodlight Java BigSwitch

Ryu Python NTT, OSGR group

NodeFlow Javascript Desenvolvedores independentes

ovs-controller C Desenvolvedores independentes

RouteFlow C++ CPqD

ONOS Java Open Networking Lab(ON.LAB)

Opendaylight Java Linux Foundation

(39)

2.1.10.1 O controlador de rede Ryu

Ryu5é um controlador SDN baseado em componentes. Ryu foi projetado para aumentar a agilidade da rede e fornece componentes de software com API bem definida que facilitam a criação de novas aplicações de gerenciamento e controle de rede. Esta abordagem de compo-nentes auxilia as organizações e seus desenvolvedores a personalizar suas implementações para atender necessidades específicas.

A Figura 2.11 ilustra os elementos da arquitetura. O Framework SDN Ryu disponibiliza uma API bem definida e bibliotecas muito úteis para construção de aplicações para SDN. Escrito totalmente em Python, o Ryu suporta vários protocolos de gerenciamento, como OF, além de Netconf e OF-config. Suporta totalmente as versões entre 1.0 e 1.5 do protocolo OF. Seu código está disponível gratuitamente sob a licença aberta (RYU SDN FRAMEWORK COMMUNITY, 2012).

Figura 2.11: Arquitetura do Controlador Ryu

Fonte: Adaptado do site SDX Central6

O controlador Ryu possui uma arquitetura orientada a eventos, cujo modelo básico de aplicação é ilustrado na Figura 2.12. A comunicação entre aplicações é realizada pela transmissão e recebimento de eventos de forma assíncrona, sendo que também existem fontes de eventos internos que não são aplicações Ryu, como o controlador OF (caminho de dados). Cada aplicação possui uma simples fila First In, First Out (FIFO) para receber eventos e uma thread para processamento dos mesmos. A thread executa um loop de eventos, onde ela vai retirando eventos da fila e chamando o manipulador de eventos apropriado a cada loop.

Como o Manipulador é chamado no contexto da thread de processamento de eventos, o bloqueio da comunicação deve ser realizado. Enquanto o manipulador estiver bloqueado nenhum outro evento para a aplicação Ryu será processado. Um evento pode conter eventos de objetos Python, não sendo recomendado passar eventos complexos entre aplicações Ryu.

(40)

Figura 2.12: Arquitetura baseada em eventos de uma aplicação Ryu

Fonte: Adaptado de ryu book7 2.1.11 Métricas de Qualidade de Serviço

Segundo KRISHNA (2016), QoS é um mecanismo para melhorar o desempenho das redes. Um administrador pode gerenciar os seus recursos e prover elevados níveis de serviço sem que haja sobrecarga. QoS é importante em aplicações que necessitam de garantias específicas. Aplicações de Streaming de vídeo, por exemplo, requerem baixos atrasos e pouca variação no atraso de chegada dos pacotes (jitter). Já a comunicação de dados é menos sensível a atrasos e jitter, sendo mais sensível à perda de pacotes. Sobre as principais métricas de QoS temos:

Atraso: tempo que uma mensagem leva entre o envio por um remetente e a recepção pelo destinatário. O atraso pode ser ocasionado por características do meio de trans-missão e pelo tempo de processamento dos dispositivos da rede. Atrasos altos, acima de 150 Milissegundos (ms) podem ocasionar causar interrupções numa comunicação contínua e baixar percepção de qualidade em um vídeo.

jitter: a variação do atraso causado pela diferença de tempos de chegada entre os pacotes que trafegam por rotas diferentes na rede. Ter taxas de jitter altas pode causar distorções no sinal recebido, podendo causar efeitos como intervalos de tempo vazios, o que pode prejudicar a compreensão da informação. Segundo RAHRER et al. (2006), para vídeo em HD com codificação MPEG-4 o jitter deve ser abaixo de 50 ms.

perda de pacotes: durante o tráfego na rede, muitos pacotes podem ser perdidos pelo caminho, acontece também quando se trabalha com tráfego com taxa acima da capacidade do canal. O protocolo UDP, diferente do TCP, não realiza o controle e retransmissão dos quadros perdidos, o que pode ser crítico na transmissão multimídia.