LISP: nové paradigma ve směrování (1.)

19. 9. 2013

Doba čtení: 15 minut

Líbí se vám článek?
Podpořte redakci

Locator/ID Split Protocol je v posledních letech jedním z diskutovaných řešení, které by mohlo přinést úlevu od bolístek (mobilita, multihoming, adresování) současného internetu. Tento seriál se vám pokusí nastínit vše podstatné – ideu funkce, strukturu protokolu i konfiguraci na zařízeních.

Pod trochu zavádějící zkratkou LISP (nikoli ten funkcionální programovací jazyk plný závorkového šilenství), neboli Locator/ID Split Protocol, se skrývá zapouzdřovací protokol, který se rozhodl podívat se alternativním způsobem na IP adresování zařízení připojených k internetu. V tomto díle si nastíníme motivaci vzniku protokolu samotného a popíšeme si zjednodušený „den života“ unicastového paketu v LISP síti.

Motivace

V roce 2006 se sešla IAB na Routing and Addressing Workshopu, kde se pokusila znovuotevřít diskuzi ohledně koncepčních chyb, které začaly být patrné s tím, jak se zvětšoval počet uživatelů na síti a s tím přímo uměrně i počet zařízení. Jako motivaci a to nejen za vývojem samotného LISPu, ale i dalších iniciativ (protkol ILNP), jmenujme některé z těchto slabostí:

Problém první: Multihoming a růst směrovacích tabulek default-free zone

Čím dál tím více koncových sítí (koncových zákazníků) touží po záložním připojení k Internetu pro případ výpadku linky k primárnímu Internet Service Providerovi (ISP). V tom případě je třeba obvykle zabývat se dvěma věcmi:

Řešit směrovací politiku – Když má zákazník jen jednoho ISP, tak je typicky celá jeho síť součástí autonomního systému (AS) poskytovatele. Pokud chce mít ale redundantní připojení k Internetu, musí provozovat vlastní (byť privátní) autonomní systém a vyměňovat si informace se sousedními AS k zajištění konektivity.
Řešit adresování – Správci sítě se obvykle snaží zajistit perzistentní adresování pomocích tzv. provider independent (PI) adres, aby při změnách ISP nebylo potřeba přeadresovávat všechna zařízení (a zejména ta koncová). Pokud je síť adresovaná pomocí PI adres, musí se informace o ní propagovat do celého Internetu a nelze použít sumarizace. Bohužel obzvláště v případě IPv4 (a s přihlédnutím k obecnému nedostatku adres v ní) tak díky multihomingu dochází ke štěpení adresního prostoru na bloky, které se nedají už nijak agregovat.

V současnosti se multihoming řeší zcela v režii Border Gateway Protocolu (BGP), kterým se vyměňují směrovací informace (cesty k sítím, jejich atributy, ale i požadované politiky pro směrování) mezi AS, resp. hraničními směrovači mezi AS, jež spolu peerují. Termín default-free zone (DFZ) označuje tu množinu typicky tranzitních AS, které obsahují úplné směrovací informace (znají cesty ke všem sítím) a nepotřebují tudíž klasickou obezličku v podobě výchozí cesty.

Za každý AS, který provozuje multihoming, se tak zvyšuje množství informací, které se musí propagovat do DFZ, aby byl celý „systém“ funkční. DFZ pak ale neúměrně nabobtnává na velikosti. V této souvislosti se často uvádějí grafy z webu bgp.potaroo.net při blogu Geoffa Hustona. Jmenovitě následující dva, zobrazující nárust záznamů v forwarding information base (FIB) pro IPv4 a IPv6 na experimentálním pozorovacím routeru v AS 6447.

Naneštěstí oba tyto grafy mají tendenci lidé desinterpretovat zejména při poskytování motivací za různými vědeckými i technologickými články o budoucím vývoji Internetu! Obvykle začínají slovy, že můžeme pozorovat exponenciální nárůst ať už ve FIB, v prefixech či v množství cest. Poslední reálné a relevantní výzkumy však ukazují, že se v případě IPv4 nejedná ani tak o růst exponenciální, jako spíš lineární, a v případě IPv6 se často opomíjí vertikální osa – 12 000 záznamů. V tak malém množství prefixů je každý nárust citelně znát. Přiznejme si však, že po více než 16 letech její existence to není nic, na co by IPv6 mohla být v globálnosti svého nasazení hrdá.

Screenshot z páteřního routeru nám dá reálnější pohled to, jak se růst informací projevuje. DFZ tedy v současnosti tvoří přibližně 476 tisíc sítí, které zabírají cca 62,8 MB v paměti. Mezi těmito sítěmi existuje celkem 13,2 miliónů cest, jejichž udržování pro korektní konvergenci spolkne přes 691,4 MB. Všechny cesty mají celkem přes 2,1 miliónů atributů, což si vezme dalších 360 MB. Konkrétně tento router tak má na činnost protokolu BGP alokováno přes 1,11 GB RAM.

Rozhodně to je hodně v případě, kdy se musí pomocí TCP, nad kterým BGP běží, přenést úplné směrovací informace při navazování sousedství s novým peerem. Na druhou stranu by ale neměl být až takový problém postavit hardwarově dostatečně zdatné zařízení, když si uvědomíme, že žijeme v době vícejádrových CPU a smartphonů, které mají k dispozici 2 GB RAM paměti již standardně. Dá se říci, že nám Moorův zákon hraje do karet, a jak to tak vypadá, tak minimálně v oblasti počítačových sítí postavených na IP, se na vlně jeho důsledků budeme moci ještě chvíli vozit.

Nicméně faktem zůstává, že ať už chceme nebo ne, tak množství informací v DFZ přibývá, i když to není tak drastické, jak se nám mnozí škarohlídi snaží vnutit.

Problém druhý: Mobilita zařízení

Pod mobilitou zařízení v počítačové síti aspoň v tomto seriálu rozumějme schopnost zařízení měnit koncové sítě, ke kterým je zařízení připojeno za běhu (a nejlépe beze ztráty konektivity). Samotné TCP/IP na toto nikdy nemyslelo, a tak je zmíněná vlastnost doplněna v rámci IETF spíše méně zdařilými pokusy. Ty se zabývají otázkami, které jsou s mobilitou úzce designově spjaty:

„Jak je mobilita technicky řešena (samotný proces roamingu mezi sítěmi)?“
V současnosti jsou asi nejvýznamnější zástupci v řešení této otázky Mobile IP, Mobile IPv6 či HMIPv6.
„Jak sdělit klientům, že se změnila adresa mobilního zařízení ze staré na novou?“
Pokud není práce s adresami přímo součástí protokolu zajišťujícího roaming, můžeme se uchýlit k očividnějším řešením, jako např. dynamická aktualizace DNS záznamů.
„Pokud má mobilní zařízení více rozhraní, jaké primárně používat ke komunikaci?“
Vezměme si smartphone současnosti – ten má k dispozici typicky jak datové připojení od operátora (EDGE, HSPDA), tak WiFi bezdrátové připojení. I pokud jsou v danou chvíli dostupné a aktivní obě připojení, tak smartphone prediktivně komunikuje jen jedním z nich. Jistou úlevou v této oblasti může být MultiPath TCP, ale ten není dostatečně generický.

S tím jak nemilosrdně roste počet k Internetu připojených mobilů a smartphonů, je vyvíjen i čím dál tím větší tlak na skutečně funkční a globálně akceptované řešení mobility zařízení v počítačové síti.

Problém třetí: Identita zařízení

V posledních letech se čím dál tím více skloňuje myšlenka Internet of Things, ve které její vizionářsští autoři pracují s ideou, že každá jednotlivé věc na světě, bude připojena k Internetu a bude mít svou vlastní jedinečnou adresu, díky které bude moci komunikovat s ostatními a oni s ní. Podle některých predikcí má být k roku 2020 připojených na 20 miliard zařízení – od serverů, stolních počítačů, přes mobilní zařízení, až po senzorové prvky (jako např. fotobuňky či požární hlásiče).

Pokud je zařízení připojené k síti jen jedím rozhraním, pak jeho adresa skutečně zařízení identifikuje. A díky této jednoznačně identifikaci jsme schopni zařízení v celé síti následně lokalizovat. Pokud ovšem má zařízení více rozhraní, tak jejich adresy jsou de facto jen tzv. body připojení (point of attachment, neboli PoA) pro dané koncové sítě, do kterých rozhraní směřují. Naneštěstí adresa PoA nemá tu vlastnost, že by zařízení jedinečně identifikovala. Uvědomme si, že pokud je jedno takové rozhraní (na jehož adresu se všichni klienti připojují) nedostupné, tak to nemusí nutně znamenat, že by se se zařízením nedalo komunikovat pomocí jiného PoA.

Ve světě aktivních síťových prvků se tento problém řeší za pomocí adres přidělených loopbackovým rozhraním. Loopback interface je jakési virtuální rozhraní, které není přímo připojeno k žádné siti, jíž je zařízení členem. Loopbackovou adresu ale můžeme propagovat ve směrovacích informacích sousedům. Takové rozhraní je pak dostupné tak dlouho, dokud existuje nějaká průchozí cesta sítí k prvku vlastnícímu Loopback rozhraní. Toto totiž oproti PoA není připojeno k žádné koncové síti, ale svou povahou k zařízení samotnému.

Problém identity zařízení je bohuže negativním důsledkem špatného návrhu celého TCP/IP stacku.

Základní myšlenka a princip protokolu

Cíle LISP iniciativy vychází z podstaty problémů zmíněných výše – omezit růst DFZ, zamezit neagregovatelnému štěpení bloků adres, umožnit multihoming koncovým sítím bez BGP, poprat se s mobilitou a identitou zařízení. Zároveň s tím nasazení LISPu funguje bez nutností rekonfigurat koncová zařízení, bez změn v DNS, je agnostické k použitému IP protokolu (podporuje jak IPv4, tak IPv6, ale svou podstatou jakýkoli jiný protokol síťové vrstvy) a už od návrhu obsahuje podporu mobility a přechodových mechanismů (pro komunikaci s neLISP zařízeními).

Funkce IP adresy je v současnosti přetěžována, neb zastává jak lokalizačního tak identifiakčního významu. Zatímco lokalizace obvykle podléhá adresnímu plánování od ISP, tak adresování pro identifikaci je v rukou správce koncové sítě. Toto přetěžování má pak za důsledek nemožnost vybudovat dlouhodobě škálovatelnou a efektivní směrovací architekturu na úrovni DFZ v rámci decentralizovaného Internetu. Původní idea Internetu byla vytvořit jednoduchou decentralizovanou síť založenou na přepínání paketů (packet switching) bez předchozího ustavení spojení (connectionless), která bude schopna vypořádat se se stochastickými výpadky uzlů, které ji tvoří. Od doby autoritativního zavedení TCP/IP stacku jsme se po 30 letech fungování a provozu tohoto designu dopracovali do bodu, kdy původně „jednoduchou síť“ musíme různými technikami (IPv4 a IPv6, IGP protokoly, BGP, PIM, MPLS, QoS) udělat velice „chytrou a inteligentní“ (nabobtnat síťové prvky spoustou dalších informací) a i přesto komunikace mezi dvěma pořítači nefunguje tak hladce, jak podle původního návrhu měla. Teď ale zpátky k LISPu a způsobu, který volí, aby nás zbavil aspoň části problémů…

Hlavní idea LISPu tedy je v oddělení dvojí funkcionality IP adresy – separaci lokalizace od identifikace! Jak si to představit? Vezměte si mobilní telefon – jednoznačnou identifikaci tvoří telefonní číslo, lokalizaci pak představuje síť operátora, do které je telefon přihlášený. Zavolá li někdo na jeho číslo (identifikace), tak se v síti operátora vyhledána patřičná BTS (lokalizace), se kterou je telefon aktuálně zasociován, a hovor se spojí. Ve chvíli, kdy se mobil přesune do zahraničí, tak se pouze změní operátor – místo připojení zařízení k síti – ovšem lidé se jsou stále schopni dovolat na to stejné číslo, neb to zůstalo stejné.

Aby tohoto efektu LISP dosáhl, zavádí místo jednoho téměř plochého adresního systému, kterým je Internet dnes, systémy dva:

prostor Routing Locators (RLOC), kde adresy budou plnit funkci lokalizátorů, kde je v síti zařízení připojeno (v obrázku červený mrak a případně červené adresy);
prostor Endpoint Identifiers (EID), ve kterém má každé zařízení jedinečnou adresu, která ho identifikuje vůči ostatním (v obrázku zelený mrak a případně zelené adresy).

Krom EID a RLOC prostorů existuje (a asi vždy u bude existovat) i neLISP adresní systém (v obrázku vyblitý modrý mrak a případně modré adresy), tedy takový, ve kterém LISP není vůbec podporován (a to i záměrně). Krom adresních systémů musí být přitomny i specializované aktivní síťové prvky, které zajišťují komunikaci mezi nimi (na obrázku zařízení na hranicích mezi mraky), popřípadě které se starají o mapovací systém (na obrázku zařízení s EID-RLOC mapovací tabulkou).

LISP funguje na tzv. map-and-encap principu, se kterým poprvé přišel Robert Hinden s ENCAPSem. Abstraktně se tento princip dá shrnout do dvou částí – ve chvíli, kdy paket přechází z jednoho prostoru do druhého, je potřeba na hraničním prvku provést namapování mezi adresami z různých prostorů (princip map) a paket pak zapouzdřit (princip encap) novou hlavičkou.

V případě LISPu se mapování provádí mezi EID adresami, ke kterým se hledají patřičné RLOCy. U procesu enkapsulace je pak původní (tzv. vnitřní) IP hlavička s EID adresami zabalena do hlavičky nové (tzv. vnější), ve které se používají jako adresy RLOCy. Když pak paket dorazí na hraniční prvek cílového EID prostoru, je vnější IP hlavička odstraněna. V rámci procesu zapouzdřování se mezi vnější a vnitřní hlavičku vkládá ještě UDP hlavička a za ní LISP hlavička. V UDP hlavičce se používá vyhrazených čísel cílových portů, kde 4341 je rezervováno pro datový LISP provoz (obvyklou komunikaci mezi klienty v LISP prostorech) a 4342 pak pro signalizační provoz LISPu samotného. Samotná LISP hlavička pak obsahuje data relevantní pro LISP a podle použitého síťového protokolu je buď 36 B (v případě IPv4 adres), nebo 56 B (v případě IPv6 adres) velká. LISP podporuje kombinace jak stejných – IPv4 vnější / IPv4 vnitřní, IPv6 vnější / IPv6 vnitřní – tak rozdílných verzí IP protokolů – IPv4 vnější / IPv6 vnitřní, IPv6 vnější / IPv4 vnitřní. Zde je nutné zmínit, že princip zapouzdřování je natolik obecný, že se může použít nejen existující IP, ale teoreticky libovolný protokol s jednoznačným adresováním.

Pokud byste si spustili WireShark a začali odchytávat někde v RLOC prostoru komunikaci přes LISP, tak následující obrázek shrnuje možné druhy zapouzdření vnějších (ty červené s RLOC adresami) a vnitřních (ty zelené s EID adresami) IP hlaviček, které byste dnes eventuelně mohli pozorovat při přenosu dat. Světle modře je pak na obrázku každého paketu vyznačena UDP mezihlavička a žíhaně modrou barvou pak struktura LISP hlavičky.

LISP je hlavně směrovací protokol, ale nemohl by jako takový fungovat bez dvou svých základních stavebních kamenů – procesu přepouzdřování a mapovacího systému.

Přepouzdřování

ITR a ETR

Mezi základní komponenty LISP architektury patří zařízení Ingress Tunnel Router (ITR)a Egress Tunnel Router (ETR). Oba jsou hraničními zařízeními mezi EID prostorem a RLOC prostorem. Jejich rozdílná funkcionalita se však projevuje ve směru, z kterého do kterého prostoru paket putuje. Zařízení může zastávat buď jen ITR, nebo jen ETR funkcionalitu, v reále ovšem jedno zařízení obvykle zastává obojí funkcionalitu zaráz. Tímto zařízením je ze své podstaty obvykle směrovač (v následujících obrázcích označován jako xTR).

ITR je vstupním bodem z EID prostoru (či chcete-li LISP lokality) do RLOC prostoru, přičemž se stará o zaopatření klientského provozu vnější hlavičkou. To může zahrnovat i vyhledání mapování EID na RLOC a následnou aktualizaci tzv. map cache, ve které se udržují aktuálně používaná mapování. Ve vnější hlavičce se na pozici zdrojové IP adresy objevuje jeden z RLOCů, kterými směrovač fyzicky disponuje, a v cílové IP adrese pak RLOC provázaný s cílovou EID adresou, či alespoň mezilehlé zařízení, které má dostatečné znalosti pro doručení paketu.

ETR je výstupním bodem z RLOC do EID prostoru. Stará se o odpouzdřování paketu přijatého z RLOC prostoru a určeného do EID prostoru, technicky to znamená odstranit mapovanou vnější IP + UDP + LISP hlavičku a poslat paket jen s vnitřní IP hlavičkou. Dále má ETR na zodpovědnost ohlašovací povinnost pro jaké LISP lokality plní funkci ETR a skrz jaké RLOCy jsou tyto lokality dostupné.

Ukázka unicastového přenosu

Níže uvedený obrázek ukazuje topologii sítě, ve které jsou dvě LISP lokality (Site A s EID adresami z bloku 100.0.0.0/24 a Site B s EID adresami z bloku 200.0.0.0/24) spojeny skrz RLOC prostor, který tvoří pět vzájemně různě propojených ISP (používající pro ukázku /8 bloky IPv4 adres). Představme si nyní dvě LISP lokality, přičemž v lokalitě Site A je PC s adresou 100.0.0.99, které se rozhodne komunikovat s PC v lokalitě Site B. To, že se klienti nacházejí v LISP lokalitě s adresami, které jsou vnímány jako EID, je pro ně zcela transparentní, z jejich pohledu je EID adresa jen IP adresa a nic víc. Co všechno se během této unicastové komunikace stane? Kótované žluté body pak odpovídají bodům v tříděném seznamu pod obrázkem.

Pokud klient nezná adresu cíle, typicky provede DNS překlad doménového jména, např. jeho resolving mu vrátí záznam:
```
pc.siteb.com A 200.0.0.99
```
Operační systém klienta má všechny patřičné informace a odešle paket se zdrojovou IP adresou 100.0.0.99 na cílovou adresu 200.0.0.99).
V rámci LISP lokality se díky IGP směrování dostane paket až na router xTR-A2, který jej příjme na vnitřním rozhraní. Tento směrovač, který plní funkcionalitu ITR, musí vytvořit patřičnou vnější IP hlavičku a obalit původní data. Na základě cílové EID adresy 200.0.0.99 provede vyhledání RLOCu v map cache. Záznam v map cache tvoří RLOC adresy i dva další atributy – priorita (priority) a váha (weight). V případě, že je k danému EID k dispozici více RLOCů, tak se preferuje ten s nejmenší prioritou. Pokud je priorita 0, záznam je sice uchováván v map cache, ale daný RLOC se vůbec nepoužívá. Pokud více RLOCů sdílí stejnou prioritu, tak se jejich využití procentuálně poměrově střídá podle parametru váhy (dochází k load-balancingu). V případě ukázky je zvolen RLOC 4.0.0.1, jelikož měl nejmenší prioritu. ITR provede zapouzdření původního paketu a pošle jej pryč do systému RLOCů.
Pokud bychom měli možnost odchytit si paket a analyzovat jeho obsah ve Wiresharku ve chvíli, kdy putuje napříč sítemi ISP, tak ve vnější IP hlavičce by byly použity 2.0.0.1 jako zdrojová a 4.0.0.1 jako cílová RLOC adresa. Ve vnejší IP hlavičce by bylo v políčku Protocol číslo 17, udávající, že další protokol v pořadí je UDP. Následná UDP hlavička by měla nastavený cílový port 4341, přičemž za ní by se nadcházela LISP hlavička. Po ní už jen vnitřní IP hlavička s EID zdrojovou adresou 100.0.0.99 a cílovou 200.0.0.99.
Skrz AS ISP doputuje paket až na hraniční směrovač xTR-B2, který provede odpouzdření (odstřihne vnější IP hlavičku a související pomocné provozy) a podle informací ve směrovací tabulce pošle paket odchozím rozhraním ve směru k síti 200.0.0.0/24.
Paket v LISP lokalitě Site B putuje v podobě, v jaké ho odeslal počítač v lokalitě Site A. Tedy pouze s jednou hlavičkou, ve které se používají k adresování EID.

Implementace ITR musí vždy respektovat hodnoty priority a váhy k daným RLOCům a řídit se jimi v případě směrování provozu. Díky tomu je vždy zajištěn tzv. vstupní traffic-engineering (ingress TE), který má zcela ve své režii správce konkrétní LISP lokality, neb ten je definuje. Pokud neuvažujeme LISP, tak vstupního TE se dá docílit použitím BGP směrovacích politik. Ovšem oproti LISPu v případě BGP politik není garantováno, že je bude druhá strana respektovat a aplikovat.

Závěr

Výše uvedený je příklad, kdy ITR už patřičné informace má ve své mapovací cache. Jak si ale ITR tuto cache vytváří? Tím se budeme zabývat v dalším díle…

Kam dál?

Začátkem roku 2013 slavil LISP po několika letech urputného snažení úspěch v rámci standardizačních tendencí skrz IETF. V lednu onoho roku tak byly úspěšně posvěceny následující dokumenty formou experimentálního RFC s vlastním číslem. Tyto dokumenty stejně jako související aktivní drafty jsou asi nejvhodnějším a referenčním zdrojem informací pro studium struktury LISPu a jeho fungování použít. Hvězdičkou * jsou označeny odkazy více relevantní k tomuto dílu seriálu.

IETF materiály:

GoogleTech prezentace:

Další odkazy:

Seriál: LISP: nové paradigma ve směrování

Přečtěte si všechny díly seriálu LISP: nové paradigma ve směrování nebo sledujte jeho RSS

Vstoupit do diskuse (11 názorů)

Vladimír Veselý

Dílu je napsaných celkem pět, budou vycházet každý čtvrtek.

Petr Krčmář

Sdílet

Motivace