Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Redes de Computadores
SDN: SouthBound Interface
Prof. Rodrigo de Souza Couto
Bibliografia• Esta aula é baseada nos seguintes trabalhos:
– [1] Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo, Christian Esteve Rothenberg, SiamakAzodolmolky, Steve Uhlig. Software-DefinedNetworking: A Comprehensive Survey. Proceedings ofthe IEEE, 2015.
– [2] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, I. Peterson, J. Rexford, S. Shenker, J. Turner. “OpenFlow: Enabling Innovation in Campus Networks”. ACM SIGCOMM Computer Communication Review, 2008.
– [3] Adrian Lara, Anisha Kolasani, ByravRamamurthy.Network Innovation using OpenFlow: A Survey. IEEE Communications Surveys & Tutorials, 2014.
2
Bibliografia
• Esta aula é baseada nos seguintes trabalhos:– [4] Especificação do OpenFlow v1.0.0
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf
– [5] B. Paff and B. Davie. The Open vSwitch Database Management Protocol. Internet Engineering Task Force, RFC 7047 (Informational), 2013.
– [6] Open vSwitch Deep Dive The Virtual Switch for OpenStack. https://www.youtube.com/watch?v=x-F9bDRxjAM
3
Visão Geral da ArquiteturaSDN
4
Figura adaptada de [1]
Visão Geral da ArquiteturaSDN
5
Figura adaptada de [1]
Southbound Interface
Plano de Dados:Southbound Interface
• É a ponta que conecta o Plano de Controle ao Plano de Dados– Elemento crucial para prover a separação entre os
planos
• Também chamada de Southbound API
6
OpenFlow
• Southbound API mais utilizada em SDNs
• Padrão aberto– Diferentes fabricantes podem implementá-lo em seus
comutadores
• Inicialmente proposto para experimentos acadêmicos
– Redes de universidades
– Ideia de configurar fluxos para separar tráfego de produção de tráfego experimental
• Industria posteriormente começou a adotá-lo para aumentar a funcionalidade da rede, mas reduzindo custos e complexidade do hardware
7
OpenFlow
• Sistemas Operacionais de Rede (NOSs) o utilizam para configurar os comutadores da rede– Diferentes tipos de mensagem podem ser trocados
• Provê três fontes de informação para os Sistemas Operacionais de Redes– Mensagens baseadas em eventos
• Enviadas pelos comutadores para indicar mudanças na rede (p.ex. enlace se desconectou)
– Estatísticas para cada fluxo• P.ex. número de bytes e pacotes enviados
– Mensagens enviadas ao controlador quando novo fluxo é detectado
8
Versões do OpenFlow
• Versão 1.0.0 - 2009– A mais utilizada atualmente
• Versão considerada nos próximos slides, quando não mencionado diferente
• Versão 1.1.0 – 2011
• Versão 1.2 – 2011
• Versão 1.3.0 – 2012
• Versão 1.4.0 – 2013
• Versão 1.5.0 – 2014
• Versão 1.6 – 2016
9
Componentes de um Comutador OpenFlow
• Tabela de fluxos– Lista de ações
correspondentes
• Canal Seguro
– Conexão entre comutador e Controlador
• Protocolo OpenFlow
10
Figura adaptada de [2]
Implementação da Tabela de Fluxos
11
Plano de Dados Específico do Fabricante
OpenFlow foi idealizado para poder ser implementado com apenas com atualizações de firmware do fabricante
Figura adaptada de [3]
Implementação da Tabela de Fluxos
12
Plano de Dados Específico do Fabricante
OpenFlow foi idealizado para poder ser implementado com apenas com atualizações de firmware do fabricante
Abstração para
o Controlador
Figura adaptada de [3]
Implementação da Tabela de Fluxos
13
Figura adaptada de [3]
Definição de fluxos no OpenFlow v.1.0.0
Porta de Entrada
MAC de Origem
MAC de Destino
Ether Type
VLAN id
VLAN priority CoS
IP de Origem
IP de Destino
IP Proto
IP ToS bits
Porta de origem TCP/UDP
Porta de destino TCP/UDP
14
• Campos do protocolos
dos pacotes
• 12 possíveis campos
• Podem ser utilizados
um ou mais campos
• O fluxo não precisa
ser definido por
todos os campos
Tabela adaptada de [3]
Algumas ações de umcomutador OpenFlow v.1.0.0
• FORWARD (encaminhar)– Porta física específica
– ALL• Envie o pacote para todas as interfaces, à exceção
daquela na qual o pacote chegou
– CONTROLLER• Encapsule o pacote e mande-o para o Controlador
• DROP (descartar)
• ENQUEUE (enfileirar – função opcional)
– Envia o pacote para uma fila ligada a uma porta• Utilizado para fins de QoS
15
Algumas ações de umcomutador OpenFlow v.1.0.0
• MODIFY-FIELD (modifica algum campo do cabeçalho – função opcional)– IP de origem/destino
– MAC de origem/destino
– Porta de origem/destino
– Entre outras...
16
Apesar de não ser obrigatória,
aumenta as funcionalidades
possíveis de um comutador
OpenFlow.
Exemplos de Estatísticas
• Por tabela– Entradas ativas
– Correspondências de pacotes
• Por fluxo– Bytes enviados
– Pacotes enviados
– Duração (segundos)
• Por porta– Bytes recebidos
– Bytes transmitidos
– Erros de recepção
– Erros de transmissão
17
Exemplos de Estatísticas
• Por fila– Pacotes transmitidos
– Bytes transmitidos
18
Canal Seguro
• Interface que conecta cada comutador ao Controlador– Envio de configurações,
pacotes e notificações de eventos
• Comunicação do Canal Seguro com datapath do comutador pode ser específica para cada fabricante
– Entretanto mensagens devem seguir o protocolo OpenFlow
19
Mais detalhes do protocolo e
de outras informações do
canal seguro serão vistas
adiante no curso
Processamento de Pacotes noOpenFlow v.1.0.0
1- Quadro Ethernet entra no comutador e é analisado
2 - Cabeçalhos do quadro são extraídos e geram um packet lookup header
• Conjunto de todos os cabeçalhos extraídos
3 - Packet lookup header é enviado para um sistema que realiza a correspondência dos quadros
4- O Packet lookup header é comparado com as regras da tabela de fluxos
• Regras são colocadas em ordem decrescente de prioridade na tabela
– Primeira regra encontrada será executada
20
Processamento de Pacotes noOpenFlow v.1.0.0
5A – A lista de ações referente a regra encontrada é executada
5B – Se não foi encontrada nenhuma regra para os cabeçalhos selecionados, os primeiros 200 bytes do quadro são enviados ao Controlador
• Controlador decide o que fazer com o pacote e instala novas regras no Comutador
21
Exemplo de interação com um Controlador
Exemplo de interação com um Controlador
Envio de Pacotes
por um Cliente –
Fluxo Desconhecido
A B
C
Exemplo de interação com um Controlador
Encapsulamento e
envio para o
Controlador
A B
C
Exemplo de interação com um Controlador
Controlador
configura a Tabela
de Fluxos do
Comutador A
A B
C
F
Exemplo de interação com um Controlador
A B
C
Todos os pacotes do
fluxo que chegam
em A irão para B
F
Exemplo de interação com um Controlador
A B
C
Após definido o fluxo, o
pacote irá para B
F
Exemplo de interação com um Controlador
A B
C
Pacote encapsulado
para o Controlador
F
Exemplo de interação com um Controlador
A B
C
Controlador configura
comutador B com o
fluxo
F
F
Exemplo de interação com um Controlador
A B
C
Fluxo configurado no
Comutador B
F
F
Exemplo de interação com um Controlador
A B
C
Após procedimento
semelhante, C é
configurado
F
F
F
Exemplo de interação com um Controlador
Pacotes do Fluxo são
encaminhados sem a
utilização do
Controlador
F
F
F
OpenFlow 1.1.0Algumas características
novas• Mais de uma tabela de fluxo
– Processamento em pipeline• Tabelas de fluxo operam em cadeias
• Quando pacote chega no comutador, é enviado para a primeira tabela do pipeline
• Se a entrada apontar para outra tabela, pacote é enviado para essa tabela
• Lembre-se: cada tabela de fluxo é implementada em hardware. Assim, o pipeline pode melhorar o desempenho do comutador
• Tabela de Grupo
– Realiza operações comuns múltiplos fluxos
33
OpenFlow 1.1.0Comutador OpenFlow
34
OpenFlow 1.1.0Definição de fluxo
35
Porta de Entrada
MAC de Origem
MAC de Destino
Ether Type
VLAN id
VLAN priority CoS
IP de Origem
IP de Destino
IP Proto
IP ToS bits
Porta de origem TCP/UDP
Porta de destino TCP/UDP
Metadados
MPLS Label
MPLS EXP traffic class
Suporte a MPLS
Campo de metadados é
utilizado para passar
informações entre as
tabelas do pipeline
Tabela adaptada de [3]
Outras versões
• OpenFlow 1.2– Suporte a IPv6
– Possibilidade de conectar um comutador a múltiplos controladores
• Recuperação rápida de falhas
• Balanceamento de carga
• OpenFlow 1.3
– Possibilidade de controlador a taxa de pacotes por fluxo
36
O OpenFlow é especificação,protocolo ou arquitetura? [3]• Especificação
– Um comutador OpenFlow é construído seguindo o padrão especificado
• Protocolo
– Comunicação entre o comutador e o controlador
• Arquitetura
– Demais componentes para o OpenFlow funcionar• P.ex. controladores
– Confusão entre OpenFlow SDN• OpenFlow não é SDN! OpenFlow é uma (dentre muitas)
formas de os componentes se comunicarem numa SDN
37
PROTOCOLO OPENFLOW
Computadores Digitais II–DETEL-FEN/UERJ Prof. Rodrigo de Souza Couto
Tipos de Mensagem
• Controlador para comutador
• Assíncronas
• Simétricas
39
Mensagens do Controlador para o Comutador• Features
– Enviada no momento da conexão com o comutador
– Solicitação das funcionalidades suportadas pelo comutador
• Lembre-se, nem todas as funcionalidades são obrigatórias
• Configuration
– Envio de configurações
• Modify-state
– Objetivo principal de adicionar e deletar fluxos
• Read-state
– Coleta de estatísticas
40
• Send-packet– Envio de pacotes pelo controlador na rede, saindo de uma
porta específica do comutador
• Barrier
– Quando comutador recebe essa mensagem, processa todos os pacotes que foram recebidos antes dela, esperando para processar as mensagens recebidas posteriormente
• Mensagens subsequentes à barrier são enfileiradas
• Após processamento das mensagens anteriores, envia-se confirmação ao controlador
– Utilizada pois o comutador pode processar arbitrariamente mensagens de modificação de estado
41
Mensagens do Controlador para o Comutador
Mensagens Assíncronas
• Mensagens enviadas pelo comutador sem a solicitação do controlador
• Packet-in– Enviada quando não há uma entrada (fluxo)
correspondente a um pacote recebido
– Também utilizada quando o pacote corresponde a uma entrada com ação “enviar para controlador”
– Mensagem possui uma fração do pacote recebido• Caso comutador não possua espaço em buffer, pacote é
enviado por completo
42
Mensagens Assíncronas
• Flow-removed– Avisa remoção de um fluxo
– Disparada quando• Idle timeout: após um certo período no qual nenhum
pacote corresponde ao fluxo
• Hard timeout: após um certo período pré-definido
• Controlador envia mensagem de remoção de fluxo
– Ao instalar um fluxo, controlador pode desabilitar a necessidade futura de envio de um flow-removed
43
Mensagens Assíncronas
• Port-status– Enviada quando o estado de uma porta é alterado
• P.ex. quando a porta é desabilitada
• Error– Utilizada para notificar erros
• P.ex. problemas modificando fluxos
44
Mensagens Simétricas• Enviadas sem solicitação, em ambas as direções
• Hello– Enviada por ambos os lados no estabelecimento de
conexão
– Informa a maior versão suportada por cada um• Utilizada para negociação de versão
• Echo
– Ao emitir um “echo request”, espera-se um “echo reply”
– Utilizada para indicar latência, banda disponível e existência da conexão entre o comutador e o controlador
• Vendor– Envia dados específicos de um fabricante
– Utilizada para adicionar funcionalidades
45
Estabelecimento de Conexão
• Estabelecimento do canal seguro TLS (TransportLayer Security)– Protocolo que permite privacidade e integridade dos
dados de uma conexão
• Comutador se conecta a um Controlador utilizando um endereço IP e porta (TCP)
46
Estabelecimento de Conexão
• Tráfego pelo canal seguro não é verificado na tabela de fluxo– Comutador deve verificar se tráfego é “local” antes de
verificar a tabela de fluxos
• Imediatamente após estabelecimento da conexão, HELLOs são enviados por ambas as partes
– Escolha da versão do OpenFlow a ser utilizada• Escolhe-se a menor versão informada
47
Interrupção de Conexão
• Perda de conexão com o controlador– Falha de um “echo request”
– Timeout da sessão TLS• Sessão segura entre controlador e comutador
– Outros tipos de desconexão
• Comutador deve tentar se conectar com controladores de backup
• Se as tentativas de contactar algum controlador falharem, comutador entra no modo de emergência– Utilização de um conjunto pré-definido de fluxos
– Demais entradas são removidas
– Na primeira vez que um comutado inicia, esse se encontra no modo de emergência
48
Implementações do OpenFlow
• Hardware compatível com OpenFlow– Diversos fabricantes suportam
• Cisco, NEC, HP, Juniper, Dell, etc.
• Simulação com o Mininet– Instalado em PCs comuns
– Utilizado para simular múltiplos nós em uma única máquina virtual
49
Implementações do OpenFlow
• NetFPGA– “Placa de Rede” programável
• Comutadores de software– Executa todos as funções por software
• Baixo custo (grátis em alguns casos)
• Pior desempenho que soluções por hardware
– Podem ser instalados em PCs comuns
– Open vSwitch é um dos mais utilizados• Plataforma gratuita
50
Open vSwitch
• Código Aberto
• Utilizado para prover redes entre máquinas virtuais em uma mesma máquina física– Mas também pode ser utilizado entre as máquinas
virtuais e o mundo externo
– Mais detalhes na parte de Computação em Nuvem
• Permite a criação de diversos comutadores virtuais em uma máquina física
51
Exemplo de Uso
52
Criação de redes
virtuais entre VMs
(Virtual Machines –
Máquinas Virtuais)
Exemplo de Uso
53
Comutadores
(switches) virtuais
são também
chamados de
bridges virtuais
Open vSwitch:Arquitetura
54
Figura adaptada de [5] e [6]
Open vSwitch:Arquitetura
55
Controlador
OpenFlow e/ou
gerenciador de DB
do OVS
Figura adaptada de [5] e [6]
Open vSwitch:Arquitetura
56
OVS é
remotamente
configurável
Figura adaptada de [5] e [6]
Open vSwitch:Arquitetura
57
Armazena
informações
permanentes:
configuração de
comutadores
virtuais, interfaces,
etc.
Figura adaptada de [5] e [6]
Open vSwitch:Arquitetura
58
Comutador
propriamente dito,
mesmo papel das
bridges do Linux
Figura adaptada de [5] e [6]
Bridges do Linux
• Linux possui mecanismo que permite implementação de comutadores de software– Bridge-utils
• Funcionalidades das bridges do Linux– Simples encaminhamento
• Verificação no MAC do quadro e posterior encaminhamento
– Aprendizado de MAC
59
Encaminhamento nabridge do Linux
• Como encaminhamento é simples, pode ser realizado diretamente a nível de kernel– Melhor desempenho
60
Figura adaptada de [6]
Encaminhamento no Open vSwitch
• Como possui funções mais avançadas, decisão de encaminhamento deve ser feita antes, no modo usuário– Primeiro pacote do fluxo passa pelo ovs-vswitchd
61
Figura adaptada de [6]
Encaminhamento no Open vSwitch
• Pacotes posteriores do fluxo são encaminhados diretamente pelo kernel
62
Figura adaptada de [6]
Open vSwitch:Protocolos de Controle
63
OpenFlow é
utilizado para
configuração de
fluxos
Open vSwitch:Protocolos de Controle
64
OVSDB é utilizado
para
gerenciamento dos
comutadores
(bridges) virtuais
OVSDB (Open vSwitch Database Management Protocol)
• Utilizado para configuração e gerenciamento de instâncias OVS
• É também considerado como uma SouthboundInterface
• Complementar ao OpenFlow na arquitetura do OVS– Trabalha em uma escala de tempo maior que a do
OpenFlow
65
Exemplos de Operações realizadas pelo OVSDB
• Criação, remoção e modificação de bridges
• Configuração do conjunto de Controladores aos quais o OpenFlow deve se conectar
• Criação, modificação e remoção de filas nas bridges
• Configuração de políticas de QoS e anexação dessas políticas às filas
• Coleta de Estatísticas
66
ForCES(Forwarding and Control
Element Separation)• Outra Southbound interface
• Proposta antes do OpenFlow para separar plano de dados do plano de Controle– Início da padronização pelo IETF em 2003
• Plano de controle ainda é distribuído– Por exemplo, cada elemento de rede pode ter seu plano
de controle
– Não muda a arquitetura da rede, como o OpenFlow• Mudança é apenas nos elementos de rede
67
ForCES(Forwarding and Control
Element Separation)• Padroniza a comunicação entre plano de dados e plano
de controle– Assim como o OpenFlow
• Não necessita mudar a arquitetura tradicional de rede– Elementos de rede com o ForCES podem ser comunicar
com elementos de rede tradicionais• Plano de controle distribuído
• Adoção bem menor que o OpenFlow
68
Objetivo do ForCES
• Plano de dados pode ser desenvolvido independentemente do plano de controle– P.ex., fabricantes diferentes
– Atualização do plano de controle pode ser mais simples do que nas redes tradicionais
• Entretanto, mais complexa do que do OpenFlow, no qual o plano de controle é logicamente centralizado
– Cada plano pode ser executado por um equipamento distinto
69