Tutorial presented in the Enucomp 2017 (http://www.enucomp.com.br/2017/) about Network Softwarization (in portuguese).

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

5. INTRODUÇÃO
5

6. Contexto/Motivação 6
@
Infraestrutura das Operadoras de Telecom Source: Ericsson(Adaptado)
Acesso Núcleo Nuvem
OSS / BSS

7. Crescimento do Tráfego Global 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
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

12. Camada de Dados
Conceitos
12

13. Redes Atuais 13
Linux ou Unix

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.

18. Camada de Dados
Linguagem P4
18

19. Linguagem P4
• Programming Protocol-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 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.

24. Camada de Dados
Atividade Prática
24

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

28. Camada de
Encaminhamento/Controle
Conceitos
28

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

30. Evolução com SDN

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

32. Arquitetura SDN 32
RESTful, NVP, SDMN

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

36. Camada de
Encaminhamento/Controle
Atividade Prática
36

37. OpenFlow :: Atividade Prática 37
Mininet

38. Comandos (1/2)
• Iniciar topologia (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)
• Inserir as 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. Camada de Orquestração
Conceitos
40

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

42. NFV 42

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

44. Opções Alternativas para Virtualizar 44

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

47. Projetos Open Source 47

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

49. Camada de Orquestração
Atividade Prá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
• 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

55. Desafios e Oportunidades de
Pequisa
55

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

58. Desempenho 58
Souce: ETSI NFV 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 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

62. Conclusão
62

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

65. Finalizando…. 65

66. “
66

67. Referências
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 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