Control plane: differenze tra le versioni

Versione delle 00:22, 22 dic 2022

Versione attuale delle 04:03, 17 mar 2025

(14 versioni intermedie di 8 utenti non mostrate)

Riga 1:

{{Da controllare|Tecnicamente, il "control plane" è un concetto di rete ben più generale che non si applica solo ai router ma anche ad altri casi di reti in cui i router possono essere anche totalmente assenti, come leil livello ottico delle reti di telecomunicazioni, dove rappresenta il piano logico con cui la rete si autoconfigura instaurando circuiti di traffico o instradamento di frequenze ottiche tramite protocolli appositi, (vedi [[GMPLS]]). Lo stesso si dica per il "management plane" e nonper èil limitato"data alplane", solotermine instradamentopiù diffuso rispetto a "forwarding plane"|informatica|dicembre 2022}}

Nell'ambito dell'instradamento, il '''control plane''' è quella parte dell'architettura di un [[router]] che si occupa di tracciare la [[topologia di rete]], o le informazioni all'interno di una [[tabella di routing]] che definiscono cosa fare con i [[Pacchetto (reti)|pacchetti]] in arrivo. Le funzioni del control plane, come la partecipazione ai [[Protocollo di routing|protocolli di routing]], vengono svolte nell'elemento di controllo architetturale.<ref>{{Cita web|url=https://www.rfc-editor.org/in-notes/rfc3746.txt|titolo=Forwarding and Control Element Separation (ForCES) Framework, RFC 3746, Network Working Group, April 2004}}</ref> Nella maggioranza dei casi, la tabella di routing contiene una lista di indirizzi di destinazione e le interfacce di uscita associate con ciascuno. La logica del control plane può anche identificare alcuni pacchetti che devono essere scartati, così come il trattamento preferenziale di certi pacchetti per i quali è stata definita una [[Quality of Service]] più alta da meccanismi come i [[Differentiated services]].

A seconda della specifica implementazione sui vari router, potrebbe esserci una [[forwarding information base]] separata che viene popolata dal control plane, ma utilizzata dal [[forwardingdata plane]] ad alta velocità per osservare i pacchetti e decidere come maneggiarli.

Nel calcolo dati, il control plane è quella parte di software che configura e spegne il [[data plane]].<ref name="sciencedirect.com">{{Cita pubblicazione|nome=Truong-Xuan|cognome=Do|nome2=Younghan|cognome2=Kim|data=2017-06-01|titolo=Control and data plane separation architecture for supporting multicast listeners over distributed mobility management|rivista=ICT Express|volume=3|numero=2|pp=90–9590-95|lingua=en|accesso=2022-12-21|doi=10.1016/j.icte.2017.06.001|url=https://www.sciencedirect.com/science/article/pii/S2405959517300577}}</ref> Al contrario, il data plane è la parte del software che elabora le richieste di dati.<ref>{{Cita web|url=https://www.networkworld.com/article/3342212/named-data-networking-stateful-forwarding-plane-for-datagram-delivery.html|titolo=Named data networking: Stateful forwardingdata plane for datagram delivery|autore=Matt Conran|sito=Network World|data=2019-02-25|lingua=en|accesso=2022-12-21}}</ref> Il data plane viene a volte chiamato forwarding plane.

La distinzione si è ritrovata utile nel campo del networking all'interointerno del quale si è originata, perchèperché separa gli interessi: il data plane è ottimizzato per la velocità di esecuzione, per la regolarità e la semplicità, il control plane è ottimizzato per la personalizzabilità, la gestione delle policy, la gestione di situazioni eccezionali, e in generale per facilitare e semplificare l'elaborazione del data plane.<ref>{{Cita web|url=https://personal.ntu.edu.sg/|titolo=Nanyang Technological University|sito=personal.ntu.edu.sg|accesso=2022-12-21}}</ref><ref>{{Cita web|url=https://www.profsandhu.com/cs5323_s17/ahmad15.pdf|titolo=Ahmad, Ijaz; Namal, Suneth; Ylianttila, Mika; Gurtov, Andrei (2015). "Security in Software-Defined Networks: A Survey" (PDF). Institute of Electrical and Electronics Engineers. 17 (4): 2317–2342.}}</ref>

La separazione concettuale del data plane dal control plane è un processo che va avanti da anni.<ref>{{Cita pubblicazione|nomename=Truong-Xuan|cognome=Do|nome2=Younghan|cognome2=Kim|data=2017-06-01|titolo=Control and data plane separation architecture for supporting multicast listeners over distributed mobility management|rivista=ICT Express|volume=3|numero=2|pp=90–95|lingua=en|accesso=2022-12-21|doi=10.1016/j.icte.2017.06.001|url=https://www."sciencedirect.com" /science/article/pii/S2405959517300577}}</ref> Uno dei primi esempi è [[Unix]], dove le operazioni di base sui file sono ''open'' e ''close'' per il datacontrol plane, ''read'' e ''write'' per il controldata plane.<ref>{{Cita libro|titolo=Bach, Maurice J. (1986). The Design of the Unix Operating System. Prentice-Hall.}}</ref>

== Costruzione della tabella di routing unicast ==

Riga 47:

È corretto dire che le rotte direttamente connesse saranno sempre preferite. A parte ciò, tuttavia, ci saranno sempre delle differenze.

Gli implementatori hanno generalmente una preferenza numerica, per la selezione delle rotte. Più è bassa la preferenza, più desiderabile è la rotta. L'implementazione di Cisco IOS rende eBGP la sorgente di informazioni di routing dinamico più desiderabile<ref>{{Cita web|url=https://web.archive.org/web/20070118002418/http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfindep.htm|titolo=Configuring IP Routing Protocol-Independent Features|sito=web.archive.org|data=2007-01-18|accesso=2022-12-21|dataarchivio=18 gennaio 2007|urlarchivio=https://web.archive.org/web/20070118002418/http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfindep.htm|urlmorto=sì}}</ref>, mentre per Nortel RS sono più desiderabili le rotte provenienti da OSPF intra-area.<ref>{{Cita web|url=https://web.archive.org/web/20070929090608/http://support.nortel.com/go/main.jsp?cscat=DOCDETAIL&id=436071&poid=9015|titolo=Nortel: Technical Support: Routers & Routing Switches: Ethernet Routing Switch 8600|sito=web.archive.org|data=2007-09-29|accesso=2022-12-21|dataarchivio=29 settembre 2007|urlarchivio=https://web.archive.org/web/20070929090608/http://support.nortel.com/go/main.jsp?cscat=DOCDETAIL&id=436071&poid=9015|urlmorto=sì}}</ref>

In generale, l'ordine per la selezione delle rotte da installare nella tabella di routing è il seguente:

Riga 60:

== Tabella di routing vs Forwarding information base ==

Ciascuna implementazione ha i propri metodi di aggiornare la [[Forwarding information base]] con le nuove rotte installate nella tabella di routing (RIB). Se la FIB è in corrispondenza uno a uno con la RIB, la nuova rotta viene installata nella FIB non appena si trova nella RIB. Se la FIB è più piccola della RIB e la FIB usa una [[hash table]] o un'altra [[struttura dati]] che non può essere aggiornata facilmente, la FIB esistente non verrà più considerata valida e sarà sostituita con una nuova calcolata dalla RIB aggiornata.

{{Vedi anche|Forwarding plane}}

Ciascuna implementazione ha i propri metodi di aggiornare la [[Forwarding information base]] con le nuove rotte installate nella tabella di routing (RIB). Se la FIB è in corrispondenza uno a uno con la RIB, la nuova rotta viene installata nella FIB non appena si trova nella RIB. Se la FIB è più piccola della RIB e la FIB usa una hash table o un'altra struttura dati che non può essere aggiornata facilmente, la FIB esistente non verrà più considerata valida e sarà sostituita con una nuova calcolata dalla RIB aggiornata.

== Tabelle di routing multicast ==

Riga 67 ⟶ 66:

Possono essere configurate delle rotte statiche multicast, oppure possono essere diffuse e apprese attraverso protocolli di routing dinamici multicast come [[Protocol Independent Multicast|PIM]].

== Note ==

<references />

== Voci correlate ==

* [[ForwardingData plane]]

* [[Forwarding plane]]

* [[Management plane]]

{{portale|telematica|ingegneria}}

== Note ==

[[Categoria:Protocolli di rete]]

[[Categoria:ArchitetturaTeorie di Internetdell'informatica]]

[[Categoria:Telecomunicazioni]]