Universidade Federal do Esprito Santo

Eros Silva Spalla

Estratgias para Resilincia em SDN:Uma Abordagem Centrada emMulti-Controladores Ativamente

Replicados

Vitria-ES2015

Eros Silva Spalla

Estratgias para Resilincia em SDN:Uma Abordagem Centrada emMulti-Controladores Ativamente

Replicados

Dissertao para obteno do graude mestre em Informtica apresen-tada Universidade Federal do Es-prito Santo

rea de concentrao: Cincia daComputao

Orientador: Magnos Martinello

Vitria-ES2015

Spalla, Eros S.Estratgias para Resilincia em SDN: Uma Aborda-

gem Centrada em Multi-Controladores Ativamente Re-plicados

70 pginasDissertao (Mestrado) - Universidade Federal do

Esprito Santo.

1. SDN

2. OpenFlow

3. Resilincia

Eros Silva Spalla

Estratgias para Resilincia em SDN:Uma Abordagem Centrada emMulti-Controladores Ativamente

Replicados

Dissertao para obteno do grau de Mestre em Infor-mtica apresentada Universidade Federal do EspritoSanto. rea de concentrao: Cincia da Computao.

Aprovada em 10/07/2015

Prof. Dr. Magnos MartinelloOrientador

Prof. Dr. Rodolfo da Silva VillaaExaminador

Prof. Dr. Rafael Rodrigues ObelheiroExaminador

Dedico este trabalho minha famlia e amigos.

Agradecimentos

Agradeo ao meu orientador Magnos pelo acompanhamento, pela motivao constante,compreenso quando o tempo foi curto, e por todas as direes indicadas e ensinamentospassados ao longo do mestrado; ao professor Rodolfo por toda colaborao ao trabalho, es-pecialmente por suas excelentes revises; ao Christian e o Lasaro pelas valiosas discussessobre SDN e replicao de dados.

Tambm no poderia esquecer de meus companheiros do NERDS, que sempre foramcolaborativos e solcitos. Gostaria de agradecer especial o Alextian e o Diego, esses doisque fazem o dia ter 30 horas, por sempre terem sido os grandes parceiros de todos osmomentos, desde os primeiros trabalhos das disciplinas, at a correria dos vrios deadlines.

Por fim, agradeo aos meus pais, Walter e Leninha, s minhas irms, J e Mila,e minha namorada Fran, por todos os momentos de carinho e amor que vocs meproporcionam. Apesar das distncias, sempre mantive vocs por perto.

Resumo

As Redes Definidas por Software (SDN) separam os planos de dados e de controle. Em-bora o controlador seja logicamente centralizado, ele deve ser efetivamente distribudopara garantir alta disponibilidade. Desde a especificao OpenFlow 1.2, h novas funci-onalidades que permitem aos elementos da rede se comunicarem com mltiplos contro-ladores, que podem assumir diferentes papis master, slave e equal. Entretanto, essespapis no so suficientes para garantir resilincia no plano de controle, pois delega-seaos projetistas de redes SDN a responsabilidade por essa implementao. Neste trabalho,exploramos os papis definidos no protocolo OpenFlow no projeto de arquiteturas resili-entes SDN com base em multi-controladores. Como prova de conceito uma estratgia dereplicao ativa foi implementada no controlador Ryu usando o servio OpenReplica paragarantir a consistncia dos estados. O prottipo foi testado com switches comerciais debaixo custo(RouterBoards/MikroTik) avaliando-se a latncia na recuperao de falha, namigrao de switches entre controladores e de processamento de packet-in pelos contro-ladores. Observamos diferentes compromissos de projeto em experimentos em ambientereal sujeitos variao de carga nos planos de dados e de controle.

Palavras-chave: SDN, OpenFlow, Resilincia, Alta-Disponibilidade.

Abstract

Software Defined Networking (SDN) are based on the separation of control and data pla-nes. The SDN controller, although logically centralized, should be effectively distributedfor high availability. Since the specification of OpenFlow 1.2, there are new features thatallow the switches to communicate with multiple controllers that can play different roles master, slave and equal. However, these roles alone are not sufficient to guarantee aresilient control plane and the actual implementation remains an open challenge for SDNdesigners. In this paper, we explore the OpenFlow roles for the design of resilient SDNarchitectures relying on multi-controllers. As a proof of concept, a strategy of active re-plication was implemented in the Ryu controller, using the OpenReplica service to ensureconsistent state among the distributed controllers. The prototype was tested with com-modity RouterBoards/MikroTik switches and evaluated for latency in failure recovery,switch migration and packet-in latency with different workloads. We observe a set oftrade-offs in real experiments with varying workloads at both data and control plane.

Keywords: SDN, OpenFlow, Resilience, High-Availability.

Lista de Figuras

2.1 Arquitetura Fechada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Arquitetura SDN [Foundation 2012]. . . . . . . . . . . . . . . . . . . . . . 172.3 Organizao do controlador Nox [Rao 2015a]. . . . . . . . . . . . . . . . . 182.4 Organizao do controlador OpenDayLight [OpenDayLight 2015]. . . . . . 192.5 Organizao do controlador Ryu [Rao 2015b]. . . . . . . . . . . . . . . . . 192.6 Switch OpenFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Arquitetura Clssica x Arquitetura OpenFlow. . . . . . . . . . . . . . . . . 232.8 Equipamento OpenFlow [Foundation 2012]. . . . . . . . . . . . . . . . . . 24

3.1 Onix: arquitetura de controle distribuda[Koponen et al. 2010]. . . . . . . . 283.2 Controlador com replicao passiva[Fonseca et al. 2013]. . . . . . . . . . . 293.3 Controlador com replicao ativa[Fonseca et al. 2013]. . . . . . . . . . . . . 303.4 Arquitetura Smartlight[Botelho et al. 2014]. . . . . . . . . . . . . . . . . . 31

4.1 Replicao Ativa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Replicao Passiva. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Monitoramento via agente externo. . . . . . . . . . . . . . . . . . . . . . . 374.4 Monitoramento via controladores. . . . . . . . . . . . . . . . . . . . . . . . 384.5 Monitoramento via switches. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Proposta de arquitetura Resilincia para o plano de controle OpenFlow. . . 415.2 Open Replica para replicao e sincronizao do estado. . . . . . . . . . . . 425.3 Organizao do controlador implementado. . . . . . . . . . . . . . . . . . . 445.4 Deteco de falha via controladores OpenFlow. . . . . . . . . . . . . . . . . 445.5 Processo de Recuperao de Falha. . . . . . . . . . . . . . . . . . . . . . . 455.6 Processo de Restaurao da Falha. . . . . . . . . . . . . . . . . . . . . . . 475.7 Deteco de falhas via switch OpenFlow. . . . . . . . . . . . . . . . . . . . 49

6.1 Recuperao e Restaurao de Falha - Trfego no Plano de Controle . . . . 546.2 Carga de Processamento nas RouterBoards - Trfego no Plano de Controle 546.3 Latncia de Deteco de Falhas pelos Controladores . . . . . . . . . . . . . 556.4 Latncia Processamento de Packet-in - Trfego no Plano de Controle . . . 566.5 Recuperao e Restaurao da Falha - Trfego no Plano de Dados. . . . . . 566.6 Carga de Processamento nas RouterBoards - Trfego no Plano de Dados . 576.7 Latncia de Deteco de Falhas pelos Switches. . . . . . . . . . . . . . . . . 586.8 Latncia deteco e recuperao falha - switch versus controlador. . . . . . 586.9 Deteco de falha - Switch x Controlador. . . . . . . . . . . . . . . . . . . 59

Lista de Tabelas

2.1 Tabela com o resumo das caractersticas dos principais Controladores. . . . 202.2 Tabela Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Tabela Evoluo OpenFlow [Tourrilhes et al. 2014]. . . . . . . . . . . . . . 27

6.1 Latncia mdia em milisegundos de acordo com o nmero de controladorese a taxa de packet-in/s por controlador. . . . . . . . . . . . . . . . . . . . 60

Lista de Abreviaturas e Siglas

BYOA Bring Your Own App

BYOD Bring Your Own Device

CAP Consistency, Availability e Partition Tolerance

CPqD Centro de Pesquisa e Desenvolvimento em Telecomunicaes

CPU Computer Processor Unit

GRE Generic Routing Encapsulation

ICMP Internet Control Message Protocol

IP Internet Protocol

IPsec IP Security Protocol

IPV6 Internet Protocol Version 6

L3 Layer 3

MAC Media Access Control

MBPS Mega Bits Por Segundo

MPLS Multiprotocol Label Switching

MS Milissegundo

NAT Network Address Translation

NIB Network Information Base

OF OpenFlow

OO Orientado a Objetos

OS Operating System

OVS Open Virtual Switch

QoS Quality of Service

SCTP Stream Control Transmission Protocol

SDN Software Defined Network

TCAM Ternary Content Access Memory

TCP Transport Control Protocol

TI Tecnologia da Informao

TTL Time to Live

UDP User Datagram Protocol

VLAN Virtual Local Area Network

Sumrio

1 Introduo 121.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Contribuio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Fundamentao Terica 142.1 Limitaes da Arquitetura de Rede Tradicional . . . . . . . . . . . . . . . 142.2 Arquitetura de Redes Definidas por Software . . . . . . . . . . . . . . . . . 16

2.2.1 Plano de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.2 Plano de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Mensagens OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.2 Evoluo do OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Trabalhos Relacionados 283.1 Onix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Replicao Passiva e Ativa em SDN . . . . . . . . . . . . . . . . . . . . . . 283.3 SmartLight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Plano de Controle Resiliente 324.1 Configurao Equal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Configurao Master-Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Configurao Multi-Master / Multi-Slave . . . . . . . . . . . . . . . . . . . 354.4 Configurao via Data Store . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Deteco de Falha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.5.1 Utilizando Agentes Externos . . . . . . . . . . . . . . . . . . . . . . 374.5.2 Utilizando os Controladores OpenFlow . . . . . . . . . . . . . . . . 374.5.3 Utilizando os switches OpenFlow . . . . . . . . . . . . . . . . . . . 38

4.6 Consideraes parciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Implementao do Prottipo 415.1 Data Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Plano de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.1 Deteco de Falhas via Plano de Controle . . . . . . . . . . . . . . 445.2.2 Tratamento da Falha . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Plano de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3.1 Deteco de Falhas via Plano de Dados . . . . . . . . . . . . . . . . 48

6 Avaliao Experimental 506.1 Plataforma de Avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.1.2 Carga de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.1.3 Medies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Discusso dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2.1 Avaliao do Ambiente Real . . . . . . . . . . . . . . . . . . . . . . 53

6.2.1.1 Desempenho do plano de controle . . . . . . . . . . . . . . 536.2.1.2 Desempenho do plano de dados . . . . . . . . . . . . . . . 56

6.2.2 Avaliao Latncia com Mltiplos Controladores . . . . . . . . . . . 596.2.3 Comentrios finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Concluso e Trabalhos Futuros 63

Referncias Bibliogrficas 65

Publicaes do Autor 70

Captulo 1

Introduo

1.1 Contextualizao

A flexibilidade oferecida pela arquitetura das Redes Definidas por Software (SDN

Software-Defined Networking) apoia-se na separao do plano de controle do plano de

dados, permitindo a implementao das funes de controle de rede a partir de uma viso

centralizada [Kreutz et al. 2015]. Nesta abordagem, o estado dos dispositivos da rede

determinado por um controlador, que envia suas decises aos dispositivos, sob a forma de

entradas nas tabelas de fluxos por meio do protocolo OpenFlow [Rothenberg et al. 2010].

Atualmente, o protocolo OpenFlow considerado o padro de facto em SDN. Porm,

garantir alta disponibilidade no plano de controle um desafio em aberto para o qual o

protocolo OpenFlow no oferece uma soluo pronta, e sim um conjunto de possibilidades.

Desde a verso 1.2 da especificao, o OpenFlow tem incorporado novas funcionalidades

que permitem aos switches se comunicarem com mltiplos controladores. Uma dessas

funcionalidades so os papis (roles) de master, equal e slave, assumidos por mltiplos

controladores na comunicao com os dispositivos no plano de dados. Entretanto, apenas

essas novas features no so suficientes para garantir uma soluo resiliente, uma vez que,

o padro OpenFlow define os papis, mas deixa a cargo dos projetistas de redes SDN a

escolha de estratgias para implement-las.

Uma onda de trabalhos recentes tem abordado o problema de resilincia em re-

des SDN (ex: Sec.V [Kreutz et al. 2015]), incluindo o posicionamento de controladores

distribudos [Heller et al. 2012], clustering [Penna et al. 2014], particionamento do con-

trole [Koponen et al. 2010], garantias de consistncia [Botelho et al. 2013], entre outros.

Uma caracterstica comum a todos os trabalhos relacionados que encontramos no terem

explorado as opes de conectividade simultnea com mltiplos controladores, usando as

trs opes de papis disponveis no protocolo OpenFlow.

13

1.2 Contribuio

A primeira contribuio do trabalho apresentar e discutir diferentes estratgias de re-

plicao do plano de controle e seus trade-offs, abordando aspectos prticos de cada uma.

Nossa proposta baseia-se no levantamento das caractersticas e componentes que tornam

esses sistemas funcionais, tais como a relao entre papis OpenFlow dos controladores

e a distribuio de estados, assim como o comportamento da rede em caso de falha e

restaurao nos controladores.

Como prova de conceito de um plano de controle resiliente, uma estratgia de replica-

o ativa foi implementada no controlador Ryu1, e o prottipo foi testado com switches

RouterBoards comerciais, modificados por uma arquitetura aberta [Liberato et al. 2014],

onde foram observadas a latncia na recuperao de falha e restaurao de falha/migrao

de switches entre controladores. A descrio do prottipo implementado e a anlise ex-

perimental so nossa segunda contribuio ao estado da arte, j que a maior parte dos

trabalhos relacionados apenas consideraram ambientes emulados.

Nossa terceira contribuio diz respeito ao modo de deteco de falhas dos controla-

dores. E neste caso as especificaes do OpenFlow delegam essa funo aos projetistas de

redes, apesar da verso 1.5 apresentar uma nova feature que possibilita aos controlado-

res receberem eventos sobre o estado da conexo de outros controladores da rede. Desse

modo, propomos uma nova tcnica de deteco de falha, em que os controladores so

notificados a partir de um mecanismo implementado nos switches.

1.3 Estrutura

O restante deste trabalho est estruturado da seguinte forma: o Captulo 2 apresenta a

fundamentao terica, o objetivo deste captulo discutir aspectos tericos importantes

para compreenso do trabalho, deste modo, discutimos os principais conceitos sobre redes

SDN e o protocolo OpenFlow, evidenciando os elementos bsicos para um ambiente SDN.

H uma mirade de questes de pesquisa em recentes trabalhos relacionados distribuio

de controle em redes SDN objetivando solues de alta disponibilidade, todavia, no Ca-

ptulo 3 citamos apenas os trabalhos mais prximos ao foco da proposta deste trabalho,

que a soluo do problema de conectividade com mltiplos controladores e o uso de

data stores para consistncia do estado. O Captulo 4 discute diferentes abordagens para

implementao de resilincia em controladores OpenFlow. O Captulo 5 apresenta uma

proposta para controladores resilientes. O Captulo 6 lista os procedimentos metodolgi-

cos, expe os resultados obtidos e aponta o comportamento do experimento em ambiente

real. Por fim, no Captulo 7 so tecidas as consideraes finais e a direo dos trabalhos

futuros.

1https://github.com/osrg/ryu

Captulo 2

Fundamentao Terica

2.1 Limitaes da Arquitetura de Rede Tradicional

Observando a infraestrutura de comunicao de dados existente, podemos afirmar que as

redes de computadores se tornaram um ponto crtico em praticamente todas as reas de ne-

gcio que conhecemos. Existem milhares de aplicaes que funcionam sobre um estrutura

de switches, roteadores, bridges, firewalls e etc., que necessitam de caractersticas como:

confiabilidade, segurana, baixa latncia, flexibilidade, e escalabilidade, para citar algu-

mas. Entretanto, apesar do aumento das capacidades dos canais de comunicao e maior

poder de processamento dos equipamentos de rede permitirem o surgimento de uma grande

quantidade de aplicaes ([Ghemawat et al. 2003], [DeCandia et al. 2007],[Dean and Ghemawat 2008],

[Chang et al. 2008]), a rede em sua infraestrutura, do ponto de vista arquitetural, no

apresentou tantas mudanas.

Desde o momento em que as redes passaram a empregar equipamentos como switches

e roteadores para encaminhar pacotes, a estrutura pouco se alterou. Fabricantes criam

equipamentos como uma caixa-pretas, de modo que o firmware esteja encapsulado e fe-

chado no hardware, fundindo-os como se fossem uma entidade nica. E ento, empresas

constroem suas redes como um aglomerado de caixas-preta interligadas.

Este modelo estabelecido frequentemente referenciado, do ponto de vista estrutural,

como uma beno e uma maldio. A forma como a evoluo da rede se deu, criou

como base um emaranhado de protocolos e camadas de equipamentos, que apesar de

permitir a comunicao da forma como conhecemos hoje, ergueu-se uma enorme barreira

para inovaes e experimentaes necessrias rea de redes de computadores. Qualquer

inovao nessa infraestrutura representa um processo de alta complexidade. Segundo Nick

Mckeown[McKeown 2009], pouca tecnologia transferida da academia para o mercado,

e em geral, a partir de sua concepo, uma inovao leva at 10 anos para entrar em

produo.

Tradicionalmente, esse modelo impe diversas barreiras para os administradores de

15

redes. Por exemplo, se o administrador de redes desejar realizar alguma alterao na

lgica de tratamento/encaminhamento e/ou roteamento dos pacotes, o equipamento no

permite, pois apenas uma interface de alto nvel disponibilizada para configurao do

hardware. E assim, normalmente, a adio de novas features significa novos produtos

ou novas licenas de software, o que cria uma profunda dependncia dos fabricantes de

hardware. A Figura 2.1 apresenta um exemplo de equipamentos com arquitetura fechada.

--------APP APP

Operating System

Specialized PacketForwarding Hardware

APP

--------APP APP

Operating System

Specialized PacketForwarding Hardware

APP

--------APP APP

Operating System

Specialized PacketForwarding Hardware

APP

--------APP APP

Operating System

Specialized PacketForwarding Hardware

APP

--------APP APP

Operating System

Specialized PacketForwarding Hardware

APP

Figura 2.1: Arquitetura Fechada.

A seguir, destacamos alguns pontos que explicitam a necessidade de um novo para-

digma de redes em face s demandas atuais:

1. Novos padres de trfego: atualmente, com os grandes Data Centers de empresas

que provm servios como computao na nuvem, redes centradas em contedo, e

outros, os padres de trfego mudaram sensivelmente. Ao contrrio de uma co-

municao cliente-servidor tradicional, em que um cliente conecta-se a um servidor

em uma comunicao vertical, as novas aplicaes utilizam diferentes bancos de

dados e servidores, o que significa que para a requisio, esse fluxo de dados ir

envolver diversos pontos da rede antes de retornar ao usurio. Tambm, a forma

como o usurio se conecta e interage como a rede, seja via um smartphone, tablet

ou computador altera esses padres de trfego, j que cada um desses equipamentos

tem sua forma de consumir e gerar dados;

2. consumerizao de TI: usurios cada vez mais fazem acesso s redes corporativas

a partir de diferentes dispositivos como smartphones e tablets. Desse modo, existe

uma necessidade crescente de configuraes especficas de acordo com o perfil dos

16

usurios, a fim de permitir o acesso rede, ao mesmo que tempo em que os nveis

de segurana sejam mantidos. Essa mudana, onde bring your own device (BYOD)

e bring your own app (BYOA) foram os principais agentes transformadores, traz

um grande desafio para a gerncia de TI, j que so comportamentos que esto em

plena evoluo e condizem com a perspectiva atual de TI, em que a tecnologia est

cada vez mais presente, intuitiva e user-driven.

3. Computao na nuvem e virtualizao: com o advento da computao na nuvem,

empresas vislumbraram diversas possibilidades para seus negcios, o que resultou

em um crescimento expressivo das solues em nuvem. Todavia, manter uma infra-

estrutura do tipo cloud envolve requisitos de segurana, disponibilidade, escalabili-

dade, auditoria, mudanas das regras de negcio, e grande volume de dados, o que

significa uma estrutura complexa. Entretanto, ainda assim, desejvel que todo o

gerenciamento da infraestrura seja simples.

2.2 Arquitetura de Redes Definidas por Software

As Redes Definidas por Software surgiram como um promissor conceito para o pro-

jeto de novas arquiteturas para a Internet [McKeown 2009]. O ponto central das SDN

encontra-se na separao dos planos de dados e de controle em uma interface uniforme,

independente de fornecedor, para o mecanismo de encaminhamento (ex.: OpenFlow

[McKeown et al. 2008]).

Lantz [Lantz et al. 2010] explica que em uma rede definida por software o plano de

controle (ou sistema operacional de rede) separado do plano de dados. Normalmente,

o sistema operacional de rede observa e controla o estado de toda a rede a partir de um

ponto central, oferecendo recursos como: protocolos de roteamento, controle de acesso,

virtualizao de rede, gesto de energia e tambm prototipao de novos protocolos. A

principal consequncia das SDN que as funcionalidades da rede podem ser facilmente

alteradas ou mesmo definidas aps a rede ter sido implantada. Novas funcionalidades

podem ser adicionadas, sem a necessidade de se modificar o hardware, permitindo que o

comportamento da rede evolua na mesma velocidade que o software.

Entretanto, o aspecto mais importante de uma rede SDN o alto grau de flexibilidade

oferecido pela programabilidade da rede, uma vez que os projetistas de redes tm a pos-

sibilidade de configurar e escrever suas aplicaes por meio de uma camada de abstrao de

alto nvel, em vez de aguardar um update de firmware ou um novo produto do fabricante.

E mais, isso permite que a cada alterao na lgica de encaminhamento da rede ou

adio de uma nova feature, o cdigo da aplicao seja simplesmente atualizado. Como a

camada de aplicao independe do hardware, a evoluo da aplicao pode ser dinmica e

constante. Assim, todo o poder que uma linguagem de programao pode oferecer, passa

17

a estar disponvel para ser utilizada em uma aplicao SDN.

APPLICATION LAYER

CONTROL LAYER

INFRASTRUCTURE LAYER

Business Applications

API API API

Network Services

SDN

Control

Software

Control Data Plane interface(e.g., OpenFlow)

Network DeviceNetwork Device Network Device

Network DeviceNetwork Device

Figura 2.2: Arquitetura SDN [Foundation 2012].

A Figura 2.2 apresenta a viso lgica da arquitetura SDN. A inteligncia da rede

centralizada (logicamente) em controladores SDN, os quais mantm a viso global dos

estados da rede. Como resultado dessa abstrao, para a camada de aplicao, a rede

apresentada como um nico switch lgico. Como a viso da rede logicamente centra-

lizada, a implementao e operao da rede torna-se mais simples, assim como o plano

de dados. Como equipamentos de encaminhamento passam a ter uma funo muito bem

definida, que encaminhar pacotes, isso permite que o hardware tambm possa ser mais

simples, o que pode resultar em um equipamento com um custo mais baixo.

Abaixo, listamos algumas caractersticas inerentes ao uso de SDNs [Foundation 2012]:

Gerenciamento e controle centralizado dos equipamentos de mltiplos fabricantes;

Maior capacidade de inovao, j que que novas ferramentas e servios podem surgir

por meio de aplicaes desenvolvidas, ou seja, por desenvolvimento de software, sem

a necessidade fazer alteraes no hardware;

Controle granular da rede, com possibilidade de aplicar diferentes polticas de segu-

rana a diferentes perfis de usurios e equipamentos;

Melhoria da automao do gerenciamento, usando diferentes APIs para abstrair os

detalhes da rede para outras aplicaes, como sistemas de orquestrao, sistemas de

provisionamento e aplicaes de rede.

Nas prximas duas subseces apresentaremos pontos relevantes da arquitetura SDN,

em especial os planos de controle e dados, alm de uma descrio do protocolo OpenFlow.

Essas informaes sero teis para compreenso da arquitetura proposta.

18

2.2.1 Plano de Controle

O plano de controle de uma rede SDN a abstrao que encapsula os conceitos relaciona-

dos ao controle de uma rede de computadores convencional. Com essa nova arquitetura,

em que o controle ou a inteligncia da rede desacoplada da camada fsica dos equipa-

mentos, isto , do plano de dados, surge o sistema operacional de redes. Basicamente,

os sistemas operacionais fornecem um mecanismos para simplificar a interao do plano

de controle com o plano de dados, e uma interface para que aplicaes possam ser desen-

volvidas. Por exemplo, um projetista de redes ao escolher uma plataforma network OS

(Operating System), passa a ter uma viso de alto do nvel do plano de controle, desta

forma, programar uma rede SDN torna-se uma tarefa muito parecida como desenvolver

uma aplicao em uma linguagem de programao qualquer.

Do mesmo modo como em outras arquiteturas, que existem diversos sistemas opera-

cionais, em SDNs no diferente. Controladores so desenvolvidos cada um com ca-

ractersticas e objetivos bastante variados, cobrindo desde o controle de ambientes para

experimentaes acadmicas, at redes de grande porte. A seguir, listamos alguns con-

troladores e suas principais caractersticas:

Core-Apps

------------------------------

------------------------------

---------------

--------------- ------------------------------

------------------------------

---------------

---------------

Net-Apps Web-Apps

-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

----------------------------------

----------------------------------

NOX-Controller

ConnectionManager

EventDispatcher

OpenflowManeger

DSO Deployer ExistingComponents

Input/Output:Socket

AsynchronousFile

OpenFlowAPI

Core-Services:Threading and

Event-Management

Others:Network

protocols, data-structures,

utilities

Figura 2.3: Organizao do controlador Nox [Rao 2015a].

Nox [Gude et al. 2008] um controlador OpenFlow desenvolvido inicialmente pela

Nicira e ento, a partir de 2008, disponibilizado para a comunidade. A interface de pro-

gramao disponvel para criar aplicaes, assim como a linguagem utilizada no desenvol-

vimento do controlador em questo, foi o C++. Uma das principais caractersticas deste

controlador o alto desempenho. Atualmente, possui suporte verso 1.0 do OpenFlow,

entretanto existe uma verso modificada pelo CPqD (Centro de Pesquisa e Desenvolvi-

mento em Telecomunicaes) que suporta parcialmente a verso 1.3 [Fernandes 2013]. A

Figura 2.3 apresenta a arquitetura do controlador Nox.

A partir do controlador Nox surgiu um novo projeto, cujo objetivo prover uma interface

mais simples para controladores SDN. Desenvolvido em Python, o controlador Pox ??

19

uma verso do controlador Nox tradicional. Este controlador normalmente utilizado

como uma alternativa ao Nox em experimentos e prototipao, j que possui uma interface

mais amigvel.

DLUXVTN

CoordinatorOpen Stack

NeutronSDNI

WrapperDDoS

Protection

Network ApplicationsOrchestrations &Services

AAA - AuthN Filter

OpenDaylight Apis ( )REST

Base Network Service Functions

TopologyManager

StatsManager

SwitchManager FRM

HostTracker

OpenStack ServiceGBP

ServiceSFC AAA

DOCSISAbstraction

VTNManager

OVSDBNeutron

Plugin20C LISPService

L2Switch

SNBIService

SDNIAggrerater

Service Abstraction Layer (SAL)(Plugin Manager, Capability Abstractions, Flow Programming, Inventory, etc.)

ControllerPlatfom

Southbound Interfaces& Protocol Plugins

GBP Renderers

OpenFlow

1.0 1.3 TTPOVSDB NETCONF

PCMMCOPS

SNBI LISP BGP PCEP SNMP Plugin20C

OpenFlow Enabled

Devices

OpenvSwitches

Additional Virtual &Physical Devices

Data Plane Elements(Virtual Switches, Physical

Device Interfaces)

Figura 2.4: Organizao do controlador OpenDayLight [OpenDayLight 2015].

OpenDayLight [OpenDaylight 2013] um projeto open source cujo desenvolvimento

tem participao de grandes empresas como Cisco, Citrix, Microsoft, IBM, dentre

outras. O principal objetivo da comunidade acelerar o processo de popularizao do uso

de SDNs, e como parte do projeto, disponibilizam a plataforma para o desenvolvimento

de aplicaes em SDNs. O OpenFlow um dos padres suportados pelo OpenDaylight,

e atualmente tem suporte s verses 1.0 e 1.3 do OpenFlow. A Figura 2.4 ilustra a

organizao do controlador OpenDayLight.

OpenStack-Neutron agent and OF-REST

RYU APPLICATIONS

App-Manager

Ryu-Manager

Openflow-Controller

Bullt-In Applications

Core Processes: EventManagement, StateManagemente etc.

OpenflowProtocol

Libraries

OVSDB OFCONFIG NETCONF XFLOW 3 -Party_rd

Figura 2.5: Organizao do controlador Ryu [Rao 2015b].

20

Ryu [RYU 2014] um controlador open source desenvolvido por um grupo japons da

NTT Labs. O projeto totalmente implementado em Python, e possui boa integrao

com outras ferramentas de rede, como por exemplo o OpenStack [Corradi et al. 2012].

Um dos principais pontos do projeto o suporte a vrios protocolos de southbound, como

OpenFlow, NetConf e OF-Config. O desenvolvimento constante por parte da comunidade

permite que o controlador esteja atualizado com a verses mais recentes do Openflow.

Atualmente, possui suporte total at a verso 1.4, e algumas implementaes parciais da

verso 1.5. A arquitetura do controlador japons Ryu apresentada na Figura 2.5.

A Tabela 2.1 sintetiza o resumo dos principais controladores, juntamente com infor-

maes adicionais, como a verso do OpenFlow suportado e a linguagem da API.

Tabela 2.1: Tabela com o resumo das caractersticas dos principais Controladores.

Controlador Suporte OpenFlow Licena Linguagem APINox 1.0 GPLv3 C++Pox 1.0 GPLv3 PythonOpenDayLight 1.0 e 1.3 EPL v1.0 JavaRyu 1.0, 1.1, 1.2, 1.3 e 1.4 Apache 2.0 Python

2.2.2 Plano de Dados

O plano de dados ou plano de encaminhamento em uma rede definida por software tem

como funo central o encaminhamento de pacotes, isto , escoar o trfego da rede. Logo,

o plano de dados passa a ser representado pelos equipamentos de rede, sejam eles fsicos

ou virtuais, que possuam a capacidade de encaminhar pacotes.

De modo geral, os equipamentos de encaminhamento tradicionais possuem uma ou

mais tabelas de fluxos, normalmente em pores de memria TCAM (Ternary Content

Access Memory), onde so implementados servios de firewall, NAT (Network Address

Translation), traffic shaping, roteamento, entre outros. Vale lembrar que, no paradigma

de rede tradicional, como a arquitetura fechada, cada fabricante faz essas implemen-

taes de modo distinto. Em equipamentos OpenFlow, por ser open-source, o conjunto

de instrues do protocolo pode ser implementado em diferentes equipamentos, j que a

tabela de fluxos definida pelo protocolo.

Um switch OF (OpenFlow), tambm chamado datapath, pode ser representado em

trs partes:

1. Tabela de Fluxos: nessa tabela, cada fluxo associado a uma ao, e assim, os

pacotes que chegam ao equipamento so encaminhados de acordo com as regras

instaladas na tabela de fluxos;

21

2. Canal Seguro: esse canal conecta o equipamento ao controlador remoto, utilizando

uma conexo criptografada, e permite que mensagens e pacotes sejam enviadas entre

o controlador e o switch;

3. O protocolo OpenFlow: o protocolo define um padro aberto de comunicao entre

o controlador e o switch, que permite a programao da tabela de fluxos do equi-

pamento por meio de uma interface de alto nvel. Assim, o projetista de redes no

precisa se preocupar com as caractersticas do equipamento.

SecureChannel

FlowTable

SW

HW

OpenFlow Switch

--------------------------- OpenFlow Protocol

SSL

Controller

Figura 2.6: Switch OpenFlow.

Entre os diversos switches OpenFlow, que podem ser fsicos ou virtuais, podemos citar:

1. Open vSwitch [Pfaff et al. 2009] um switch virtual open-source que segue a arqui-

tetura OpenFlow. Uma caracterstica importante deste encaminhador que, apesar

de ser implementado em software, seu plano de dados executado em kernel mode,

enquanto o plano de controle acessado a partir do espao de usurio. O OvS (Open

Virtual Switch) possui suporte completo a verso 1.3 do OpenFlow.

2. Pica8 um switch OpenFlow de alto desempenho baseado em Linux. Fabricado pela

empresa Pica8 Inc., este equipamento executa um sistema operacional prprio, cha-

mado PicOS, que inclui capacidade de encaminhamento layer-2 e layer-3, e suporte

ao protocolo OpenFlow atravs de uma implementao do Open Vswitch embarcada

no sistema. O sistema PicOS um sistema operacional para equipamentos de rede,

baseado no projeto XORP [Handley et al. 2005], que executado em um kernel

Linux, com a adio de servios de rede. Atualmente possui suporte completo a

verso 1.4 do OpenFlow.

3. Plataforma aberta programvel [Liberato et al. 2014] um projeto do NERDS (N-

cleo de Estudos em Redes Definidas por Software), grupo de pesquisa ligado UFES

22

(Universidade Federal do Esprito Santo), que desenvolve pesquisas em SDN e pos-

sui um projeto que estuda plataformas de hardware que possam ser utilizadas como

encaminhadores OpenFlow. Neste projeto, equipamentos do tipo RouterBoard da

empresa Mikrotik basicamente tm seu sistema operacional substitudo pelo sistema

open source OpenWRT, junto com uma verso do OvS compilada especialmente para

essa arquitetura. No momento, o projeto suporta a verso 1.3 do OpenFlow.

4. CPqD Softswitch13 [CPqD 2014], assim como o OvS, um switch open source im-

plementado em software. Todavia, neste projeto, tanto o acesso ao plano de controle

quanto o plano de dados, so implementados no espao do usurio. O Softswitch13

baseado nos projeto Ericssons Traffic Lab OpenFlow 1.1 switch1 e no Stanford

OpenFlow 1.0 reference switch2, com alteraes para suportar a verso 1.3 do Open-

Flow.

A Tabela 2.2 apresenta uma viso sistemtica dos encaminhadores citados.

Tabela 2.2: Tabela Switches

Switch Suporte OpenFlow Licena Modo de EncaminhamentoOpen Vswitch 1.0, 1.1, 1.2 e 1.3 Apache 2.0 KernelPic8 1.0, 1.1, 1.2, 1.3, 1.4 Copyright KernelPlataformaAberta

1.0, 1.1, 1.2 e 1.3 Apache 2.0 Kernel

CPqDSoftswitch13

1.0 e 1.3 BSD Espao de usurio

2.3 OpenFlow

O protocolo OpenFlow foi o primeiro padro de interface de comunicao entre o plano

de controle e o plano de dados de uma arquitetura SDN [Foundation 2012]. O OpenFlow

permite o acesso e manipulao do plano de dados nos equipamentos de rede como rotea-

dores e switches, tanto fisica quanto virtualmente (baseado em hypervisor). Essa interface

padronizada e aberta permite que o plano de controle possa se comunicar com o plano

de dados independentemente do fabricante. Essa caracterstica exatamente oposta ao

que existia at ento, equipamentos de redes com o sistema fechado em uma arquitetura

monoltica, e extremamente dependente dos fabricantes.

Sherwood [Sherwood et al. 2009] apresentou uma comparao entre a arquitetura tra-

dicional e a arquitetura que utiliza o protocolo OpenFlow. Na arquitetura clssica, tanto

1https://github.com/TrafficLab/of11softswitch2http://yuba.stanford.edu/git/gitweb.cgi?p=openflow.git;a=summary

23

a lgica de controle quanto a lgica de encaminhamento esto localizadas internamente

ao switch, comunicando-se atravs de um barramento proprietrio do fabricante. Na ar-

quitetura OpenFlow o switch executa apenas a lgica de encaminhamento. A lgica de

controle executada no controlador OpenFlow e a comunicao entre elas se d atravs

do protocolo OpenFlow. A Figura 2.7 ilustra as duas arquiteturas.

Figura 2.7: Arquitetura Clssica x Arquitetura OpenFlow.

O OpenFlow utiliza o conceito de fluxos para identificar o trfego da rede, que so

representados como um conjunto de pacotes que possuem campos dos cabealho de dados

com o mesmo valor. Assim, um equipamento, ao receber o trafgo da rede, ou seja, fluxos,

consulta a sua tabela de fluxos, definida pela aplicao da rede, de modo a decidir como

encaminhar estes pacotes. Essas regras podem ser definidas dinmica ou estaticamente.

Caso no haja regras que coincidam com o fluxo recm chegado, o primeiro pacote do fluxo

(packet-in) encaminhado ao controlador, que ento realiza o processamento necessrio

para definir uma nova regra de encaminhamento para tal fluxo. A flexibilidade dessa

abordagem permite aos projetistas de redes definir como os pacotes sero encaminhados

pelos equipamentos baseando-se em parmetros, padres de trfego e aplicaes, por

exemplo.

De acordo com o apresentado na Figura 2.8, o protocolo define um conjunto de ope-

raes que podem ser utilizadas por uma aplicao do plano de controle para programar

o plano de dados, por exemplo como learning switch. O conjunto de operaes disponi-

bilizadas pelo OpenFlow est para o protocolo assim como o conjunto de instrues est

para uma arquitetura de processador.

Uma rede SDN que utiliza o protocolo OF basicamente composta por um ou mais

controladores, aplicaes, e equipamentos que operam o plano de dados, como roteadores

e switches.

24

OpenFlow Switch-enabled Network Device

OpenFlow Switch

Flow Table Comparable to an instruction set

MAC src MAC dst

10:20:.

IP Src IP Dst TCP dport ... Action Count

5.6.7.8

192*

25

port 1

port 2

drop

local

controller

250

300

892

120

11

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

*

Figura 2.8: Equipamento OpenFlow [Foundation 2012].

2.3.1 Mensagens OpenFlow

Controladores OpenFlow se comunicam com o plano de dados por meio de mensagens

OF. Nesta seo, apresentamos algumas das principais mensagens OpenFlow, que podem

ser classificadas como sncronas ou assncronas. Para uma descrio mais detalhada do

protocolo, a especificao oficial pode ser consultada [McKeown et al. 2008].

As mensagens sncronas so caracterizadas por serem mensagens iniciadas pelo con-

trolador e normalmente exigirem uma resposta ou confirmao. Dentre estas, podemos

citar:

Features-Request - Uma vez estabelecida a conexo entre o controlador e o switch,

o controlador envia uma mensagem de requisio ao switch. O switch responde a

solicitao informando os dados referentes as suas capacidades e configuraes;

Flow-Mod - Mensagens deste tipo so enviadas pelo controlador para gerenciar os

estados do switch. O propsito dessa instruo adicionar, modificar e excluir fluxos

nas tabelas dos equipamentos;

Stats-Request - Essas requisies so utilizadas pelo controlador para coletar esta-

tsticas sobre as tabelas, portas e fluxos dos switches ;

Barrier-Request - Mensagens de barreira so utilizadas pelo controlador para garan-

tir que o processamento de pacotes pelo switch seja realizado de acordo com uma

sequncia ou para confirmar que determinada operao foi executada. Por exemplo,

25

caso existam 5 operaes pendentes em um switch e uma barrier-request enviada,

isso significa que todas as operaes pendentes devem ser processadas antes do que

qualquer outro fluxo que tenha chegado aps a mensagem de barreira.

Os equipamentos do plano de dados, em geral, executam aes indicadas pelo contro-

lador, entretanto, em algumas situaes, preciso que mensagens sejam enviadas a partir

do plano de dados. Essas mensagens so chamadas de assncronas, e tm como objetivo

informar os controladores sobre eventos do plano de dados, como chegada de pacotes,

mudana de estado no switch ou a ocorrncia de um erro. Abaixo so descritas algumas

das principais mensagens assncronas.

Packet-In - Sempre que um novo fluxo chega ao switch e no h uma entrada na

tabela de fluxos que faa matching com esse conjunto de pacotes, uma mensagem

do tipo packet-in enviada ao controlador. Como a lgica de encaminhamento est

localizada no plano de controle, cabe ao controlador processar tal pacotes e definir

qual encaminhamento este fluxo ter;

Port-Status - Essa mensagem informa ao controlador mudanas que ocorram na

portas do switch. Por exemplo, caso um cabo seja desconectado ou uma interface

esteja desabilitada, uma mensagem port-status ser enviada ao plano de controle;

Flow-Removed - Quando uma regra instalada na tabela de fluxos de um switch,

deve-se indicar quando essa regra ir expirar, seja por inatividade ou por tempo.

Assim que uma regra removida da tabela de fluxo, todos os controladores recebem

uma mensagem do tipo flow-removed.

2.3.2 Evoluo do OpenFlow

As primeiras verses do protocolo OpenFlow datam de meados de 2008, entretanto, so-

mente ao fim de 2009 uma verso estvel foi lanada. Na verso 1.0 [Specification 2009] o

controlador dispe de uma nica tabela de fluxo em cada switch, e o match pode ser feito

sobre os campos dos protocolos Ethernet, VLAN, IP, ICMP, TCP e UDP. Uma outra

importante feature o slicing, que um mecanismo de QoS que permite isolamento de

trfego em redes OpenFlow. Essa verso suporta ainda mscaras de bits nos campos do

protocolo IP.

Na verso 1.1 do protocolo OpenFlow [Specification 2011a] o controlador passa a su-

portar operaes em mltiplas tabelas de fluxo, alm de um grande conjunto de novas

aes (copy/decrement TTL, push/pop tag, QoS, Groups actions) e campos de cabealho

(VLAN priority, MPLS tag), o que permite aumentar a flexibilidade no uso do protocolo.

No fim de 2011 foi lanada a verso 1.2 do OpenFlow [Specification 2011b], que por

meio do conceito de papis passa a suportar a conexo dos switches a mltiplos contro-

ladores. Nesta verso, outras features que merecem destaque so: suporte ao protocolo

26

IPV6, multi layer switching, tneis GRE/L3, possibilidade de uso de SCTP e UDP+IPsec

para a conexo de controle, entre outros.

A verso 1.3 [Specification 2012], lanada em abril de 2012, traz suporte aos cabealhos

de extenso do IPV6, meters de trfego por fluxo e QoS por aplicao. Esta verso

est sendo amplamente aceita pela comunidade, no sentido de que mostrou-se que o

desenvolvimento do protocolo est alinhado s demandas das redes atuais.

Em 2013 foi lanada a verso 1.4 [Specification 2013], cujas principais inovaes desta

verso so: suporte a execuo de um conjunto de aes (bundles) por meio de uma nica

operao; vacancy events, que sinalizam ao plano de controle caso a tabela de fluxos

esteja prxima de seu limite; flow monitors, que permitem os controladores monitorarem

alteraes nos switches ; e notificao dos controladores em caso de troca de papel para

os switches. Tambm, a porta padro para o protocolo foi alterada, passando de 6633

para 6653. Essa verso trouxe uma quantidade considervel de novas caractersticas em

relao verso anterior.

Por ltimo, a verso 1.5 [ONF 2014], lanada em 2014, traz mais de 20 novas features,

entre as principais, suporte a egress tables, monitoramento das conexes com os controla-

dores, e pipeline baseado no tipo do pacote. Em verses anteriores 1.5 todos os pacotes

processados deviam ser do tipo Ethernet, com a incluso de packet type aware pipeline,

passa a ser possvel o processamento de outros tipos de pacotes, como IP ou PPP.

A Tabela 2.3 sintetiza as mudanas ocorridas no OpenFlow ao longo das verses do

protocolo.

27

Tabela 2.3: Tabela Evoluo OpenFlow [Tourrilhes et al. 2014].

Agrupamentodos Recursos

Descrio dos Recursos VersoOpenFlowSuportada

Separao de PlanosFlow cookies - Poltica para identificar entradas defluxos

1.0

Vacancy Events - Notificao sobre o esgotamentode recursos

1.4

Viso CentralizadaPapis OpenFlow (Multi-controlador) 1.2Event-filtering por conexo (Multi-Controlador) 1.2Bundles - Aplicar um conjunto de operaes emuma nica requisio

1.4

Connection status - Monitoramento das conexesdos controladores

1.5

Monitoramento de fluxos (Multi-controlador) 1.4

Northbound APIsSlicing - isolamento de trfego 1.0Meters por fluxo 1.3Tunnel id - identificao do encapsulamento utili-zado

1.3

ProgramaoGroups Operaes sobre grupos flow actions 1.0Extenso de campos dos pacotes e reescrita de ca-bealho

1.2

Table Features - Maior flexibilidade na operaode flow miss

1.3

Tabelas de FluxosMltiplas tabelas de fluxo 1.1Egress tables - processamento de pacotes baseadono contexto de porta de sada

1.5

Pipeline baseado no tipo de pacote 1.5

Captulo 3

Trabalhos Relacionados

3.1 Onix

ONIX [Koponen et al. 2010] foi a proposta pioneira no controle distribudo em redes SDN,

particionando o escopo dos controladores, agregando as informaes, e compartilhando

o estado, via APIs, para diferentes tipos de data stores em funo dos requisitos de

consistncia. O trabalho, porm, no discute a conectividade com mltiplos controladores

nem o tratamento de falhas, que ficam sob a responsabilidade das aplicaes. A Figura

3.1 ilustra a organizao implementao apresentada por Koponen.

Figura 3.1: Onix: arquitetura de controle distribuda[Koponen et al. 2010].

3.2 Replicao Passiva e Ativa em SDN

Em [Fonseca et al. 2013] os autores apresentam um estudo em SDN em que as estrat-

gias de replicao ativa e passiva so usadas para implementar controladores distribudos.

Alm disso, indicam cenrios em que utilizao de cada tcnica pode ser mais efetiva.

No experimento que adota replicao passiva, os switches se conectam a um controlador

29

primrio, que faz o processamento de todos pacotes da rede, enquanto podem existir in-

meros controladores secundrios, que no processam nenhum pacote dos controladores.

Nesta tcnica, todo o estado do controlador primrio replicado nos controladores se-

cundrios, ou seja, o controlador primrio, medida que recebe e processa o pacotes dos

switches, envia mensagens aos controladores secundrios atualizando seus estados.

Para o tratamento de falhas, caso o controlador primrio esteja down, os switches

acessam uma lista de controladores, previamente configurada, e se conectam a um novo

controlador. Este controlador passa a ser o novo controlador primrio, com a garantia

de ter seu estado consistente, e a rede continua em operao aps o perodo de falha. A

Figura 3.2 ilustra a implementao da estratgia de replicao passiva apresentada por

Fonseca.

Figura 3.2: Controlador com replicao passiva[Fonseca et al. 2013].

Na implementao em que utiliza-se replicao ativa, os switches se conectam a todos

os controladores da rede, e estes processam os pacotes de forma simultnea. Neste mtodo,

ao enviar um pacote para o plano de controle, todos os controladores recebem e processam

os pacotes dos switches, e ento, apenas um controlador responde tal requisio, e para

tanto, trocam mensagem de controle para definir qual controlador processou o pacote em

menor tempo. Essa tcnica permite que os estados da rede estejam replicados em cada

controlador, j que todos controladores processam o mesmo pacote. A Figura 3.3 ilustra

a implementao da estratgia de replicao ativa apresentada por Fonseca.

O procedimento para tratamento de falhas caracterstica intrseca arquitetura

proposta. Como todos os controladores da rede processam os mesmos pacotes, o que os

leva a ter os mesmos estados, caso um controlador no esteja mais disponvel, esta falha

no ser perceptvel, desde que haja pelo menos mais um controlador na rede.

Segundo os autores, a implementao da estratgia de replicao passiva mostra-se

mais indicada para ambientes que utilizem uma abordagem menos intrusiva e que tenham

menor sensibilidade indisponibilidade da rede. J a tcnica de replicao ativa dos

30

controladores tem indicao para ambiente com baixa tolerncia a falhas, j que neste

caso, por conta dos mltiplos controladores que processam os pacotes da rede, no h

perodo de downtime.

Figura 3.3: Controlador com replicao ativa[Fonseca et al. 2013].

Apesar do estudo levantar pontos relevantes para a rea, as duas implementaes apre-

sentadas utilizam a verso 1.0 do protocolo OpenFlow, deixando a cargo dos projetistas

de SDN implementar seus prprios mecanismos para que switches lidem com mltiplos

controladores. Outra limitao da estratgia ativa implementada, segundo os autores,

que a sincronizao dos controladores usando consenso distribudo aumenta consideravel-

mente a latncia da rede e reduz a capacidade de processamento. Por fim, a arquitetura

no escala, na perspectiva do ganho em desempenho, dado que adicionar controladores

arquitetura no aumenta o throughput do plano de controle.

3.3 SmartLight

Em [Botelho et al. 2014] apresenta-se uma proposta de uma arquitetura para mltiplos

controladores chamada SmartLight. A estratgia baseada em uma variao da aborda-

gem passiva, em que h um controlador principal, que processa packet-in, e N controlado-

res backup. Neste trabalho, todos os switches da rede se conectam a todos os controladores

disponveis, entretanto apenas um controlador assume o papel master.

Para detectar a falha do controlador master, foi implementado um servio de coorde-

nao entre os controladores, de modo que em caso de falhas no controlador principal,

uma das rplicas possa assumir o controle da rede. Um dos pontos centrais do trabalho

a utilizao de um data store como meio de distribuir os estados da rede. Apenas o

controlador principal interage com o data store, escrevendo e recuperando informaes,

e em caso de falhas, o novo controlador principal deve recuperar os estados armazena-

31

dos no data store. A Figura 3.4 apresenta a implementao de controladores replicados

passivamente por Botelho.

Nos experimentos realizados, em ambiente emulado, os autores utilizam um prottipo

com dois controladores, e medida em que variam a carga da rede e o nmero de switches,

observam o comportamento do prottipo.

Figura 3.4: Arquitetura Smartlight[Botelho et al. 2014].

O trabalho apresenta uma linha promissora, no entanto o uso de apenas um controlador

principal limita a vazo do plano de controle. Um outro ponto levantado que, em caso de

falha, o controlador que assumir as operaes da rede precisa recuperar todos os estados

no data store, o que pode adicionar uma maior latncia na transio dos controladores.

Captulo 4

Plano de Controle Resiliente

As caractersticas arquiteturais e inovaes advindas das SDN so objeto de inmeros

estudos e discusses [Kreutz et al. 2015]. Nesse contexto, um ponto controverso justa-

mente uma de suas principais caractersticas: a centralizao do controle. Isto porque,

caso tal viso centralizada seja implementada por um nico controlador, uma falha nesse

elemento pode levar indisponibilidade total da rede. O problema fundamental e os trade-

offs por trs da distribuio do controle em redes SDN podem ser modelados adaptando

o teorema de CAP [Panda et al. 2013].1

Por exemplo, considere uma rede de campus convencional e seus switches. Nesse

cenrio, toda a lgica de encaminhamento e o controle das configuraes dos elementos de

rede esto particionadas entre os prprios equipamentos. Assim, caso um desses elementos

falhe, muito provavelmente parte da rede ser afetada mas o restante continuar em

produo. J no caso de uma SDN implementada com o protocolo OpenFlow, esse arranjo

responsabilidade dos controladores, ou seja, toda a lgica de encaminhamento est

centralizada no(s) controlador(es). Isto , alm da possibilidade de falhas nos switches,

como no exemplo anterior, possvel que o controlador tambm falhe, o que, nesse caso,

pode levar inoperncia da rede uma vez que novas regras de encaminhamento no seriam

geradas pela durao da falha.

Embora tenha ficado claro desde a especificao inicial do OpenFlow que o controla-

dor, apesar de logicamente centralizado, poderia ser implementado de forma distribuda,

somente a partir da verso 1.2 que os mecanismos para esta distribuio comearam a

ser especificados. Nas verses 1.0 e 1.1, cada switch se conecta apenas a um controlador,

que torna-se um ponto nico de falha e demanda aes no especificadas para reposio.

Desde a verso 1.2, switches OpenFlow podem se conectar a diversos controladores simul-

taneamente, que devem assumir um dentre trs papis: master, slave e equal. Contudo, na

literatura, no h sequer guidelines ou melhores prticas de como estes papis devam ser

1O teorema CAP (Consistency, Availability and Partition Tolerance) , tambm cohecido como Teoremade Brewer, afirma a impossibilidade de um sistema computacional distribudo garantir simultaneamenteconsistncia, disponibilidade e tolerncia ao particionamento.

33

usados. Assim, cabe aos projetistas de SDN o uso de tcnicas que garantam a disponibili-

dade dos servios executados pelo controlador e a dependabilidade da rede. A abordagem

bvia para se atender tal requisito a redundncia do estado do controlador via alguma

forma de replicao, como at sugerido pelos nomes dos papis, permitindo que outro

controlador continue a atuar sobre o mesmo estado, em caso de falha do primeiro ou,

ainda, que mltiplos controladores compartilhem tal tarefa.

Na implementao da replicao em ambiente SDN com multi-controladores, diversas

perguntas ainda precisam de respostas, dentre elas destacamos as seguintes: vrios con-

troladores processam os pacotes recebidos e atualizam o estado ou somente um processa e

informa aos outros o novo estado? No primeiro caso, a mesma ordem de processamento

imposta para garantir consistncia e, no segundo, como o estado compartilhado? Todos

acessam o estado global ou ele particionado entre os controladores? Como so tratadas

as falhas de um controlador? Nas sees seguintes, discutiremos tais perguntas e possveis

respostas.

Em uma rede implementada com o protocolo OpenFlow, os switches mantm tabelas

de fluxos que ditam como o trfego deve fluir pela rede. Quando um pacote no pode ser

encaminhado, o controlador responsvel pelo switch informado via um evento packet-in.

Baseado em seu estado, o controlador gera uma nova regra a ser inserida na tabela de fluxos

do switch para lidar com o pacote e outros similares. Assim, se h apenas um controlador

por switch, a tabela de fluxos sempre consistente com o estado do controlador.

Contudo, a partir da definio do conceito de papis, um switch pode se conectar a

mais de um controlador. Neste caso, quando a conexo ocorre, por padro, o controlador

assume o papel equal, implicando que todos os controladores tm igual poder de atualizar

tabelas do switch. Neste cenrio os controladores devem, de uma forma no especificada,

coordenar a atualizao de seus estados, mantendo uma viso logicamente centralizada

da rede e garantindo que suas intervenes sejam consistentes.

Outros papis que podem ser assumidos pelo controlador so master e slave. Ao

assumir o papel master, assim como no equal, o controlador passa a ter privilgios sobre

o switch, com permisso de leitura e escrita, alm de receber mensagens assncronas. J

no modo slave, o controlador tem limitado seu acesso ao switch, podendo realizar apenas

operaes de leitura, isto , nenhuma mensagem que altere a tabela de fluxos do switch

processada. Caso comandos de escrita sejam enviados ao switch, uma mensagem de erro

ser gerada. Mensagens assncronas tambm no so enviadas ao controlador, exceo

de algumas, entre elas, mensagens de port-status, que informam sobre o estado das portas.

Nas prximas sees discutiremos sobre a configurao de switches com mltiplos

controladores, fazendo o uso dos papis OpenFlow master, equal e slave.

34

4.1 Configurao Equal

Com base nas definies dos papis OpenFlow, podemos descrever uma configurao

bsica para uma rede com mltiplos controladores rodando uma aplicao de learning

switch:

1. um switch se conecta a N controladores;

2. todos os controladores assumem o papel equal.

Neste arranjo simples, todos os switches so configurados com os endereos dos contro-

ladores, e estes no demandam nenhuma configurao extra, uma vez que o papel padro

no OpenFlow o equal. Um switch ao receber um pacote que no tenha fluxo instalado em

sua tabela, encaminha um packet-in ao plano de controle, isto , a todos os controladores.

Tais controladores, ao receberem o pacote, realizam o seu processamento de forma con-

corrente, e enviam um packet-out para o switch. Desde que processem os mesmos pacotes,

na mesma ordem, e que o processamento seja determinstico, os estados dos controladores

evoluiro consistentemente. Neste cenrio, em caso de falha, os controladores restantes

continuam a operar a rede, normalmente. Este o princpio da replicao de mquinas de

estados [Lamport 1978, Schneider 1990], tambm conhecido como Replicao Ativa, ilus-

trado na Figura 4.1. Obviamente, a dificuldade na implementao desta tcnica est em

garantir a entrega, totalmente ordenada, das mensagens aos controladores, o que requer

alguma forma de comunicao em grupo [Dfago et al. 2004].

Figura 4.1: Replicao Ativa.

Apesar de conceitualmente simples, essa implementao tem desvantagens claras:

maior uso de recursos j que todos os controladores processam todos os pacotes; so-

brecarga da rede de controle devido ao broadcast dos packet-in e mltiplas respostas;

a capacidade de processamento do plano de controle no escala com o nmero de con-

troladores, j que todos processam os mesmos pacotes e mantm o mesmo estado; e por

35

fim, a menos que os comandos que alteram as tabelas de fluxo sejam idempotentes, o

resultado pode no refletir o que foi determinado pelos controladores por exemplo, em

nossos experimentos, observamos a duplicao de pacotes causada pelo processamento de

comandos duplicados pelo switch.

4.2 Configurao Master-Slave

Uma soluo alternativa, que minimiza alguns dos efeitos indesejveis listados anterior-

mente, consiste em ter apenas um dos controladores processando as mensagens e respon-

dendo ao switch, e repassando suas mudanas de estado aos outros controladores. Esta

tcnica, conhecida como Replicao Passiva [Budhiraja et al. 1993], primary-backup ou,

finalmente, master-slave, ilustrado na Figura 4.2, diminui o processamento nos controlado-

res, elimina o no determinismo na atualizao do estado e evita as respostas redundantes

e seus efeitos. Do ponto de vista do OpenFlow, esta tcnica pode ser implementada da

seguinte forma:

1. um controlador assume o papel master para todos os switches da rede;

2. os demais controladores assumem o papel slave para todos os switches da rede.

Assim, como no caso da replicao ativa, apenas atribuir os papis no o suficiente

para levar a uma soluo completa. Se na replicao ativa era necessrio garantir a entrega

e ordenao das mensagens, na passiva necessrio garantir que as atualizaes feitas no

controlador mestre sejam replicadas para os escravos, novamente usando alguma forma

de comunicao em grupo. Alm disso, tambm necessrio que os escravos monitorem

o mestre e que um deles assuma seu papel no caso de falha, informando os switches.

------------------------------

Master

---------------------------

------ Slave

State Message

Figura 4.2: Replicao Passiva.

4.3 Configurao Multi-Master / Multi-Slave

A terceira proposta discutida para prover resilincia ao plano de controle utiliza meca-

nismos para que os controladores no sejam o gargalo da rede. Em um arranjo com

36

switches e controladores pode-se ter a seguinte configurao:

1. para cada switch da rede, um controlador deve assumir o papel master ;

2. para cada switch da rede, 1 controladores devem assumir o papel slave.

Essa proposta permite que os controladores processem packet-in, j que os switches

so organizados de modo que um controlador atue como master para um switch e slave

para os demais. Nos switches nenhuma configurao extra necessria, alm dos endereos

dos controladores, levando a uma rede operacional com mnimo esforo. Todavia, ainda

existem questes que precisam ser respondidas, sendo provavelmente a mais importante

a seguinte: se os estados dos switches esto particionados entre os controladores, como

implementar a viso centralizada do controlador OpenFlow?

4.4 Configurao via Data Store

Uma variao das configuraes anteriores utilizar um data store externo, tolerante a

falhas, no qual o mestre espelha seu estado interno, e que usado pelos escravos para

atualizarem seus estados. Com o uso desta abstrao extra, os controladores a utilizam

para manter atualizados os seus estados; a viso centralizada passa a ser implementada

em uma base externa, e a viso particionada, por exemplo, corresponderia a simplesmente

o controlador ignorar parte dos dados da base externa. Tal arquitetura tem a vantagem de

abstrair a comunicao entre controladores, possivelmente simplificando a implementao.

Outra questo importante como os papis so redistribudos entre os switches, em

caso de falha dos controladores. Novamente um servio externo pode ser usado, como

por exemplo os servios de coordenao ZooKeeper [Hunt et al. 2010] ou Doozer2. Esses

servios podem ser usados para monitorar as rplicas e, em caso de falhas, eleger um

mestre para cada switch. O novo mestre deve ento agregar o estado do controlador que

falhou ao seu, a partir das informaes contidas no data store, e, por fim, informar os

switches rfos quem seu novo master.

4.5 Deteco de Falha

Como citado na seo anterior, em uma rede com mltiplos controladores deve existir

um meio para detectar falhas que ocorram no plano de controle, de modo que a partir

da deteco, aes sejam tomadas para corrigir a falha. A seguir destacamos algumas

abordagens que podem ser utilizadas.

2https://github.com/ha/doozerd

37

4.5.1 Utilizando Agentes Externos

Inicialmente, pode-se definir um agente externo para monitorar os controladores. Nessa

estratgia, um servio Heartbeat-like passa a verificar periodicamente se os controladores

respondem s requisies enviadas pelo monitor. Caso um n deixe de responder, o

monitor detecta a falha e informa aos controladores que continuam ativos. Destacamos

que como uma arquitetura de alta-disponibilidade, e como o monitor tambm est

sujeito a falhas, este deve possuir redundncia ou algum outro mecanismo de tolerncia

a falhas. A Figura 4.3 ilustra o monitoramento dos controladores via um agente externo.

Figura 4.3: Monitoramento via agente externo.

4.5.2 Utilizando os Controladores OpenFlow

Uma outra opo utilizar os prprios controladores da rede para deteco de falha. Ao

utilizar esta estratgia, em uma rede com controladores, cada controlador responsvel

por monitorar 1 controladores. Nesse modelo o monitoramento pode ser realizadopor meio de troca de mensagens keep alive, e em caso de falha de um controlador, todos

os outros que continuam ativos detectam que o n falhou. Essa estratgia resolve o

problema apresentado seo na anterior: como existem mltiplos monitores, o mecanismo

de tolerncia a falhas dos monitores inerente implementao.

Entretanto, por existir ( 1) * conexes de controle, pode haver um aumentosubstancial na troca de mensagens no plano de controle. A Figura 4.4 apresenta um dos

possveis modos de monitoramento no plano de controle.

38

Figura 4.4: Monitoramento via controladores.

4.5.3 Utilizando os switches OpenFlow

Os switches OpenFlow armazemam uma srie de dados sobre dos controladores da rede,

e em um arranjo Multi-Master/Multi-Slave, este dispositivo possui informaes sobre a

tupla controlador/papel/switch. Por exemplo, em uma rede com dois controladores e dois

switches, organizados de acordo com a Figura 4.5, o switch 01 mantm uma conexo com o

controlador , e a informao de que o controlador o seumaster ; do mesmo modo, este

switch mantm um outra conexo com o controlador , e a informao de o controlador

o seu controlador slave. Caso ocorra uma falha no controlador , considere que

nenhum mecanismo de deteco/tratamento de falhas tenha sido implementado, o switch

01 percebe que o seu controlador principal caiu, e apesar de haver um outro controlador

backup, nenhuma operao executada para contornar a falha. Deste modo, a partir

deste ponto de vista, lanamos a seguinte questo: por qu um switch, ao perder o seu

controlador master, simplesmente no sinaliza a um dos 1 controladores da rede paraque um novo master assuma o processamento de seus pacotes?

A partir dessas consideraes, seguimos na direo de que o switch com todas as in-

formaes sobre os controladores da rede e ainda pelo fato de manter conexes com estes,

tem a possibilidade de empreender um novo mecanismo de deteco de falhas em contro-

ladores SDN. Nesta nova estratgia, os switches passam a monitorar o seu controlador

master, e em caso de falha, enviam uma mensagem que todos os controladores possam

processar. Ento, um controlador deve ser escolhido para assumir este switch rfo.

Essa estratgia apresenta algumas vantagens sobre outros modos de monitoramento.

39

Como cada switch monitora apenas o seu controlador master, ou seja, a relao de 1:1,

a complexidade de monitorar mltiplos controladores distribuda entre os switches da

rede. Um outro ponto a ser destacado o fato do switch manter informaes e conexes

de/com todos os controladores da rede, o que faz esse estratgia ser pouco invasiva. Por

fim, esse mecanismo de deteco permite que aplicaes e usurios que no necessitem

manter a consistncia entre os controladores, possam usufruir de um ambiente multi-

controlador de modo muito simples. A Figura 4.5 ilustra o monitoramento via o plano de

dados.

Figura 4.5: Monitoramento via switches.

Em todas as estratgias citadas anteriomente, mais de um controlador pode ser no-

tificado sobre a falha de controladores, assim, deve haver um mecanismo para que os

controladores entrem em consenso sobre qual controlador ser escolhido para assumir o

switch que perdeu o seu controlador master. Dentre diversas solues, para o contexto

discutido, descrevemos algumas opes:

1. O monitor mantm uma lista de prioridades, e a partir dessa lista define qual con-

trolador ser solicitado para assumir o switch rfo;

2. Os controladores mantm uma lista de prioridades, onde definida a sequncia

dos controladores que assumem em caso de falha, e aps receber a sinalizao do

monitor, o controlador com a prioridade mais alta assume;

3. O monitor, de modo aleatrio, define qual controlador ser solicitado para assumir

o switch rfo;

40

4.6 Consideraes parciais

Algumas consideraes podem ser feitas em relao perspectiva de um plano de controle

resiliente. O processamento de pacotes por mltiplos controladores de forma concorrente

uma interessante escolha, visto que uma importante caracterstica para sistemas dis-

tribudos adicionada: escalabilidade. medida que controladores so adicionados

rede, o throughput do plano de controle aumenta. No entanto, ter o estado da rede dis-

tribudo entre os controladores impe desafios aos projetistas de redes SDN, tais como:

a manuteno da consistncia das informaes, a coordenao das rplicas, e deteco e

tratamento de falhas. Para avaliar essas conjecturas e os trade-offs em implementaes

reais, e avanar na viabilidade de uma soluo de SDN com alta disponibilidade, optamos

por desenvolver uma prova de conceito.

No prximo Captulo contextualiza-se a arquitetura proposta, onde detalhamos a im-

plementao do prottipo e suas principais caractersticas.

Captulo 5

Implementao do Prottipo

Aps as discusses sobre diferentes estratgias e relaes de compromisso na implemen-

tao de redes SDN com mltiplos controladores, neste captulo apresentado a proposta

de um plano de controle resiliente e o prottipo implementado.

Figura 5.1: Proposta de arquitetura Resilincia para o plano de controle OpenFlow.

Com o objetivo de lidar com os diferentes trade-offs apresentados nos exemplos anteri-

ores, os seguintes pr-requisitos foram priorizados: (1) todos os controladores devem estar

aptos a processar packet-in, isto , atuar com o papel master de forma concorrente; (2) a

distribuio de estados deve ser ativa, levando resilincia no plano de controle enquanto

o estado da rede replicado proativamente entre os controladores. Na implementao do

prottipo considerado um modelo de sistema sncrono com falhas de controladores, do

tipo fail-stop; os canais de comunicao no duplicam nem perdem mensagens.

Como consequncia do atendimento s premissas arquiteturais, segue-se com o de-

42

senvolvimento do trabalho a partir de trs perspectivas: a distribuio do estado entre

os controladores, o plano de controle, e o plano de dados. Deste modo, abordado os

desafios e as solues utilizadas para o design do prottipo implementado, ilustrado na

Figura 5.1.

Nas prximas subsees sero descritas as abordagens utilizadas nas solues para

implementao do prottipo.

5.1 Data Store

Um importante ponto no projeto de um plano de controle resiliente a implementao da

viso centralizada (estado da rede compartilhado de forma consistente) em controladores

distribudos. Sendo assim, oportuno detalhar a soluo escolhida para manter os estados

dos controladores consistentes.

Por exemplo, considere uma rede com diversos controladores executando uma aplicao

de switching : medida que em que os pacotes fluem pela rede, so processados pelos

controladores, o controlador armazena os endereos MAC dos hosts, e qual porta de qual

switch esses endereos esto associados. Caso haja uma falha em um dos controladores

da rede, todo o mapeamento que estava armazenado no controlador que falhou deve estar

disponvel para o restante dos controladores da rede.

Nossa proposta utiliza um servio aberto chamado OpenReplica1 para manter a con-

sistncia do estado da rede. Este um servio que prov replicao e sincronizao para

sistemas distribudos em larga escala. Baseado em uma nova implementao de mquinas

de estados replicadas via Paxos [Lamport 1998], que utiliza uma abordagem orientada a

objetos, o sistema, ativamente, cria e mantm rplicas vivas para objetos fornecidos pelo

usurio. Assim, de forma transparente aos clientes, os objetos replicados so acessados

como se fossem objetos locais (vide Figura 5.2).

...

NS NS

R1 R2 R3 R4

PAXOS

Ob

jeto

Ob

jeto

Ob

jeto

Ob

jeto

ProxyCliente

Chamada defunes Requisies

RequisiesDNS

Figura 5.2: Open Replica para replicao e sincronizao do estado.

1http://openreplica.org/

43

Na implementao do prottipo, define-se uma estrutura de dados chamada de NIB

(Network Information Base), que pelo fato da abordagem do servio de replicao ser OO

(Orientado a Objetos), tambm pode ser chamada de objeto NIB. Nessa estrutura so

armazenadas as informaes compartilhadas entre os controladores, como por exemplo, os

mapeamentos controlador/papel/switch e endereo MAC/porta/switch. Assim, o objeto

NIB acessado via OpenReplica reflete a viso global da rede SDN.

Como caracterstica de programao OO, os atributos dos objetos devem ser acessados

por meio de mtodos, e seguindo este paradigma, o objeto NIB possui um conjunto

de mtodos para inserir, alterar e excluir dados de sua estrutura. Esse mtodos so

executados pelos controladores. De um modo simplificado, a abstrao provida pelo

OpenReplica pode ser vista como uma poro de memria virtual comum a todos os

controladores da rede.

Uma outra caracterstica inerente escolha deste servio de replicao diz respeito

fcil integrao com o controlador Ryu. Pelo fato de ambos serem escritos em Python

dispensvel o uso de binds, o que torna a integrao entre os sistemas mais simples.

5.2 Plano de Controle

O sistema operacional de redes escolhido para atuar como controlador utilizado no pro-

ttipo foi o Ryu, verso 3.18, em virtude deste ser um ambiente com suporte completo s

verses 1.0, 1.2, 1.3 e 1.4 do protocolo OpenFlow. Outros pontos importantes para esta

escolha foram os fatos de se tratar de um projeto de cdigo aberto; ter suporte de uma

comunidade ativa, o que faz o controlador estar alinhado com a evoluo do OF; e dispor

de farta documentao oficial, o que inclui um e-book [Team 2013].

O controlador Ryu no dispe de nenhuma feature para atuar em conjunto com outros

controladores, deste modo, todo mecanismo de comunicao entre controladores e/ou data

store fica a cargo das implementaes do projetista de redes. No modelo sugerido, pode

haver mltiplos controladores na rede, e a princpio deve ser permitida a comunicao

entre estes.

Em cada controlador as funes do sistema so divididas em duas aplicaes que so

executadas em paralelo:ConnectionManager e LearningSwitch. A ConnectionManager

responsvel por manter as principais funes do prottipo, dentre elas, realizar a comuni-

cao com o data store, com outros controladores da rede e com a aplicao de switching ;

detectar e monitorar falhas nos controladores; e gerenciar a conexo com os switches, j

que o controlador pode assumir diferentes papis para diferentes switches. J a segunda

aplicao executa uma lgica de um Learning Switch adaptada para receber eventos do

Ryu. Figura 5.3 ilustra a estrutura organizacional das aplicaes ConnectionManager e

LearningSwitch.

44

------

RYU

ConnectionManager

LearningSwitch

------

--------

Figura 5.3: Organizao do controlador implementado.

5.2.1 Deteco de Falhas via Plano de Controle

Como descrito na seo anterior, nessa estratgia multi-controlador podemos ter con-

troladores processando pacotes do plano de dados, e todos os controladores deste arranjo

esto sujeitos a falhas. Isto , em uma rede com mltiplos controladores, caso um deles

deixe de funcionar, deve existir um mecanismo que detecte essa falha e sinalize para os

controladores que continuam operacionais, a falha de um n da rede. Para tanto, inicial-

mente, definido que os prprios controladores podem ser responsveis pela deteco das

falhas do plano de controle.

Figura 5.4: Deteco de falha via controladores OpenFlow.

Na implementao do prottipo apresentado, no caso de uma rede com controla-

dores, cada controlador deve abrir uma conexo com 1 controladores. Deste modo,cada controlador utiliza mensagens do tipo keep-alive, enviadas por estas conexes, para

monitorar o restante dos controladores da rede. Como as aplicaes do controlador Ryu

so escritas em Python, utiliza-se a interface BSD socket da linguagem para implementar

45

tais conexes, e caso ocorra uma falha que torne um dos controladores indisponveis, 1controladores detectam a falha. A Figura 5.4 apresenta a tcnica implementada no plano

de controle para detectar falhas nos controladores.

Ao receber a notificao de falha, os mltiplos controladores devem entrar em con-

senso sobre qual controlador ir assumir a propriedade do switch rfo. O mecanismo

implementado para determinar qual controlador ir assumir baseado em uma lista de

prioridades armazenada no data store, sendo assim, a lista de comum acesso para todos

os controladores da rede.

5.2.2 Tratamento da Falha

Uma vez detectada a falha em um dos controladores, um procedimento deve ser executado

a fim de contornar o problema causado pela indisponibilidade de tal controlador, com o

objetivo de minimizar o impacto no funcionamento da rede. Essa rotina foi definida como

Recuperao de Falha.

A recuperao de falha consiste em um processo que faz com que um dos controladores,

que continua ativo, torne-se o novo master para todos os switches que perderam o seu

controlador principal, isto , o seu controlador master. Ento, os passos executados na

operao, so: no momento em que a falha detectada pelos controladores, uma funo

da aplicao ConnectionManager acessa os dados da NIB no data store e verifica se o seu

ID o designado para assumir as funes do controlador que falhou. Caso seja verdadeiro,

este controlador verifica quais so os switches que tm como master o controlador que

falhou, e os envia uma mensagem role-request master. Cada switch responde com uma

mensagem role-reply para confirmar a operao. A Figura 5.5 ilustra a comunicao do

controlador com o switch orfo.

Figura 5.5: Processo de Recuperao de Falha.

Em [Dixit et al. 2013] os autores apresentam um protocolo de migrao de switches.

Nesta tcnica, com o uso de mensagens OpenFlow possvel migrar switches on the fly

entre controladores. A partir de uma variao da tcnica apresentada por Dixit, adicio-

46

namos uma outra operao a ser utilizada no prottipo do plano de controle resiliente, a

Restaurao da Falha. Essa ao ocorre quando o controlador que falhou est dispo-

nvel novamente, e reassume os switches que o tinham como master no momento anterior

falha.

Inicialmente, pode-se sugerir que um controlador que volta de uma falha e deseja

reassumir os seus switches, deve simplesmente enviar uma mensagem de change-role-

request solicitando que seu papel seja novamente master para os switches em questo.

Todavia, quando um switch recebe uma solicitao para responder a um novo controlador

master, este switch automaticamente reduz o seu controlador, que era master at ento,

para o papel slave. Assim, caso o controlador master inicial possua respostas pendentes

para um switch e passe, de modo abrupto, para o modo slave, a este no ser permitido

o envio de fluxos pendentes, j que controladores com papel slave no tm permisso

de escrita na tabela de fluxos de switches. Portanto, um mecanismo que permita uma

transio suave de switches entre controladores necessrio.

No processo de restaurao de falha, o controlador que volta de um perodo de in-

disponibilidade, no momento da inicializao de suas aplicaes, acessa o data store, e

percebe que est voltando de uma falha. A partir ento, assume o papel equal para todos

os switches que o tinham como master, entretanto no processa packet-in algum. Esse

procedimento otimiza a execuo da migrao, j que as mensagens de troca de papel so

enviadas na inicializao do controlador. Aps essa operao, considerando o controlador

, o controlador (voltando de uma falha), e um switch , os passos executados no

protocolo de migrao so definidos em quatro fases:

Fase 1: o controlador envia uma mensagem de migrao start-migration para o

controlador , inicializando o protocolo;

Fase 2: o controlador envia uma mensagem do tipo flow-mod ao switch , adi-

cionando um dummy-flow ; logo em seguida, envia uma outra mensagem do tipo

barrier-request. Essa mensagem garante que todos pacotes que tenham chegado

anteriormente barrier-request sejam processados antes que qualquer pacote que

chegue aps a mensagem de barreira; o switch responde com uma mensagem barrier-

reply ; ento, o controlador envia uma mensagem flow-mod ao switch excluindo

o dummy-flow adicionado alguns passos atrs; o switch responde com uma mensa-

gem flow-removed, que tanto o controlador quanto o recebem. Essa mensagem

funciona como um gatilho para o controlador , indicando que ele assumir o con-

trole do switch em questo;

Fase 3: como podem existir pacotes pendentes para ainda serem processados por

, uma nova mensagem de barreira enviada ao switch; assim que o controlador

recebe a barrier-reply, envia uma mensagem ao controlador finalizando a

migrao;

47

Fase 4: por sua vez, envia uma mensagem role-request master para , que ento

responde com uma mensagem role-reply. A Figura 5.6 apresenta os passos para a

migrao de switches.

Figura 5.6: Processo de Restaurao da Falha.

Por fim, cabe a aplicao de ConnectionManager definir os papis de cada controlador

em relao aos switches da rede. De acordo com as definies do OpenFlow, para cada

switch deve haver um, e apenas, um controlador master. No prottipo implementado os

switches so configurados de modo alternado, isto , o switch 1 tem o controlador A como

master e o controlador B como slave. J o switch 2 tem o controlador B como master e

o controlador A como slave.

5.3 Plano de Dados

Existem diversos equipamentos com suporte OpenFlow disponveis no mercado, entre-

tanto, em geral, esses equipamentos apresentam diversas limitaes, e talvez a principal

seja o fato de serem implementaes fechadas. Um outro ponto o desinteresse dos gran-

des fabricantes em acompanhar a evoluo do protocolo, o que leva a opes de switches

com verses mais antigas do protocolo OpenFlow ou com implementaes parciais, isto

, apenas algumas funes esto disponveis.

A partir de um projeto desenvolvido no NERDS, grupo de pesquisa ligado UFES,

foi criada uma plataforma aberta para experimentao em switches OpenFlow.

Nesse projeto utilizamos equipamentos da Mikrotik, uma empresa da Letnia fundada

em 1995, responsvel pelo desenvolvimento do sistema operacional RouterOS, e posteri-

48

ormente pela construo do hardware embarcado Mikrotik RouterBoard. Combinados,

eles so destinados ao mercado de pequenos a mdios provedores de servio Internet. O

Mikrotik RouterOS o sistema operacional embarcado originalmente no hardware Rou-

terBoard, podendo tambm ser instalado em computadores com arquitetura x86. Baseado

no Kernel do Linux verso 2.6, traz consigo uma gama de recursos, como roteamento,

firewall, controle de banda, ponto de acesso sem fio, hotspot, dentre outros [Mikrotik 2014].

A partir de sua verso 6.0, o RouterOS possibilita a utilizao do protocolo OpenFlow

verso 1.0, atravs da instalao de seu respectivo pacote. Por ser um software proprietrio

de plataforma fechada, o RouterOS no permite modificaes e atualizaes alm do

OpenFlow 1.0 padro, disponibilizado pelo fabricante.

O projeto da plataforma aberta iniciou-se pela substituio do sistema operacional, ori-

ginalmente RouterOS que suporta apenas OF 1.0 (Plataforma Fechada), pelo OpenWRT

[OpenWRT 2014] que permite a instalao dos switches virtuais (OvS e Softswitch13) que

suportam novas verses do protocolo OF (por exemplo a verso 1.3).

Em nossos experimentos utilizamos o OpenWRT, que uma distribuio GNU/Linux

altamente extensvel para dispositivos embarcados, dentre eles, o Routerboard utilizado

neste trabalho. Diferentemente dos demais softwares originais desses equipamentos, o

OpenWRT foi construdo a partir do zero para ser um sistema operacional completo e

facilmente modificado, utilizando um kernel do Linux mais recente que a maioria das

outras distribuies. Como mquina de encaminhamento, utilizamos o Open vSwitch

(OvS) que um switch virtual que segue a arquitetura OpenFlow, tambm imple-

mentado em software, mas com o plano de dados implementado diretamente no ker-

nel do Linux, en