Aula 10 - SDNs - Tendências e Perspectivas

Prévia do material em texto

Redes De�nidas por Software
Aula 10: SDNs - Tendências e Perspectivas
Apresentação
Nas aulas anteriores, apresentamos e estudamos redes SDN que surgiram devido à complexidade e di�culdade de
con�guração das redes tradicionais IP. Assim, a SDN introduziu uma mudança na forma de como os dados podem ser
encaminhados, permitindo maior �exibilidade. Nesta aula, faremos um apanhado das tendências e perspectivas de
SDN/OpenFlow no meio acadêmico e empresarial.
Veremos que, inicialmente, diversos protocolos surgiram e o mais famoso deles é o OpenFlow, que, com o passar dos
anos, recebeu novas versões que agregaram novas funções, em conjunto, logicamente, com maior complexidade. Porém,
o processamento de pacotes nos dispositivos de rede ainda era realizado de forma in�exível, o que limitava a alteração e
inserção de novas funcionalidades.
Devido a essa característica dos dispositivos de rede, uma nova abordagem surgiu: a programação no plano de dados, que
deu origem a uma nova linguagem, chamada P4 (Programming Protocol-independent Packet Processors). Assim,
estudaremos aqui o P4, suas diferenças com o OpenFlow e direções futuras.
Objetivos
Listar exemplos de uso da linguagem P4;
Identi�car a origem da linguagem P4.
 Fonte: Google
 Do OpenFlow à linguagem P4 – Programabilidade do plano de
dados
As redes tradicionais, durantes anos, se mostraram rígidas e �xas aos hardwares em que atuavam. Porém, nos últimos anos,
essa in�exibilidade às mudanças e a não escalabilidade se impuseram como fortes limitantes.
Isso incentivou a pesquisa em novas tecnologias como SDN e a programabilidade do plano de dados. A partir de agora,
veremos esta nova abordagem de programabilidade do plano de dados.
 A ideia original
Quando o OpenFlow foi criado, o que se desejava era uma maneira comum em que o plano de controle pudesse controlar
remotamente vários switches diferentes.
Sua intuição foi que, na maioria das redes, os switches faziam praticamente as mesmas coisas: Ethernet, IPv4, lista de controle
de acesso (Access Control Lists - ACLs), VLANs etc. Assim, se fosse possível de�nir um padrão, ou uma interface (aberta), que
preenchesse tabelas de encaminhamento nesses switches (isto é, tabelas para pesquisa de endereço Ethernet, tabelas de
correspondência de pre�xo mais longo para IPv4 e pesquisas de caracteres curinga para ACLs), seria possível criar um plano
de controle que poderia controlar switches de vários fornecedores diferentes.
Comentário
A ideia era simples. Alguns fornecedores até tinham medo de transformar seus produtos (switches) em commodities e ameaçar
suas margens de lucro, porém o objetivo principal era facilitar a vida daqueles que trabalhavam em redes, favorecendo a operação
no plano de controle.
Segundo McKeown (2016), esta ideia deu certo e incentivou muitos data centers a cosntruírem planos de controle internos
desta forma, ou seja, aplicando a idea de SDNs.
 Como funciona o OpenFlow?
 Clique no botão acima.
Como funciona o OpenFlow?
Voltando ao OpenFlow, devemos nos lembrar que ele, no seu funcionamento, assume que os switches e/ou
dispositivos de rede têm um comportamento �xo e conhecido, geralmente descrito no datasheet e implementado em
seus chips ASIC (Application Speci�c Integrated Circuits).
Datasheet são documentos em que se pode ter informações mais detalhas dos equipamentos e de seus componentes
internos. Um chip ASIC é um circuito integrado (IC) personalizado para um uso especí�co, em vez de ser destinado
para uso geral.
Alguns exemplos de uso são: um chip projetado para funcionar em um telefone celular, em satélite, em um minerador
de Bitcoin etc, ou seja, relacionados à alta e�ciência e uso de�nido.
Os chips tradicionais de alto desempenho suportam um conjunto �xo de protocolos. Dessa forma, implementam
diretamente os protocolos do padrão IEEE (Institute of Eletrical and Electronics Engineers) e IETF (Internet Engineering
Task Force) em sua placa de silício.
A Figura 10.1 ilustra o funcionamento dos equipamentos de redes usando diversos protocolos sob um Sistema
Operacional dedicado ao hardware, e que passa as instruções para o processador ASIC usando um driver.
Assim, não se pode alterar o comportamento deles (chips), adicionar novos protocolos ou novas maneiras de medir e
controlar o caminho de dados (datapath). Uma mudança neste comportamento leva tempo.
Só para se ter uma ideia, hoje em dia leva-se cerca de quatro anos para adicionar um novo protocolo a uma função �xa
no ASIC (MCKEOWN, 2016).
O OpenFlow atua no preenchimento de tabelas do switch. A primeira versão do OpenFlow pode preencher tabelas
apenas para quatro protocolos: Ethernet, VLANs, IPv4, ACLs. Depois, conforme o interesse cresceu, mais tipos de
cabeçalho (com as versões do OpenFlow) foram sendo adicionados, como: IPv6, MPLS (Multiprotocol Label Switching)
e VXLAN (Virtual Extensible LAN).
Atualmente, o OpenFlow permite adicionar e excluir entradas de encaminhamento para cerca de 50 tipos diferentes de
cabeçalhos. Os fornecedores de switches podem informar ao plano de controle quais cabeçalhos suportam usando o
padrão TTP (Table Type Patterns) da Open Networking Foundation (ONF).
Um TTP é um modelo de switch abstrato (�ctício) que descreve o comportamento de encaminhamento especí�co que
um controlador OpenFlow pode programar via protocolo OpenFlow.
O TTP é descrito em um documento que informa as capacidades de processamento de �uxo de um OFLS (OpenFlow
Logical Switch). O sdesenvolvimento desse documento foi motivado por vários fatores, incluindo:
Acomodar melhor a heterogeneidade dos switches existentes.
Permitir a inovação futura em switches.
Permitir a comunicação precisa entre desenvolvedores de aplicativos/controladores e fabricantes de switch.
Como vimos nas outras aulas, o OpenFlow, na realidade, não controla
ativamente o comportamento do switch; ele nos dá uma maneira de
preencher um conjunto de tabelas conhecidas a partir de cabeçalhos.
 Figura 10.1 - O funcionamento de roteadores e switches tradicionais. (SOUSA E ROTHENBERG, 2017)
OpenFlow continuará dando suporte a mais e mais cabeçalhos?
Um problema que preocupa muitas pessoas é se o OpenFlow continuará dando suporte a mais e mais cabeçalhos.
Esse problema surgiu devido a uma propriedade dos chips dos switches, que não são programáveis.
Se eles fossem programáveis, não precisaríamos de um protocolo �xo (como o OpenFlow). Em vez disso,
simplesmente diríamos ao switch como processar pacotes e quais tabelas manter.
Os programadores poderiam de�nir qualquer API que �zesse sentido para preencher as tabelas criadas nos switches.
 Por que os chips dos switches têm função �xa?
Isso se deve ao tempo em que os chips de switches programáveis só podiam processar pacotes a cerca de um décimo ou um
centécimo das taxas especi�cadas.
Atenção
Porém, hoje em dia, existem chips de comutação recon�guráveis no mercado que processam pacotes com a mesma rapidez que
os mais rápidos switches de função �xa. Indo um pouco mais além, pode-se fazer chips de swithes ainda mais programáveis que
rodam tão rápido quanto os switches de função �xa. Esses chips programáveis são chamados de PISA (Protocol Independent
Switch Architecture).
Se os chips PISA programáveis funcionam tão rápido quanto os de
função �xa, então pode-se abrir uma nova era na rede, na qual pode-
se de�nir exatamente como os pacotes são processados nos
switches.
Isso signi�ca que é possível realizar um programação no plano de dados. Se de�nirmos uma linguagem para programar
comutadores rápidos, podemos usar a mesma linguagem para programar comutadores mais lentos, aqueles construídos
usando NPUs, FPGAs ou comutadores de software (por exemplo, vSwitches).
Além disso, seria importante encontrar uma linguagem comum para programar cada switch na rede, assim a interoperabilidade
entre switches seria quase imediata, poderia-se programá-los todos da mesma maneira.
Assim, com esses objetivos em mente, pesquisadores de vários locais,como Google, Intel, Microsoft, Stanford, Princeton,
de�niram a linguagem P4.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Linguagem de programação P4
Um dos principais problemas que a comunidade SDN enfrenta é tentar reduzir o tempo necessário para implementar novos
protocolos ou estender suas funcionalidades.
A demora se dá, em primeiro lugar, porque todo protocolo precisa passar pela diretoria do IETF, que é um longo processo em si.
Depois que um padrão o�cial é de�nido, os projetistas de chip precisam implementá-lo em seus ASICs. Não há garantia de que
não serão necessárias modi�cações no protocolo ao longo do tempo.
Há outro problema signi�cativo, além do fato de que as empresas que operam grandes redes precisam esperar que o hardware
suporte esses protocolos: os fornecedores de chips de rede são os únicos que supervisionam a de�nição de como um
recurso funcionará.
As redes corporativas entendem que não podem ditar seus desejos e, por
isso, �cam presas às soluções impostas pelos fornecedores.
Tradicionalmente as redes foram desenvolvidas por meio de con�gurações �xas, seguindo uma hierarquia do tipo “de baixo
para cima” (bottom-up), em que o software era criado para se adequar às características do processador (hardware). Esse
modelo rígido é extremamente dependente do hardware, e torna difícil a adoção de novas tecnologias de maneira rápida
(SOUSA e ROTHENBERG, 2017).
Assim, nos últimos anos, novas pesquisas têm sido feitas com o objetivo de habilitar a abordagem do tipo de cima para baixo
(top-down), em que o software é quem dita o que deve ser feito para o hardware. Dessa maneira, é possível reprogramar o plano
de dados de forma a disponibilizar novos serviços e funcionalidades, sem a necessidade de se adquirir novos equipamentos.
Como consequência, o que antes era feito em anos hoje pode ser feito em meses, ou até menos (SOUSA e ROTHENBERG,
2017).
 Figura 10. 2 – Abordagem bottom-up à esquerda e top-down à direita (Adaptado de https://P4.org/ )
O surgimento da linguagem P4 é resultado do esforço conjunto da
comunidade para tornar o plano de dados programável e transformar essa
abordagem “de baixo para cima” em uma abordagem top-down, permitindo
que as empresas de�nam como os chips devem tratar/encaminhar pacotes.
P4 (Programming Protocol-Independent Packet Processors) é uma linguagem especí�ca de domínio, para expressar como os
pacotes serão processados pelo plano de dados de um elemento de encaminhamento programável, como um switch (de
hardware ou software), placa de interface de rede, roteador ou dispositivo de rede (P4 Language Speci�cation, 2017).
O P4 fornece ao desenvolvedor um conjunto básico de instrumentos para implementar uma pilha de rede no hardware do
switch. Pode-se operar com abstrações como:
javascript:void(0);
1
Tipos de cabeçalho (conjuntos de campos e seus tamanhos)
2
Analisadores (como os cabeçalhos são organizados, como
distingui-los etc.)
3
Tabelas de associação de chaves de�nidas pelo usuário com
ações
4
Contadores
5
Medidores
 Figura 10.3 – Evolução na programação dos elementos de rede. (KOKHAN, 2018).
 Evolução do SDN
 Clique no botão acima.
Evolução do SDN
A evolução do SDN começou com o desacoplamento de dados e planos de controle e a transferência do plano de
controle do hardware de rede para o software.
O protocolo OpenFlow é um exemplo bem-sucedido dessa abordagem, permitindo a organização de operações de rede
de switch por meio de um controlador centralizado.
A programação P4 é o próximo passo no caminho da evolução, permitindo a de�nição da funcionalidade do dispositivo
fora do próprio dispositivo, enquanto o controle das operações ainda está disponível através da interface P4.
A linguagem P4 não sabe como os cabeçalhos Ethernet ou IP se parecem. O desenvolvedor é aquele que diz ao
hardware (ao silício) qual é o cabeçalho Ethernet e como analisá-lo, combiná-lo, depará-lo (deparse) (construir um
cabeçalho para o pacote de saída), para qual(is) porta(s) encaminhar o pacote etc.
Essa capacidade de programação abre possibilidades inteiramente novas para os negócios:
Flexibilidade da pilha de rede em oposição aos switches tradicionais de função �xa.
Capacidade de atualização, que permite adicionar funções e protocolos aos dispositivos de rede, atualizando o
software P4 executado neles, em vez de comprar novos switches.
 Figura 10.4 – Switches tradicionais vs switches programáveis (P4 specification, 2017).
 O P4 substituirá o OpenFlow?
O OpenFlow é um dos protocolos SDN mais difundidos atualmente. Tem uma infraestrutura estabelecida, comunidade e
controladores trabalhando em cima dele, a�rma Pritsak (2018).
Comentário
Embora seja enganoso ou precipitado pensar que todos abandonarão o OpenFlow e começarão a implantar switches com suporte
P4 em suas redes, ainda há algumas desvantagens signi�cativas no OpenFlow que trabalhadores do data center podem levar em
consideração.
Funções OpenFlow são baseadas em um conjunto de cabeçalhos de protocolo de�nidos no TTPs, que um fornecedor pode ou
não suportar. Além disso, adicionar um novo TTP não é uma tarefa simples, requer grande quantidade de trabalho, bem como o
envolvimento da comunidade.
Isso pode não ser um caso de uso adequado para pesquisa ou ambiente dinâmico em data centers uma vez que os requisitos
estão mudando rapidamente ou até mesmo são desconhecidos. Em vez disso, o P4 permite que o hardware seja programado
de maneira genérica e reimplantado em questão de dias.
Curiosamente, o software OpenFlow também pode ser escrito em P4, o que torna o OpenFlow essencialmente um subconjunto
do que o P4 pode oferecer ao mundo. P4 é uma ferramenta independente de protocolo que pode implementar um pipeline de
switch para qualquer �nalidade e fornecer uma API para um controlador preencher as tabelas.
O problema com o Open�ow é que ele requer uma revisão de especi�cação, enquanto as soluções baseadas em P4 são
mais ágeis e dinâmicas.
 Figura 10.5 – P4 e OpenFlow (PRITSAK, 2018).
 Exemplo de especi�cação em liguagem P
 Clique no botão acima.
Exemplo de especi�cação em liguagem P4
Como exemplo para ilustrar os recursos das arquiteturas, considere implementar um switch simpli�cado em alto nível
em P4.
Vamos primeiro descrever a arquitetura do switch e depois descrever como seria um programa P4 que
especi�casse o comportamento do plano de dados do switch.
Este exemplo foi retirado da especi�cação da linguagem P4 (P4 Language Speci�cation - version 1.0.0), que pode ser
consultada para maiores detalhes.
Esta arquitetura será chamada de Very Simple Switch (VSS), pois trata- se de um exemplo didático. A Figura 10.6 é um
diagrama dessa arquitetura.
O VSS tem vários blocos de funções �xas (mostrados em azul-claro na Figura). Os blocos brancos são blocos
programáveis usando P4.
O VSS recebe pacotes por meio de uma das portas Ethernet de entrada (Packets in), através de um canal de
recirculação (recirculate) ou de uma porta conectada diretamente à CPU.
O VSS tem um único analisador (Parser), alimentando-se em um único pipeline de correspondência de ação (Match-
action pipeline), que é alimentado em um único deparser.
Depois de sair do deparser, os pacotes são emitidos por uma das portas Ethernet de saída ou por uma das três portas
“especiais”:
1) Pacotes enviados para a “CPU port” são enviados para o plano de controle.
2) Pacotes enviados para o “Drop port” são descartados.
3) Pacotes enviados para o “Recirculate Port” são reinjetados no switch através de uma porta de entrada especial.
Os blocos brancos na �gura são programáveis e o usuário deve fornecer um programa P4 correspondente para
especi�car o comportamento de cada bloco. As setas vermelhas indicam o �uxo de dados de�nidos pelo usuário.
Os blocos azuis-claros são componentes de função �xa. As setas verdes são interfaces de plano de dados usadas
para transmitir informações entre os blocos de funções �xas e os blocos programáveis— expostos no programa P4
como metadados.
16
 Figura 10.6 – Exemplo de arquitetura de um switch simplificado implementado em P4. (P4 specification, 2017).
Exemplo de usos do P4
Os casos de uso listados aqui foram retirados de “Is P4 Programming the Future of SDN”.
Clique nos botões para ver as informações.
Temos o P4Runtime, que é um projeto para ativar a autogeração de interface de aplicativo para preencher tabelas P4 via
plano de controle. O P4Runtime é completamente independente de protocolo e independente de fornecedor.
Um exemplo de um dos projetos em andamento envolvendo o P4 é o ONOS (Open Network Operationg System), um
controlador SDN.
O projeto anunciou o suporte do P4Runtime como um protocolo para controlar o pipeline P4 em switches programáveis e
placas de rede. Os dispositivos habilitados para P4Runtime têm capacidade de provisionar pipelines P4 e trabalhar com
tabelas de ação de correspondência por meio de APIs ONOS existentes.
Outro exemplo de uso é em telemetria de rede. O INT (Inband Network Telemetry) é uma estrutura projetada para permitir
a coleta e o relato do estado da rede pelo plano de dados, sem intervenção do plano de controle.
O INT é um bom candidato para a adoção do P4 porque pode mudar com o tempo e exigir extensões. O P4 permite uma
abordagem completamente �exível, permitindo coletar teoricamente qualquer tipo de dados em uma rede.
Os próprios usuários decidem quais dados devem ser anexados e quem deve coletá-los. Usando essa abordagem, é
possível rastrear a rota de um pacote em uma rede, a latência, a ocupação do buffer e muitas outras métricas.
Auxílio a um controlador SDN 
A linguagem P4 pode ser usada para de�nir o padrão de funcionamento, de algum dispositivo, aos fornecedores de
hardware, ou seja, como o hardware deve se comportar.
Um switch de software P4 permite compilar e executar simulações de switches escritas em P4 para desenvolver novos
recursos sem ter nenhum hardware de processamento de pacotes.
Uso em modelo de comportamento 
 Qual o futuro do P4? E do OpenFlow?
 Clique no botão acima.
Qual o futuro do P4? E do OpenFlow?
O P4 está em seus estágios iniciais de adoção, mas já mostra uma dinâmica positiva de interesse entre os
participantes do mercado.
Organizações com conhecimento interno su�ciente para programar chips de rede agora podem transformar seus
switches em qualquer coisa que desejarem. Eles não precisam mais esperar que seu fornecedor de ASIC suporte um
novo protocolo ou altere um parâmetro especí�co.
Isso pode ser feito por meio de inovação interna. Essa �exibilidade resulta potencialmente em custo-benefício,
permitindo que empresas de rede comprem componentes de hardware diretamente de fabricantes originais, sem
recorrer a terceiros.
Mesmo que não seja certo que o P4 torna-se um padrão da indústria, iniciativas de empresas como Google, Microsoft
e outros estão aproximando-o de ser.
O OpenFlow de�nitivamente ainda é útil para redes construídas a partir de uma combinação de switches programáveis 
e switches de função �xa mais antigos que suportam o protocolo OpenFlow. Já existe um programa P4 chamado
“open�ow.P4” que programa um chip PISA para suportar o OpenFlow.
Na linguagem P4, o OpenFlow é um programa. Dessa forma, OpenFlow e
P4 podem trabalhar juntos nas redes. Embora o OpenFlow seja projetado
para redes SDN nas quais separamos o plano de controle do plano de
encaminhamento, o P4 foi projetado para programar o comportamento de
qualquer comutador ou roteador, seja controlado localmente, a partir de
um sistema operacional de comutador, ou remotamente, por um
controlador SDN.
Não há nenhuma razão particular para pensar que o P4 tornará o OpenFlow obsoleto em breve. Há vários ASICs de
comutação de funções �xas no mercado, e muitos deles podem ser controlados usando o OpenFlow.
De fato, à medida que mais TTPs são escritos para chips de comutação de função �xa, há uma boa razão para pensar
que o OpenFlow estará disponível por um tempo.
O P4 oferece uma maneira perfeita de construir redes usando uma combinação de switches programáveis e de função
�xa, e nos permite introduzir novos recursos e protocolos na rede em software, em vez de esperar por um novo
hardware.
Os codi�cadores P4 podem manter esses recursos de diferenciação para si mesmos, em vez de compartilhar tudo
com os fornecedores de chips, através de seus fornecedores, com seus concorrentes.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Conclusão
Em nossa última aula, vimos um pouco sobre uma nova
abordagem que é a programção do plano de dados, que
surgiu graças ao desenvolvimento de chips programáveis do
tipo PISA por serem rápidos em resposta.
Como vimos, esses chips implusionaram o desenvolvimento
de uma nova linguagem chamada P4, que, diferentemente
do OpenFlow que foi desenvolvido para redes SDN, pode
funcionar em qualquer rede.
O P4 não representa o �m do OpenFlow, visto que ambos
podem trabalhar juntos, e pode ter diversos usos. Além de
estar em sintonia com a nova tendência de produção, que
antigamente seguia uma abordagem bottom-up, e
atualmente é do tipo top-down, ou seja, não é o hardware
que impõe como o software dever ser e sim o oposto.
 Fonte: Google
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Atividade
1. Sobre a relação entre OpenFlow e P4, podemos dizer que:
a) O P4 tornou o OpenFlow obsoleto.
b) Não existe como os dois coexistirem em uma mesma rede.
c) Para o P4, o OpenFlow é visto com um programa.
d) No OpenFlow, o P4 é visto como um programa.
e) Nenhuma das anteriores está correta.
2. Podemos citar como uma característica que alavancou o desenvolvimento da linguagem P4:
a) O crescimento do número de acessos a computação em nuvem.
b) O aumento no uso de switches OpenFlow.
c) As mudanças implementadas pelas versões do OpenFlow.
d) O aumento de velocidade dos chips programáveis.
e) A adoção de NetFPGAs.
3. Como benefícios da programabilidade do plano de dados, temos:
a) Rápido ciclo de design, possibilidade de rápida inovação, uso flexível de tabelas.
b) Aumento da complexidade e uso inflexível de tabelas.
c) Adição de novos protocolos e não necessidade de verificação de tabelas pelos switches.
d) Possibilidade de remoção de protocolos que não sejam úteis e uso inflexível de tabelas.
e) Nova telemetria e lento processo de inovação.
4. Não são vantagens da linguagem P4:
a) Eficiência no descarte de protocolos não utilizáveis.
b) Maior nível de visibilidade, devido à possibilidade de criação de rótulos para os pacotes.
c) Uso direcionado a um tipo de hardware, garantindo melhor desempenho.
d) Independência na implementação.
e) Nenhuma das respostas anteriores.
5. São exemplos de chips programáveis que possibilitam a programabilidade do plano de dados:
a) PISA
b) ASIC
c) MIPS
d) RISK
e) MISC
6. Não é uma característica do P4:
a) Funcionar em equipamento com chip programável.
b) Poder funcionar em conjunto com o OpenFlow.
c) A necessidade de conhecer os cabeçalhos que serão tratados pelo equipamento, como os cabeçalhos Ethernet.
d) Diminuir o tempo de atualização.
e) Nenhuma das respostas anteriores.
Notas
Referências
FEFERMAN, D. L.; MEJIA, J. S.; SOUSA, N. F. S. de; ROTHENBERG C. E. Uma Nova Revolução em Redes: Programação do Plano
de Dados com P4. Disponível em: https://intrig.dca.fee.unicamp.br/wp-
content/uploads/2018/08/Minicurso_P4_versao_�nal.pdf. Acesso em: 18 set. 2019.
MCKEOWN, Nick; REXFORD, Jen. Clarifying the differences between P4 and OpenFlow. 2016. Disponível em:
https://p4 org/p4/clarifying-the-differences-between-p4-and-open�ow html Acesso em: 18 set 2019
javascript:void(0);
javascript:void(0);
https://p4.org/p4/clarifying the differences between p4 and open�ow.html. Acesso em: 18 set. 2019.
KOKHAN, Andriy. P4. Disponível em: https://plvision.eu/expertise/sdn-nfv/p4. Acesso em: 18 set. 2019.
ONS. OpenFlow Table Type Patterns - Version N. 1.0, 2014. Disponível em: . Acesso em: 18set. 2019.
PRITSAK, Marian. Is P4 Programming the Future of SDN? 2018. Disponível em: https://plvision.eu/rd-lab/blog/sdn/P4-
programming-future-sdn. Acesso em: 18 set. 2019.
P4.ORG. P4 Language Tutorial. Disponível em: https://P4.org/assets/P4_tutorial_01_basics.gslide.pdf. Acesso em: 18 set. 2019.
P4.ORG. P4-16 Language Speci�cation - Version 1.0.0. The P4 Language Consortium. 2017. Disponível em: https://p4.org/p4-
spec/docs/P4-16-v1.0.0-spec.html. Acesso em: 18 set. 2019.
Próxima aula
Explore mais
Assista ao vídeo Why Does the Internet  Need a Programmable Forwarding Plane with Nick McKeown. Você pode ativar as
legendas do vídeo para facilitar o entendimento.
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);