redes de computadoresrodrigo/coe728dir/aula07.pdfopen vswitch • código aberto • utilizado para...

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

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf

Visão Geral da ArquiteturaSDN

4

Figura adaptada de [1]

Visão Geral da ArquiteturaSDN

5


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


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



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



13


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


Envio de Pacotes

por um Cliente –

Fluxo Desconhecido

A B

C


Encapsulamento e

envio para o

Controlador

A B

C


Controlador

configura a Tabela

de Fluxos do

Comutador A

A B

C

F


A B

C

Todos os pacotes do

fluxo que chegam

em A irão para B

F


A B

C

Após definido o fluxo, o

pacote irá para B

F


A B

C

Pacote encapsulado

para o Controlador

F


A B

C

Controlador configura

comutador B com o

fluxo

F

F


A B

C

Fluxo configurado no

Comutador B

F

F


A B

C

Após procedimento

semelhante, C é

configurado

F

F

F


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


• 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


• 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]


55

Controlador

OpenFlow e/ou

gerenciador de DB

do OVS



56

OVS é

remotamente

configurável



57

Armazena

informações

permanentes:

configuração de

comutadores

virtuais, interfaces,

etc.



58

Comutador

propriamente dito,

mesmo papel das

bridges do Linux


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


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


Encaminhamento no Open vSwitch

• Pacotes posteriores do fluxo são encaminhados diretamente pelo kernel

62


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

redes de computadoresrodrigo/coe728dir/aula07.pdfopen vswitch • código aberto • utilizado para...

Documents