Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN
•Download as PPTX, PDF•
0 likes•105 views
The programmable network architectures that emerged in the last decade have opened new ways to enable Autonomic Networks. However, there are several open issues to address before making such a possibility into a feasible reality. For instance, defining network goals, translating them into network rules, and granting the correct functioning of the network control loop in a self-adaptive manner are examples of complex tasks required to enable an autonomic networking environment. Fortunately, architectures based on the concept of Models at Runtime (MART) provide ways to overcome such complexity. This paper proposes a MART-based framework – using the RFC 7575 as reference (i.e., definitions and design goals for autonomic networking) – to implement autonomic management into a programmable network. The evaluation shows the proposed framework is suitable for satisfying the functional and performance requirements of a simulated network.
Recommended
More Related Content
Similar to Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN
Similar to Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN (20)
Recently uploaded
Recently uploaded (20)
Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN
- 1. Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Felipe A. Lopes Instituto Federal de Alagoas (IFAL)
- 2. Autonomic Networking LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Information Processing Knowledge Generation / Analysis Policy Processing Business Goals / Policies Configuration Context Based on Strassner, John, Nazim Agoulmine, and Elyes Lehtihet. "Focale: A novel autonomic networking architecture." (2006).
- 3. Autonomic Networking in SDN LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Control Plane Information Processing Knowledge Generation / Analysis Policy Processing Business Goals / Policies Configuration Context Based on Stamou, Adamantia, et al. "Autonomic handover management for heterogeneous networks in a future internet context: A survey." IEEE Communications Surveys & Tutorials 21.4 (2019): 3274- 3297. Challenges
- 4. Scope: RFC 7575 IETF’s Network Management Group (NMRG) LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Guidelines and Reference Model for implementing autonomic networks Objective: Achieve Self-Management Self-* properties Self-configuration Self-healing Self-protection Self-optimizing Design goals Coexistence with tradicional management Decentralization Distribution Simplification of NBI Abstraction Autonomic monitoring ... 5 more
- 5. Autonomic Networking in SDN LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Control Plane Information Processing Knowledge Generation / Analysis Policy Processing Business Goals / Policies Configuration Context Based on Stamou, Adamantia, et al. "Autonomic handover management for heterogeneous networks in a future internet context: A survey." IEEE Communications Surveys & Tutorials 21.4 (2019): 3274- 3297. Challenges Opportunities How to enable autonomic networking in SDN?
- 6. How to enable autonomic networking in SDN? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Autonomic Network Management is not a new area Control Plane is software Automated Software Engineering Community made contributions Models at Runtime First papers from 2000’s IETF’s Community made contributions RFC 7575
- 7. Models at Runtime (MART) LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Structure Behavior Goals System The word “Models” of MART comes from the Model-Driven Engineering (MDE) discipline. Objective/Adaptation Models Learning/Monitoring Reasoning Analyzer Executor Managed System Aßmann, Uwe, et al. "A reference architecture and roadmap for models@ run. time systems." Models@ run. time. Springer, Cham, 2014. 1-18. Objective Management Layer Configuration Management Layer Base Layer
- 8. Models at Runtime (MART) LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN The word “Models” of MART comes from the Model-Driven Engineering (MDE) discipline Objective/Adaptation Models Learning/Monitoring Reasoning Analyzer Executor Managed System Aßmann, Uwe, et al. "A reference architecture and roadmap for models@ run. time systems." Models@ run. time. Springer, Cham, 2014. 1-18. Metamodels Concrete Syntax Modeled System Monitoring Machine Learning Algorithms Generated Code Runtime Models Code Templates
- 9. LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Autonomic Network Management is not a new area Control Plane is software Automated Software Engineering Community made contributions First papers from 2000’s IETF’s Community made contributions How to enable autonomic networking in SDN? RFC 7575 How to use RFC 7575 and MART for enabling Autonomic Networking in SDN? Autonomic Network Models at Runtime
- 10. RFC 7575 and MART for Autonomic Networking in SDN LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Proposed MART Architecture RFC 7575 Design Goals Self-configuration Self-healing Self-optimizing Abstraction Autonomic Reporting Independence of Function and Layer Full Life-Cycle Support
- 11. RFC 7575 and MART for Autonomic Networking in SDN LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Models Metamodels
- 12. RFC 7575 and MART for Autonomic Networking in SDN LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Development and Management Models as inputs Running code / Network rules as outputs
- 13. Evaluation Which RFC 7575’s design goals the proposed MART-based solution could not achieve? Why? How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN
- 14. Evaluation Which RFC 7575’s design goals the proposed MART-based solution could not achieve? Why? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN RFC 7575 Design Goals not achieved Reason Self-protection Currently, metamodels do not have entities for representing such goal. Coexistence with Traditional Management The final ANM system supports only intents. Secure by Default The final ANM system cannot assert the membership of all componentes as required by the RFC. Common Autonomic Networking Infrastructure Achieving this goal using a unique MART solution would increase the complexity of metamodels.
- 15. Evaluation How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Use case Metamodels and algorithms implemented in Graphical Modeling Framework (GMF) Modeling Simulation https://github.com/felipealencar/mdn Enable the communication in a network topology consisting of three nodes connected by four switches, forming two different paths. All the links have 10Mb of bandwidth.
- 16. How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Use case Modeling Configuration Model Objectives Model
- 17. How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Simulation Modeling Code Generation Monitoring Learning Models as inputs of code templates Mininet network simulation
- 18. How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Simulation Modeling Select actions and network monitoring to check if h1 reaches h2. Learning rate: 0.0001 Activation function: ReLu
- 19. How suitable is the proposed MART-based solution from a performance perspective? LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Simulation Modeling Introduce congestion traffic to verify model transformations and reasoning in the action selection process
- 20. Conclusions LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN Proposal for enabling autonomic network management in SDN Knowledge combination High-level modeling for implementing autonomic behavior Evaluation in different use cases and scenarios Suitable performance Some design goals could not be covered Proposal for enabling autonomic network management in SDN Knowledge combination High-level modeling for implementing autonomic behavior Evaluation in different use cases and scenarios Proper functioning and suitable performance Some design goals could not be covered
- 21. Thank you! Questions? <felipe.alencar@ifal.edu.br> LOPES, F. A., Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN
Editor's Notes
- Bom dia! Meu nome é Felipe Alencar, sou professor do IFAL e irei apresentar o artigo “Using the RFC 7575 and Models at Runtime for Enabling Autonomic Networking in SDN” aceito nesta edição do Workshop Pré-IETF.
- Então começando pelo conceito de redes autonômicas, ele é utilizado para definir conjunto de procedimentos, dados e interações que resultam em redes que funcionam baseadas em objetivos e executam tarefas (com pouca ou nenhuma interação de um ser humano) que visam alcançar estes objetivos de forma autonômica. Essa imagem, baseada na arquitetura Focale, proposta por Strassner (2006), ilustra estas interações, os procedimentos e os possíveis dados envolvidos no ciclo autonômico para redes tradicionais.
- Com o surgimento do paradigma SDN, a grande diferença é que o conjunto de elementos autonômicos agora podem ser implementados em um plano de controle separado dos elementos de encaminhamento. Porém, existem desafios na definição de objetivos ou políticas de rede, na geração e análise de conhecimento, no processamento das políticas de rede, na configuração automática de elementos de rede e no monitoramento utilizado para gerar a base de conhecimento e oferecer suporte ao atendimento dos objetivos
- Neste cenário, o Network Management Group do IETF trabalhou na RFC 7575 que define diretrizes a serem seguidas para que o conceito de redes autonômicas seja alcançado. Essa RFC tem em seu escopo 4 propriedades Self-* e 11 objetivos de design para soluções que busquem prover redes autonômicas, como por exemplo: aumento no nível de abstração, monitoramento autonômico e coexistência com o gerenciamento de rede tradicional.
- Considerando que os desafios que existem em cada parte necessária para a realização de redes autonômicas podem também ser encarados como a oportunidade de responder à pergunta que motiva este trabalho: “Como habilitar redes autonômicas em SDN”?
- Para responder a questão que motiva este trabalho, devemos ter em mente que: a área de gerenciamento autonômico de redes não é nova. Os primeiros artigos surgiram no início dos anos 2000. O plano de controle, em SDN, é software. E já existem contribuições em comunidades que lida com tornar softwares autonômicos. A comunidade de Engenharia de Software Automatizado têm contribuições nessa linha de autonomicidade, o conceito de Modelos em Tempo de Execução é uma dessas contribuições. O próprio IETF contribuiu com a RFC 7575 e grupos de trabalho nesta mesma linha.
- E o que são os Modelos em Tempo de Execução? Este conceito considera que todo sistema observável possui objetivos, comportamento e uma estrutura. Ao considerar esse sistema como software, é possível representá-lo como modelos que interagem entre si, aprendendo, monitorando, analisando e executando a própria representação do sistema. Na categorização de Assmann, essa representação pode ser feita em três camadas: camada de objetivos, camada de configuração e o camada base, onde ocorre a execução do sistema observado.
- Ao concretizar cada representação do sistema, temos: primeiro) metamodelos que são usados para definir formalmente os conceitos do sistema observado ou a ser gerenciado; segundo) uma sintaxe que é usada para definir semanticamente os conceitos do sistema, aumentando o nível de abstração; terceiro) modelos de código que têm o papel de permitir a adaptação do que será executado em acordo com o que está modelado; quarto) técnicas de monitoramento e algoritmos de aprendizagem de máquina que devem ser utilizados para classificar e predizer comportamentos do sistema. Assim, essa concretização resulta no sistema modelado em alto nível transformando-se em código gerado que reflete com precisão os modelos criados.
- Compreendendo a RFC 75757 e agora o conceito de MART. A pergunta que surge é: como combinar estes dois conceitos para permitir redes autonômicas em SDN.
- Para responder à pergunta específica levantada neste ponto, este trabalho propõe uma arquitetura MART composta por 3 camadas que interagem entre si. São elas: i) a camada de modelo de rede, responsável por abrigar metamodelos e modelos a serem usados na modelagem dos objetivos e da própria rede; ii) a camada de adaptabilidade, que abriga a base de conhecimento e elementos de análise, aprendizado e raciocínio (ou predição) e interage tanto com a camada de modelo de rede quanto com a camada de infraestrutura; iii) camada de infraestrutura que por sinal é a última camada prevista na arquitetura proposta prevê uma infraestrutura SDN padrão. Os elementos dessas camadas foram definidos visando alcançar os objetivos de design definidos pela RFC 7575.
- A Camada de Modelo de Rede é totalmente baseada em metamodelos e sintaxes concretas dos elementos do domínio do sistema. Apesar de nesta parte da apresentação serem mostrados apenas dois metamodelos, é importante observar que é nesta camada onde são especificadas as regras sintáticas que compõe cada metamodelo. Por exemplo, se na linguagem de modelagem final iremos modelar um objetivo, são estes metamodelos que garantem que é possível haver um relacionamento transitivo entre ações e objetivos, e entre ações e fluxos, mas não um relacionamento direto entre objetivos e fluxos. Essas regras garantem a boa formação de modelos e a geração correta de código executável.
- A segunda camada, chamada Camada de Adaptabilidade, faz uso dos modelos criados na Camada de Modelo de Rede (que podem sofrer atualizações durante a execução). Estes modelos servem como entrada do algoritmo de aprendizagem por reforço profunda que possui o papel de receber os objetivos que foram modelados e buscar ações que alcancem estes objetivos. Enquanto o objetivo modelado não é alcançado, o algoritmo (que é baseado em implementações da literatura) seleciona aleatoriamente uma das possíveis ações do modelo e seu respectivo parâmetro de rede, calcula a variável de aprendizado antes da execução da ação, e depois da ação executada, monitorando a rede, é calculada a recompensa (ou punição) decorrida desta execução. Essa associação entre ação executada e valor da recompensa é armazenada na base de conhecimento, onde um número X de amostras é coletado para comparar o desconto a ser aplicado na recompensa calculada anteriormente. Esse passo é necessário para conseguir fazer a comparação histórica da execução de ações (isso evita que o algoritmo volte a utilizar regras que não estavam melhorando o parâmetro observado). Restando atualizar a última transição com o desconto aplicado e treinar a rede Q (uma rede neural treinada com valores de qualidade, ou Q value, e ações executadas). E, por fim, realizar a comparação entre o estado do objetivo a ser alcançado, o melhor estado até então observado e o pior estado até então observado). Vale ressaltar que código executável e regras de rede são sempre gerado a partir dos modelos e do algoritmos de aprendizagem.
- A avaliação deste trabalho buscou responder duas perguntas, que estão diretamente relacionadas à motivação original sobre como permitir redes autonômicas em SDN. São elas: Quais objetivos de design da RFC 7575 a solução proposta baseada em MART não pôde alcançar e por que? Quão viável é a solução proposta baseada em MART sob uma perspectiva de desempenho?
- Para responder à primeira pergunta, uma análise qualitativa funciona foi feita e foi possível observar que dos 11 objetivos de design definidos pela RFC 7575, 4 deles não puderam ser alcançados, além de 3 que foram parcialmente alcançados. Dos que não puderem ser alcançados temos: - O objetivo de auto-proteção que, apenas por falta de inserções de entidades no metamodelo, não pôde ser atingido; A coexistência com gerenciamento tradicional, que não é possível dado que o suporte do sistema de gerenciamento gerado é apenas para Intents; A segurança por padrão que a RFC requer garantias de que os componentes que interagem no sistema de gerenciamento sejam identificáveis, isto ficou fora do escopo da metamodelagem; E o objetivo de definir uma infraestrutura de rede autonômica padrão, que a RFC define para padronizar a definição de todas as funções autonômicas conhecidas da rede. Isso iria aumentar muito a complexidade dos metamodelos da proposta e também foi deixado fora do escopo.
- Para avaliar o desempenho e verificar a sua adequação a possíveis implantações reais, foi realizada a implementação da arquitetura proposta utilizando o framework GMF (um framework para gerar ferramentas computacionais baseadas em modelos de alto nível). Além disso, foi definido um caso de uso para ser modelado, que tem como objetivo simplesmente permitir a comunicação entre uma topologia de rede composta por 3 nós, 4 switches e duas rotas. E, por fim, gerada uma simulação para observar métricas de desempenho e o sistema de gerenciamento de rede autonômico em execução. Vale ressaltar que o código da implementação usada na modelagem está disponível no GitHub.
- A etapa de modelagem envolve o uso da ferramenta gerada a partir dos metamodelos. Esse uso refere-se a criação do modelo de configuração da rede e a criação do modelo de objetivos da rede. Considerando as informações do caso de uso, temos no modelo de configuração a modelagem dos três nós, conectados por links e 4 switches formando as duas rotas possíveis de comunicação entre esses nós. No lado do modelo de objetivos, temos que um dos objetivos modelos é permitir o encaminhamento de fluxos entre o nó h1 e o nó h2.
- Da modelagem anterior, ocorre a geração de código – baseada na forma de interação com um controlador SDN (o Ryu no caso dessa avaliação) – e esta geração utiliza as informações do modelo para o código final gerado a ser executado pelo controlador. Nesse ponto, o algoritmo de aprendizagem por reforço profunda também é utilizado e suas variáveis são substituídas por valores presentes no modelo neste processo de geração de código. Com o código gerado, ocorre a simulação na ferramenta Mininet. Por meio de monitoramento, a simulação retroalimenta os modelos, que podem ser atualizados, a depender das ações escolhidas pelo algoritmo de aprendizagem e do reflexo delas na rede.
- O primeiro experimento nesse cenário buscou avaliar se o sistema autonômico era capaz de alcançar o objetivo modelado: permitir a comunicação entre os hosts h1 e h2. Neste gráfico podemos ver a evolução das recompensas conforme o algoritmo começa a utilizar regras de rede que o aproximem do parâmetro estabelecido. Além do comportamento funcional de um simples encaminhamento de fluxos, adicionamos um objetivo de minimização de atraso no modelo de objetivos para verificar o comportamento do algoritmo nesta situação.
- Neste cenário de minimização e atraso, também foi possível observar a auto-adaptação que o algoritmo buscou, executando regras de rede de delegação de fluxo como alternativa para alcançar o segundo objetivo.
- Concluindo, a proposta de combinação de áreas distintas visando permitir redes autonômicas em SDN pôde contribuir com uma solução alternativa de alto nível para implementar comportamento autonômico no gerenciamento destas redes, solução esta baseada em diretrizes de uma RFC. Como limitações, o trabalho demonstrou alguns objetivos de design que não puderam ser alcançados e que podem ser abordados em trabalhos futuros, como a compatibilidade com o gerenciamento de rede tradicional. A avaliação da solução proposta em diferentes cenários e casos de uso também é um caminho a ser explorado. Porém, os resultados dos experimentos mostraram um funcionamento correto e um desempenho adequado da solução.
- Obrigado!