Jednym z kluczowych wyzwań związanych z wdrażaniem sieci definiowanych programowo jest decyzja o wyborze kontrolera – odgrywa on znaczącą rolę w komunikacji pomiędzy aplikacjami sieciowymi a infrastrukturą sieciową. Do tej pory nie powstał jednak żaden model idealnego kontrolera SDN, nie są także określone standardy, jakie powinien spełniać. Projekt OpenDaylight ma to zmienić.

Idea sieci definiowanych programowo jest próbą rozwiązania problemu, w jaki sposób łatwiej zarządzać i szybciej konfigurować sprzęt sieciowy. Jak wiadomo, tradycyjnie urządzenia sieciowe pełnią trzy główne funkcje: pierwsza to określenie reguł traktowania pakietów sieciowych, druga to zarządzanie, czyli dostęp do panelu kontrolnego lub konsoli, a trzecia – przekazywanie pakietów na podstawie wcześniej stworzonych reguł. W sieciach SDN dwa pierwsze zadania zostają przerzucone na kontroler SDN – trzecie jest nadal realizowane przez fizyczne urządzenia sieciowe. Komunikacja pomiędzy kontrolerem SDN a urządzeniem sieciowym jest często określana jako mostek południowy (API Southbound). Przykładem protokołu działającego na tym etapie jest OpenFlow lub Cisco OpFlex. Z mostkiem południowym współpracuje mostek północny (API Northbound), który zapewnia komunikację pomiędzy kontrolerem a aplikacjami użytkownika.

Kontroler SDN pozwala oddzielić transmisję danych od kontroli nad tą transmisją w środowisku sieciowym. Informuje urządzenia sieciowe, w jaki sposób przekazywać ruch, ale nie zajmuje się jego przekazywaniem. Taki scenariusz jest znany z protokołu OpenFlow, gdzie kontroler służy do konfiguracji tablicy OpenFlow, wbudowanej w urządzenie sieciowe. W sieciach OpenFlow urządzenie fizyczne odbiera pakiet i przekazuje go zgodnie z tablicą przepływów, a gdy nie ma informacji o celu danego przepływu, odwołuje się do kontrolera. Kontroler określa, co urządzenie powinno zrobić z przepływem i tworzy konfigurację, którą przesyła do urządzenia. Ten proces jest określany nazwą konfiguracji przepływu. Ilość przepływów na sekundę, jaką kontroler może zrealizować to bardzo istotny parametr. Powiązanie dużej liczby przepływów z dużą ilością urządzeń sieciowych może być dla kontrolera wyzwaniem. Jednak nie każdy przepływ będzie wymagał konfiguracji – te rozpoznane wcześniej nie będą ponownie konfigurowane. Ponadto producenci stosują różne metody ograniczania ilości przepływów. Jedną z nich są tzw. maski, które potrafią powiązać wiele mikroprzepływów w jeden większy. Ułatwia to analizę i przyspiesza konfigurację.

Rozwiązania SDN często są realizowane za pomocą wielu kontrolerów w jednym wdrożeniu. Powstaje pytanie - w jaki sposób kontrolery komunikują się miedzy sobą? Implementacja najczęściej zależy od dostawcy, a najbardziej znane techniki wykorzystują technologię BGP. Większość sieci SDN pracuje jednak z jednym kontrolerem, umieszczonym centralnie. Warto zastanowić się jak dane konfiguracyjne z kontrolera są przesyłane do urządzeń sieciowych. W trybie in-band ruch kontrolny przesyłany jest tymi samymi ścieżkami co normalny ruch. W trybie out-of-band komunikacja kontrolerów z urządzeniami sieciowymi wykorzystuje odseparowaną sieć fizyczną. Tryb in-band jest wykorzystywany przez dostawców, którzy badają awarie w topologii sieci poprzez sprawdzanie dostępności (jeżeli urządzenie sieciowe nie jest osiągalne, kontroler powinien wykryć zmiany i zmienić konfigurację). Drugi tryb jest wykorzystywany przez dostawców zamierzających gwarantować opóźnienia pomiędzy kontrolerem a przełącznikiem, zwiększyć bezpieczeństwo i niezawodność.

Centralny kontroler nie może funkcjonować jako urządzenie fizyczne lub klaster kilku redundantnych urządzeń, realizujących zadania kontrolera. Część dostawców rozprasza jednak funkcje kontrolera pomiędzy rozproszone środowisko wirtualnych maszyn, które komunikuje się i współdzieli jedną bazę danych.