mercoledì 18 luglio 2012

ABBIAMO BISOGNO SIA OPENFLOW E NETCONF


Ogni volta che scrivo su un caso di semplice utilizzo che potrebbero beneficiare di OpenFlow, ho sempre avere un commento sulla falsariga di " si può fare con netconf ".Ripetuta abbastanza spesso, tali osservazioni potrebbe fare un osservatore esterno credere che tu non hai bisogno di OpenFlow per Software Defined Networking (SDN) , che non è vero. Qui ci sono almeno tre ragioni fondamentali per cui questo è il caso.

Controllo / Data piano di separazione

Se avete bisogno di OpenFlow per SDN dipende ovviamente da come si definisce SDN. I componenti di rete sono state definite dal loro software nel momento in cui è diventato più intelligente di cavi di collegamento singoli host (nel periodo 3705 IBM ha lanciato negli anni Settanta, se non prima), quindi sicuramente non c'è bisogno OpenFlow per implementare rete definita da software.
Tuttavia, lame scherzi a parte, la definizione di SDN come promosso dalla Fondazione Networking aperto presuppone la separazione di controllo e piani di dati, e semplicemente non è possibile farlo con netconf. Semmai, ForCES sarebbe lo strumento giusto per il lavoro, ma non hai sentito parlare molto ForCES dal vostro fornitore preferito, avete ... anche se il suo sviluppo è stata lenta progressione (o meno, a seconda dei punti di vista) per nell'ultimo decennio.

Implementazione di nuove funzionalità

Netconf è un protocollo che consente di modificare la configurazione del dispositivo di rete. OpenFlow è un protocollo che consente di modificare la propria tabella di inoltro. Se è necessario riconfigurare un dispositivo, netconf è la strada da percorrere. Se si desidera implementare nuove funzionalità (qualunque esso sia) che non è facilmente configurabile all'interno del software del dispositivo di rete è in esecuzione, è meglio essere in grado di modificare il piano di inoltro direttamente.
Ci possono essere cose interessanti che si potrebbe fare attraverso la configurazione di rete del dispositivo con netconf (l'installazione di mappe delle rotte con policy-based routing, liste di accesso o MPLS statico in / out Etichetta mappature, per esempio), ma installando le stesse voci tramite OpenFlow sarebbe modo più facile , semplice e (soprattutto) dispositivo e indipendente dal vendor.
Ad esempio, netconf non ha alcun meccanismo standard si può usare oggi per creare e applicare una ACL a un'interfaccia . È possibile creare un ACL su un Cisco IOS / XR / NX-OS o uno switch o router con Junos netconf, ma il contenuto effettivo del messaggio netconf sarebbe vendor-specific. Per supportare i dispositivi realizzati da diversi fornitori, che avrebbe dovuto attuare vendor funzionalità specifiche nel controller netconf. Al contrario, è possibile installare le voci di inoltro stessi (con l'azione DROP) attraverso OpenFlow in qualsiasi OpenFlow-enabled switch (la questione "solo" essere se queste voci saranno eseguiti in hardware o la CPU centrale).

Stato effimero

Protocollo netconf modifica la configurazione del dispositivo. Qualunque cosa configurare con netconf appare nella configurazione del dispositivo e può essere salvato l'esecuzione configurazione permanente (o avvio) uno quando si decide di salvare le modifiche.Potrebbe non vogliamo che ciò accada se tutto quello che vogliamo fare è applicare una temporanea ACL su un'interfaccia o creare un MPLS-TP-like tunnel ingegneria del traffico (calcolato esternamente, non è segnalato tramite RSVP).
OpenFlow voci create nella tabella di inoltro sono per definizione temporanee. Essi non appaiono nella configurazione del dispositivo (e sono probabilmente divertente per risolvere i problemi, perché appaiono solo nella tabella di inoltro) e sono perso su reload dispositivo o la perdita di link.

Possiamo fare a meno netconf?

Considerato tutto quanto sopra, possiamo implementare reti SDN senza netconf?Naturalmente siamo in grado di assumere il scendiamo OpenFlow-unica via, ma gli utenti non molti considerando OpenFlow o venditori sono disposti a farlo ( Google di essere una delle eccezioni ), la maggior parte di loro vorrebbe mantenere le testate sul campo della loro intelligenza dispositivi di rete e aumentare la loro funzionalità aggiuntive configurato attraverso OpenFlow. In un vero network, ci sarà quindi bisogno di entrambi netconf configurare il software esistente in esecuzione in dispositivi di rete (si spera attraverso messaggi standardizzati in un futuro non troppo lontano), e potenzialmente OpenFlow per aggiungere nuove funzionalità quando necessario.


Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.