abordagem dirigida a modelos para o gerenciamento de redes

 Journals Homepage: www.sustenere.co/journals
ABORDAGEM DIRIGIDA A MODELOS PARA O
GERENCIAMENTO DE REDES DEFINIDAS POR
SOFTWARE
RESUMO
As Redes Definidas por Software (SDN) vêm obtendo grande atenção por parte da
comunidade acadêmica e também da indústria, devido a diversos aspectos. Apesar
disso, o gerenciamento e o desenvolvimento de aplicações voltadas para este novo
campo em redes de computadores ainda são complexos, carentes de metodologias
e ferramentas que permitam utilizar todo o nível de abstração possibilitado pelas
SDNs. Com foco neste problema, o presente trabalho propõe uma Domain-Specific
Modelling Language (DSML), aplicada à abordagem de SDN, aumentando o nível de
abstração para o gerenciamento destas redes.
Revista Brasileira de Administração Científica, Aquidabã, v.5, n.2, Out 2014. ISSN 2179‐684X SECTION: Articles TOPIC: Sistemas e Tecnologia da Informação Anais do Simpósio Brasileiro de Tecnologia da Informação (SBTI 2014) PALAVRAS-CHAVES: Redes Definidas por Software; DSML; Sistemas.
DOI: 10.6008/SPC2179‐684X.2014.002.0014 MODEL-DRIVEN APPROACH TO SOFTWARE-DEFINED
NETWORKING MANAGEMENT
ABSTRACT
Software-Defined Networking (SDN) has been getting great interest from the
academic community and industry, due to several aspects. Nevertheless, the
application development oriented for this new SDN field is still complex, lacking
methodologies and tools that enable use all the level of abstraction afforded by these
networks. Focusing on this problem, the current paper proposes a Domain-Specific
Modeling Language (DSML) applied to SDN, which raises the level of abstraction in
SDN management.
KEYWORDS: Software-Defined Networking, Domain-Specific Modeling Language;
Systems.
Felipe Alencar Lopes Universidade Federal de Pernambuco, Brasil http://lattes.cnpq.br/6490167896355223 [email protected] Stênio Flávio de Lacerda Fernandes Universidade Federal de Pernambuco, Brasil http://lattes.cnpq.br/8598484164048317 [email protected] Received: 31/08/2014 Approved: 15/10/2014 Reviewed anonymously in the process of blind peer. Referencing this: LOPES, F. A.; FERNANDES, S. F. L.. Abordagem dirigida a modelos para o gerenciamento de redes definidas por software. Revista Brasileira de Administração Científica, Aquidabã, v.5, n.2, p.186‐201, 2014. DOI: http://dx.doi.org/10.6008/SPC2179‐
684X.2014.002.0014 Revista Brasileira de Administração Científica (ISSN 2179‐684X) © 2014 Sustenere Publishing Corporation. All rights reserved. Rua Dr. José Rollemberg Leite, 120, CEP 49050‐050, Aquidabã, Sergipe, Brasil WEB: www.sustenere.co/journals – Contact: [email protected] Abordagem dirigida a modelos para o gerenciamento de redes definidas por software INTRODUÇÃO
A arquitetura da Internet tem se tornado complexa e difícil de gerenciar. A necessidade de
tornar a Internet e outras redes de computadores complexas mais dinâmicas, permitindo novas
técnicas de gerenciamento, fez surgir um novo paradigma chamado Rede Definida por Software,
do inglês Software-Defined Networks (SDN). As SDNs permitem separar a parte lógica da rede
(control-plane) em um plano desacoplado dos dispositivos de encaminhamento (forwarding-plane).
As políticas de uma SDN são definidas através de um controlador externo que compõe o controlplane (FEAMSTER et al., 2013). Neste cenário, o protocolo denominado OpenFlow tem o papel de
determinar o comportamento da rede, além de permitir e definir a comunicação entre os dispositivos
de encaminhamento e os controladores (MCKEOWN et al., 2008).
Atualmente, diversas abordagens existem para tornar possível a gerência da rede através
de políticas fazendo uso subjacente do protocolo OpenFlow (FOSTER et al., 2013; VOELLMY &
HUDAK, 2011). Apesar de permitir várias formas de gerenciamento, o uso de diferentes tecnologias
para definir o comportamento de uma SDN pode torná-la complexa e difícil de manter,
(SHERWOOD et al., 2009). O contexto atual mostra a importância em se ter uma plataforma única
que permita o gerenciamento destas redes, atendendo as diversas estruturas subjacentes.
O principal conceito que torna a proposta deste trabalho única é o paradigma Model-Driven
Development (MDD), que tem sido utilizada em diversos tipos de redes, aplicando-se à criação de
aplicações e modelagem de componentes destas redes, resultando na redução da complexidade
no gerenciamento, e permitindo que especialistas do domínio lidem apenas com problemas relativos
ao desenho e comportamento destas redes (RODRIGUES et al., 2011). Além disso, a associação
entre SDN e MDD ainda não foi investigada por trabalhos anteriores.
Este trabalho propõe os fundamentos inicias para a utilização do paradigma MDD na
gerência de SDNs, visando a interoperabilidade entre controladores, e a redução da complexidade
envolvida no gerenciamento. Especificamente, a proposta deste trabalho apresenta a associação
entre o paradigma MDD, através de uma Domain-Specific Modelling Language (DSML), e os
conceitos relativos ao gerenciamento de SDNs. Esta associação contribui para o aumento no nível
de abstração, formalizando as etapas do gerenciamento das SDNs, e reduzindo a possibilidade de
ações errôneas por parte de especialistas do domínio e operadores de rede.
O restante deste artigo está organizado da seguinte forma: primeiro é exibida a
fundamentação teórica para os conceitos utilizados na proposta, posteriormente apresentamos uma
solução baseada em MDD para o problema de gerenciamento em SDN apresentado nesta
introdução. Os trabalhos relacionados, a discussão dos resultados e a conclusão completam em
ordem a estrutura do trabalho.
REVISÃO TEÓRICA
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 187 LOPES, F. A.; FERNANDES, S. F. L. O interesse pela utilização de SDN vem crescendo cada vez mais nos últimos anos. Estudos
em destaque abordam a abstração do baixo nível de implementação e especificação existente na
interação entre operadores de rede e o protocolo OpenFlow, utilizado subjacentemente nas SDNs
(FERGUSON et al., 2013; FOSTER et al., 2013; VOELLMY et al., 2011). Basicamente, nestes
estudos, camadas de abstração têm sido adicionadas para facilitar a criação de políticas e
aplicações em uma SDN, além de resultar em tentativas de redução dos possíveis erros existentes
na manipulação destas políticas e aplicações. Estas camadas se relacionam com o controlador da
SDN, os pacotes e os dispositivos de encaminhamento.
Considerando esta tendência em criar abstrações que diminuam o nível de complexidade
existente na interação com as SDNs, motiva-se a investigação dos conceitos de MDD aplicados ao
gerenciamento de SDNs, especificamente. A utilização do paradigma MDD já foi investigada em
outros tipos de redes de computadores, tais como: Wireless Sensor Networks (WSN) (RODRIGUES
et al., 2011), Software-Defined Radio (SDR) (CLAYPOOL et al., 2009), e redes Ethernet (IMTIAZ et
al., 2008). Este capítulo mostra o contexto das SDNs, os principais conceitos, e os principais
problemas que existem quando se observa o gerenciamento destas redes. Além disso, a
fundamentação de MDD, através de uma associação com SDN, reforça a proposta para o
gerenciamento de SDNs abordada por este artigo.
Software-Defined Networking (SDN)
A separação entre o plano de controle e o plano de encaminhamento é o pilar do paradigma
e arquitetura SDN. Esta separação permite que a rede se desenvolva, reduzindo a complexidade
para implantar novos protocolos ou atualizar qualquer aplicação de rede, incluindo protocolos
experimentais (FEAMSTER et al., 2013). SDN surge da necessidade atual em que operadores e
aplicações de rede precisam implementar novas estratégias na rede, de forma robusta e dinâmica
em cenários realísticos, suportando o crescimento da complexidade existente nas aplicações e
serviços da Internet.
Arquitetura de rede tradicional
Arquitetura de SDN
Figura 1: Comparativo entre arquiteturas de rede.
Por meio de uma nova arquitetura, SDN torna possível que redes de computadores sejam
programáveis. Quando o controle lógico é separado dos dispositivos de encaminhamento, toda a
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 188 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software inteligência da rede (e.g. políticas, balanceamento de carga) é também movida para o controlador.
O controlador SDN se torna o componente de rede responsável por gerenciar a rede, como mostra
a Figura 1. Tal estratégia de gerenciamento é realizada através de uma tabela de fluxo (flow table)
presente nos switches, que é utilizada conforme ela recebe políticas ou regras de rede, definidas
pelo controlador. Em outras palavras, as entradas da tabela de fluxo adicionadas pelo controlador
nos switches os instrui em como manipular pacotes ou fluxos. O controlador possui toda informação
sobre a rede (e.g. onde os hosts estão conectados, a topologia da rede, a fonte e o destino de cada
pacote), e envolve uma séria de detalhes para lidar com resolução de conflitos que envolvem
políticas em geral. Além disso, é papel do controlador evitar comportamentos errôneos na rede.
Vale ressaltar que diversos controladores têm sido propostos (GUDE et al., 2008; ERICKSON, 2013;
PROJECT FLOODLIGHT, 2014), neste trabalho, devido à sua característica open source,
utilizaremos o POX (NOX Repo, 2014) como controlador subjacente para geração de código.
Figura 2: Arquitetura SDN e suas camadas.
Visando fornecer uma visualização melhor do que é o plano de controle de uma SDN, é
comum nomear e diferenciar duas interfaces: (1) o northbound é uma interface relacionada com
elementos de alto nível, tais como aplicações e serviços de rede, que oferecem suporte para
realização do gerenciamento das SDNs, instruindo controladores através de APIs e políticas de
rede bem-definidas, e (2) o southbound que permite em sua interface a comunicação entre os
controladores e os dispositivos de encaminhamento. A Figura 2 ilustra estas interfaces.
No plano de controle, é possível obter uma perspectiva que engloba o relacionamento entre
as interfaces northbound e southbound, identificando as características intrínsecas deste
relacionamento. A interface northbound tem a responsabilidade de abstrair funções subjacentes da
rede, de uma maneira que operadores de rede possam implementar políticas e gerenciar a rede
para atingir seus objetivos, eliminando a necessidade de lidar com outros aspectos da rede que não
estejam relacionados com suas ações. Por outro lado, a interface southbound convergiu para
utilização do protocolo OpenFlow (McKeown et al., 2008), o qual tem sido limitado a questões de
eficiência do plano de dados e integração ao plano de controle. A southbound habilita switches SDN
a se comunicarem com os controladores SDN, de modo que os switches possam lidar com pacotes
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 189 LOPES, F. A.; FERNANDES, S. F. L. de entrada, identificar a topologia da rede, e aplicar regras no comportamento da rede, que são
definidas através de aplicações, APIs, ou serviços no northbound.
Resumidamente, pode-se observar que o gerenciamento de uma SDN ocorre através da
interface northbound de um controlador SDN. Este controlador irá realizar as interações com os
fluxos e dispositivos de encaminhamento na rede de forma que as políticas ou regras estabelecidas
por um operador, serviço ou aplicação de rede através da interface northbound sejam aplicadas
corretamente nos elementos ligados ao southbound do controlador.
Gerenciamento SDN
Operadores de rede são responsáveis por configurar e gerenciar a rede para seguir várias
políticas de alto nível, e para responder a uma grande variedade de eventos de rede (e.g. aumento
de tráfego, falhas) que podem ocorrer. O gerenciamento da rede continua incrivelmente difícil devido
à complexidade em implementar estas políticas de alto nível por meio de interfaces de configuração
de baixo nível. Atualmente as redes fornecem pouco ou nenhum mecanismo para diminuir esta
complexidade (KIM & FEAMSTER, 2013).
Apesar de não existir um conjunto completo de definições para o gerenciamento de
SDN, neste trabalho utilizaremos o conjunto de domínio para controle de rede definido por Kim e
Feamster (2013) para SDNs. Este conjunto, exibido no Quadro 1, envolve uma variedade de
políticas que se encaixam em três tipos diferentes de estruturas de rede, que são complexos para
implementar em linguagens de configuração convencionais.
Quadro 1: Possíveis domínios para gerenciar num ambiente de rede.
Domínio para Controle
Tempo
Uso de dados
Status
Fluxo
Exemplos
Horários de pico, período de férias
Quantidade de dados utilizada, taxa de tráfego
Autenticação, identidade de dispositivo ou usuário
Porta de entrada, ou saída, destino
Informações do quadro: (1) Tempo - operadores de rede geralmente precisam implementar
políticas onde o comportamento da rede depende da data ou horário no dia; (2) Uso de dados algumas vezes, operadores especificam políticas onde o comportamento da rede depende da
quantidade de dados utilizada por seus usuários; (3) Status - um operador deve especificar
privilégios para diferentes grupos de usuários de acordo com seus status. O mesmo ocorre para
dispositivos específicos na rede; (4) Fluxo - o comportamento da rede também deve ser gerenciado
a partir de informações de fluxo, especificados em um pacote ou um conjunto de pacotes.
Além dos conceitos relacionados ao domínio de controle, para realizar o gerenciamento de
SDNs, as políticas são implantadas por meio de códigos executáveis (semelhante à programação
de sistemas em geral). Estes códigos têm sido criados a partir do uso de Domain-Specific
Languages (DSL), que abstraem parte da complexidade envolvida na interação direta com as
funcionalidades do protocolo OpenFlow e outras linguagens de baixo-nível utilizadas na
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 190 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software implementação destas funcionalidades. O esquema exibido na Figura 3 traduz essa organização
no gerenciamento de SDNs e o papel destas DSLs.
Figura 3: Esquema para gerenciamento de SDNs.
Model-Driven Development (MDD)
Aumentar o nível de abstração no gerenciamento de sistemas sempre foi um objetivo das
tecnologias em computação. O paradigma MDD foca na automação de várias tarefas complexas,
tais como: suporte para persistência de sistemas, interoperabilidade, e distribuição, tendo como
objetivo subjacente a melhora na produtividade, isto é, reduzir a complexidade do desenvolvimento
de aplicações ou gerenciamento de ambientes computacionais (ATKINSON & KUHNE, 2003).
Apesar de existirem definições diferentes para MDD, neste artigo, fundamentaremos MDD em dois
principais aspectos: o conceito MDD e sua infraestrutura.
Conceitualmente, MDD é uma visão arquitetural do paradigma Model-Driven Engineering
(MDE) para desenvolvimento de aplicações a partir de modelos (STAHL et al., 2006). Ou seja,
produção de código automatizada a partir de modelos visuais. Entretanto, este é apenas um dos
três principais componentes do paradigma MDD: (1) a própria produção de código a partir de
modelos, (2) a linguagem de modelagem (DSML), e (3) o metamodelo desta linguagem (ATKINSON
& KUHNE, 2003).
Então, para a construção de uma infraestrutura MDD e concretização destes três
componentes, os seguintes requisitos devem ser atendidos: (1) Definição dos conceitos disponíveis
para criação de modelos e as regras que os regem; (2) A notação utilizada para representação os
modelos; (3) Definição de como elementos dos modelos representam elementos do mundo real,
incluindo artefatos de software; (4) Elaboração de conceitos para facilitar extensões dinâmicas do
usuário para conceitos do modelo, notação do modelo, e os modelos criados a partir deles; (5)
Conceitos para facilitar o intercâmbio de conceitos de modelos e notação, e os modelos criados a
partir deles; (6) Conceitos para facilitar mapeamentos definidos pelo usuário, de modelos aos
artefatos, incluindo código.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 191 LOPES, F. A.; FERNANDES, S. F. L. Figura 4: Arquitetura de uma infraestrutura MDD.
Esta infraestrutura possui uma arquitetura de quatro camadas que sustentam as primeiras
tecnologias MDD – nomeadas Unified Modeling Language (UML) e a Meta-Object Facility (MOF).
Consistindo em uma hierarquia de níveis de modelos, cada um (exceto o superior) sendo
considerado uma instância do nível acima, esta arquitetura, ilustrada na Figura 4, possui a vantagem
de acomodar novos padrões de modelagem (e.g. Common Warehouse Metamodel), assim como
instâncias de MOF na camada M2 inferior.
Em uma descrição que parte do nível mais baixo para o mais alto da arquitetura MDD, temos
que o nível mais baixo, M0, lida com dados do domínio (ou usuário) – os dados de objetos que o
software manipula. O próximo nível, M1, é tido como o manipulador do modelo dos dados de M0.
Os modelos criados para o domínio se encontram neste nível. O nível M2 abriga um modelo de
informação em M1. Devido a ele ser um modelo de outro modelo, ele é geralmente referenciado
como metamodelo. Finalmente, o nível M3 abriga o modelo de informação presente em M2, sendo
assim, chamado de meta-metamodelo (ATKINSON & KUHNE, 2003).
A DSML (Domain-Specific Modeling Language), é um componente importante do paradigma
MDD, ela pode ser construída utilizando padrões do Object Management Group (OMG) e sua visão
de MDD, a Model-Driven Architecture (MDA), por razões de interoperabilidade. Porém, com a
utilização de DSML para realizar MDD, não há a restrição de adotar as sintaxes abstrata e concreta
da UML, especificada nos requisitos da MDA (NIKIFOROVA et al., 2009). Essa liberdade,
possibilitada por uma DSML, é útil quando os elementos gráficos ou as regras de construção da
UML não são adequadas para um domínio particular, como no caso das SDNs.
Modelagem e Composição de DSMLs
Na seção anterior, definiu-se inicialmente que uma DSML é uma forma de realizar a
aplicação do paradigma MDD. Formalmente, uma DSML é uma 5-tupla composta por sintaxe
concreta (C), sintaxe abstrata (A), semântica do domínio (S), semântica dos mapeamentos (MS), e
sintática dos mapeamentos (MC) (CLARK et al., 2001):
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 192 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software L = < C, A, S, MS, MC >
1. A sintaxe concreta (C) define a notação específica utilizada para
expressar modelos, os quais devem ser gráficos, textuais ou
ambos;
2. A sintaxe abstrata (A) define os conceitos, relacionamentos,
restrições de integridade disponíveis na linguagem;
3. A semântica do domínio (S) é geralmente definida pelo significado
de algum formalismo matemático, em termos que descrevem o
significado dos modelos;
4. O mapeamento semântico (MS) refere-se aos conceitos sintáticos
do domínio semântico;
5. O mapeamento sintático (MC) atribui construções sintáticas
(gráfica, textual ou ambas) para os elementos da sintaxe abstrata.
Qualquer DSML que for utilizada na modelagem de soluções requer uma especificação
precisa (ou modelagem) de todos os cinco componentes que definem a linguagem. Esta
especificação de componentes permite que DSMLs atendam aos seis requisitos definidos para o
paradigma MDD. As linguagens utilizadas para definição de componentes das DSMLs são
chamadas de metalinguagens, e as especificações formais das DSMLs são chamadas
metamodelos (EMERSON et al., 2004).
A especificação da sintaxe abstrata de uma DSML requer uma metalinguagem que possa
expressar conceitos, relacionamentos, e restrições de integridade. Neste trabalho, foi adotada uma
combinação da especificação de MOF (Meta-Object Facility) com a Object Constraint Language
(OCL) para servir de metalinguagem na DSML proposta. Esta seleção é consistente com a
arquitetura de quatro camadas que compõe uma infraestrutura MDD (OMG, 2003).
O modelo concreto da sintaxe em uma DSML fornece uma notação visual para os elementos
da sintaxe abstrata, sendo necessário descrever o mapeamento sintático entre o modelo concreto
da sintaxe e os elementos abstratos. O mapeamento semântico ocorre a partir da relação correta
entre o modelo criado e o resultado da transformação em código e sua execução esperada pelo
especialista de domínio, baseado na semântica do domínio (EMERSON et al., 2004).
Geração de Código a partir de DSMLs
De acordo com o paradigma MDD, um dos requisitos necessários para segui-lo é o
mapeamento entre modelos e artefatos, incluindo código. Neste contexto, diversas ferramentas
existem para auxiliar na transformação de modelos em códigos executáveis, neste trabalho
analisamos três: Graphical Modeling Framework (GMF) (STEINBERG et al., 2009), MetaEdit+
(TOLVANEN & ROSSI, 2003), e AToM³ (DE LARA & VANGHELUWE, 2004).
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 193 LOPES, F. A.; FERNANDES, S. F. L. Nesta seção, devido ao espaço textual, não serão detalhadas as duas útlimas ferramentas
(MetaEdit+ e AToM³). Detalharemos apenas o GMF, que é o framework utilizado na abordagem
deste trabalho. O motivo para isso é decorrente de três fatores: (1) a licença (Licença Pública
Eclipse), (2) a ampla aceitação no suporte para MDD, e (3) por ser a única ferramenta dentre as
três analisadas que suporta restrições baseadas em OCL. O GMF é baseado em dois outros
frameworks, o Eclipse Modeling Framework (EMF) e o Graphical Editing Framework (GEF)
(BAETENS, 2011). Antes de definir como esta combinação de frameworks ocorre, é preciso expor
o que é cada um deles:
a. Eclipse Modeling Framework (EMF)
O projeto EMF é um framework de modelagem e um facilitador em geração de código para
construção de ferramentas e outras aplicações baseadas em um modelo de dados estruturado. A
partir de uma especificação de modelo descrita em XMI, o EMF fornece ferramentas e suporte em
execução para produzir um conjunto de classes Java para o modelo, aliado com um conjunto de
classes adaptadoras que permitem a visualização e a edição baseada em comandos do modelo, e
um editor de texto básico. Estas informações são baseadas na especificação presente no site do
projeto EMF no Eclipse (2014).
b. Graphical Editing Framework (GEF)
A tecnologia para criar editores editores gráficos e visões do Eclipse Workbench UI é definida
no GEF. Estes editores consistem de diversos componentes: o editor do diagrama de modelos,
incluindo uma paleta de ferramentas; figuras que representam graficamente os elementos de dados
dos modelos subjacentes; EditParts que combinam figuras e seus respectivos elementos do
modelos; objetos de requisição para entradas do usuário; objetos EditPolicy que avaliam as
requisições e criam objetos de comando apropriados; objetos de comando que editam o modelo e
fornecem as funcionalidades de ‘desfazer’ ou ‘refazer’.
Alguns destes componentes irão aparecer no fluxo do trabalho descrito na próxima seção.
Este fluxo segue o objetivo dessa proposta, resultando em um editor gráfico para gerenciamento de
SDNs, gerado a partir do GMF com a DSML proposta subjacente.
c.Unindo EMF e GEF
Conforme citado anteriormente, a implementação do editor gráfico é um dos requisitos para
atingir o objetivo principal deste trabalho. Esta implementação requer o atendimento de diversos
requisitos já vistos, de forma que o paradigma MDD seja satisfeito. Além disso, de maneira prática,
para a geração deste editor é preciso criá-lo a partir de um modelo EMF. Sendo assim, o metamodelo será gerenciado pelo EMF, e a parte gráfica gerenciada pelo GEF. O GMF é o framework
que facilita a união destes dois frameworks. A facilidade é possibilitada a partir de duas partes
principais: um ambiente de execução (que estende algumas funcionalidades de ambos frameworks,
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 194 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software EMF e GEF) e um framework de geração (Generation Framework). Este último contém editores
especiais para manipular modelos GMF e um gerador que produz código a partir destes modelos.
Figura 5: Mapeamento GMF entre EMF e GEF.
A partir da Figura 5, podemos visualizar à esquerda o meta-modelo (definido no EMF, um
arquivo Ecore), na direita está a representação visual (GEF). No centro é que ocorre o mapeamento,
realizado pelo GMF. Todo elemento do modelo de domínio (EMF) que deva ser exibido
graficamente, precisa de um elemento representativo no modelo de definição gráfica da DSML.
Apesar da explicação sequencial, existe uma ferramenta criada pelo projeto Eclipse, chamada
EuGEN ia (ECLIPSE, 2014), que automatiza a união dos frameworks mencionados anteriormente,
implementando modelos necessários para criação de editores baseados no GMF. A geração de
código ocorre no mapeamento GMF-EMF, a partir da utilização de templates EGL (Epsilon
Generation Language), com espaços reservados para a inserção dos dados presentes no modelo
do domínio construído pelo usuário.
RESULTADOS E DISCUSSÃO
Mdd-Sdn: Abordagem Dirigida Por Modelos Para Gerenciamento De Redes Definidas Por
Software
Os conceitos expostos na seção de fundamentação teórica mostraram uma base para
compreender o possível relacionamento entre MDD e SDN. Esta seção, apresenta a DSML proposta
por este trabalho, mostrando, principalmente, (1) a extensão do meta-modelo MOF para modelar
elementos SDN e seus relacionamentos em um domínio de controle específico, servindo como
sintaxe abstrata da DSML, (2) os elementos gráficos que representam este modelo, e (3) a geração
de código, de forma que esta DSML permita o gerenciamento das SDNs seguindo o paradigma
MDD.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 195 LOPES, F. A.; FERNANDES, S. F. L. Devido à limitação no espaço do texto, esta seção irá apresentar a abordagem MDD-SDN
com foco apenas na modelagem e gerenciamento de políticas de rede relacionadas ao controle de
domínio baseado no tempo. Também não será detalhada a construção da sintaxe concreta da
DSML proposta. Vale ressaltar que o fluxo de trabalho utilizado no desenvolvimento desta
abordagem é consistente com os requisitos do paradigma MDD (BAETENS, 2011). Além disso, por
utilizar alguns frameworks para modelagem, este fluxo também foi determinado por características
intrínsecas aos frameworks utilizados. A Figura 6 demonstra, resumidamente o fluxo de trabalho
realizado para atingir o objetivo desta proposta.
Figura 6: Fluxo de desenvolvimento da DSML proposta.
Para oferecer e construir a DSML, com base nos padrões que norteiam o paradigma MDD,
além da definição do escopo de domínio, onde o fundamentamos utilizando os conceitos do
gerenciamento de SDNs com controle de domínio baseado no tempo, uma das formas de
implementar DSML é utilizar MOF como padrão para descrição de meta-modelos (WACHSMUTH,
2008). Além disso, o GMF incorpora meta-modelos MOF, habilitando a criação de ferramentas para
modelagem de aplicações a partir destes meta-modelos (KOLOVOS et al., 2007). Sendo assim, (1)
definiu-se o escopo do domínio e seus conceitos, atendo aos requisitos 5 e 6 do paradigma MDD,
(2) sua sintaxe concreta, posteriormente, (3) criou-se a sintaxe abstrata da DSML proposta, e por
último (4) foi especificado o template para geração de código.
Embora seja apresentada para compor a demonstração do processo de desenvolvimento da
DSML, a criação da sintaxe concreta não será profundamente discutida nesta seção, tendo em vista
que sua validação ainda não foi realizada em critérios qualitativos, embora as regras de construção
utilizadas na DSML garantam sua eficácia sintática. A Figura 7 exibe os elementos concretos
representativos e os relacionamentos entre eles, constituindo a sintaxe concreta na DSML proposta.
Um estudo qualitativo para este componente da DSML será tratado em um trabalho futuro,
analisando a representação gráfica destes elementos, podendo compará-la com outras linguagens
que definem graficamente comportamentos de rede.
A criação da sintaxe abstrata realizou a extensão do meta-modelo MOF (Ecore), para
adequar-se a um cenário de controle de domínio baseado no tempo para gerenciar SDNs. A criação
da sintaxe abstrata, desta forma, atende tanto ao requisito 4 do paradigma MDD, como satisfaz ao
requisito do GMF em utilizar um descritor de linguagem baseado em MOF. A Figura 8 ilustra a
sintaxe abstrata da abordagem.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 196 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software Figura 7: Sintaxe concreta da DSML proposta.
Figura 8: Meta-modelo da abordagem MDD-SDN.
Para a geração de código, foi necessário o uso de uma DSL subjacente compatível com o
controlador POX que definimos como primeiro controlador a ser suportado pela DSML proposta,
devido à sua característica open source. A única DSL conhecida, voltada para este controlador, é
denominada Pyretic (MONSANTO et al., 2013).
Embora tenha sido definido o controlador POX e a linguagem relacionada Pyretic para
implementar a geração de código da DSML, o modelo extensível da proposta permite que mais
DSLs sejam adicionadas para geração de código, assim como mais controladores sejam
suportados, isso pode ser necessário para aumentar a abrangência dos modelos criados,
possibilitando ainda interoperabilidade entre modelos para gerenciamento de redes com
infraestrutura subjacentes distintas.
Quadro 2: Trecho do template utilizado na DSML para geração de código.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 197 LOPES, F. A.; FERNANDES, S. F. L. def ui_loop (self): [%for (policy in Policy) {%] [%if (policy.concession == 'Deny') {%] try: nb = [%=policy.condition%] (str1,str2) = nb.split(',') (mac1,mac2) = (MAC(str1),MAC(str2)) self.AddRule(mac1,mac2) except: print "Invalid Format" [%}%] [%if (policy.concession == 'Allow'%) {%] try: nb = [%=policy.condition%] (str1,str2) = nb.split(',') (mac1,mac2) = (MAC(str1),MAC(str2)) self.DeleteRule(mac1,mac2) except: print "Invalid Format" [%}%] [%}%] O GMF utiliza templates na etapa de geração de código (Kolovos et al., 2007). Para que não
sejam gerados códigos inválidos e inconsistentes, a construção destes templates deve estar de
acordo com os conceitos e relacionamentos definidos no modelo da DSML. No Quadro 2 está um
trecho do template utilizado na geração de código da proposta. Não será detalhada a sintaxe da
DSL utilizada no template. Estas informações podem ser encontradas na documentação da
linguagem (FRENETIC, 2014), e o template completo pode ser acessado no repositório da proposta.
Simulação e Validação
A validação da DSML e seus componentes foi realizada no simulador Mininet (LANTZ et al.,
2010). A simulação envolveu a análise de fluxo numa SDN, simplesmente utilizando o comando
pingall do simulador, que tenta atingir todos os nós da topologia SDN. O cenário hipotético para
validar a proposta é o mesmo exibido na Figura 7. Com a utilização subjacente do controlador POX,
configurado com um módulo de aprendizado de rotas. Uma das execuções da simulação utilizou o
horário fora do intervalo estabelecido pelas políticas (iguamente definido para ambas por fins de
simplificação), o resultado foi a comunicação entre todos os hosts, já que essa é a regra geral . Por
outro lado, a segunda execução do experimento foi realizada em um horário entre os período
especificado pelas políticas. Satisfatoriamente, as políticas foram aplicadas da forma que foi
construído o modelo, e a comunicação entre os hosts B e D não ocorreu. Esta afirmação é
consistente com a saída produzida pelo Mininet, evidenciada pelo Quadro 3, que demonstra os
resultados da simulação realizada.
Quadro 3: Trecho do template utilizado na DSML para geração de código.
Execução fora do período especificado
nas políticas
mininet> pingall
Saída resultante
*** Ping: testing ping reachability
hA -> hB hC hD
hB -> hA hC hD
hC -> hA hB hD
hD -> hA hB hC
*** Results: 0% dropped (0/12 lost)
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 198 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software Execução no período especificado nas
políticas
mininet> pingall
Saída resultante
*** Ping: testing ping reachability
hA -> hB hC hD
hB -> hA hC
hC -> hA hB hD
hD -> hA hC
*** Results: 16.6% dropped (2/12 lost)
Trabalhos Relacionados
A utilização de APIs e DSMLs para a modelagem de redes é encontrada como base, por
exemplo, para trabalhos semelhantes ao de Rodrigues et al. (2011). Este trabalho apresenta uma
infraestrutura baseada em MDA para redes de sensores sem fio (Wireless Sensor Network – WSN),
promovendo a separação de responsabilidades entre os especialistas envolvidos na WSN e os
componentes da WSN. Em Imtiaz et al. (2008) define-se uma abordagem que utiliza MDD para
configurar de forma automática redes Ethernet de tempo real. Barrett et al. (2007) também utiliza
MDD, tendo como objetivo modelar uma ferramenta para geração e análise de políticas de rede.
Ambas as abordagens possuem DSLs subjacentes utilizadas como base para a transformação
modelo-código.
A proposta em discussão difere destas outras abordagens por permitir a gerência de redes
SDN, proporcionando independência de controladores, possibilitando extensões para vários
cenários, além de reduzir drasticamente o nível de complexidade envolvido neste gerenciamento.
CONCLUSÕES
O principal objetivo deste trabalho foi propor uma abordagem, baseada no paradigma MDD
(DSML especificamente), para o gerenciamento de SDN, resultando em benefícios já obtidos pela
utilização deste paradigma em outros tipos de rede. Além disso, evidenciou-se que o o modelo
construído satisfaz aos requisitos levantados.
Esta proposta teve como contribuição principal a DSML pioneira voltada para SDNs, que
compõe um editor gráfico utilizado para aumentar o nível de abstração no gerenciamento destas
redes. Além disso, dois artefatos subjacentes à DSML proposta singularizam as contribuições deste
trabalho: (1) o meta-modelo extensível que mapeia os conceitos em SDNs e como estes conceitos
estão relacionados, e (2) o fluxo de desenvolvimento MDD adequado à criação de uma ferramenta
de gerência em SDNs, que possibilita uma interação intuitiva entre especialistas de domínio e os
recursos das redes definidas por software.
Para trabalhos posteriores, é preciso investigar de forma qualitativa os elementos que
compõem a DSML proposta, identificando benefícios que podem ser alcançados ao utilizar uma
linguagem de modelagem para gerenciamento de SDNs, no lugar de codificar scripts. Além disso,
a extensão desta DSML para outros domínios de controle é uma tendência clara para buscar a
completude da abordagem.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 199 LOPES, F. A.; FERNANDES, S. F. L. AGRADECIMENTOS
Este trabalho foi apoiado pela FACEPE, com o identificador: IBPG-0738-1.03/12.
REFERÊNCIAS
ATKINSON, C.; KUHNE, T.. Model-driven development: a metamodeling foundation. IEEE Software, v.20,
n.5, p.36-41, 2003.
BAETENS, N.. Comparing graphical DSL editors: AToM³, GMF. MetaEdit+, University of Antwerp, 2011.
BARRETT, K.; DAVY, S. STRASSNER, J.; JENNINGS, B.; VAN DER MEER, S.; DONNELLY, W.. A Model
Based Approach for Policy Tool Generation and Policy Analysis. First International Global Information
Infrastructure Symposium, 2007.
CLARK, T.; EVANS, A.; KENT, S.; SAMMUT, P.. The MMF Approach to Engineering Object-Oriented
Design Languages. Workshop on Language Descriptions, Tools and Applications, 2001.
CLAYPOOL, D.; MCNEVIC, T.; MCNEIL, K.. Automated Software Defined Radio Deployment Using
Domain Specific Modeling Languages. IEEE Mobile WiMAX Symposium, 2009.
DE LARA, J.; VANGHELUWE, H.. Meta-modelling and graph grammars for multi-paradigm modelling in
AToM³. Atom”, Software and Systems Modeling, v.3 n.3, p.194-209, 2004.
EMERSON, M.; SZTIPANOVITS, J.; BAPTY, T.. A MOF-based meta-modeling environment. Journal of
Universal Computer Science, p.1357-1382, 2004.
ERICKSON, D.. The beacon openflow controller. Proceedings of the second ACM SIGCOMM workshop
on Hot topics in software defined networking, p.13-18, 2013.
FEAMSTER, N.; REXFORD, J.; ZEGURA, E.. The Road to SDN. Queue - Large-Scale Implementations,
p.20, 2013.
FERGUSON, A. D.; GUHA, A.; FONSECA, R.; KRISHNAMURTHI, S.. Participatory networking: an API for
application control of SDNs. Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, p.327338, 2013.
FONTES, R.; SAMPAIO, P.. Visual Network Description: A Customizable GUI for the Creation of Software
Defined Network Simulations. European Simulation and Modelling Conferece, 2013.
FOSTER, N.; GUHA, A.; REITBLATT, M.; STORY, A.; FREEDMAN, M.; KATTA, N.; MONSANTO, C..
Languages for Software-Defined Networks. IEEE Communications Magazine, 2013.
FOSTER, N., HARRISON, R., FREEDMAN, M. J., MONSANTO, C., REXFORD, J., STORY, A., & WALKER,
D.. Frenetic: a network programming language. Proceedings of the 16th ACM SIGPLAN international
conference on Functional programming, p.279-291, 2011.
GUDE, N.; KOPONEN, T.; PETTIT, J.; PFAFF, B.; CASADO, M.; MCKEOWN, N.; SHENKER, S.. NOX:
towards an operating system for networks. ACM SIGCOMM Computer Communication Review, p.105110, 2008.
IMTIAZ, J.; JASPERNEITE, J.; WEBER, K.; GOETZ, F. J.; LESSMAN, G.. A novel method for auto
configuration of Realtime Ethernet Networks. IEEE International Conference on Emerging Technologies
and Factory Automation, p.861-868, 2008.
KIM, H.; FEAMSTER, N.. Improving network management with software defined networking. IEEE
Communications Magazine, p.114-119, 2013.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 200 Abordagem dirigida a modelos para o gerenciamento de redes definidas por software KOLOVOS, D. S.; PAIGE, R. F.; ROSE, L. M.; POLACK, F. A.. Bridging the Epsilon Wizard Language
and the Eclipse Graphical Modeling Framework. Modeling Symposium, Eclipse Summit Europe, 2007.
LANTZ, B.; HELLER, B.; MCKEOWN, N.. A network in a laptop: rapid prototyping for software-defined
networks. Hotnets-IX Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Networks, 2010.
MCKEOWN, N.; ANDERSON, T.; BALAKRISHNAN, H.; PAULKAR, G.; PETERSON, L.; REXFORD, J.;
TURNER, J.. OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer
Communication Review, p.69-74, 2008.
MONSANTO, C.; REICH, J.; FOSTER, N.; REXFORD, J.; WALKER, D.. Composing Software-Defined
Networks. Proceedings of the USENIX conference on Networked Systems Design and Implementation, p.114, 2013.
NIKIFOROVA, O.; CERNICKINS, A.; PAVLOVA, N.. Discussing the Difference between Model Driven
Architecture and Model Driven Development in the Context of Supporting Tools. Fourth International
Conference on Software Engineering Advances, p.446-451, 2009.
RODRIGUES, T.; DANTAS, P.; DELICATO, F.; PIRES, P.; PIRMEZ, L.; BATISTA, T.; ZOMAYA, A.. ModelDriven development of wireless sensor network applications. International Conference on Embedded
and Ubiquitous Computing, p.11-18., 2011.
SHERWOOD, R.; GIBB, G.; YAP, K. K.; APPENZELLER, G.; CASADO, M.; MCKEOWN, N.; PARULKAR,
G.. FlowVisor: a network virtualization layer. OpenFlow Consortium, 2009.
STAHL, T.; VÖLTER, M.; BETTIN, J.; HAASE, A.; HELSEN, S.. Model-Driven Software Development:
technology, engineering, management. England: John Wiley & Sons, 2006.
STEINBERG, D.; BUDINSKY, F.; PATERNOSTRO, M.; MERKS, E.. EMF: Eclipse modeling framework 2.0.
Addison-Wesley Professional, 2009.
TOLVANEN, J. P.; ROSSI, M.. MetaEdit+: defining and using domain-specific modeling languages and code
generators. OOPSLA Companion of ACM SIGPLAN conference on Object-oriented programming,
systems, languages, and applications, p.92-93, 2003.
VOELLMY, A.; AGARWAL, A.; HUDAK, P.. Nettle: Functional Reactive Programming for OpenFlow
Networks. PADL, 2011.
WACHSMUTH, G.. Modelling the operational semantics of domain-specific modelling languages.
Berlin: Springer-Verlag, 2008.
Revista Brasileira de Administração Científica  v.5 ‐ n.2  Anais do SBTI 2014 ‐ Out 2014 P a g e | 201