10.2 Reťazec servisných funkcií

 

10.2 Reťazec servisných funkcií

Ako je opísané v [RFC7498], poskytovanie služieb typu end-to-end môže vyžadovať, aby paket prešiel cez sériu servisných funkcií v určenom poradí; toto sa nazýva „reťazec servisných funkcií“ (SFC, Service Function Chain). SFC definuje usporiadanú množinu abstraktných servisných funkcii (SF) a obmedzení ich usporiadania, ktoré musia byť aplikované na vybrané pakety, rámce alebo toky podľa ich klasifikácie (viď [RFC7665]). Na Obr. 1 je znázornené reťazec servisných funkcií, cez ktoré prechádzajú pakety najprv cez  firewall-2 a následne cez napt44-2.

Obr. 1 Príklad reťazca servisných funkcií

Za prechod paketov cez jednu alebo viacero prepojených servisných funkcií podľa informácií prenášaných v zapuzdrení SFC je zodpovedný SFF (Service Function Forwarder).  SFF zodpovedá aj za doručovanie paketov do klasifikátora, za prenos do iného SFF a za ukončenie SFP (Service Function Path).

SFP udáva, kam musia smerovať pakety priradené k určitej servisnej funkcií. Môže ísť o presné určenie miesta, kam majú byť pakety smerované, alebo toto miesto nemusí byť presne špecifikované. SFP poskytuje úroveň nepriameho prepojenia medzi plne abstraktnou špecifikáciou servisného reťazca ako postupnosti abstraktných servisných funkcií a detailnou špecifikáciou, t.j. cez ktoré SFF a SF bude paket prechádzať. Obr. 2 znázorňuje situáciu, keď dvaja klienti požadujú prístup na web server. Prístup na server je chránený firewallom, ktorého úlohou je blokovanie niektorých typov spojení. V našom prípade je funkcia firewallu zabezpečovaná prostredníctvom dvoch servisných funkcií SF1 a SF2, pričom SF1 blokuje HTTP prevádzku a SF 2 blokuje SSH. Ako je na obrázku vidieť, žiadosti klientov 1 a 2 o komunikáciu s web serverom sú spracované vstupným klasifikátorom, ktorý zabezpečuje dymanické mapovanie tokov a to klienta 1 do servisného reťazca 1 a klienta 2 do servisného reťazca 2.

Obr. 2 Dynamické SFC

Dátová prevádzka od obidvoch klientov je následne smerovaná SFF1cez firewall SF1 alebo SF2. Ako SFF1 je tu použitý Open vSwitch s podporou protokolu OpenFlow, ktoré boli opísané v predošlých častiach. Rozdielne smerovanie  paketov pre SF1 a SF2 je tu zabezpečené tým, že OpenFlow prepínač (OVS) má vo svojich tabuľkách vytvorené odlišné záznamy pre toky SF1 a SF2. Cesty týchto tokov (na Obr. 2 označené červenou a modrou farbou) sa nazývajú RSP (Rendered Service Path) a udávajú postupnosť skutočných, špecifických SFF a SF, cez ktoré paket prechádza.

Obr. 3 Príklad definovania RSP pomocou grafického rozhrania
SDN kontroléra OpenDaylight

Pri cloudovej realizácií SFC je každý prepínač pripojený k SF nakonfigurovaný ako SFF  a  každá SF je pripojená k SFF podľa toho, na ktorom výpočtovom uzle je daná VM umiestnená (viď Obr. 4).

Obr. 4 Realizácia SFC v cloudovom prostredí

Uvedený model uvažuje s viacerými SFF, čo spôsobuje čo predlžuje reťazec servisných funkcií a robí ho zbytočne zložitým, preto bol zavedený koncept logického SFF, ktorý prináša abstrakciu infraštruktúry dátového centra a umožňuje, aby sieť dátového centra bola abstrahovaná jediným SFF (viď Obr. 5).

Obr. 5 Logický SFF