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
• Nathan Saraiva
• 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 uma visã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
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
NFV Network
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” de Rede 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 de Rede 11
A "softwarização" de rede definindo as camadas de um sistema de rede
14. Ciclo para Novas Funcionalidades 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ção top-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
• Nova geraçã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
Contudo a 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.
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 Encaminhamento 21
Generaliza como os pacotes são processados em diferentes equipamentos e
em diferrentes tecnologias (PISA, NPU, FPGA).
22. Compilador P4
• Compilador especí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
Lista de 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.
25. P4 :: Atividade Prática 25
Topologia para Atividade Prática do P4.
26. Comandos (1/2)
• Compilar o 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)
• CLI do 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
29. Definição de SDN 29
“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
31. Características SDN
• Rede programá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
33. OpenFlow
• Primeiro protocolo padrã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
Classifier Action
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
41. Contexto
• Redes de transporte 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
43. Mudanças do NFV 43
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
45. Serviço de Rede 45
Uma ou mais VNFs Uma ou mais VMs
Detalha as
informações e
comportamento
VNFD
46. Arquitetura de Referência ETSI 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
48. Considerações sobre a Arquitetura
• 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
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
• Embarcar a 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 e o 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)
• Comando para 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)
• Verificar o 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
56. Desafios
• A área de 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 tecnologias tornou 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
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 um infraestrutura “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, SDN e 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
63. Conclusão
• Tradicionais redes sã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 ainda está 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
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 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