Pomsta za Internet?

Síťové sekci konference Intel European Research and Innovation Conference 2013 (program) jednoznačně vévodily dvě zkratky: SDN (Software Defined Networking) a NFV (Network Functions Virtualization). O SDN jsem už na tomto místě psal a na další příspěvek se chystám v souvislosti s účastí CZ.NIC v FP7 projektu NetIDE.

O virtualizaci síťových funkcí přednášeli především zástupci velkých telekomunikačních operátorů (Telefónica, Verizon) a firem, které jim navrhují infrastrukturu a dodávají služby. Mně osobně daly jejich příspěvky možnost nahlédnout pod pokličku sítí 4G LTE, o nichž, přiznám se, jsem toho dosud mnoho nevěděl. Ne že bych byl teď o mnoho moudřejší, ale jeden základní dojem jsem si přece jenom odnesl – tyhle sítě jsou v porovnání se standardním Internetem pekelně složité. Už jen ta záplava zkratek, namátkou: OSS, BSS, HSS, MME, PCRF, OTT, BRAS, SGSN, GGSN, VAS … Virtualizace je pak celkem pochopitelně jednou z cest, jak tento moloch zvládnout.

Přemýšlel jsem o tom, kde se ta složitost vlastně bere. Zčásti jde jistě na vrub známých nedostatků v reálném Internetu, jakými jsou třeba nefungující multicast či chabá podpora mobility. Hlubším důvodem je ale podle mého známý end-to-end princip, na němž jsou protokoly TCP/IP postaveny, tedy v podstatě hloupá a ne zcela spolehlivá síť, jež funguje díky tomu, že pokročilejší funkce jsou soustředěny v koncových stanicích. Je jasné, že v takové best-effort síti je obtížné nabízet zákazníkům diferencované služby a podle toho je pak také kasírovat.

Když tedy technologičtí experti předestírají vize budoucího Internetu jakožto sítě chytrých telefonů a jiných mobilních zařízení, musíme si uvědomit, že se nejedná jen o osvobození od kabelů, ale dost možná taky o podstatné změny v architektuře globální sítě – bude to vlastně ještě Internet, jak jej dnes známe?

Ladislav Lhotka

Je email mrtvý?

Nedávno vystoupil v Hyde Parku na ČT24 Luis Suarez, ovšem nikoliv útočník FC Liverpool, ale, jak pravil moderátor, vizionář ve službách IBM. Jeho vize je v kostce tato: zahodit email a pro veškerou komunikaci používat sociální sítě. Jsem dalek toho, abych panu Suarezovi takový systém rozmlouval, pokud mu (zatím) funguje, těžko však mohu souhlasit s tím, když je prezentován jako obecný návod pro širokou veřejnost.

Stinné stránky sociálních sítí jsou již dostatečně známé. Pomineme-li ty, které si uživatelé sami způsobují svým neopatrným chováním, nejvážnějším problémem je fakt, že se profily osob a skupin, jakož i veškerá jejich komunikace, soustřeďují v rukou provozovatele sociální sítě. Ten pak z těchto dat může zajisté těžit informace pro různé účely, v lepším případě komerční. Email je naproti tomu stále velmi distribuovaná služba a každý její uživatel má možnost, aspoň principiálně, rozhodovat o tom, komu svá data a texty poskytne.

Zdá se však, že pro mnoho uživatelů se email stává docela obtížným břemenem, a tak snáze podléhají představě, že v silu sociální sítě jim bude líp. Možná si řeknete: no jasně, spam. Já si ale myslím, že běžný spam je docela dobře řešitelná záležitost a pro průměrného uživatele představuje jen okrajový problém.

Mnohem větším uměním je vyrovnat se s tím, co zbude po odfiltrování spamu, tedy se zprávami, které lze v podstatě považovat za legitimní. Znám řadu lidí, třeba i jinak dobře organizovaných, kteří s sebou jako kouli na noze táhnou inbox zvíci tisíců zpráv. Podle svého naturelu se tím pak zbytečně stresují anebo nereagují ani na důležité maily (případně obojí).

Dostupné technologie jim s tím bohužel příliš nepomohou. Běžní mailoví klienti typu GUI jsou zbytnělé kusy softwaru, které při práci s opravdu velkými mailovými archivy buď rovnou kolabují anebo se nesnesitelně zpomalí. Nástroje pro klasifikaci zpráv, vyhledávání apod. také obvykle nejsou na úrovni doby. Je charakteristické, že uživatelsky nejpříjemnější a technologicky nejpokročilejší jsou zase centralizované služby typu GMail. Jiné alternativy, jako je například projekt Notmuch, jsou stále v počátcích a pro řadového uživatele jen obtížně použitelné.

Otázka, jíž je nadepsán tento příspěvek, je možná sugestivní a odpověď je zatím naštěstí záporná. Zatím… Nejde snad tolik o mail jako takový, ale o princip distribuované aplikace, kterou nemá nikdo konkrétní plně v rukou. Mně se do sila nechce.

Ladislav Lhotka

Poslední výzva pro datové modely

Předseda pracovní skupiny NETMOD při IETF vyhlásil poslední výzvu (Working Group Last Call) pro tři Internet Drafty:

Tyto dokumenty obsahují specifikaci tzv. základních (core) datových modelů v jazyku YANG pro použití především s protokolem NETCONF. První z nich definuje konfigurační a stavová data síťových rozhraní a druhý k tomu přidává základní parametry IPv4 a IPv6. Třetí z dokumentů je pak zaměřen na IP směrování – kromě obecně potřebných parametrů vytváří i rámec, do něhož budou zasazeny budoucí datové modely směrovacích protokolů, route filtrů apod.

Zmíněné tři základní datové modely obsahují skutečně jen elementární parametry, které potřebuje téměř každé síťové zařízení. Jejich vývoj přesto nebyl úplně hladký, především proto, že jedním z hlavních požadavků byla kompatibilita s konfiguračními rozhraními (CLI) předních výrobců, tj. v první řadě Cisco Systems a Juniper Networks. Na tomto místě snad mohu přiznat, že jsem též přihřál naši polívčičku a při návrhu datového modelu pro směrování zohlednil i způsob konfigurace démona BIRD.

Právě proto, že jde o základní a široce použitelné věci, je velmi důležité, aby v těchto datových modelech nebyly žádné podstatné vady. Dovoluji si proto požádat všechny experty, kteří čtou tento příspěvek, aby se na uvedené dokumenty podívali. Pokud by zjistili nějaké nesrovnalosti, mohou je napsat buď přímo do mailing listu pracovní skupiny NETMOD, anebo jednoduše jako komentář k tomuto příspěvku – já bych je potom předal dále. Poslední výzva končí v pátek 30. listopadu, připomínky bude ale možné zapracovat i po tomto datu. Předem díky!

Ladislav Lhotka

Z IETF 84: Interface to the Routing System

Novou zkratkou, kterou bylo často slyšet v kuloárech vancouverského meetingu IETF, je IRS. Cílem této iniciativy je, jak už název napovídá, standardizované rozhraní pro přístup do „střev“ IP směrovačů. Toto rozhraní má zprostředkovat externím softwarovým aplikacím poměrně detailní náhled do stavu směrovacího subsystému, ale také umožnit přímé zásahy do směrování a modifikace směrovacích tabulek (RIB) a dalších datových struktur, například LFIB (pro MPLS) a multicast RIB.

Více informací o IRS lze prozatím získat ze dvou Internet draftů:

Oba dokumenty lze těžko obvinit z přílišné skromnosti, pokud jde o šíři očekávaných aplikací. Autoři předpokládají nasazení IRS jak pro monitoring a diagnostiku směrování, tak i pro implementaci nejrůznějších administrativních politik v oblastech jako QoS, bezpečnost, diferencované nakládání se zákazníky apod., prostě všude tam, kde standardní konfigurace a směrovací protokoly (údajně) nestačí.

Prezentace IRS při jednání pracovní skupiny Routing Area vyvolala velmi bohatou diskusi. Reakce byly většinou pozitivní a podpůrné, kritické komentáře upozorňovaly hlavně na nebezpečí přílišné šíře záběru – jak se pěkně anglicky říká: „boiling the ocean“.

IRS se má od existujících metod interakce se směrovacím systémem (CLI, SNMP, IPFIX, NETCONF) lišit možností rychlého přístupu k detailním informacím o stavu systému a možností operativních softwarově řízených zásahů. První z uvedených dokumentů však při analýze vhodnosti protokolu NETCONF coby mechanismu pro realizaci IRS vycházel v řadě ohledů ze zastaralých anebo přímo nesprávných informací – NETCONF byl pak na jejich základě zavržen. Tyto nedostatky byly v diskusi také zmíněny a aktivisté IRS přislíbili, že se k výchozí analýze ještě vrátí a použití NETCONFu a jeho datových modelů znovu zváží.

Moje osobní dojmy jsou zatím smíšené. Samotná idea IRS jako mechanismu pro přístup ke směrovacím datům je v pořádku, trochu mne ale dráždí jeho avizované použití. Vychází totiž z předpokladu, že směrování v Internetu lze optimalizovat aktivním řízením routerů z nějakého „inteligentního“ centra. Dosavadní zkušenosti mne přesvědčují, že se v takových případech výkon sítě často spíše zhorší.

Otázky IRS jsou intenzivně diskutovány v konferenci  irs-discuss. Pokud půjde vše podle předpokladů, bude se na příštím meetingu IETF 85 v Atlantě konat zasedání typu BoF (Birds of a Feather) a z něj by následně mohla vzejít nová pracovní skupina IRS při IETF.

Ladislav Lhotka

Z IETF 84: SNMP data pod křídla NETCONFu?

Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.

Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.

Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.

To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.

Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.

Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.

Ladislav Lhotka

Z IETF 84: standardizace konfiguračních dat

Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.

Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).

Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.

V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.

Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.

Ladislav Lhotka

OpenFlow s otazníky

Abych řekl pravdu, dosud jsem si myslel, že OpenFlow je záležitost povýtce akademická a nemá  valného praktického významu. Přispěla k tomu jistě i prezentace „Software Defined Networking“ na IETF 82, která ve mně i řadě dalších posluchačů zanechala dojem ryzího slidewaru.

Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.

OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.

OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.

Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.

Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.

Ladislav Lhotka