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

26. 9. 2013

Doba čtení: 10 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. Náš krátký 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 šílenství), 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 se seznámíme s komplexním mapovacím systémem, který LISP ke své činnosti neodmyslitelně potřebuje.

Mapovací systém

Než se dostaneme k mapovacímu procesu LISPu konkrétně, je dobré si shrnout některé obecně platné poučky, jež s ním souvisí. Problematika efektivity procesů lokalizace a identifikace se řeší už od prapočátku existence počítačových sítí. Dopracovali jsme se ke dvěma diemetrálně odlišným přístupům, které každý z nich používá:

Push model - Každý relevantní uzel sítě informaci má, neb je k němu tato aktivně propagována. Laicky řečeno „všichni vědí všechno, a tak je každý chytrý“. Příkladem využívání tohoto modelu je činnost IGP směrovacích protokolů, které si zasíláním aktualizací mezi sebou udržují konzistentní pohled na síť a totožný obsah routing information base (RIB). Nevýhodou tohoto přístupu je riziko neúměrné režie k udržení sdíleného stavu (zejména hojnost a častost aktualizačních zpráv, popřípadě velikost úložiště směrovacích informací);
Pull model - Informace je dostupná danému uzlu, ale až na vyžádání, o její zjištění se musí uzel aktivně přičinit. Laicky řečeno „každý ví jen to, co potřebuje, a zároveň ví, koho se má zepatat, když něco neví“. Příkladem využívání tohoto modelu je systém DNS, ve kterém není potřeba, aby si každé zařízení pamatovalo všechna doménová jména a k ním příslušející adresy, co na světě jsou. Při použití DNS nemusíme vědět nic, jen koho se zeptat, přičemž odpověď si můžeme po dobu, co ji potřebujeme, lokálně uložit. Nevýhodou tohoto přístupu je rychlost a nepřímost propagace informace, či míra důvěry v odpověď zprostředkované mezičlánky.

Oba přístupy mají své pro i proti. Nicméně limitu push modelu, který se aktuálně používá pro směrování na internetu (IGP a EGP směrovací protokoly), bylo již dosaženo a jak se ukázalo, jeho škálovatelnost je omezena. Oproti tomu DNS škáluje velice dobře, a to zejména díky vštěpované hierarchii kořenových, autoritativních a dalších nameserverů. I přesto, že v RFC specifikacích souvisejících s LISPem se objevovala řešení založená na obou modelech, implementace se dočkal nakonec jen ten založený na pull modelu, který je postavený na autoritativních mapovacích entitách.

Signalizační zprávy, Map Server, Map Resolver

V architektuře LISPu existují zařízení Map Resolver (MR) a Map Server (MS), která se starají o proces mapování. Zjištění RLOCu k EID adrese je analogické k DNS dotazování. V případě DNS se náš počítač ptá DNS resolveru (který má nastavený v OS) na to, jaká IP adresa patří k danému doménovému jménu. Resolver pak buď přímo odpovídá tázajícímu, nebo deleguje dotaz nadřazenému DNS serveru. U LISPu je dotazujícím se typicky hraniční ITR směrovač, který potřebuje zjistit příslušné RLOC-to-EID mapování. ITR má nakonfigurovaný MR, který za něj deleguje jeho dotaz po zbytku LISP mapovacího systému. Stejně jako u překladu DNS je mapování EID na RLOC data-driven, děje se jen ve chvíli, kdy na ITR směrovači čekají data k přenosu do zatím neznámých RLOCů. Mapovací cache tak obsahuje vždy jen ty záznamy, které jsou v daný okamžik potřeba.

Signalizační zprávy, které LISP používá k činnosti mapovacího systému, shrnuje následující výčet. Ještě před ním stojí za to poznamenat, že jsou to vlastně LISP datové zprávy (vnější IP + UDP se zdrojovým a cílovým portem 4342 + LISP) jen bez vnitřní IP hlavičky a obsahu. I díky této zapoudzřenosti se lze o nich v některé literatuře dočíst i jako o tzv. Encapsulated Control Message (ECM):

LISP Map-Register – Každý ETR se stará o jednu či více LISP lokalit v tom ohledu, že autoritativně oznamuje MS pomocí LISP Map-Register zpráv jaké RLOCy se dají pro přístup k daným lokalitám použít;
LISP Map-Request – Pomocí této zprávy ITR zjišťuje konkrétní mapování RLOCů k EID;
LISP Map-Reply – Zpráva slouží jako odpověď na LISP Map-Reply a obsahuje poptávané informace (RLOCy a jejich atributy). Součástí každého ITR je map cache, ve které se uchovává aktuálně používané mapování (RLOCy k EID adresám, se kterými se komunikuje). Relevantní záznamy v map cache jsou aktualizovány právě při přijetí LISP Map-Reply zprávy;
LISP Negative Map-Reply - Generuje se jako odpověď na LISP Map-Reply zprávu ve chvíli, kdy adresa, pro kterou zjišťujeme mapování, nepochází z LISP světa a je potřeba paket směrovat jinak než přes LISP.

Strukturální detaily každé jednotlivé zprávy jsou nad rámec tohoto seriálu, proto nezbývá než laskavého čtenáře odkázat na externí zdroje (jmenovitě v příslušné sekci RFC6830). Nyní zevrubněji zase ke komponentám, jež jsou součástí mapovacího systému.

MR přijímají LISP Map-Request zprávy, které vygenerovaly ITR. Buď je delegují dále do mapovacího systému, nebo odpovídají pomocí LISP Negative Map-Reply ve chvíli, kdy dotazované EID ve skutečnosti není adresa používaná v LISPu.

Každý MS si vytváří tzv. mapovací databázi LISP lokalit, které mu ETR oznámily pomocí LISP Map-Register zpráv. Ve chvíli, kdy MS příjme LISP Map-Request zprávu:

buď může tázajícímu se ITR sám odpovědět, protože ve své mapovací databázi má informace o tom, jaké RLOCy jsou k danému EID pro něj známy,
nebo může dotaz přeposlat některému ETR zodpovědnému za konkrétní EID, který se u něj před tím registroval.

Provázání Map Serverů

ETR router se registruje jen k jednomu MS. Vzhledem k tomu, že počítačové sítě vytvářejí decentralizované celky nejde technicky všechny ETR zaregistrovat k jednomu MS. Musí tedy být způsob, jak propojit mezi sebou vzájemně MS tak, aby nikde nechyběly LISP mapovací informace a MR vždy věděly komu mají delegovat LISP Map-Request zprávy. Existuje několik přístupů, aktuálně nejpoužívanější a nejnasazovanější jsou dva následující.

Alternate Topology (ALT) je způsob propojení MS pomocí dedikovaných tunelů (za použití technologie GRE) skrz neLISPový svět. LISP směrovací informace se pak přenášejí pomocí redistribuce do BGP. ALT agreguje EID prefixy a udržuje alokační politiku. Tento systém není příliš škálovatelný při velkém množství MS, ovšem je schopen se snadno vypořádat s nehierarchicky přidělenými bloky EID adres. Více o něm se lze dočíst v RFC 6836, později v tomto seriále bude představeno i konfigurační demo. Na obrázku níže je vidět ukázka propojení tří MS skrz neLISPový prostor, každý s každým tak má ustavený separátní tunel.

Delegated Distributed Tree (DDT) je hierarchicky distribuovaná databáze, která předává zaodpovědnost za části bloků EID. Koncept podobný jako u DNS, kde existuje posloupnost lokálních nameserverů, nad nimi TLD serverů a nad nimi kořenových serverů. DNS dotaz klienta pak probublává rekurzivně a předvídatelně až k autoritativním nameserverům. Analogicky u DDT pak dotaz na mapování putuje od MR stromovou strukturou až k listovému uzlu, který představuje buď zodpovědně MS nebo ETR (na obrázku níže je to vyznačeno fialovou čárkovanou šipkou). K interaktivnímu předelegovávání dotazu si mezi sebou DDT uzly posílají speciální LISP Map-Referral zprávu, která tázajícího vždy odkáže na další uzel ve směru k vyhledávaným RLOCům k danému EID. Více informací je v draftu a taktéž si později popíšeme, co obnáší připojení se do DDT.

Ukázka registrace

Mějme jednu LISP lokalitu jménem Site B, kterou propojují s RLOC prostorem tři směrovače – ETR-B1, ETR-B2 a ETR-B3 - připojené každé k jinému ISP, a tudíž disponující RLOC adresami rozhraní z různých sítí (3.0.0.1, 4.0.0.1 a 5.0.0.1). Jednotlivé MS jsou zde pak propojeny pomocí ALTu. Ukázka registrace LISP lokality do mapovací databáze MRMS-B je pak popsána následovně:

Ve chvíli, kdy se na ETR nastaví, kdo je jeho MS, tak začne co jednu minutu periodicky generovat LISP Map-Register. V této zprávě je uveden EID-prefix, o který se ETR stará a RLOCy, které se k tomuto prefixu váží. Ve zprávě je vždy označeno, které RLOCy registrujícímu ETR fyzicky náleží (onzačeny jako „lokální“) a které ne, popřípadě jaký je stav těchto RLOCů pomocí status bitového vektoru (1 = up = dostupné, 0 = down = nedostupné);
LISP Map-Register dorazí na MS, kde dojde k jejímu zpracování. Pro ochranu control plane MS je každá zpráva zabezpečena SHA-1 hashem hesla, jenž je sdíleno jak MS, tak registrujícími ETR směrovači. Pokud zpráva tedy projde touto kontrolou, jsou informaci v ní uloženy do mapovací databáze MS;
V případě použití ALTu se pak směrovací informace redistribují z LISPu do BGP, přičemž mezi MRMS-A a MRMS-B je ustanoven BGP peering skrz GRE tunel. Samotná redistribuce technicky znamená, že MRMS-B oznamuje EID prefix 200.0.0.0/24, čímž na sebe nalákává provoz určený této LISP lokalitě.

Ukázka dotazu

Vraťme se nyní k příkladu unicastového přenosu a jen zdůrazněme, že pro provázání MS se používá ALTu. Opět si spolu povídají klienti mezi LISP lokalitami s tím, že komunikaci zahajuje počítač 100.0.0.99 odesláním dat počítači 200.0.0.99. Rozdíl ve scénáři je nyní v tom, že ITR-A2 v lokalitě Site A nemá ve své mapovací cache žádné informace potřebné pro namapapování nějakého RLOCu k cílovému EID lokality Site B. Je nutné provést dotazování nad mapovacím systémem, a to probíhá takto:

Na základě přijatého datového paketu od 100.0.0.99 ITR-A1 generuje LISP Map-Request zprávu a pošle ji svému nakonfigurovanému MR – jejich adresy lze nalézt ve zdrojové a cílové vnější IP hlavičce s RLOCy. Ve vnitřní hlavičce se použije jako zdrojová EID adresa 100.0.0.2 rozhraní, kterým je ITR-A1 připojen k Site A, a jako cílové se použije EID, ke kterému se zjišťuje mapování, tedy přímo adresa druhého počítače 200.0.0.99. Samotné tělo zprávy je komplexnější, než jak je znázorněno na obrázku, obsahuje mimo jiné:
- nonce neboli kontrolní výzvu, která musí být zopakována v těle odpovědi LISP Map-Reply a která chrání mapovací proces proti podvrženým a nevyžádaným zprávám;
- zdrojovou adresu toho, kdo dotaz k mapování vyvolal (100.0.0.99);
- seznam EID, pro které je prováděn mapovací dotaz (200.0.0.99/32);
- RLOC cachovací data pro ETR ohledně vyžádané LISP Map-Reply odpovědi (k EID 100.0.0.0/24 patří RLOCy 1.0.0.1 a 2.0.0.1);
MR jménem MRMS-A příjme mapovací dotaz. Odstřihne vnější hlavičku a zajímá se jen o zbývající obsah. Podívá se do své směrovací tabulky, kam má směrovat provoz určený adrese 200.0.0.99 a zjistí, že je to MRMS-B, kterému pak pošle dotaz zapouzdřený v rámci GRE tunelu – z jeho konce tunelu 192.0.2.1 na druhý 192.0.2.2;
MRMS-B dostane skrz tunel LISP Map-Request zprávu a zpracuje ji. Podívá se do své mapovací databáze a některému (v závistlosti na implementaci) ETR, který registroval EID 200.0.0.0/24, přepošle dotaz. V demonstračním příkladě je jím směrovač ETR-B2.

Ukázka odpovědi

Co způsobí zpracování mapovacího dotazu při scénáři započatém v předchozím příkladě?

Vygenerování LISP Map-Reply zprávy se může ubírat dvěma cestami:
1. MRMS-B delegoval LISP Map-Request zprávu poslednímu registrujícímu, tedy ETR-B2. Ten po přijetí této zprávy vytvoří odpověď, kterou pošle z 4.0.0.1 na cílovou 2.0.0.1 adresu tázajícího;
2. Na ETR se dá během registrace k MS vynutit, tzv. proxy-reply volba. Díky ní bude na LISP Map-Request zprávy odpovídat MS, bez toho, aby zprávu delegoval ETR . Protože má MS k dispozici ty stejné informace jako jakýkoli registrující ETR, tak může LISP Map-Reply zprávu vygenerovat i on. V ukázce ji zasílá se svou zdrojovou IP adresou 5.0.0.255. Díky proxy-reply se ušetří na signalizační režii protokolu, čehož můžou s výhodou využít zejména mobilní či na energii spořivé ETR uzly;
V každém případě dříve nebo později probublá odpověď až k ITR-A2, který celý proces spustil, přičemž ten si do své mapovací cache uloží informaci o tom, že k EID prefixu 200.0.0.0/24 náleží tři RLOCy, a to 3.0.0.1, 4.0.0.1 a 5.0.0.1. Komunikace mezi počítači v lokalitách Site A a Site B tak může začít. Podle použitých priorit a vah bude další komunikace z 100.0.0.99 do 200.0.0.99 používat jako cílový RLOC adresu 4.0.0.1. Podobně jako při ARP throttlingu se datový provoz, který signalizaci vyvolal, necachuje a je do doby, než dojde k namapování EID ITR směrovačem, zahazován – jednoduše řečeno, prvních pár paketů komunikace se může ztratit.

Závěr

V dnešní části jsme si představili všechny důležité pojmy a principy fungování LISP mapovacího systému. V díle následujícím si povíme něco o přechodových mechanismech při komunikaci LISPového a neLISPového světa.

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 (7 názorů)

Líbí

Nelíbí

Vladimír Veselý

Mě by pořád zajímalo, co tak magického přináší LISP oproti DNS. To mě zajímá víc než halda technických detailů, které si můžu načíst třeba z RFC. Asi je to moje chyba, ale z těch článků se toho nějak nemůžu dobrat.

Pavel Šimerda

Sdílet

Mapovací systém