OF-CONFIG

Když se člověk zabývá novými technologiemi, nevyhnutelně narazí i na standardy a hlavně proces standardizace. Podle encyklopedie je standardizace procesem sjednocení pomocí zavádění standardů. Kolegové zabývající se vývojem vysokorychlostních síťových karet by mohli sami přidat několik historek týkajících se standardizace Ethernetu. Já bych se dnes chtěl ale zaměřit na naši anabázi s protokolem OF-CONFIG a dát tak trochu nahlédnout do toho, jak také může vznikat standard.

OF-CONFIG je protokol, který doplňuje funkcionalitu protokolu OpenFlow. Ten je dnes synonymem pro Software Defined Networking (SDN). Tedy, zjednodušeně řečeno, umožňuje při routování v síti propojit „svaly“ v podobě samotného routery, který jen hloupě přehazuje pakety na svých síťových rozhraních a „mozek“ v podobě kontroleru, který rozhoduje o tom, co mají „svaly“ dělat. Pokud tedy router neví, co s paketem, zeptá se kontroleru právě pomocí protokolu OpenFlow. A OF-CONFIG má sloužit k nastavení toho celého. Tedy například aby router věděl, kde (na jaké IP adrese) má svůj kontroler. O standardizaci obou těchto protokolů se stará Open Networking Foundation (ONF).

Ještě jedna odbočka ohledně standardizačních organizací. Obecně je asi nejznámější takovou organizací Mezinárodní organizace pro normalizaci (ISO), která pak pod sebe sdružuje jednotlivé národní normalizační organizace. Celé to ale samozřejmě není takhle jednoduché, jinak bych tady o tom vlastně ani nemluvil. Vedle ISO existuje celá řada dalších organizací, které se soustředí na konkrétní technickou oblast a jejíchž aktivity se s ISO a často i mezi jimi samotnými více či méně překrývají. Když tedy zůstaneme v oblasti komunikací, máme tu Mezinárodní elektrotechnickou komisi (IEC), Mezinárodní telekomunikační unii (ITU)  nebo Institut pro elektrotechnické a elektronické inženýrství (IEEE). Že už teď je těch organizací hodně? Ještě vůbec nekončíme. Dalším velkým hráčem zejména v prostředí Internetu je Komise pro technickou stránku Internetu (IETF) . Mimochodem, o tom, jak v IETF vznikají standardy podle mručící většiny si můžete přečíst v článku Ládi Lhotky a postřehy z nedávného IETF 94 zase přinesl náš kolega Tomáš Čejka. A zapomenout nesmíme ani na World Wide Web konsorcium (W3C)  pod který obecně spadají technologie spojené s webem. Všichni by mezi sebou samozřejmě měli spolupracovat, jenže ne vždycky věci fungují tak jak mají. Zjistit pak co je v kompetenci té které organizace nemusí být vůbec jednoduché. Například první verze protokolu HTTP byla standardizována v rámci W3C, zatímco dnes nejrozšířenější verze 1.1 je specifikována pod hlavičkou IETF.

Ale zpět k našemu OF-CONFIGu. Z té encyklopedické definice vyplývá, že když vzniká nějaký standard, sjednocuje něco, v našem případě protokoly, co již existuje a používá se. A buď existuje pouze jeden takový protokol, který se také stane normou, nebo je jich víc a pak musí norma sjednocovat. V zásadě pak existují tři cesty, kterými se lze v procesu standardizace vydat. První možností je, že se vybere jeden ze současných protokolů a ten se prohlásí za normu bez ohledu na ostatní a případně se dál vyvíjí. Druhou možností je vzít si konkrétní vlastnosti a nějak je namixovat. Vznikne pak nový protokol, jehož jednotlivé prvky jsou ale ověřeny ve stávajících protokolech, které sjednocujete. Třetí způsob asi vyzní trochu šíleně, ale nejde vůbec o ojedinělý přístup. Prostě se vymyslí kompletně nový protokol. Ten je samozřejmě úplně jiný a lepší, než ty předchozí. Když mě před lety jeden kolega uváděl do prostředí IETF, komentoval to vtipem: „Co se stane, když zavřeš lidi z IETF do místnosti a pár dní je tam necháš? Vymyslí nový protokol.“ Jsem si jistý, že se to dá zobecnit i na další standardizační organizace.

Poslední zmiňovaný postup je ale velmi ošidný. Velmi záleží na tom, od koho vzejde iniciativa k takové standardizaci. Pokud jde o uživatele, kteří si jsou dobře vědomi nedostatků současných přístupů a jsou ochotni nový protokol testovat a vyvíjet, může všechno dopadnout výborně. Pokud ale bude probíhat standardizace od stolu s účastí lidí, kteří problematiku příliš neznají nebo chybí vůle navrhované koncepty uvádět do praxe, je to cesta do pekel. Bohužel právě tohle je případ OF-CONFIGu.

OF-CONFIG vznikl jako doplněk protokolu OpenFlow, protože existovala potřeba konfigurovat některé parametry, které nedává smysl řešit přímo pomocí protokolu OpenFlow. Tuhle potřebu nemělo přímo ONF, ale hlavně uživatelé a vývojáři, kteří OpenFlow přímo implementovali. Dnes nejznámější a nejpoužívanější implementací je Open vSwitch, na jehož vývoji se podílí i někteří z původních Stanfordských autorů myšlenky OpenFlow. Bohužel ale nedošlo ke společnému postupu. ONF vytvořilo specifikaci protokolu OF-CONFIG, ale nemělo implementaci. Open vSwitch měl nejdřív implementaci stejné funkcionality (samozřejmě naprosto odlišné od OF-CONFIGu) a následně došlo dokonce i k vytvoření standardu OVSDB (tedy pouze informativního RFC 7047, ale i tak) pod hlavičkou IETF a naprosto nezávisle na ONF.

OVSDB je principiálně i implementačně o něco jednoduší protokol postavený na JSON-RPC. No a hlavně, existuje referenční implementace. Nijak zvlášť se ale neřeší bezpečnost, včetně autentizace, v případě vzdáleného přístupu. Naopak OF-CONFIG je de facto NETCONF pro konkrétní zařízení. Tedy standardizovaný (opět pod hlavičkou IETF, ale na rozdíl od OVSDB již jako klasický standard) protokol používající pro zabezpečení transportní protokol SSH a jako jedno z rozšíření jsou specifikována dokonce i pravidla řízení přístupu k datům. Jenže pro OF-CONFIG chybí, tedy vlastně chyběla, referenční implementace.

Někteří lidé aktivní v komunitě ONF s tímhle stavem nebyli moc spokojeni. A vzhledem k tomu, že v CESNETu máme dlouholeté zkušenosti s vývojem nejrůznějších nástrojů, byli jsme na konci roku 2013 osloveni, jestli bychom nebyli schopni OF-CONFIG naimplementovat. Byli, jenže v ONF trvalo ještě celý rok, než se oficiálně rozhodla, že něco takového opravdu chce. Naštěstí došlo mezi tím i k jakési drobné podpoře ze strany OVS a dohodě, že OF-CONFIG vytvoříme přímo pro OVS. Vývojář je ale od přírody tvor opatrný, proto bylo nemyslitelné přímo nahradit stávající OVSDB nebo zásadně měnit fungování konfigurace v OVS. Ale domluvili jsme se alespoň na umístění kódu OF-CONFIGu v repozitáři OVS. Tedy na jednoduše dostupném místě pro stávající uživatele OVS.

Na přelomu roku 2014 a 2015 jsme se tak v CESNETu pustili do práce. Jenže už ve fázi návrhu jsme narazili na věci, které prostě nešli implementovat. Jen zmíním, že OF-CONFIG jsme implementovali už ve verzi 1.2. Člověk by tedy předpokládal, že věci budou alespoň trochu odladěné. Jenže my museli řešit například to, že položka, která měla v konfiguraci obsahovat privátní klíč OpenFlow switche ve skutečnosti umožňovala zapsat pouze veřejný klíč. Nebo že při konfiguraci portu nebylo možné určit, které fyzické síťové rozhraní vlastně zrovna konfigurujete. A specifikace obsahovala i další perličky. To vše, jak jsem již zmiňoval, ve verzi 1.2, tedy po několika revizích. Kromě implementace jsme tedy i upravovali samotný standard a sepisovali, co všechno by mohlo být jinak a jak by se to dalo udělat. A neustále jsme opakovali, že než dokončí další revizi OF-CONFIGu, musí ji ověřit fungující implementací.

Na jaře 2015 jsme implementaci OF-CONFIGu pro OVS zdárně dokončili. ONF začala pracovat na verzi 1.3 podle našich připomínek a my jsme na podzim dostali ocenění za významný technický přínos pro ONF. Šťastný konec, chtělo by se napsat. Jenže zájem o OF-CONFIG v OVS po prvním ohlasu zase upadá a ONF nedělá nic pro vybudování životaschopné komunity uživatelů a vývojářů. Práce na nové verzi 1.3 stále pokračuje, jenže změny ve specifikaci se dělají pouze na papíře. Implementovat se asi začne zase, až bude specifikace „hotová“. Ale snad je to výjimka právě u OF-CONFIGu. Obecně lze totiž v ONF sledovat změny a celá organizace se odklání od pouhého sepisování standardů spíše k podpoře a vytváření open source projektů pro SDN technologie.

Radek Krejčí