Le lezioni precedenti sono importanti per capire quanto rivoluzioni P4.
Come abbiamo visto i protocolli SDN sono molto utili per controllare la rete in maniera automatizzata, portabile e standard. SDN divide l’infrastruttura in due macro-blocchi: control plane (abbiamo visto RYU e ONOS) e data plane (abbiamo visto Mininet, ma può anche essere hardware).
L’idea delle SDN è che il control plane configura le tabelle di forwarding, e in base alla destinazione (o altri criteri) dice ai nodi come dirigere il traffico. Il data plane invece gestisce singolarmente ogni pacchetto, verifica se c’è una regola (installata dal controller) che matcha quel pacchetto, e fa di conseguenza. Il data plane è quindi completamente passivo e senza potere decisionale.
OpenFlow può essere quindi riassunto come un proocollo che fornisce una regola di forwarding come un insieme di campi di match e un insieme di azioni da fare sul pacchetto in base al match.
Esempio di insieme di regole con relative azioni
Una cosa interessante è proprio il concetto di astrazione match-action, e anche la centralizzazione del controller con una singola entità, che quindi semplifica il control plane.
L’idea di OpenFlow è partita in maniera semplice, ma al tempo era una grandissima innovazione, un po’ come HTTP.
Il problema è che mano a mano che si vuole cercare di fare sempre più cose, e il suo potere espressivo col passare degli anni è diventato sempre meno “al passo”, soprattutto per applicazioni complesse.
Negli anni è stato esteso, ma la dimensione dell’header è aumentata molto (da 12 a 41 campi), e quindi si aggiungono altri problemi.
Un altro problema è che ogni volta che si aggiorna il protocollo OpenFlow, anche l’hardware va cambiato, con una spesa non da poco.
Da questi ragionamenti nasce un’idea: come faccio a prevedere tutte le possibili combinazioni di match/action/funzioni di rete/ecc..? non posso. Quindi si “softwarizza” lo switch. Quindi il metodo con cui lo switch gestisce i pacchetti in entrata e uscita è gestito da un software, con il linguaggio P4, che descrive tutti i possibili match/action con la possibilità di aggiungere operazioni extra.
P4 ci da un metodo standard per programmare l’hardware (gli switch) e un linguaggio portabile tra vari vendors (fino a un certo punto ovviamente).
Con OpenFlow abbiamo quindi il Control Plane (che ha pieno controllo) e lo Switch (che è passivo). Con questo “nuovo” OpenFlow abbiamo un’astrazione intermedia, che ci permette di avere un programma compilato che descrive parser e tables, e dice come tradurre queste regole sul data plane.
New OpenFlow
Abbiamo quindi ora un approccio top-down.
NB: lo scopo espressivo di P4 è l’header, non il payload.