Hardware-Accelerated Network Control Planes

One design principle of modern network architecture seems to be set in stone: a software-based control plane drives a hardware- or software-based data plane. We argue that it is time to revisit this principle after the advent of programmable switch ASICs which can run complex logic at line rate. We explore the possibility and benefits of accelerating the control plane by offloading some of its tasks directly to the network hardware. We show that programmable data planes are indeed powerful enough to run key control plane tasks including: failure detection and notification, connectivity retrieval, and even policy-based routing protocols. We implement in P4 a prototype of such a "hardware-accelerated" control plane, and illustrate its benefits in a case study. Despite such benefits, we acknowledge that offloading tasks to hardware is not a silver bullet. We discuss its tradeoffs and limitations, and outline future research directions towards hardware-software co-design of network control planes

A state consistency framework for programmable network data planes

Tese de mestrado, Engenharia Informática (Arquitetura, Sistemas e Redes de Computadores) Universidade de Lisboa, Faculdade de Ciências, 2021A tecnologia de Rede Definida por Software (SDN – Software-Defined Networking) é um método de gestão de rede que permite um planeamento dinâmico e programaticamente eficiente da mesma, a fim de melhorar o seu desempenho e monitorização. SDN tenta centralizar o cérebro da rede num único dispositivo, desassociando o processo de encaminhamento de pacotes (Data Plane), do processo de roteamento (Control Plane). A constituição do control plane consiste em um ou mais controladores, nomeadamente, aplicações que atuem de forma estratégica, que são referenciadas como sendo o cérebro da rede SDN, onde toda a inteligência é agregada. Esta dissertação foca-se em redes programáveis, o que significa que o programador da rede, pode controlar a forma como um dado dispositivo controla o fluxo de pacotes, por meio de software, sendo executado de forma independentemente do hardware da rede. Dado que a cada dia que passa as SDNs tornam-se cada vez mais importantes, permitindo aos programadores optar por diferentes métodos e formas para desenhar, implementar, e operacionalizar as redes com que diariamente se deparam. Assim, uma ferramenta que permita garantir uma comunicação fidedigna entre os dispositivos de rede, assume um papel cada vez mais relevante. Existe também o objetivo desejável de manter um estado global partilhado entre os dispositivos que constituem a rede. A crescente necessidade de garantir a segurança das redes, que cada vez mais são o veículo de transmissão da informação neste mundo globalizado e por conseguinte a proteção dos dados que nelas circulam, provocam de uma forma global um crescente interesse na atividade dos atacantes. Cada vez mais utilizam ferramentas e conceitos mais sofisticados tentando quebrar ou contornar as regras de segurança na tentativa de obter gratificação pessoal, ou porque, ao existirem melhorias numa nova área, é provável que com a sua introdução, estas insiram novas vulnerabilidades que possam ser exploradas por esses atacantes. Além disso, existe o fato que, no campo das SDNs, muitos propuseram mecanismos de comunicação entre os dispositivos do plano de dados, ou seja, switches, e mesmo entre estes. No entanto, dada a inexistência de uma maneira globalizada para realizar esta comunicação, este trabalho visa propor uma estrutura de consistência de estado que aproveite a abstração de uma máquina de estados, usando atualizações de rede consistentes, entre switches adjacentes, por meio da clonagem de pacotes, oferecida pela linguagem de programação P4 e por piggybacking de pacotes que já se encontravam a circulação na rede. Também é usada uma média movel exponencial ponderada, onde determinada condição é alcançada, e de seguida acionamos o recurso P4, anteriormente mencionado, i.e., acionamos a clonagem de pacotes, garantindo assim que todos os pacotes chegam ao seu destino. Além disso, usamos ferramentas para realizar as verificações bit a bit, considerando que a linguagem P4, ainda carece de uma forma para aceder a partes específicas do pacote que circulam na rede. Também utilizamos uma estrutura capaz de armazenar qualquer tipo de informação, i.e., os registos, nos quais decidimos armazenar todos os dados por nós considerados relevantes e a serem utilizados durante a execução. Concretamente, guardamos toda a informação relativa, tanto aos endereços de origem e ao endereço de destino do pacote, bem como os portos de entrada e os portos de saída do switch. Foi também ponderado o uso de outra linguagem de programação em vez do P4, porém esta outra linguagem, o Domino, não nos oferece a característica principal que é possibilitar a criação novos cabeçalhos, pois este era o objetivo inicial quando a linguagem foi procurada, acabando por ser posto de parte o Domino e a escolha recaiu sobre o P4, como a linguagem de programação para a implementação da ferramenta. Tendo em conta as ferramentas de simulação e de emulação dos casos de teste, á frente apresentados, foram estudadas outras ferramentas, como o NS-3 e o Estinet. Pelo conhecimento prévio e experiência na utilização do Mininet, para simular redes de casos-tipo e atendendo que uma das características chave do Mininet é similar á do NS-3 e ambas têm um mecanismo de virtualização leve, optamos pelo Mininet, pois o Mininet possibilita-nos o uso direto do OpenFlow, sem a necessidade de adicionar extras, ao contrário das outras duas ferramentas atrás referidas, que necessitam de adicionar esses extras, para suportar o uso do OpenFlow. Para a implementação da ferramenta inicialmente, consideramos a utilização um método de pacotes de tipo probe, e depois atentamos uma metodologia baseada em um novo cabeçalho, para implementar a ferramenta ao invés da utilizada, i.e., o piggybacking. Primeiramente, atentamos utilizar pacotes do tipo probe que seriam gerados pelos switches, e conforme acontecessem alterações na rede, e.g., aumentar ou diminuir a quantidade de dispositivos de rede, envisionamos que os pacotes seriam enviados pelo switch e eles continham informação de modo aos switches restantes, poderem ter conhecimento dos eventos. A outra metodologia que atentamos consistia em criar um novo cabeçalho no qual colocaríamos toda a informação que iria ser necessária para o correto funcionamento da ferramenta proposta. Contudo, e após exaustivas tentativas de testes para concretizar a sua implementação, esta apresentou demasiados problemas. Deparamo-nos com o problema fulcral que era saber onde colocar nova informação dentro dos componentes que formam a pilha de cabeçalhos da internet, uma vez que esta, é de uso globalizado e quebrar ou tentar alterar a sua estrutura, significaria que o pacote seria puramente descartado sem a possibilidade de atentar qualquer intervenção nele. Para avaliar a solução proposta, coletamos uma ampla quantidade de informações através de um programa corrido nos emissores e bem como nos recetores dos pacotes e para isso usamos dois cenários de teste distintos. No primeiro cenário, usando uma rede com um pequeno número de dispositivos, mais concretamente, 4 switches e 3 hosts, coletamos o número de pacotes recebidos no destino e o número de pacotes retransmitidos na origem. No segundo cenário, usamos uma rede com um número maior de dispositivos em comparação com o primeiro cenário, ou seja, desta vez a rede seria composta por 8 switches e 4 hosts, e nela coletamos o mesmo tipo de dados, isto é, a quantidade de pacotes recebidos no destino, após o host ter sido reajustado de modo a fazer uso desta nova rede. Também coletamos o número de pacotes retransmitidos na origem. Após uma análise extensa dos resultados obtidos, foi possível verificar que apesar de falhas nos links superiores a 70%, ainda assim conseguimos garantir que mais de 95% dos pacotes chegam com sucesso ao seu destino. Apresentando os resultados com mais detalhe, no primeiro cenário, relativamente ao número de pacotes recebidos no destino, em 75% das execuções realizadas, a nossa solução, assegurou que perto de 100 pacotes chegassem ao seu destino em cada execução. Em referência ao segundo cenário, em 79% das execuções, a nossa solução conseguiu entregar perto de 99 pacotes por execução e que estes alcançaram o seu destino. No que diz respeito ao número de pacotes retransmitidos, nestes encontramos três tipos de retransmissões. As retransmissões normais, que como o nome sugere, são aquelas em que nada de extraordinário acontece, ou seja, os pacotes são simplesmente clonados e são novamente enviados por uma rota alternativa para seu destino. Identificamos também, retransmissões com pacotes espúrios, estas retransmissões são verdadeiramente aleatórias e repetem-se em 1 ou 2 pacotes em todos os enviados. Por último, existem as retransmissões que ocorreram e que foram afetadas pelo problema de congestionamento de pacotes ou ciclos de CPU do PC quando este se encontrava mais congestionado ou ocupado. Nestas circunstâncias os pacotes foram simplesmente marcados, para existir a possibilidade de distingui-los dos restantes. Em referência ao número de pacotes retransmitidos, no primeiro cenário a nossa solução obteve em 75% das execuções, perto de 98 pacotes retransmitidos por cada uma dessas execuções. No segundo cenário, houve uma consistência nos tipos de retransmissões, pois podemos constatar que se mantiveram os mesmos tipos, todavia foi-nos também possível verificar uma diminuição considerável dos tipos de retransmissão com pacotes espúrios e nas retransmissões afetadas pelo problema de congestionamento de pacotes ou ciclos de CPU do PC quando este se encontrava mais congestionado ou ocupado. Pelo que neste segundo senário foi notável um aumento do número de pacotes retransmitidos. Para concluir, este trabalho procurou resolver o problema de inconsistência de informação presente nos dispositivos de rede ou mesmo entre eles, i.e, switches, para isso propomos uma ferramenta que garanta consistência de estado para data planes programáveis e que aproveite a clonagem de pacotes através da aplicação de uma condição ligada á média movel exponencial ponderada e piggybacking usando P4. É notável que mesmo com falhas nos links superiores a 70%, a nossa solução mesmo assim, consegue garantir que 95% dos pacotes que foram enviados, chegam aos seus destinos. Focando-nos no trabalho futuro, poderia ser utilizado o conceito de tuplos para tornar o código mais simples e tornar o acesso a certas partes do pacote ainda mais simples. Para finalizar esta dissertação, contribui uma nova ferramenta que garante consistência de estado para data planes programáveis que nos garante que os pacotes que circulam dentro de uma rede não são perdidos utilizando a clonagem de pacotes através da utilização de uma média movel, também possibilita a utilização de piggybacking através da criação de espaço no pacote que circulam na rede. Por fim, baseado nesta dissertação foi submetido um artigo para uma conferência internacional.The Software-Defined Networking (SDN) technology is a method of network management that allows dynamic, programmatically efficient network planning to improve its performance and monitoring. This dissertation focuses on programmable networks, which means that the network programmer can control how the network devices control packet flows via software that runs independently from network hardware. Given that SDN at each passing day becomes more and more prominent, a framework that can ensure reliable communication and a global state among devices become more and more important. There is also the desirable goal of being able to maintain a global shared state among all network devices. Also, there is the fact that in the field of SDNs, many have proposed communication mechanisms among data plane devices, i.e., switches, and between the latter and the controller. However, given the inexistence of a widespread manner to do so, this work aims at proposing a state consistency framework that leverages on a state machine abstraction using consistent network updates among adjacent switches through packet cloning offered by the P4 programming language and packet piggybacking. We also use a moving average that when a condition is met, such P4 feature is triggered, hence ensuring that all packets arrive at their destination. Also, we use tools to perform bitwise checks, considering that the P4 language lacks ways to access specific parts of a packet. We also use a structure that is capable of storing any type of information, i.e., registers, in which we decide to store the data to be used. To evaluate the proposed solution, we collected a broad amount of information using two scenarios. In the first scenario using a network with a small number of devices, we collect the number of packets received at the destination and the number of packets retransmitted at the sender. In the second scenario this time, using a network with a higher number of devices compared to the first scenario, we collect the same type of data, that is, the number of packets received at the destination after it has been readjusted to mirror this new network structure. We also collect the number of packets retransmitted at the sender. After an extensive analysis of the results obtained, it was possible to verify that despite link failures higher than 70%, we still managed to have more than 95% of packets arriving successfully

Blink: Fast Connectivity Recovery Entirely in the Data Plane

We present Blink, a data-driven system that leverages TCPinduced signals to detect failures directly in the data plane. The key intuition behind Blink is that a TCP flow exhibits a predictable behavior upon disruption: retransmitting the same packet over and over, at epochs exponentially spaced in time. When compounded over multiple flows, this behavior creates a strong and characteristic failure signal. Blink efficiently analyzes TCP flows to: (i) select which ones to track; (ii) reliably and quickly detect major traffic disruptions; and (iii) recover connectivity—all this, completely in the data plane. We present an implementation of Blink in P4 together with an extensive evaluation on real and synthetic traffic traces. Our results indicate that Blink: (i) achieves sub-second rerouting for large fractions of Internet traffic; and (ii) prevents unnecessary traffic shifts even in the presence of noise. We further show the feasibility of Blink by running it on an actual Tofino switch

A Survey on Data Plane Programming with P4: Fundamentals, Advances, and Applied Research

With traditional networking, users can configure control plane protocols to match the specific network configuration, but without the ability to fundamentally change the underlying algorithms. With SDN, the users may provide their own control plane, that can control network devices through their data plane APIs. Programmable data planes allow users to define their own data plane algorithms for network devices including appropriate data plane APIs which may be leveraged by user-defined SDN control. Thus, programmable data planes and SDN offer great flexibility for network customization, be it for specialized, commercial appliances, e.g., in 5G or data center networks, or for rapid prototyping in industrial and academic research. Programming protocol-independent packet processors (P4) has emerged as the currently most widespread abstraction, programming language, and concept for data plane programming. It is developed and standardized by an open community and it is supported by various software and hardware platforms. In this paper, we survey the literature from 2015 to 2020 on data plane programming with P4. Our survey covers 497 references of which 367 are scientific publications. We organize our work into two parts. In the first part, we give an overview of data plane programming models, the programming language, architectures, compilers, targets, and data plane APIs. We also consider research efforts to advance P4 technology. In the second part, we analyze a large body of literature considering P4-based applied research. We categorize 241 research papers into different application domains, summarize their contributions, and extract prototypes, target platforms, and source code availability.Comment: Submitted to IEEE Communications Surveys and Tutorials (COMS) on 2021-01-2