TIAGO-PORTELA-DE-SOUZA

Prévia do material em texto

UNIVERSIDADE ESTADUAL DO CEARÁ
CENTRO DE CIÊNCIAS E TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
MESTRADO ACADÊMICO EM CIÊNCIA DA COMPUTAÇÃO
TIAGO PORTELA DE SOUZA
ARQUITETURA PARA FATIAMENTO DE REDES DE TRANSPORTE ÓPTICAS
UTILIZANDO O PARADIGMA DE REDES DEFINIDAS POR SOFTWARE
FORTALEZA – CEARÁ
2015
TIAGO PORTELA DE SOUZA
ARQUITETURA PARA FATIAMENTO DE REDES DE TRANSPORTE ÓPTICAS
UTILIZANDO O PARADIGMA DE REDES DEFINIDAS POR SOFTWARE
Dissertação apresentada ao Curso de Mestrado
Acadêmico em Ciência da Computação do
Programa de Pós-Graduação em Ciência da
Computação do Centro de Ciências e Tec-
nologia da Universidade Estadual do Ceará,
como requisito parcial à obtenção do título de
mestre em Ciência da Computação. Área de
Concentração: Ciência da Computação
Orientador: Prof Dr. Joaquim Celestino
Junior
Co-Orientador: Prof Dr. Maxwell Eduardo
Monteiro
FORTALEZA – CEARÁ
2015
Dados Internacionais de Catalogação na Publicação
 Universidade Estadual do Ceará
 Sistema de Bibliotecas
Souza, Tiago Portela de. 
 Arquitetura para fatiamento de redes de
transporte ópticas utilizando o paradigma de redes
definidas por software [recurso eletrônico] / Tiago
Portela de Souza. – 2015.
 1 CD-ROM: il.; 4 ¾ pol. 
 CD-ROM contendo o arquivo no formato PDF do
trabalho acadêmico com 78 folhas, acondicionado em
caixa de DVD Slim (19 x 14 cm x 7 mm).
 Dissertação (mestrado acadêmico) – Universidade
Estadual do Ceará, Centro de Ciências e Tecnologia,
Mestrado Acadêmico em Ciência da Computação,
Fortaleza, 2015.
 Área de concentração: Ciências da Computação.
 Orientação: Prof. Dr. Joaquim Celestino Júnior.
 Coorientação: Prof. Dr. Maxwell Eduardo Monteiro.
 1. Redes ópticas definidas por software. 2.
Fatiamento de redes ópticas. 3. Redes definidas por
sofware. 4. Redes ópticas. I. Título.
À minha família, por sua capacidade de acreditar
em mim e investir em mim. Mãe, seu cuidado
e dedicação foi que deram, em alguns momen-
tos, a esperança para seguir. Pai, sua presença
significou segurança e certeza de que não estou
sozinho nessa caminhada.
AGRADECIMENTOS
Primeiramente a Deus que permitiu que tudo isso acontecesse, ao me conceder saúde para
realizar meus objetivos.
Aos meus pais, Luciano e Vasconcelos de Souza e Lucia Portela de Souza, e minha irmã
Fernanda Portela de Souza, pelo amor, incentivo e apoio incondicional.
Aos irmãos que eu tive chance de escolher: Antônio Carlos e Vasconcelos Portela Junior,
Breno Furtado, David Bezerra, George Mayko, Hudson Freitas Mendes, José Machado Neto,
Leonan Vasconcelos Ribeiro, Ruan Rocha Américo de Souza e Yuri Praça.
Ao Professor Celestino, por permitir que eu entrasse no mestrado e trabalhasse em projetos de
alto nível em seu laboratório, mesmo sem me conhecer. Ao Professor Maxwell pela impres-
cindível ajuda no desenvolvimento da dissertação. Aos meus amigos Bruno Lopes, Jefferson
Alcântara e Jefferson Rodrigo, pela grande ajuda no entendimento, escrita e desenvolvimento
deste trabalho. Agradeço, também, todos meus companheiros de laboratório e de disciplinas que
me ajudaram no entendimento das matérias e a deixar os dias de trabalho mais divertidos.
Aos meus professores de graduação da Faculdade 7 de Setembro que foram os responsáveis
por toda a minha base em computação, podendo citar, dentre eles, os professores Ciro Carneiro
Coelho, Eduardo Mendes de Oliveira, Glauber Ferreira Cintra, Marum Simão Filho, Regis
Patrick Silva Simão, Roberio Gomes Patrício e Yuri Lenon Barbosa Nogueira.
“Stay hungry. Stay Foolish.”
(Steve Jobs)
RESUMO
As Redes Ópticas de Transporte (Optical Transport Networks - OTNs) são compostas por vários
dispositivos. A configuração desses dispositivos é feita de forma manual pelos operadores das
redes. Além de trabalhoso e suscetível a erros, essa forma de configuração limita também a
personalização e configuração da rede pelo cliente. Uma possível solução para esse problema
é a separação dos planos de controle e de dados desses dispositivos. As redes ópticas já
possuem essa separação proposta pelo Generalized Multi-protocol Label Switching (GMPLS),
porém, as aplicações responsáveis, por exemplo, pelo gerenciamento da topologia e roteamento,
ficavam embarcadas nos equipamentos. As redes definidas por software (Software Defined
Networks - SDNs) propõem a mesma separação de planos, mas com a flexibilidade para criação e
gerenciamento de aplicações pelos operadores de rede. Os possíveis benefícios de SDN para OTN
incluem a simplificação da virtualização da rede, a automação das operações da rede através de
interfaces programáveis e a implantação de novos serviços. O objetivo desta dissertação é propor
uma arquitetura que permita definir os componentes indispensáveis para atender as necessidades
de virtualização e fatiamento de redes OTNs; implementar um framework que será proposto
a partir da arquitetura, de tal forma que seja possível utilizar uma prova de conceito com o
intuito de atender as necessidades de criação de diversas redes virtuais fatiadas; a implementação
dos blocos necessários a partir da arquitetura levará em conta proposta de controladores SDN
atualmente disponíveis. Os controladores SDN atuais não possuem plugins responsáveis pela
virtualização e fatiamento dos elementos de redes ópticas, assim faz-se necessário a modelagem
dos elementos ópticos para criação de um plugin que permita o fatiamento das redes ópticas de
transporte.
Palavras-chave: SDN. OTN. Fatiamento de Redes Ópticas. Redes Ópticas Definidas por
Software. Virtualização de Redes Ópticas
ABSTRACT
The Optical Transport Networks (OTNs) are composed of multiple devices. The configuration
of these devices is done manually by system operators. Besides laborious and error-prone,
this configuration also limits the client customization and configuration of the network. One
way out of this lack of customization is the separation of control and data plans from these
devices. This separation is already in use by the Generalized Multi-protocol Label Switching
(GMPLS), however, the responsible applications, eg, for managing the topology and routing,
were embedded in the equipment. The Software Defined Networks (SDNs) propose the same
separation of plans, but with the flexibility to create and manage applications by network
operators. The possible benefits of SDN for OTN include simplification of network virtualization,
automation of network operation through programmable interfaces and the implementation of
new services. The objective of this dissertation is to propose an architecture that allows to
define the necessary components to meet the virtualization and slicing needs of OTN networks;
the implementation of a framework that will be proposed based on the architecture, so that it
can be used a proof of concept in order to meet the needs of creation of various sliced virtual
networks; to construct the building blocks needed for the architecture it will be considered the
currently available SDN controllers. Current SDN controllers do not have plugins responsible for
virtualization and slicing of network elements, so it is necessary to model the optical elements to
create a plugin that allows the slicing of optical virtual transport networks.
Keywords: OTN. SDN. Optical Network Slicing. Software Defined Optical Networks. Optical
Network Virtualization
LISTA DE ILUSTRAÇÕES
Figura 1 – Hierarquia OTN dividida em camadas . . . . . . . . . . . . . . . . . . . . 23
Figura 2 – Composição de um Optical Line Terminal . . . . . . . . . . . . . . . . . . 24
Figura 3 – Arquitetura do OTN Switch . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 4 – Diferença arquitetural das Redes Tradicionas e das Redes Definidas por
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 5 – Arquitetura de uma Rede Definida por Software: Planos de Gerência, Con-
trole e Dados . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 28
Figura 6 – Arquitetura OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 7 – Arquitetura OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 8 – Transceptor sintonizável e os possíveis parâmetros de configuração . . . . . 32
Figura 9 – Plano de Controle integrado OpenFlow-GMPLS . . . . . . . . . . . . . . . 33
Figura 10 – Tabela de Fluxo dos nós de ingresso e egresso da rede óptica após o estabele-
cimento do LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 11 – Diagrama de sequência representando o funcionamento do plano de controle
integrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 12 – Arquitetura SDN para uma rede heterogêna . . . . . . . . . . . . . . . . . 36
Figura 13 – Arquitetura do agente responsável pela abstração dos elementos da rede . . 37
Figura 14 – Tabela de fluxos do comutador OpenFlow estendido . . . . . . . . . . . . . 37
Figura 15 – Arquitetura de um controlador SDN para Redes Opticas . . . . . . . . . . . 39
Figura 16 – Arquitetura proposta para possibilitar o fatiamento de uma rede óptica . . . 41
Figura 17 – Módulo de fatiamento de redes ópticas . . . . . . . . . . . . . . . . . . . . 42
Figura 18 – Diagrama de classes mostrando a estrutura básica de um dispositivo óptico . 43
Figura 19 – Exemplo de uma entrada para informar as capacidades de um elemento óptico,
seguindo o modelo mostrado na Figura 18 . . . . . . . . . . . . . . . . . . 43
Figura 20 – Diagrama de classes mostrando a estrutura básica de armazenamento de uma
topologia de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 21 – Exemplo de uma entrada para informar a topologia de uma rede óptica,
seguindo o modelo mostrado na Figura 20 . . . . . . . . . . . . . . . . . . 45
Figura 22 – Topologia de rede construída a partir das especificações exibidas na Figura 21 45
Figura 23 – Diagrama de classes representando as informações necessárias para armaze-
nar conexões em uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 24 – Diagrama de classes representando as informações de uma fatia da rede . . 47
Figura 25 – Exemplo de uma entrada para solicitar a criação de uma nova fatia . . . . . 48
Figura 26 – Exemplo de uma fatia criada a partir do XML mostrado na Figura 25, utili-
zando como base a rede mostrada na Figura 27 . . . . . . . . . . . . . . . . 49
Figura 27 – Rede utilizada como base no exemplo de solicitação de criação de uma fatia 49
Figura 28 – Diagrama de sequência do fluxo básico da criação de uma fatia . . . . . . . 50
Figura 29 – Exemplo de uma entrada para solicitar o aprovisionamento de um caminho
em uma determinada fatia . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 30 – Diagrama de sequência do fluxo básico do aprovisionamento de um caminho 52
Figura 31 – Arquitetura desenvolvida para fatiamento de uma rede óptica . . . . . . . . 53
Figura 32 – Implementação do módulo de fatiamento de redes ópticas . . . . . . . . . . 54
Figura 33 – Diagrama de classes representando a estrutura básica do plugin Optical Slicer
e sua conexão com o plugin Optical Provisioning . . . . . . . . . . . . . . 55
Figura 34 – Exemplo de uma mensagem enviada para reconfigurar uma matriz de cross-
conexão modelada em uma máquina virtual . . . . . . . . . . . . . . . . . 56
Figura 35 – Modelo YANG de cross-conexão . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 36 – Topologia de uma rede com N nós, onde o nó origem possui o identificador 1
(um) e o nó destino possui o identificador N . . . . . . . . . . . . . . . . . 58
Figura 37 – Gráfico ilustrando o tempo médio necessário para criação de 3 (três) fatias
em diferentes topologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 38 – Gráfico ilustrando a porcentagem de tempo, em média, necessário para
executar os subprocessos da criação de fatias . . . . . . . . . . . . . . . . . 61
Figura 39 – Gráfico ilustrando o crescimento exponencial do tempo médio necessário
para criação de 3 (três) fatias em diferentes topologias . . . . . . . . . . . . 61
Figura 40 – Gráfico ilustrando o tempo médio necessário para aprovisionar um caminho
válido nas 3 (três) fatias, utilizando topologias diferentes . . . . . . . . . . 63
Figura 41 – Gráfico ilustrando a porcentagem de tempo, em média, necessário para
executar os subprocessos do aprovisionamento de caminhos . . . . . . . . . 63
Figura 42 – Gráfico ilustrando o crescimento linear do tempo médio necessário para
aprovisionar um caminho válido nas 3 (três) fatias, utilizando topologias
diferentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
LISTA DE TABELAS
Tabela 1 – Tabela com o tempo necessário para o controlador criar as fatias requisitadas,
reiniciando o controlador para cada teste. A Topologia 1 é formada por 5
(cinco) nós. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 2 – Tabela com o tempo necessário para o controlador criar as fatias requisitadas,
sem reiniciar o controlador para cada teste. A Topologia 1 é formada por 5
(cinco) nós. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tabela 3 – Tabela com o tempo necessário para o controlador aprovisionar um caminho
para cada uma das 3 (três) fatias, reiniciando o controlador para cada teste. A
Topologia 1 é formada por 5 (cinco) nós. . . . . . . . . . . . . . . . . . . . 62
Tabela 4 – Tabela com o tempo necessário para o controlador aprovisionar um caminho
para cada uma das 3 (três) fatias, sem reiniciar o controlador para cada teste.
A Topologia 1 é formada por 5 (cinco) nós. . . . . . . . . . . . . . . . . . . 62
Tabela 5 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 1 . 69
Tabela 6 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 2 . 69
Tabela 7 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 3 . 70
Tabela 8 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 4 . 70
Tabela 9 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 5 . 70
Tabela 10 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 70
Tabela 11 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 71
Tabela 12 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 1 . 72
Tabela 13 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 2 . 72
Tabela 14 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 3 . 72
Tabela 15 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 4 . 72
Tabela 16 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 5 . 73
Tabela 17 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 73
Tabela 18 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 73
Tabela 19 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 1 . 74
Tabela 20 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 2 . 74
Tabela 21 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 3 . 75
Tabela 22 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 4 . 75
Tabela 23 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 5 . 75
Tabela 24 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 75
Tabela 25 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 76
Tabela 26 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 1 . 77
Tabela 27 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 2 . 77
Tabela 28 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 3 . 77
Tabela 29 – Tabela com o tempo necessário para aprovisionar caminhosna Topologia 4 . 77
Tabela 30 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 5 . 78
Tabela 31 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 78
Tabela 32 – Tabela com o tempo necessário para aprovisionar caminhos na Topologia 6 . 78
LISTA DE ABREVIATURAS E SIGLAS
APS Automatic Protection Switching.
CIC Client Interface Card.
FDM Frequency Division Multiplexing.
JSON JavaScript Object Notation.
LLDP Link Layer Discovery Protocol.
NETCONF Network Configuration Protocol.
NIC Network Interface Card.
O-VPN Optical Virtual Private Network.
OCh Optical Channel Layer.
ODL OpenDaylight.
ODU Optical Channel Data Unit.
OIC Optical Interface Card.
OMS Optical Multiplex Section.
ONS Optical Network Slicer.
OPU Optical Channel Payload Unit.
OTN Optical Transport Network.
OTS Optical Transmission Section.
OTU Optical Channel Transport Unit.
PCE Path Computation Element.
REST Representational State Transfer.
SDN Software Defined Networks.
SDON Software Defined Optical Networks.
SNC SubNetwork Connection.
SNMP Simple Network Management Protocol.
TDM Time Division Multiplexing.
UNI User Network Interface.
VON Virtual Optical Network.
VPN Virtual Private Network.
WDM Wavelength Division Multiplexing.
WSS Wavelength Selective Switch.
XML Extensible Markup Language.
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 20
2.1 REDES ÓPTICAS DE TRANSPORTE . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Recomendações sobre OTN . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Camadas OTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Arquitetura de uma rede OTN . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.3.1 OTN Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 REDES DEFINIDAS POR SOFTWARE . . . . . . . . . . . . . . . . . . . 27
2.2.1 Protocolo OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 31
3.1 EXTENDING SOFTWARE DEFINED NETWORK PRINCIPLES TO IN-
CLUDE OPTICAL TRANSPORT . . . . . . . . . . . . . . . . . . . . . . 31
3.2 INTEGRATED OPENFLOW–GMPLS CONTROL PLANE: AN OVER-
LAY MODEL FOR SOFTWARE DEFINED PACKET OVER OPTICAL
NETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 SOFTWARE-DEFINED OPTICAL NETWORKS TECHNOLOGY AND IN-
FRASTRUCTURE: ENABLING SOFTWARE-DEFINED OPTICAL NETWORK
OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 AN OPTICAL SDN CONTROLLER FOR TRANSPORT NETWORK VIR-
TUALIZATION AND AUTONOMIC OPERATION . . . . . . . . . . . . . 38
4 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 ARQUITETURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Topology Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3 Path Computation Element . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.4 Provisioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.5 Slices Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Criar Fatia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 Aprovisionar Caminho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 ARQUITETURA IMPLEMENTADA . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 Optical Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2 Optical Slicer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3 Optical Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.4 Máquinas Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 CENÁRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.1 Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.2 Topologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 CRIAÇÃO DE FATIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3 APROVISIONAMENTO DE CAMINHOS . . . . . . . . . . . . . . . . . . 61
7 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 65
7.1 CONTRIBUIÇÕES DO TRABALHO . . . . . . . . . . . . . . . . . . . . 65
7.2 LIMITAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ANEXOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ANEXO A – Resultado dos testes de desempenho na criação de fatias . . . 69
A.0.1 Resultado dos testes com a reinicialização do controlador . . . . . . . . 69
A.0.2 Resultado dos testes sem a reinicialização do controlador . . . . . . . . . 72
ANEXO B – Resultado dos testes de desempenho no aprovisionamento de
caminhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.0.3 Resultado dos testes com a reinicialização do controlador . . . . . . . . 74
B.0.4 Resultado dos testes sem a reinicialização do controlador . . . . . . . . . 77
16
1 INTRODUÇÃO
As redes de computadores são formadas por várias redes diferentes interconectadas,
compostas por inúmeros dispositivos de diferentes fabricantes, através de protocolos padroni-
zados. Como resultado estão se tornando extremamente complexas. Os operadores de rede
são responsáveis por configurar as políticas que respondem aos eventos e aplicações de rede,
toda essa configuração é feita manualmente. Roteadores e Comutadores possuem interfaces de
gerenciamento que permitem ao operador a configuração e gerência desses equipamentos, por
exemplo, interfaces de linha de comando, XML/NETCONF ou Protocolo Simples de Gerência
de Rede (SNMP). Assim o operador poderia ter acesso as capacidades dos equipamentos, porém,
os níveis mais baixos de detalhes ainda eram escondidos do operador. Além de dificultar o
gerenciamento da rede, sua otimização e customização, essa diversidade de equipamentos de
fabricantes distintos impedia o desenvolvimento de inovações, pois torna quase impossível que
pesquisadores testem e programem novas tecnologias. (NADEAU; GRAY, 2013) (JI, 2012).
As Redes Definidas por Software (SDN) fornecem uma abordagem para solucionar
esses problemas. SDN é basicamente uma abordagem arquitetural que aperfeiçoa e simplifica as
operações da rede por criar um vínculo maior entre as aplicações, serviços de rede e dispositivos
(reais ou virtualizados). Nessa abordagem um dispositivo de rede é constituído por um plano de
dados, que é muitas vezes uma matriz de comutação que liga as várias portas de um dispositivo,
e um plano de controle que é o cérebro do dispositivo. Este cérebro iria enviar comandos para
cada dispositivo, comandando-o, assim, a manipular sua comutação e roteamento de hardware
físico.
As redes de transporte ópticas já possuem um controle centralizado, porém muitas
tarefas de reconfiguração da rede ainda requerem operaçãomanual. Com a evolução das redes
ópticas, de um modelo estático para um mais configurável e dinâmico, vários desafios são
apresentados para o plano de controle, como equalização óptica, roteamento e alocação de
espectro, virtualização de serviços e outros. Os possíveis benefícios de SDN para OTN incluem
simplificação da rede, virtualização das capacidades da rede, automação das operações da rede
através de interfaces programáveis e implantação de novos serviços. O paradigma atual das redes
de transporte já emprega um controle centralizado, auxiliado por funcionalidades distribuídas
do GMPLS, como descobrimento da rede, atualização do estado da rede e outros. Assim, o
desenvolvimento das Redes Ópticas Definidas por Software (SDON) deve considerar estratégias
de migração e a melhor localização para implementação dessas funções (SIQUEIRA et al.,
17
2013).
1.1 MOTIVAÇÃO
Algumas empresas conectam grandes escritórios e data centers para computação e
armazenamento virtual baseado em nuvem, enfrentando demandas média e alta de largura de
banda entre sites, e exigem a realocação da capacidade rapidamente direcionada por aplicações
como sistemas de orquestração de nuvem. O controle logicamente centralizado do SDN fornece
uma perspectiva para otimizar o uso de todos os recursos da rede, assim as empresas podem
mudar rotas dinamicamente para alocar largura de banda entre os sites como necessário por
seus aplicativos. De tal forma SDN permite que os departamentos de tecnologia da informação
corporativos funcionem como seus próprios prestadores de serviços, tal capacidade interna lhes
permite gerir conectividade e alocar largura de banda entre os sites em minutos em vez de
esperar semanas ou meses para o provedor local cumprir seu pedido de alteração da linha fixa
(FOUNDATION, 2014).
Uma empresa gerindo uma rede óptica privada tem a flexibilidade para gerenciar
sua rede e orquestrar mudanças de capacidade entre os seus sites onde e quando eles são
necessários, porém isso demanda um alto preço pelos equipamentos dedicados e fibras alugadas
e a necessidade de expertise para gerenciar a rede por conta própria. As redes ópticas privadas
virtuais (O-VPN) tem como objetivo oferecer as mesmas vantagens das redes ópticas privadas,
porém sem o custo da expertise para gerenciamento e da dedicação dos equipamentos. Usando
redes de transporte SDN, o serviço de O-VPN é possível através de virtualização de rede que
permite a um operador de rede criar fatias virtuais da rede que oferecem capacidade dedicada e
fornecer ao cliente o controle de autogestão da sua rede virtual fim a fim.
Até o momento o conceito de redes definidas por software só é aplicado em redes IP,
com comutação de pacotes, e não estão disponíveis para redes de transporte com comutação de
circuitos. Os controladores SDN possuem plugins responsáveis pela virtualização dos elementos
de rede, porém, esse plugin virtualiza apenas redes ethernet, assim, existe um grande interesse no
desenvolvimento de um plugin para virtualização e fatiamento de redes que possua conhecimento
sobre as especificidades e restrições de equipamentos ópticos.
Nos últimos anos o conceito de cidades inteligentes vem ganhando força. Várias
cidades no mundo estão se adequando a este conceito, que visa de forma ampla utilizar a tecnolo-
gia para melhorar a infraestrutura e tornar os centros urbanos mais eficientes e autossustentáveis.
18
Para que isso aconteça é necessário que haja conectividade entre os vários elementos que com-
põem uma cidade. Os governos envolvidos nesse processo já adotaram o uso de novas tecnologias
como análise de dados, dispositivos móveis e aplicações web robustas, com o objetivo de obter
uma melhor administração e comunicação com o público. Dentre as possíveis aplicações das
cidades inteligentes estão: sistemas de relatórios intuitivos de crimes que destacam áreas proble-
máticas, análise de tráfego para redução dos congestionamentos, ambulâncias se comunicando
com sistemas de tráfego para encontrar a rota mais rápida ao hospital, aplicativos que encontram
vagas para estacionar, carros autônomos, dentre outros.
A cidade de Bristol na Inglaterra está desenvolvendo um projeto chamado "Bristol is
Open", a ideia é transformar a cidade em um ambiente de incentivo a inovação, para isso ela
conta com uma rede de fibra com capacidade de 30 Gb/s. Esse projeto transformará Bristol em
um laboratório gigante com grande quantidade de dados coletados para solucionar problemas
como tráfego, poluição do ar, etc. Um dos princípios desse projeto é tornar anônimos e públicos
todos os dados coletados na cidade. Para que seja possível gerenciar e manusear todos esses
dados coletados, seria interessante dividir a rede em fatias, onde cada aplicação receberia uma
porção da largura de banda disponível na cidade (HTTP://WWW.BRISTOLISOPEN.COM/,
2015).
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Propor uma arquitetura que permita definir os componentes indispensáveis para
atender as necessidades de virtualização e fatiamento de redes OTNs e um framework que será
proposto a partir da arquitetura, como prova de conceito para criação de diversas fatias de redes
virtuais
1.2.2 Objetivos Específicos
a) Estudar redes ópticas para entender quais informações podem ser utilizadas na
virtualização
b) Definir o nível de granularidade da abstração dos elementos ópticos utilizados na
construção da topologia da rede virtualizada
c) Estudar o controlador OpenDaylight e seu módulo de virtualização para redes
19
ethernet
d) Estudar o módulo do OpenDaylight responsável pelo gerenciamento da topologia
da rede
e) Criar um módulo para fatiamento de redes ópticas
f) Criar uma aplicação que solicite o fatiamento da rede
20
2 FUNDAMENTAÇÃO TEÓRICA
O objetivo deste capítulo é apresentar uma visão geral de redes OTN, citando algumas
das principais recomendações de padronização desta tecnologia, descrevendo sua arquitetura
em camadas e citando os principais elementos que compõem esta rede, como o OTN switch,
utilizado como objeto de virtualização nesta dissertação.
2.1 REDES ÓPTICAS DE TRANSPORTE
O crescimento da demanda por banda, a necessidade da transmissão de dados a
velocidades cada vez maiores e aplicações com grande volume de informações sensíveis a
atrasos, foram alguns dos motivos que impulsionaram a pesquisa e desenvolvimento de uma rede
mais veloz. As primeiras redes de transporte eram analógicas e utilizavam cabos coaxiais para
transmissão.
Na década de 70, surgiram os sistemas de transmissão digital utilizando a técnica de
multiplexação por divisão de tempo (TDM), os quais proporcionaram uma melhoria na relação
sinal-ruído, aumentando de forma significativa as distâncias de transmissão. A técnica TDM foi
concebida para o transporte de voz nas redes telefônicas. A PDH é uma rede hierárquica de vários
níveis na qual o sinal agregado de cada ordem é formado pela junção outros sinais, denominados
tributários. A principal dificuldade do sistema PDH é a inserção/derivação dos tributários em
trechos intermediários da rede. Com isso, para inserir e/ou derivar canais tributários de um
sistema PDH, é necessário demultiplexar o feixe agregado, o que torna esse padrão pouco
flexível e de alto custo. Além disso, a PDH apresenta pouca capacidade de gerenciamento da
rede. (BERNARDO et al., 2011)
Segundo (RAMASWAMI et al., 2010), quando se fala sobre redes ópticas, normal-
mente se refere às duas gerações de redes ópticas tradicionais. Na primeira geração, as redes
eram essencialmente usadas para transmissão e aumento da capacidade. A fibra óptica é um
meio que provê baixa taxa de erro e alta capacidade de transmissão em comparação com outras
tecnologias. Todas as operações de comutação e outras funções inteligentes das redes dessa
geração são feitas eletronicamente, a partir de uma conversão O-E-O em cada elemento de rede.
Exemplos dessa primeira geração são o SONET, tecnologia usada principalmente na América doNorte, e o SDH, similar ao SONET e utilizado no Brasil, Europa e Ásia.
Na década de 90, iniciaram-se os estudos de um novo padrão, denominado Rede
21
Óptica de Transporte (OTN), para maximizar a eficiência dos sistemas de transmissão e propiciar
a sonhada integração IP/WDM. O orgão responsável por sua padronização é o International Tele-
communication Union (ITU-T), a primeira versão do padrão está descrita na norma G.709. Uma
das principais vantagens da utilização da OTN é possibilitar o uso eficiente dos comprimentos de
onda dos sistemas com a multiplexação por divisão de comprimento de onda (WDM), que é bem
similar a multiplexação por divisão de frequência (FDM). A OTN possibilita o transporte de
serviços de dados com granularidade bastante fina, como, por exemplo, VLANs Ethernet, Label
Switched Paths (LSPs) e MPLS. Com isso, é possível criar rotas fim a fim, que se originam na
rede de dados, passam pela rede óptica e terminam na rede de dados. (BERNARDO et al., 2011)
(RAMASWAMI et al., 2010)
Abaixo podemos ver os principais aprimoramentos trazidos com a OTN (ITU-T,
2010):
• Escalabilidade aprimorada: a OTN define um esquema de multiplexação similar
ao do SONET/SDH, porém transporta dados nativamente a taxas de 100 Gbps,
40 Gbps, 10 Gbps, 2,5 Gbps, 1,25 Gbps e inferiores, com uma quantidade menor
de overhead
• Transporte transparente do sinal cliente: alguns sinais clientes são encapsulados
diretamente dentro da OTN, enquanto outros tráfegos de dados utilizam, por
exemplo, o Generic Framing Procedure (GFP). Dessa forma, a OTN pode trans-
portar qualquer forma de sinal digital, e, por isso, é denominada “empacotador”
digital (digital wrapper). Essa transparência permite o transporte de uma grande
quantidade de tipos de sinais clientes, entre eles: SONET/SDH, Ethernet, Fibre
Channel, Asynchronous Transfer Mode (ATM), Frame Relay, e IP (Internet Pro-
tocol). Esses sinais são transportados sem que haja alterações nas características
intrínsecas do sinal original (formato, taxa de bits e clock)
• Mecanismo aprimorado de correção de erros (FEC – Forward Error Correction):
O SONET/SDH já possui um mecanismo de FEC, porém utiliza alguns bytes
do cabeçalho que não possuem uso definido para transportar a informação de
FEC. A OTN possui um campo maior, permitindo alcançar distâncias maiores de
transmissão sem regeneração, uma vez que o algoritmo é capaz de corrigir uma
quantidade maior de erros de bit
• Mais níveis de monitoramento TCM (Tandem Connection Monitoring): o ca-
22
beçalho OTN suporta até seis níveis de TCM independentes, tornando possível
o monitoramento de vários segmentos de caminhos em múltiplos e distintos
domínios administrativos.
• Operação, Administração, Manutenção e Aprovisionamento (OAMP): a OTN
provê funções de operação, administração, manutenção e aprovisionamento,
herdadas do SONET/SDH e expandidas para as camadas elétricas da rede OTN
Com o avanço da tecnologia, funções mais complexas foram atribuídas às redes
ópticas como comutação, roteamento na camada óptica da rede, funções de monitoramento
e gerenciamento foram adicionadas nos níveis ópticos da rede. Essas novas funcionalidades
caracterizam a segunda geração de redes ópticas.
2.1.1 Recomendações sobre OTN
Com o objetivo de difundir as redes OTN e criar uma padronização para os fa-
bricantes de elementos desta rede, a International Telecommunication Union no seu setor de
padronização de telecomunicações ITU-T, desenvolveu uma série de recomendações para especi-
ficar as funcionalidades, arquitetura, gerenciamento, etc, de redes OTN. Com tal padronização, é
possível a interoperabilidade de equipamentos entre diferentes fabricantes de maneira automática,
aumentando a usabilidade da OTN. Este trabalho utiliza as seguintes recomendações ITU-T:
ITU-T G.709, ITU-T G.798 descritas a seguir.
ITU-T G.709 (Interfaces for the Optical Transport Network (OTN)): essa recomen-
dação define as interfaces da OTN a serem usadas com as demais redes. Ela define, entre
outras coisas, os formatos de mapeamento dos sinais cliente, a hierarquia de transporte óptico,
a estrutura dos quadros, as funcionalidades do overhead, as taxas de bits, e a multiplexação de
sinais (ITU-T, 2012a).
ITU-T G.798 (Characteristics of Optical Transport Network Hierarchy Equipment
Functional Blocks): essa recomendação especifica, entre outras coisas, uma biblioteca de
blocos funcionais e um conjunto de regras que devem ser utilizadas a fim de se construir os
elementos de rede na OTN. Ela define as funções atômicas que representam as camadas da
OTN, sua interoperabilidade e o modo de como são tratadas as mensagens internamente à OTN,
especificando a correlação de defeitos, o tratamento de erros e ações consequentes (ITU-T,
2012b).
ITU-T G.874.1 (Optical transport network: Protocol-neutral management informa-
23
tion model for the network element view): essa recomendação aborda especificamente um
modelo de informação independente de protocolos, no qual é mostrado, de forma genérica, um
modelo de classes da camada de rede de transporte (ITU-T, 2012c).
2.1.2 Camadas OTN
Segundo (RAMASWAMI et al., 2010) as redes ópticas são divididas em duas
hierarquias: hierarquia óptica e hierarquia digital. Essas hierarquias são subdivididas em
camadas. A hierarquia óptica é formada pelas camadas: Optical Multiplex Section (OMS) e
Optical Transmission Section (OTS). Já na hierarquia digital temos a camada Optical Channel
Layer (OCh), que é subdividida nas camadas: Optical Channel Payload Unit (OPU), Optical
Channel Data Unit (ODU) e Optical Channel Transport Unit (OTU) (Figura 1).
Figura 1 – Hierarquia OTN dividida em camadas
Fonte: (RAMASWAMI et al., 2010)
A camada OCh e suas subcamadas são responsáveis pela criação e gerenciamento do
quadro OTN, também fornece um caminho óptico para transportar o sinal cliente pela rede OTN,
realizando conversão do sinal elétrico para óptico entre duas terminações ópticas. Na camada
OPU são realizadas adaptações necessárias para o transporte do sinal cliente pela rede OTN. A
camada ODU provê as funcionalidades de multiplexação TDM, proteção, supervisão fim-a-fim
do caminho, TCM (Tandem Conection Monitoring), entre outras funcionalidades de monitoração
da qualidade do sinal. A camada OMS é responsável por multiplexar/demultiplexar diversos
comprimentos de onda, cada um transportando um canal óptico, em uma fibra. A camada OTS
24
fornece um caminho óptico ponto-a-ponto entre dois elementos ópticos.
A transmissão nas redes OTN possui taxas pré-estabelecidas 1,25 Gbps; 2,5 Gbps;
10 Gbps; 40 Gbps e 100 Gbps, com o uso da técnica de multiplexação por divisão de tempo
(TDM), é possível transportar sinais clientes com taxas diferentes às taxas padrão de maneira
eficiente, incluindo sinais com taxas inferiores a 1,25 Gbps, sendo estes acomodados em ODUs
de baixa ordem e, após a multiplexação, acomodados em ODUs de alta ordem.
2.1.3 Arquitetura de uma rede OTN
Segundo (RAMASWAMI et al., 2010), a rede OTN é composta pelos seguintes
elementos:
• Optical line terminals (OLTs): usados no fim de um enlace ponto-a-ponto para
multiplexar e demultiplexar comprimentos de onda. Multiplexam vários compri-
mentos de onda em uma única fibra e demultiplexam um sinal WDM composto
em sinais individuais. São compostos por transponders, multiplexadores e ampli-
ficadores (Figura 2)
Figura 2 – Composição de um Optical Line Terminal
Fonte: (RAMASWAMI et al., 2010)
• Optical Add/Drop Multiplexers (ROADMs): Permite acessar sinais sem a neces-
sidade de voltar ao domínio eletrônico, além de prover a habilidade de adicionar
e derivar comprimentos de onda desejados dinamicamente sem planejamento
prévio dos equipamentos
• Optical Crossconnects (OXCs): são necessários em redes com topologias mais
complexas e com um grande número de comprimentos de onda. Comprimentos
de onda podem ser adicionados ou derivados quando necessários
• Amplificadores
25
• OTN Switch: possuiem um mesmo equipamento toda dinamicidade e flexibili-
dade proveniente das redes OTN, através da comutação e multiplexação de sinais
ópticos (OCh) e digitais (ODU)
2.1.3.1 OTN Switch
Em (DILEM et al., 2011) é apresenta uma proposta de arquitetura para o equipamento
OTN Switch, com enfoque nas funcionalidades apresentadas pelas Recomendações ITU-T,
especialmente a ITU-T G.798. Nele são exploradas as principais características do OTN Switch:
multiplexação e comutação de sinais nos domínios óptico e elétrico. Essas funcionalidades
tornam a OTN mais flexível e dinâmica, aproximando-a cada vez mais da próxima geração de
redes de transporte. Nessa proposta o equipamento é dividido em seis diferentes módulos, que
processam e/ou tratam os sinais nos domínios elétrico e óptico: CIC, ODU Switch, NIC, WSS,
OIC e Controller Card (Figura 3).
O CIC (CIC) é responsável por adaptar/recuperar um sinal cliente ingressando/saindo
na rede OTN. O módulo ODU Switch se encarrega da comutação elétrica dos sinais ODU internos
ao OTN Switch. Essa comutação é implementada por conexões de subrede (SNC) as quais
podem ser configuradas de forma automática por um plano de controle (OpenFlow, GMPLS,
etc.), ou por intervenção do operador da rede. Adicionalmente, o módulo ODU Switch é capaz
de proteger sinais ODU, fazendo uso do protocolo Automatic Protection Switching (APS). O
Network Interface Card (NIC) é responsável por prover um caminho fim-a-fim elétrico, inserir
informações de gerenciamento e correção de erros, além de fornecer a funcionalidade de, quando
necessário, um ou mais estágios de multiplexação ODU. É na NIC que acontece a conversão O-E-
O. No módulo Wavelength Selective Switch (WSS) um sinal óptico pode ser roteado, protegido,
adicionado/extraído em/de um agregado de sinais WDM. Por sua vez, o Optical Interface Card
(OIC) realiza o tratamento do sinal óptico, ou seja, a (de)multiplexação dos diferentes canais
ópticos em uma fibra, amplificação e compensação de dispersão. A Placa Controladora, ou
Controller Card realiza as funções de gerenciamento do equipamento (EMF) e comunicação
(MCF) com entidades do plano de gerência, plano de controle ou com a rede de comunicação de
dados (DCN) (DILEM et al., 2011).
A cross-conexão é responsável pela comutação entre sinais de entrada e saída,
definindo suas rotas. A comutação óptica torna-se possível utilizando uma matriz de conexão
presente na OCh_C. Utilizando essas funcionalidades, é possível realizar “roteamento” e proteção
26
Figura 3 – Arquitetura do OTN Switch
Fonte: (DILEM et al., 2011)
em faixas de comprimentos de onda ou a comprimentos de onda individuais, adicionando à rede,
importantes ferramentas de engenharia de tráfego. Semelhante à comutação óptica, a comutação
digital é realizada com a configuração da matriz de conexão da ODU_C, estabelecendo ligações
27
entre diferentes portas de um mesmo equipamento, ou entre equipamentos distintos. O sinal
ODUk é comutado entre uma porta de entrada e uma porta de saída de acordo com as conexões
estabelecidas pela matriz de conexão. (DILEM et al., 2011) descreve o ODU Switch com base
na recomendação ITU-T G.798, como sendo composto exclusivamente pela função de conexão
ODU_C, que é responsável por realizar as cross-conexões.
2.2 REDES DEFINIDAS POR SOFTWARE
As redes de computadores são compostas por inúmeros dispositivos, entre eles
temos roteadores e comutadores, que utilizam diferentes tipos de protocolos. Essas redes
possuem algumas limitações para atender a novos requisitos em segurança, qualidade de serviço,
configuração e evolução.
Os operadores de rede são responsáveis por configurar as políticas que respondem
aos eventos e aplicações de rede, toda essa configuração é feita manualmente, individualmente
para cada equipamento, e com ferramentas bastante limitadas e comandos de baixo nível e
específicos dos fabricantes de cada equipamento, dando margem a erros na configuração da rede.
As redes atuais são verticalmente integradas, ou seja, o Plano de Controle, que
decide como lidar com o tráfego da rede, e o Plano de Dados, que encaminha o tráfego de
acordo com as regras definidas pelo Plano de Controle, estão acoplados dentro dos equipamentos
de rede, limitando e reduzindo a flexibilidade e inovação (KREUTZ et al., 2014). A ideia
de redes programáveis foi proposta como uma maneira de facilitar a evolução das redes. Em
particular, redes definidas por software (SDN) são um novo paradigma no qual o hardware de
encaminhamento é desacoplado das decisões de controle (Figura 4) (ASTUTO et al., 2014).
Figura 4 – Diferença arquitetural das Redes Tradicionas e das Redes Definidas por Software
Fonte: (ASTUTO et al., 2014)
28
A arquitetura de uma rede SDN (Figura 5) é dividida em três planos: Plano de
Gerenciamento, Plano de Controle, Plano de Aplicação. O Plano de Gerenciamento é composto
por um conjunto de aplicações que implementam o controle da rede e suas operações lógicas,
como aplicações de roteamento, balanceamento de carga, monitoramento, etc.
O Plano de Controle é o cérebro da rede, cabe a ele programar e configurar os ele-
mentos do Plano de Dados. O Plano de Dados é composto pelos dispositivos de encaminhamento
interconectados. A comunicação entre os planos de Gerência e Controle é feita através de uma
Northbound API, já a comunicação entre os planos de Controle e Dados é feita através de uma
Southbound API.
Figura 5 – Arquitetura de uma Rede Definida por Software: Planos de Gerência, Controle e
Dados
Fonte: (KREUTZ et al., 2014)
2.2.1 Protocolo OpenFlow
Direcionado pelo princípio SDN de desacoplamento dos planos de Controle e Dados,
o protocolo mais conhecido e utilizado é o OpenFlow, que estabeleceu uma padronização na
informação trocada entre os dois planos. O comutador OpenFlow possui uma ou mais tabelas
de fluxo e um canal de comunicação seguro utilizado para comunicação com o controlador.
As tabelas de fluxos são formadas por entradas que determinam como os pacotes deverão ser
tratados. Essas entradas são compostas por regras, que utilizam campos dos cabeçalhos dos
pacotes recebidos para identificar o tipo de fluxo, contadores, utilizados para coletar estatísticas
do fluxo, e um conjunto de ações, que determinam como tratar os pacotes (Figura 6) (ASTUTO
29
et al., 2014) (MCKEOWN et al., 2008).
Ao iniciar a rede todos os comutadores OpenFlow possuem tabelas vazias, ao receber
o pacote o comutador retira informações dos cabeçalhos desse pacote tentando validar o pacote
em alguma de suas entradas, ao perceber que o pacote não se encaixa em nenhuma regra, o
comutador envia o mesmo ao controlador que decidirá como esse fluxo deve ser tratado e
atualizará as tabelas dos comutadores. Assim, na próxima vez que o comutador receber um
pacote pertencente a esse fluxo ele o tratará de acordo com as regras definidas pelo controlador,
precisando assim, definir tais regras apenas uma única vez para cada fluxo.
Figura 6 – Arquitetura OpenFlow
2.2.2 OpenDaylight
OpenDaylight é uma plataforma para programabilidade de redes que permite a
implantação dos conceitos SDN. Possui em seu núcleo um controlador modular e flexível. Esse
controlador é implementado estritamente como software e contém sua própria máquina virtual
Java (JVM), sendo assim irrestrita a hardwares e sistemas operacionais.
O controlador utiliza o framework Open Services Gateway Initiative (OSGi) para
comunicação das aplicações que rodam no mesmo endereço do controlador e utiliza o protocolo
REST (REST) para comunicação das aplicações com o controlador. As lógicas de negócio
e algoritmos encontram-se nas aplicações, que utilizam o controlador como forma de obter
informações sobre a rede, rodar algoritmos para analisar a rede e orquestrar as novas regras que
a rede deve seguir.
O controlador possui uma coleção de módulos dinamicamente plugáveis que exe-
cutam as tarefas necessárias pela rede, como entender quais os dispositivos estão contidos na
rede e quaissuas capacidades. Além disso, é possível a criação e adição de novos módulos
30
personalizados.
O controlador expõe uma API northbound utilizada pelas aplicações e uma API
southbound capaz de suportar múltiplos protocolos, como OpenFlow 1.0, OpenFlow 1.3, BGP-
LS, etc. Esses protocolos suportados pela API southbound são unificados em uma Camada de
Abstração de Serviços (SAL), que expõe os serviços dos dispositivos para os módulos contidos no
controlador. A SAL determina como atender ao serviços requisitados independente do protocolo
utilizado pelo controlador para se comunicar com os dispositivos de rede.
Figura 7 – Arquitetura OpenDaylight
Fonte: (KREUTZ et al., 2014)
31
3 TRABALHOS RELACIONADOS
Nesta seção será descrito trabalhos relacionados que utilizaram Redes Definidas por
Software em Redes Ópticas.
3.1 EXTENDING SOFTWARE DEFINED NETWORK PRINCIPLES TO INCLUDE OPTI-
CAL TRANSPORT
Em (GRINGERI et al., 2013), é apresentado uma revisão sobre os benefícios e
desafios de estender os conceitos das redes SDN para que esses possam ser utilizados em redes
ópticas. É explicado que a construção de um plano de controle para redes OTN é mais complexo
do que para redes Ethernet, visto que é necessário levar em conta restrições físicas, como
alcance do sinal óptico, controle da largura de banda e roteamento de caminhos de luz. Além
da complexidade do plano de controle, é apresentada uma revisão dos requerimentos de uma
aplicação e características dos serviços que poderiam se aproveitar do plano de controle SDN.
Tradicionalmente, transceptores tinham um desempenho fixo, baseado nos compo-
nentes ópticos selecionados, porém, novos transceptores de processamento digital de sinal foram
construídos e com eles é possível planejar hardwares flexíveis com parâmetros sintonizáveis
(Figura 8).
Esses parâmetros poderiam ser configurados por um controlador SDN, para determi-
nar o desempenho da rede de acordo com as necessidades das aplicações, maximizando assim a
utilização dos recursos da rede. As redes poderiam ser configuradas baseando-se na demanda de
tráfego.
A virtualização da rede em fatias é mencionada como uma das aplicações que poderia
tirar proveito dos conceitos SDN. Caminhos de luz poderiam ser configurados com base em
restrições de largura de banda e atraso, além de poderem ser dedicadas a um único cliente na
forma de uma rede virtual privada (VPN).
Ao utilizar uma camada óptica flexível, com a utilização de ROADMs e transceptores
sintonizáveis, as redes SDN podem evoluir de seu estado inicial de aplicações de pacote para
suportar aplicações de comutação e transporte, porém, ainda é necessária uma extensão dos
conceitos iniciais de SDN para sua utilização em redes OTN.
32
Figura 8 – Transceptor sintonizável e os possíveis parâmetros de configuração
Fonte: (GRINGERI et al., 2013)
3.2 INTEGRATED OPENFLOW–GMPLS CONTROL PLANE: AN OVERLAY MODEL
FOR SOFTWARE DEFINED PACKET OVER OPTICAL NETWORKS
Em (AZODOLMOLKY et al., 2011), é apresentado uma proposta de integração dos
planos de controle OpenFlow e GMPLS em um modelo de sobreposição de camadas, onde é
utilizado uma extensão do controlador OpenFlow (Figura 9).
O plano de controle GMPLS é dividido nos seguintes blocos:
• Controlador de Conexões da Rede (NCC): responsável por manusear e processar
as requisições de conexão
• Controlador de Sinalização (SC): implementa o protocolo RSVP-TE e é respon-
sável por fazer a sinalização GMPLS
• Controlador de Roteamento (RC): composto pelo protocolo OSPF-TE utilizado
33
para cálculo de rota e descoberta de topologia
• Gerenciador de Recursos do Enlace (LRM): responsável por monitorar e coletar
informações sobre o estado atual dos elementos de rede
• Controlador de Recursos da Rede de Transporte (TNRC): provê uma interface
entre o GMPLS e os elementos de rede para seu monitoramento e configuração
O controlador OpenFlow estendido é composto pelos seguintes blocos:
• Processador de Fluxo (FP): responsável pelo processamento de novos fluxos,
criação das regras e atualização das tabelas nos comutadores
• Elemento de Computação de Caminho (PCE): responsável pelo cálculo da rota
para cada fluxo no domínio de comutação de pacotes
• Agente de Descoberta (DA): tem como função descobrir a topologia e conectivi-
dade da rede incluindo os pontos finais em cada domínio de pacote
• OpenFlow Gateway (OFGW): fornece a interface entre o controlador OpenFlow
e o plano de controle GMPLS através de uma interface do usuário da rede (UNI)
• Controlador do Protocolo OpenFlow (OFPC): responsável por criar uma interface
entre o controlador e os comutadores OpenFlow para configuração das tabelas
de fluxo e monitoramento dos equipamentos
Figura 9 – Plano de Controle integrado OpenFlow-GMPLS
Fonte: (AZODOLMOLKY et al., 2011)
As tabelas de fluxos dos comutadores inicialmente estão vazias. O primeiro pacote
34
recebido será encapsulado e enviado ao controlador OpenFlow estendido. Baseado no destino
do pacote, o controlador OpenFlow identifica os pontos de ingresso e egresso da rede óptica e
requisita um caminho para o plano de controle GMPLS, utilizando a interface UNI citada acima.
O plano de controle GMPLS estabelece um LSP para aquele fluxo e informa ao controlador
OpenFlow, que atualiza as tabelas de fluxo nos nós de ingresso e egresso da rede de óptica
(Figura 10). O controlador OpenFlow mantém uma lista com os LSPs estabelecidos (Figura 11).
Figura 10 – Tabela de Fluxo dos nós de ingresso e egresso da rede óptica após o
estabelecimento do LSP
Fonte: (AZODOLMOLKY et al., 2011)
Figura 11 – Diagrama de sequência representando o funcionamento do plano de controle
integrado
Fonte: (AZODOLMOLKY et al., 2011)
Semelhante a esse trabalho, a presente dissertação utilizou-se de blocos, ou módulos,
para construir o plano de controle utilizando um controlador externo. Porém, em (AZODOL-
MOLKY et al., 2011), temos a dependência do GMPLS para cálculo e roteamento de caminhos
35
na rede óptica.
3.3 SOFTWARE-DEFINED OPTICAL NETWORKS TECHNOLOGY AND INFRASTRUC-
TURE: ENABLING SOFTWARE-DEFINED OPTICAL NETWORK OPERATIONS
(CHANNEGOWDA et al., 2013) aborda um plano de controle SDN-GMPLS in-
tegrado e um plano de controle somente com SDN. Ambos facilitaram aplicações para fatias
específicas da rede na camada óptica, provendo ainda uma plataforma unificada para o plano
de controle, possibilitando a integração de redes eletrônicas de pacotes e redes ópticas. No
contexto de computação nas nuvens SDN pode facilitar o desenvolvimento de engenharia de
tráfego programável e esquemas de balanceamento de carga em centros de dados, levando em
conta as diferentes necessidades das aplicações por largura de banda e latência.
Os desafios encontrados para a utilização de um plano de controle e gerência baseado
em SDN para redes ópticas são:
• Definição de uma granularidade para comutação e transporte ópticos (optical
flow)
• Generalização de tal granularidade para que possa ser usado por diferentes
tecnologias (fixed DWDM, flexi DWDM)
• Manter a compatibilidade com a tecnologia de comutação eletrônica de pacotes
• Planejar e implementar um mecanismo de abstração que possa esconder a hetero-
geneidade das tecnologias de redes ópticas
Com base nesses desafios, o trabalho aborda uma extensão do protocolo OpenFlow
e a definição de uma camada de abstração das rede subjacentes, permitindo a generalização
dos fluxos para tecnologias de transporte óptico heterogêneas e integração com domínios de
comutação de pacotes.
A arquitetura proposta (Figura 12) possibilita ao controlador conhecer cada domínio
utilizando tabelas de fluxos inter domínio, contendo um identificador e ações associadas para cada
NE, e intra domínio, para lidar com restrições tecnológicas para alocação de banda quando um
tráfego atravessa de um domínio para outro. As restrições dos domínios e os detalhes da topologia
são armazenados em um banco de dados, tais informações serão utilizadas pelasaplicações SDN
por uma API Northbound. Cada elemento de rede deverá implementar um agente, que visa
esconder os detalhes tecnológicos de recursos das redes de transporte heterogêneas subjacentes,
permitindo uma interface programável para a configuração do estado de hardware.
36
Figura 12 – Arquitetura SDN para uma rede heterogêna
Fonte: (CHANNEGOWDA et al., 2013)
O agente é dividido em três camadas (Figura 13):
• Camada de Apresentação do Hardware (HPL): Fornece todas as capacidades
disponíveis dos dispositivos, esconde as complexidades de hardware e exporta
os recursos e capacidades do dispositivo com base em um modelo unificado de
informação para o HIL
• Camada de Interface com Hardware (HIL): Expõem somente as características e
informações que possam ser utilizadas por uma rede baseada em fluxos, utiliza
as interfaces fornecidas pelo HPL para construir abstrações úteis que escondam
a complexidade associada aos recursos de hardware
• API OpenFlow: Mapeia informações fornecidas pelo HIL para o protocolo
OpenFlow e suas extensões
A versão atual do protocolo OpenFlow se concentra apenas no domínio de pacotes,
assim não suporta restrições de comutação e imparidades ópticas. A proposta de extensão
do OpenFlow propõe adicionar campos de identificação de fluxo pela porta, comprimento de
onda ou frequência central e tipo de sinal associado com um transporte óptico e tecnologia de
comutação específicos, atendendo assim as necessidades do domínio de pacotes, fixed-grid e
37
Figura 13 – Arquitetura do agente responsável pela abstração dos elementos da rede
Fonte: (CHANNEGOWDA et al., 2013)
flexi-grid (Figura 14).
Figura 14 – Tabela de fluxos do comutador OpenFlow estendido
Fonte: (CHANNEGOWDA et al., 2013)
Essa arquitetura foi utilizada desta forma e com a inclusão do plano de controle
GMPLS. As duas abordagens foram avaliadas em termos de tempo de configuração de caminho
utilizando uma aplicação SDN para fatias da rede. Os tempos de configuração de cada rede
foram categorizados baseados no hardware, na equalização de potência e no tempo de derivação
38
do caminho. A abordagem OF foi melhor, devido a sua habilidade de realizar cross-conexões e
equalização de potência concorrentemente nos NEs envolvidos.
A arquitetura proposta em (CHANNEGOWDA et al., 2013) é extremamente depen-
dente de um agente acoplado aos elementos de rede para que seja possível obter suas informações,
além disso, essa arquitetura é extremamente vinculada ao protocolo OpenFlow. A proposta
desta dissertação é muito mais genérica e não vincula a arquitetura a nenhum protocolo de
comunicação.
3.4 AN OPTICAL SDN CONTROLLER FOR TRANSPORT NETWORK VIRTUALIZA-
TION AND AUTONOMIC OPERATION
(SIQUEIRA et al., 2013) apresenta a arquitetura de um controlador SDN para redes
ópticas, que tem como aplicação a virtualização e fatiamento da rede. Na arquitetura proposta
(Figura 15), o Controlador SDN implementa uma camada de abstração que age como um sistema
operacional da rede que permite às aplicações tenham acesso a topologia e outras informações
necessárias para configurar e interagir com os elementos de rede. A camada abstrata implementa
o conceito de fatiamento de redes, permitindo a criação de redes ópticas virtuais (VON). Uma
virtualização da implementação do GMPLS foi adicionada ao controlador, pois algumas das
funcionalidades fornecidas pelo GMPLS como, descobrimento da rede e estabelecimento de
caminhos de luz, ainda não são suportadas pelo SDN. Para evitar configuração manual, foi
utilizado o protocolo de descoberta da camada de enlace (LLDP), que foi estendido para funcionar
no OSC, efetuando a descoberta da rede.
A arquitetura é dividida principalmente em:
• Elementos de Rede Óptico (O-NEs): possuem um agente para abstração e
controle via NETCONF e são modelados em YANG para prover uma camada de
abstração dos nós para o O-NOS
• Sistema Operacional de Redes Óptico (O-NOS): elabora um ponto de vista
simplificado concatenando os modelos YANG dos O-NEs em uma única árvore,
resultando em um modelo integrado da rede, ele é projetado para prover o
fatiamento dos recursos da rede óptica, via separação por comprimento de onda
ou por nó
• Controlador SDN para Redes Ópticas (O-SDNC): mira permitir controle autonô-
mico da rede óptica, o fatiamento da rede e fornecer interfaces GMPLS enquanto
39
Figura 15 – Arquitetura de um controlador SDN para Redes Opticas
Fonte: (SIQUEIRA et al., 2013)
simplifica os O-NEs
• Virtualização do Plano de Controle Estendido (XCP-V): virtualização do plano
de controle GMPLS
As instâncias do XCP-V foram virtualizadas utilizando containers Linux, permitindo
a utilização de vários nós na mesma máquina física, permitindo assim a instanciação de vários
agentes XCP-V, um por nó da rede por fatia, possibilitando a configuração de diferentes VPNs,
cada uma com um plano GMPLS independente.
(SIQUEIRA et al., 2013) teve grande influência na proposta de utilização de um
controlador SDN para fatiamento de redes ópticas. Vários aspectos da arquitetura proposta
nesse trabalho foram levados em consideração na criação da arquitetura proposta na dissertação.
Gerenciamento de inventário, topologia e fatias, além de um mecanismo responsável pelo cálculo
40
das rotas. Porém, tudo isso é fortemente dependente dos protocolos utilizados pelo GMPLS,
como o RSVP-TE e o OSPF-TE, o que não acontece na proposta de arquitetura dessa dissertação.
41
4 METODOLOGIA
Este capítulo descreve a arquitetura e os componentes necessários para criação de
um módulo capaz de fatiar redes ópticas de transporte.
4.1 ARQUITETURA
A arquitetura proposta (Figura 16) para possibilitar a virtualização e fatiamento da
rede, segue a metodologia das redes definidas por software, sendo composta por 3 (três) camadas.
A primeira camada contém os elementos de rede ópticos. A segunda camada é composta por um
ou mais controladores, responsáveis pela inteligência da rede. A terceira, e última camada é a de
Aplicação, responsável pelas interações do usuário com a rede. Essas camadas se comunicam
através de protocolos de comunicação.
Figura 16 – Arquitetura proposta para possibilitar o fatiamento de uma rede óptica
Fonte: Elaborado pelo autor
Essa arquitetura propõe um módulo chamado Optical Network Slicer (ONS) (Fi-
gura 17), responsável pelo fatiamento da rede óptica. Esse módulo é composto por 5 (cinco)
plugins essenciais, sendo eles: Slices Manager, Provisioner, Path Computation Element, To-
42
pology Manager e Inventory. A interface de entrada desses módulos pode ser feita utilizando
arquivos em formato Extensible Markup Language (XML), JavaScript Object Notation (JSON)
ou até mesmo através de objetos criados com a linguagem de implementação dos mesmos.
Além do módulo de fatiamento, é necessário um plugin para gerenciar as conexões
utilizadas na comunicação com os dispositivos da rede, esse plugin é chamado Sessions Manager.
Todos esses plugins devem utilizar uma base de dados para o armazenamento de informações.
Figura 17 – Módulo de fatiamento de redes ópticas
Fonte: Elaborado pelo autor
4.1.1 Inventory
Para que seja possível gerenciar uma rede, primeiramente é necessário obter as
informações dos dispositivos desta rede. O plugin Inventory é responsável por gerenciar e
armazenar informações dos dispositivos que compõem a rede óptica. Para isso ele deve ser
alimentado constantemente com informações sobre as capacidades de todos os dispositivos que
ingressarem na rede. Assim, é necessário modelar esses dispositivos em alguma linguagem de
armazenamento, definindo a granularidade necessária para seu gerenciamento.
A Figura 18 mostra um diagrama de classes com as informações mínimas e essenciais
para o fatiamento de dispositivos ópticos. Esse diagrama é composto por 3 (três) classes: Node,
Slot, Interface. Todas as classes possuem um identificador único, além dessas informações, a
classe Node possui uma lista de slots, representados pela classe Slot,que por sua vez possui
uma lista de interfaces. A classe Interface possui um campo para identificar qual camada
implementada por esta interface está sendo fatiada.
É possível incrementar esse modelo para aumentar o nível de granularidade dos
dispositivos ópticos, acrescentando por exemplo a taxa de transmissão da interface.
Um exemplo de entrada para alimentação da base de dados desse plugin, em formato
43
Figura 18 – Diagrama de classes mostrando a estrutura básica de um dispositivo óptico
Fonte: Elaborado pelo autor
XML, pode ser visto na Figura 19.
Figura 19 – Exemplo de uma entrada para informar as capacidades de um elemento óptico,
seguindo o modelo mostrado na Figura 18
Fonte: Elaborado pelo autor
4.1.2 Topology Manager
O plugin Topology Manager gerencia a topologia da rede, necessário para oferecer
a capacidade de roteamento. Essa topologia é obtida através de protocolos de descoberta de
vizinhança, como o LLDP, por exemplo. Esse plugin deve gerenciar tanto a topologia da rede
mestre, quanto as topologias das fatias criadas posteriormente, sendo responsável também por
validar se os dispositivos e conexões utilizados nas fatias, existem na topologia mestre.
44
Essa topologia pode ser representada de acordo com a Figura 20, na qual uma classe
Topology é identificada por um identificador único e possui uma lista de nós e uma lista de
conexões. Essas conexões são representadas pela classe Link, que possui um identificador, um
nó origem e um nó destino. Esses nós são representados pela classe Node, explicada na seção
anterior.
Figura 20 – Diagrama de classes mostrando a estrutura básica de armazenamento de uma
topologia de rede
Fonte: Elaborado pelo autor
Um exemplo de entrada para alimentação da base de dados desse plugin, em formato
XML, pode ser visto na Figura 21. Essa configuração resultaria em uma topologia com 3 (três)
nós, onde o nó com identificador 1 (um) está ligado ao nó com identificador 2 (dois), que por sua
vez possui uma conexão com o nó identificado como 3 (três), essas conexões são descritas no
atributo links e forma a rede exibida na Figura 22.
4.1.3 Path Computation Element
O Path Computation Element (PCE) tem como principal função calcular o caminho
entre um nó origem e um nó destino, se esse caminho existir. Esse cálculo pode ser feito
utilizando qualquer algoritmo de cálculo de rota, priorizando requisitos como: qualidade de
serviço (QoS), preço, política. Esse plugin só será ativado através de requisições de solicitação
de cálculo de rota feitas pelo plugin Provisioner. Para que o cálculo da rota seja executado,
é necessário que esse plugin receba como parâmetro o nó origem, nó destino, uma lista de
nós válidos, uma lista de conexões disponíveis e quaisquer outros parâmetros específicos do
algoritmo implementado.
45
Figura 21 – Exemplo de uma entrada para informar a topologia de uma rede óptica, seguindo o
modelo mostrado na Figura 20
Fonte: Elaborado pelo autor
Figura 22 – Topologia de rede construída a partir das especificações exibidas na Figura 21
Fonte: Elaborado pelo autor
4.1.4 Provisioner
Esse plugin é responsável pelo aprovisionamento de caminhos da rede, para isso ele
utiliza o caminho calculado pelo PCE, e com base nesse caminho, na modelagem dos elementos
ópticos e no protocolo utilizado para comunicação com esses elementos, cria as mensagens de
46
aprovisionamento que serão enviadas para configurar os dispositivos, modificando assim a rota
da transmissão.
É necessário informar ao PCE a topologia na qual este deve calcular a rota. Essa
topologia não pode conter conexões em uso, tornando necessário controlar a disponibilidade dos
recursos da rede, ou seja, armazenar tais conexões, para que os caminhos calculados pelo PCE e
aprovisionados aqui sejam válidos. As seguintes informações são necessárias para identificar
conexões em uso: identificador da conexão, dono da fatia, a qual área essa fatia pertence e o
identificador da topologia a qual a conexão pertence (Figura 23).
Figura 23 – Diagrama de classes representando as informações necessárias para armazenar
conexões em uso
Fonte: Elaborado pelo autor
4.1.5 Slices Manager
O gerenciamento das fatias da rede consiste basicamente nas operações de criação,
remoção e atualização das fatias. Essas operações devem ser realizadas pelo operador da
rede principal através deste plugin. Antes de realizar uma das operações, esse plugin deve se
comunicar com os plugins Inventory e Topology Manager, para que seja possível validar as
informações da fatia, por exemplo, verificar a existência e disponibilidade de nós e interfaces.
Além das operações citadas acima, este plugin também recebe requisições dos controladores dos
clientes, solicitando o aprovisionamento de um caminho.
As fatias devem ser modeladas levando em consideração o crescimento do conceito
de cidades inteligentes. Sendo assim, cada fatia da rede deve ser identificada por dois campos, o
primeiro campo informará quem é o dono dessa fatia e o segundo campo a qual área essa fatia
pertence: saúde, segurança, etc. O campo área pode ser utilizado para priorizar, por exemplo,
largura de banda para uma determinada área em determinado momento do dia. A representação
de uma fatia básica pode ser vista na Figura 24, onde uma fatia contém as informações de
47
identificação e uma lista de possíveis topologias.
Figura 24 – Diagrama de classes representando as informações de uma fatia da rede
Fonte: Elaborado pelo autor
4.2 CASOS DE USO
Os dois principais casos de uso do fatiamento de uma rede óptica são a criação
de uma fatia e a solicitação do aprovisionamento de um caminho em determinada fatia. Nas
subseções seguintes serão descritos tais casos de uso.
4.2.1 Criar Fatia
Este caso de uso especifica a ação de solicitar a criação de uma nova fatia no
controlador, com o objetivo de tornar possível o gerenciamento desta fatia através de um
controlador externo. Apenas o operador da rede principal terá acesso a esta função. Esse caso de
uso terá início, após o operador da rede enviar uma solicitação para criação de uma nova fatia ao
plugin Slices Manager.
O fluxo básico deste caso de uso tem início quando o operador decide criar uma nova
fatia da rede. Nesse momento ele deve solicitar a criação desta fatia ao plugin Slices Manager,
passando como argumento um arquivo XML, contendo as informações básicas para criação da
fatia, dentre as principais informações estão o dono da fatia, a qual área esta pertence, os nós,
slots, interfaces e conexões.
A Figura 25 exibe um arquivo XML, com as informações necessárias para criação
de uma fatia composta por 3 (três) nós, como mostrado na Figura 26. Esse arquivo utiliza como
base uma rede composta por 5 (cinco) elementos (Figura 27), com as seguintes conexões:
48
• Nó 1 (um) e Nó 3 (três): conectam-se aos nós 2 (dois), 4 (quatro) e 5 (cinco)
• Nó 2 (dois) e Nó 4 (quatro): conectam-se aos nós 1 (um), 3 (três) e 5 (cinco)
• Nó 5 (cinco): conecta-se a todos os nós
Figura 25 – Exemplo de uma entrada para solicitar a criação de uma nova fatia
Fonte: Elaborado pelo autor
49
Figura 26 – Exemplo de uma fatia criada a partir do XML mostrado na Figura 25, utilizando
como base a rede mostrada na Figura 27
Fonte: Elaborado pelo autor
Figura 27 – Rede utilizada como base no exemplo de solicitação de criação de uma fatia
Fonte: Elaborado pelo autor
Ao receber a requisição, o plugin Slices Manager irá validar os dados recebidos, para
isso, irá se comunicar com o plugin Inventory, para que este possa validar os dados relacionados
ao inventário dos dispositivos. Em seguida, solicitará ao plugin Topology Manager, que verifique
se existem conexões válidas entre os dispositivos informados na fatia. A última validação é feita
para verificar se os dispositivos informados na entrada estão disponíveis para um novo cliente,
ou seja, não foram alugados por nenhum cliente até o momento.
O processo termina quando as informações da fatia sãosalvas no banco de dados,
decretando assim a criação da fatia. Esse fluxo pode ser observado no diagrama de sequência
(Figura 28).
50
Figura 28 – Diagrama de sequência do fluxo básico da criação de uma fatia
Fonte: Elaborado pelo autor
4.2.2 Aprovisionar Caminho
Este caso de uso especifica a ação de solicitar ao controlador o aprovisionamento
de um caminho para determinada fatia, com o objetivo de possibilitar o aprovisionamento de
caminhos por fatia. Essa função é acessada a partir de uma aplicação cliente, visualizada como
um controlador cliente. Esse caso de uso terá início, após o controlador cliente enviar uma
solicitação para aprovisionamento de um caminho em uma determinada fatia ao plugin Slices
Manager.
O fluxo básico deste caso de uso tem início quando o controlador cliente decide
aprovisionar um caminho. Nesse momento ele deve solicitar o aprovisionamento do caminho
na fatia que ele é dono, passando como argumento um arquivo XML, contendo as informações
básicas para aprovisionamento de caminhos (Figura 29), dentre as principais informações, estão
o dono da fatia, a qual área esta pertence, os nós, slots, interfaces e conexões.
Ao receber a requisição, o plugin Slices Manager irá validar os dados recebidos,
passando pelo mesmo processo de validação descrito no caso de uso de criação de uma fatia. Após
a validação, o plugin Slices Manager irá requisitar ao plugin Provisioner o aprovisionamento de
um caminho. O Provisioner irá efetuar 3 (três) operações básicas para realizar o aprovisionamento.
Primeiro ele irá solicitar o plugin Path Computation Element uma rota válida entre os dispositivos
51
Figura 29 – Exemplo de uma entrada para solicitar o aprovisionamento de um caminho em uma
determinada fatia
Fonte: Elaborado pelo autor
de origem e o destino. Com a rota calculada, as mensagens de cross-conexão serão construídas e
enviadas aos dispositivos, através do plugin Sessions Manager.
O processo termina quando as mensagens de cross-conexão forem enviadas aos
elementos ópticos, decretando assim o aprovisionamento de um caminho. Esse fluxo pode ser
observado no diagrama de sequência (Figura 30).
52
Figura 30 – Diagrama de sequência do fluxo básico do aprovisionamento de um caminho
Fonte: Elaborado pelo autor
53
5 IMPLEMENTAÇÃO
Este capítulo descreve a implementação da arquitetura proposta, as modificações e
os componentes utilizados no desenvolvimento de uma prova de conceito.
5.1 ARQUITETURA IMPLEMENTADA
A arquitetura implementada (Figura 16) possui todas as funções da arquitetura
proposta na Seção 4.1, porém, para facilitar o desenvolvimento, alguns plugins concentram mais
de uma função. O desenvolvimento desta prova de conceito foi feito utilizando a linguagem Java
e a plataforma para programabilidade de redes ODL, facilitando a modularização da arquitetura.
Figura 31 – Arquitetura desenvolvida para fatiamento de uma rede óptica
Fonte: Elaborado pelo autor
Seguindo os princípios da arquitetura proposta, a arquitetura desenvolvida como
prova de conceito é composta por 3 (três) camadas. Devido a dificuldade de ter acesso a
elementos ópticos reais, a primeira camada foi adaptada para substituir tais elementos, sendo
composta por máquinas virtuais com modelos de informação que representam as características
54
de elementos ópticos. A terceira camada é formada por aplicações cliente, responsáveis pelas
interações do usuário com o controlador.
A segunda camada é composta pelo controlador ODL, e possui o módulo de fati-
amento de redes ópticas. O ODL foi utilizado por ser um controlador SDN de código aberto,
escrito em java, e com uma comunidade bastante ativa. Dentre seus principais plugins, é possível
destacar os seguintes:
• Topology Manager: responsável pelo controle da topologia da rede
• Inventory: responsável pelo controle das informações de inventário da rede
• VTN (Virtual Tenant Network) Manager e Coordinator: responsável pela virtua-
lização e fatiamente de redes Ethernet
• Flow Programming: responsável pela programação de fluxos em redes que
utilizam protocolo OpenFlow
Esses plugins possuem as mesmas responsabilidades de alguns plugins citados
na Seção 4.1, porém com capacidade de atender apenas as necessidades das redes Ethernet.
Assim, foi necessário criar plugins com as mesmas responsabilidades, porém, que atendessem as
necessidades de uma rede óptica. Esses plugins foram agrupados dentro do módulo ONS (ONS).
O módulo ONS (Figura 32) é composto por 3 (três) plugins, que representam os
5 (cinco) plugins da arquitetura geral proposta. Esses plugins são: Optical Slicer, Optical
Provisioning e Optical Network Topology. Todos eles recebem como parâmetro arquivos em
formato XML (XML) ou objetos Java. O plugin utilizado para gerenciar as conexões utilizadas na
comunicação com as máquinas virtuais é nativo ao ODL e é chamado Netconf Connector. Todos
esses plugins utilizam uma base de dados própria do ODL, essa base armazena informações
utilizando a linguagem YANG.
Figura 32 – Implementação do módulo de fatiamento de redes ópticas
Fonte: Elaborado pelo autor
O controlador se comunica com as máquinas virtuais utilizando o protocolo Network
55
Configuration Protocol (NETCONF). A comunicação do controlador com as aplicações é reali-
zada através do protocolo Representational State Transfer (REST).
5.1.1 Optical Network Topology
Esse plugin concentra as responsabilidades dos plugins Inventory e Topology Mana-
ger, explicados nas Seções 4.1.1 e 4.1.2 respectivamente. Esse agrupamento das responsabilida-
des deve-se ao fato do inventário possuir poucas informações, logo, seria desnecessário criar um
plugin específico para lidar apenas com informações de slot e interface.
5.1.2 Optical Slicer
Esse plugin representa fielmente o plugin descrito na Seção 4.1.5, porém, ao invés
de se comunicar com os plugins Inventory e Topology Manager, para validar as informações da
fatia, ele se comunica com o plugin Optical Network Topology. Este plugin é o ponto de acesso
para criação e configuração das fatias. A Figura 33 mostra um diagrama de classes resumido
deste plugin, ocultando as variáveis de instância, os parâmetros passados para os métodos e as
possíveis exceções lançadas durante a execução dos mesmos.
Figura 33 – Diagrama de classes representando a estrutura básica do plugin Optical Slicer e sua
conexão com o plugin Optical Provisioning
Fonte: Elaborado pelo autor
5.1.3 Optical Provisioning
Esse plugin concentra as responsabilidades dos plugins Path Computation Element e
Provisioner, explicados nas Seções 4.1.3 e 4.1.4 respectivamente.
O algoritmo de Dijkstra foi utilizado para o cálculo das rotas, assumindo assim as
responsabilidades do plugin Path Computation Element, com o intuito de acharmos o menor
caminho entre o nó origem e o nó destino. Não foram utilizados pesos pras conexões, pois
56
consideramos que todas as conexões possuem a mesma taxa de transmissão.
Após o cálculo do caminho pelo Dijkstra, esse plugin cria as mensagens que serão
enviadas às máquinas virtuais. Essas mensagens são criadas a partir do modelo de informação
base utilizado nas máquinas virtuais e seguem o padrão do protocolo NETCONF. A Figura 34
demonstra um exemplo de uma mensagem enviada para uma máquina virtual, onde o conteúdo
da mensagem representa uma reconfiguração dos slots de entrada e saída do sinal, que são
utilizados como uma abstração da matriz de cross-conexões da camada elétrica de um otn-switch,
com taxa de transmissão fixa de 10 Gbps.
Figura 34 – Exemplo de uma mensagem enviada para reconfigurar uma matriz de
cross-conexão modelada em uma máquina virtual
Fonte: Elaborado pelo autor
57
5.1.4 Máquinas Virtuais
Como explicado anteriormente, devido a dificuldade em ter acesso a elementos ópti-
cos reais, máquinas virtuais foram utilizadas para substituir esses elementos na implementação
de uma prova de conceito. As máquinas foram criadas utilizando o software OpenStack, capaz
de gerenciar