![Referências/Literaturas
• Paul Goransson and Chuck Black, Software Defined Networks:
A Comprehensive Approach. Morgan Kaufmann; 1 edition (June
29, 2014)
• Bosshart, P., Varghese, G., Walker, D., Daly, D., Gibb, G., Izzard,
M., McKeown, N., Rexford, J., Schlesinger, C., Talayco, D., and
Vahdat, A. (2014). P4: Programming Protocol-Independent
Packet Processors. ACM SIGCOMM Computer Communication
Review, 44(3):87–95.
• Industry Specification Group (ISG) NFV 2014a] ETSI Industry
Specification Group (ISG) NFV (2014a). Network Functions
Virtualisation (NFV); Management and Orchestration; Report
on Architectural Options.
69](https://image.slidesharecdn.com/enucomp2017-tutorial-netsoftwarization-171122164421/85/Enucomp2017-Tutorial-about-network-softwarization-69-320.jpg)
Enucomp2017 - Tutorial about network softwarization
- 1. 1 Softwarização em Redes:Do Plano de Dados ao Plano de Orquestração Minicurso – 16 de novembro de 2017 Nathan F. Saraiva de Sousa Christian Esteve Rothenberg
- 2. Currículo 2 • NathanSaraiva • Titulação • Tecnólogo em Redes de Comunicação – IFPI • Especilaista em Redes de Computadores - FSA • Graduação e Mestrado em Ciência da Computação - UFPI • Estudante de Doutorado em Engenharia Elétrica/Computação – UNICAMP • Experiências • FAPEPI/PoP-RNP • UESPI (Analista e Professor de Especialização), FAP, INTA, FAESF, CET (Tecnólogo e Especialização) • IFPI • Linhas de Pesquisa • SDN • NFV • Orquestração Multi domínio. • CV: http://lattes.cnpq.br/6190003234095907 • Email: nsaraiva@dca.fee.unicamp.br
- 3. Agenda • Parte I:: 08:30 – 10:30 ○ Introdução ○ Programação na Camada de Dados • Conceitos • Atividade Prática ○ Programação na Camada de Encaminhamento • Conceitos • Parte II :: 10:30 – 12:30 ○ Programação na Camada de Encaminhamento • Atividade Prática ○ Programação na Camada de Gerenciamento e Orquestração • Conceitos • Atividade Prática ○ Desafios ○ Conclusão 3
- 4. Objetivos • Apresentar umavisão geral na área de softwarização de redes. • Abordar os princípios do: ○ Plano de dados; ○ Plano de encaminhamento/controle; ○ Plano de orquestração e gerenciamento. • Introduzir atividades práticas com: ○ Linguagem P4; ○ Protocolo OpenFlow; ○ Virtualização de funções de rede com OpenStack-Tacker. • Discutir os principais desafios e áreas de pesquisa. 4
- 5.
- 6. Contexto/Motivação 6 @ Infraestrutura dasOperadoras de Telecom Source: Ericsson(Adaptado) Acesso Núcleo Nuvem OSS / BSS
- 7. Crescimento do TráfegoGlobal 7 Source: Ericsson ExaBytes/month
- 8. Problemas das Operadoras •Aumento da disparidade entre custo e receita; • Grande variedade de tipos de hardware proprietários; • Clico de vida reduzido do hardware; • Dificuldade na implantação de novos serviços; • Gerenciamento por CLI ou soluções proprietárias; 8
- 9. Novas tecnologias 9 NFVNetwork Softwarization Flexibilidade Escalabilidade Automação Agilidade Processador Programável Redes Definidas por Software Virtualização de Funções de Rede Hardware Software Source:ACMSIGCOMMNetPL2017
- 10. Definindo “Softwarização” deRede 10 Possibilidade da rede ser programável e flexível se adequando às necessidades dos clientes e do tráfego de rede.
- 11. Novo Sistema deRede 11 A "softwarização" de rede definindo as camadas de um sistema de rede
- 12.
- 13. Redes Atuais 13 Linuxou Unix
- 14. Ciclo para NovasFuncionalidades 14 Network Equipment Vendor Network Owner ASIC Team Software Team Feature Years Source: Nick McKeown. “Programmable forwarding planes are here to stay”. In ACM SIGCOMM NetPL 2017
- 15. Novas Abordagens • Programaçãotop-down, sem necessidade de todo processo de desenvolvimento. • Novos equipamentos de redes: ○ Processador de pacotes configurável: não viculado a um formato específico de cabeçalho; ○ Tabelas de pacotes flexíveis: múltiplas tabelas no pipeline e funções mais complexas; ○ Primitivas gerais de processamento de pacotes: implementar primitivas como copiar, adicionar e remover. 15
- 16. Tecnologias promissoras • Novageração de switches Application Specific Integrated Circuits (ASIC): Intel Flexpipe, Cisco Doppler, Cavium (Xpliant), Barefoot Tofino. • Network Processor Unit (NPU): EZchip, Netronome. • CPU: Open Vswitch, eBPF, DPDK, VPP. • FPGA: Xilinx, Altera. 16
- 17. Rede Programável 17 Contudoa programação dos processadores é difícil. Portanto, é necessário uma linguagem de alto nível que consiga abstrair o plano de dados e permita programar como os equipamentos de rede devem se comportar.
- 18.
- 19. Linguagem P4 • ProgrammingProtocol-independent Packet Processors 19 Proposta Especificação
- 20. Objetivos do P4 •Independência do protocolo ○ Switch não deve ser atrelado à qualquer protocolo de rede ou formato de pacote; • Independência de arquitetura ○ P4 não deve se preocupar com detalhes dos equipamentos de processamento de pacotes (compilador); • Reconfigurável em campo ○ Programadores devem ser capaz de alterar o processamento dos pacotes nos equipamentos de rede mesmo eles já implantados. 20
- 21. Modelo de Encaminhamento21 Generaliza como os pacotes são processados em diferentes equipamentos e em diferrentes tecnologias (PISA, NPU, FPGA).
- 22. Compilador P4 • Compiladorespecífico para cada dispositivo (hw ou sw). • Mapeia a descrição do programa em difinições do equipamento. • Dois estágios da compilação: ○ Programa P4 é convertido em grafos de dependência; ○ Mapeamento para recursos específicos do equipamento; • Versão atual: 16 • Informações: http://p4.org 22
- 23. Programa P4 23 Listade campos ordenados com nome e tamanho. Identificar e extrair os valores dos cabeçalhos. Funções customizadas compostas de ações primitivas. Relação entre os campos dos pacotes e as ações.
- 24. Camada de Dados AtividadePrática 24
- 25. P4 :: AtividadePrática 25 Topologia para Atividade Prática do P4.
- 26. Comandos (1/2) • Compilaro programa P4 e gerar o arquivo do tipo json para o dispositivo "simple_router" conforme os comandos abaixo: ○ cd behavioral-model/targets/simple_router ○ sudo p4c-bmv2 --json simple_router.json simple_router.p4 • Executar o roteador virtual "simple_router" usando o mininet: ○ cd behavioral-model/mininet/ ○ sudo python 1sw_demo.py --behavioral-exe ../targets/simple_router/simple_router --json ../targets/simple_router/simple_router.json 26
- 27. Comandos (2/2) • CLIdo mininet testar o ping entre os dois hosts; ○ > h1 ping h2 • Em um outro terminal, rodar a aplicação para popular as tabelas do roteador. ○ cd behavioral-model/targets/simple_router/ ○ ./runtime_CLI < commands.txt • Testar novamente o ping 27
- 28.
- 29. Definição de SDN29 “OpenFlow is SDN, but SDN is not OpenFlow” ̶̶̶̶̶̶̶̶̶ Networking community (Does not say much about SDN) “Don’t let humans do machines’ work” ̶̶̶̶̶̶̶̶̶ Networking Professional (probably right…) “Let’s call SDN whatever we can ship today” ̶̶̶̶̶̶̶̶̶ Vendor X (aka SDN washing) “SDN is the magic buzzword that will bring us VC funding” ̶̶̶̶̶̶̶̶̶ Startup Y (hmmm… N/A, N/C) “SDN is the magic acronym that will get my paper/grant accepted” ̶̶̶̶̶̶̶̶̶ Researcher Z (maybe but not at tier 1 conferences / funding agencies) Redes cuja infraestrutura física e lógica são separadas em planos de controles diferentes
- 30.
- 31. Características SDN • Redeprogramável, flexível, robusta e simples. • Lógica e o estado da rede estão logicamente centralizados em um controlador SDN ou Sistema Operacional de Rede. ○ OpenDayLight, ONOS, Ryu, POX, NOX ○ Visão abstrata da rede ao mesmo tempo que esconde os detalhes das infraestruturas físicas • Proporciona serviços fim-a-fim, roteamento avançado, balanceamento de carga, funções de firewall, controle de redes ópticas, entre outros. 31
- 32. Arquitetura SDN 32 RESTful,NVP, SDMN
- 33. OpenFlow • Primeiro protocolopadrão OpenFlow • Protocolo que proporciona acesso à tabela de fluxos dos equipamentos de rede e fica entre o controlador e switch. 33 Analisa o tráfego de entrada e verifica regras Controla e gerencia a rede
- 34. OpenFlow 1.0 34 ClassifierAction Modify Field Enqueue Forward NORMAL FLOOD Virtual Port Physical Port Forward Mandatory Action Optional Action Statistics Classifier Action Statistics Classifier Action Statistics Classifier Action Statistics … Ingress Port Ethernet SA DA Type IP SA DA Proto TCP/UDP Src VLAN ID Priority TOS Dst Virtual Port ALL CONTROLLER LOCAL TABLE IN_PORT Drop Tabela de Fluxos
- 35. Evolução do OpenFlow •Limitações do OpenFlow 1.0 ○ Número de campos; ○ Definição de regras mais complexas com múltipas tabelas. 35
- 36.
- 37. OpenFlow :: AtividadePrática 37 Mininet
- 38. Comandos (1/2) • Iniciartopologia (OpenFlow 1.3 e OvS) ○ sudo mn --mac --switch ovsk --controller remote • Iniciar o wireshark na loopback e filtro openflow_v4 ○ sudo su ○ wireshark & • Iniciar o controlador Ryu ○ sudo ryu-manager • Verificar as mensagens OpenFlow • Na CLI do OpenFlow tentar pingar as estações ○ > h1 ping h2 38
- 39. Comandos (1/2) • Inseriras regras no switch ○ sudo ovs-ofctl show s1 ○ sudo ovs-ofctl dump-desc s1 ○ sudo ovs-ofctl add-flow s1 priority=100,in_port=1,actions=output:2 ○ sudo ovs-ofctl add-flow s1 priority=100,in_port=2,actions=output:1 ○ sudo ovs-ofctl dump-flows s1 • Tentar novamente o ping entre as estações • Verificar a vazão entre as estações ○ > iperf h1 h2 39
- 40.
- 41. Contexto • Redes detransporte são complexas ○ Grande variedade de nós proprietários e appliances • Lançar novos serviços é difícil e leva muito tempo • Espaço e energia para os equipamentos ○ Requer ajustes e ser integrados • Operação é cara ○ Equipe especializada ○ Ciclo de vida dos equipamentos 41
- 42.
- 43. Mudanças do NFV43 Source: ETSI NFV ISG – DIRECTION & PRIORITIES – Steven Wright (NFV World Congress 2015) • Funções de rede mais flexíveis • Rápida implantação • Escalonamento dinâmico • Automatização • Orquestração dos serviços • Alocação de funções em locais apropriados
- 44. Opções Alternativas paraVirtualizar 44
- 45. Serviço de Rede45 Uma ou mais VNFs Uma ou mais VMs Detalha as informações e comportamento VNFD
- 46. Arquitetura de ReferênciaETSI 46 Operação e aplicações de negócio Gerenciamento das VNFs em execução Componentes de hardware e software Orquestra os recursos e gerencia o ciclo de vida dos serviços de rede Configuração e gerenciamento do ciclo de vida da VNF Controle e gerenciamento dos recursos do NFVI
- 47.
- 48. Considerações sobre aArquitetura • NFV-MANO não especifica nada sobre SDN em sua arquitetura. • Ele assume que a infraestrutura de transporte já está estabelecida e pronta para uso. • ETSI faz recomendações sobre a arquitetura e não define detalhes técnicos principalmente a serviços de rede fim-a- fim. 48
- 49. Camada de Orquestração AtividadePrática 49
- 50. Tacker • Projeto OpenStack •Implementa NFVO e VNFM • Baseado no ETSI NFV-MANO • Integrado à nuvem OpenStack • Utiliza templates TOSCA ○ Linguagem para descrever a topologia de nuvens, seus componentes e relacionamentos. ○ Automatizar a implantação de aplicações e gerenciamento de ciclo de vida. ○ Utilizado na definição de VNF e Network Service (NS). 50 TACKER
- 51. Passos Iniciais • Embarcara VNF ou NS no framework. • Implantação da VNF pode usar o catálogo do Tacker ou diretamente usando o template VNFD. • Criar as funções virtuais usando os componentes do OpenStack. • A VNFD é gerenciada e configurada via driver de gerenciamento. • O driver de gerenciamento monitora a VNF e em caso de falhas uma mensagem é enviada para a API do Tacker. 51
- 52. Descrição • VNFD eo NSD baseados no TOSCA V1.0 • Escritos YAML • Comportamento e workflow definidos no descritor. • Função: ○ Implantar um roteador OpenWRT como VNF 52
- 53. Comandos (1/2) • Comandopara upload da imagem: ○ openstack image create OpenWRT --disk-format qcow2 --container- format bare --file caminho/Para/Imagem/imagem.img --public • Download do template ○ https://docs.openstack.org/tacker/latest/install/deploy_openwrt.html • Criar uma VNFD no Tacker ○ tacker vnfd-create --vnfd-file tosca-vnfd-openwrt-with-firewall-rules.yaml openwrtVNFD • Criar um VNF a partir do VNFD criado no passo anterior ○ tacker vnf-create --vnfd-name openwrtVNFD openwrtVNF 53
- 54. Comandos (2/2) • Verificaro status ○ tacker vnfd-list ○ tacker vnf-list ○ tacker vnf-show <VNF_ID> • Acessar a máquina virtual criada ○ cat /etc/config/firewall • Para deleter uma VNFD e uma VNF utilizar os comandos ○ tacker vnfd-delete <VNF_ID/NAME> ○ tacker vnf-delete <VNF_ID/NAME> 54
- 55. Desafios e Oportunidadesde Pequisa 55
- 56. Desafios • A áreade programação e virtualização de redes existem muitos desafios que necessitam de atenção da comunidade científica, industrias e órgãos de padronização. • Rede difere do ambiente de nuvem em dois fatores: ○ Cargas de trabalho no plano de dados são extremamente altas o que leva a uma busca constante por alta performance; ○ Requer uma visão geral de toda a topologia para o gerenciamento e estabelecimento de conexões fim-a-fim. 56
- 57. Desempenho • Novas tecnologiastornou o ambiente extremamente virtualizado e baseado em software. • Desempenho é um desafio constante nesse ambiente. • Throughput de switches OpenFlow comerciais varia de 38 a 1000 fluxos por segundos. • Tecnologias como o DPDK,ClickOS e FPGA ○ Suporte aos desafios de desempenho do NFV ○ Novos índices de desempenho 57
- 58. Desempenho 58 Souce: ETSINFV White Paper 2
- 59. Portabilidade • Linguagem P4é independentes de Hardware. ○ Complexidade fica no compilador. • Diferentes implementações de SDN dificultam a portabilidade e a integração. ○ OpenFlow é interface southbound mais utilizada; ○ Interface northbound não é padronizada e com várias soluções. • O ETSI define uma arquitetura de referência NFV porém muitas soluções não possuem interoperabilidade. ○ Não existe uma modelagem de serviços e recursos padrão; ○ Alguns liguagem de modelagem são TOSCA, YANG e HOT; ○ Dificuldade no estabelecimento de serviços fim-a-fim onde múltiplos provedores de serviços necessitam interoperar. 59
- 60. Segurança • Para uminfraestrutura “softwarizada” a segurança é um grande desafio. • Novos recursos e funcionalidades necessitam ser implantadas. ○ Autenticidade, Gerenciamento de Identidade e Controle de Acesso. • Programação de Pacotes ○ Vulnerabilidade das tabelas e metadados. • Prioridade para SDN ○ Evitar ataques cibernéticos • Problemas do SDN ○ Controle da rede logicamente centralizado ○ Interfaces northbound e southbound • Problemas do NFV ○ Segurança na camada de virtualização ○ Comunicação com componentes externos 60
- 61. Integração P4, SDNe NFV • Tecnologias propõem diversas inovações e arquiteturas voltadas para a programabilidade em redes. • Elas são tecnologias complementares. • P4 e SDN são interligadas ○ Não existe uma padronização • SDN e NFV são tecnologias independentes. • Na arquitetura NFV não está claro a definição de SDN. 61 P4
- 62.
- 63. Conclusão • Tradicionais redessão caracterizadas pela forte ligação com hardware fixos e proprietários. ○ Não escalável, inflexível e alto custo de implantação e operação • “Softwarização” de rede ○ Muda como as redes são criadas e operadas ○ Flexibilidade, escalabilidade e automação • Programação do plano de dados ○ Linguagem P4 em crescente ascenção e ampla aplicação • Redes definidas por software ○ Bem consolidada com aporte da ONF ○ Soluções amplas: OpenDayLight e ONOS 63
- 64. Conclusão • NFV aindaestá em fase de padronização com ETSI ○ Muitas soluções estão surgindo desde de ações de operadoras de telecomunicações como da industria e organizações Open Source • ONAP • Tacker • Cloudify • OpenBaton • Todas essas tecnologias apresentam desafios nesse meio tão fértil de novas oportunidades de pesquisa. 64
- 65.
- 66.
- 67.
- 68. Referências/Literaturas • Kreutz, D.,Ramos, F. M., Esteves Verissimo, P., Esteve Rothenberg, C., Azodolmolky, S., & Uhlig, S. (2015). Software- defined networking: A comprehensive survey. Proceedings of the IEEE. • Rostami, A., et al., “Orchestration of RAN and Transport Networks for 5G: An SDN Approach,” IEEE Communications Magazine, April 2017. • Bernardos, C. J., Dugeon, O., Galis, A., Morris, D., and Simon, C. (2015). 5G Exchange (5GEx) – Multi-domain Orchestration for Software Defined Infrastructures. 68
- 69. Referências/Literaturas • Paul Goranssonand Chuck Black, Software Defined Networks: A Comprehensive Approach. Morgan Kaufmann; 1 edition (June 29, 2014) • Bosshart, P., Varghese, G., Walker, D., Daly, D., Gibb, G., Izzard, M., McKeown, N., Rexford, J., Schlesinger, C., Talayco, D., and Vahdat, A. (2014). P4: Programming Protocol-Independent Packet Processors. ACM SIGCOMM Computer Communication Review, 44(3):87–95. • Industry Specification Group (ISG) NFV 2014a] ETSI Industry Specification Group (ISG) NFV (2014a). Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options. 69
Notas do Editor
- #12 Refatorando a pilha