Co přinesou pravidla

Základním důvodem využívání politik je možnost dosažení velkých úspor. Ty se ve velké míře nabízejí např. p


Základním důvodem využívání politik je možnost dosažení velkých úspor. Ty se ve
velké míře nabízejí např. při dálkových přenosech. Zde lze s pomocí síťových
komponent kompatibilních s QoS a odpovídajících pravidel realizovat velmi
významná zlepšení výkonnosti sítě. Pro vnitropodnikové sítě LAN představují
nástroj, se kterým lze provozovat kritické aplikace v rámci celé firmy v
žádoucí kvalitě. Konfigurování pravidel Formulování politik (pravidel) v síti
probíhá na třech základních úrovních:

Nejvyšší rovina definuje požadavky, které vyplývají z potřeb kritických
obchodních procesů.

Abstraktnější druhá rovina formuluje pravidla nezávisle na používaných
zařízeních jako dohody o úrovni služeb SLA (Service Level Agreements). O
realizaci pravidel obchodního procesu se stará administrátor pravidel
(Policy-Administrator).

Aby bylo možno pravidla ukládat v koncových zařízeních, jsou převáděna z formy
nezávislé na těchto zařízeních do podoby na nich závislé, tedy do tzv. SLO
(Service Level Objectives). Ukažme si rozdíl mezi těmito druhy pravidel na
typickém příkladě: Vedoucí oddělení výpočetní techniky by chtěl zajistit, aby v
jeho firemní síti mohlo fungovat řešení VoIP (přenos hlasu přes protokol IP).
Podmínkou je ovšem vysoká kvalita přenosu řeči. Ta je definována nejdříve v
abstraktní podobě nezávislé na používaných přístrojích, následně pak jako
limity zpoždění (Delay) doplněné o požadavky na šířku přenosového pásma. Tak je
zanesena do centrálního seznamu pravidel. Konkrétní zásada by kupříkladu mohla
znít takto: Pro VoIP spojení garantuji minimální zpoždění a šíři přenosového
pásma 100 Kb/s. Následně rozšíří tento požadavek mezi koncová zařízení sítě.
Adresáře V heterogenních prostředích lze úspěšně implementovat rozlišování
úrovní služeb jen tehdy, jestliže existují jednotná a přizpůsobitelná pravidla.
Pracovní skupina IETF zabývající se touto oblastí vypracovala standardy pro
SLA. Vycházela přitom z práce pracovní skupiny DMTF (Distributed Management
Task Force) na téma CIM (Common Information Model). Jedná se o objektově
orientovaný model popisující řídicí data.
Díky intenzivní spolupráci uvnitř IETF vznikl z CIM vyšší model PCIM (Policy
Core Information Model), který popisuje všeobecné definice informací o
pravidlech. Je založen na schématu CIM verze 2.2 a v současnosti existuje ve
formě RFC (Request for Comment). Pravidla orientovaná na QoS budou také
definována v modelu QPIM, který na základě objektů popisuje reprezentaci
pravidel kvality služeb. QPLS ukládá tato data do adresáře pravidel LDAP.
Za přeměnu síťových pravidel na pravidla specifická pro jednotlivé přístroje je
zodpovědný bod PDP (Policy Decision Point). Získaná data převádí do příkazů
srozumitelných koncovým zařízením. Zatím ovšem neexistuje žádný návrh
dokumentu, který by tuto přeměnu popisoval. Výrobci proto implementují každý
své vlastní řešení. Proto se doporučuje nasazovat v síti jen PDP od stejného
dodavatele.
IETF v současnosti vyvíjí nový informační model podobný QPIM, jenž popisuje,
jak se mají projevovat informace o pravidlech na síťových komponentách
zaručujících QoS.

Politika vměšování aneb priority v síti
Aby bylo možné efektivně spravovat stále rostoucí šířku pásma v komplexních
datových sítích, je třeba využívat sofistikované řídicí mechanismy. K tomu mají
dopomoci standardy COPS (Common Open Policy Service), které automaticky
informují jednotlivé komponenty sítě o pravidlech, podle nichž je třeba
přenášet data s určitou prioritou.

Především velké podniky jsou stále častěji konfrontovány s požadavkem na
zvláštní zacházení s určitými aplikacemi v síti. Nejvhodnějším řešením, které
je dnes nabízeno, je tzv. správa založená na politikách (Policy-based
Networking), která však na síť klade určité další nároky. Některé aplikace
vyžadují středně široké, ale garantované šířky přenosového pásma, jiné zase co
nejmenší zpoždění nebo naopak vysokou frekvenci přenášených datových paketů.
Požadavek na přenášení IP paketů pomocí inteligentnějších metod, než
představuje standardní přístup "největší snahy" (Best-Effort), přiměl již před
několika lety Internet Engineering Task Force (IETF) k založení různých
pracovních skupin, které měly najít vhodné řešení. Ty vypracovaly dvě
technologie pro zvýšení přenosové kvality v sítích pracujících pod IP:
lRezervace zdrojů pro tok dat: Dochází k signalizaci a rezervaci žádoucí šířky
přenosového pásma, které zůstává vyhrazeno po celou dobu daného toku dat. Tak
je umožněno dosahovat pro určené aplikace potřebné kvality služeb QoS (Quality
of Service). Standardizovaný protokol IETF se nazývá RSVP/Intserv, RFC 2205.
lPrioritizace paketů z určitých toků: Tato koncepce na okraji sítě klasifikuje
a označuje pakety dat v rámci jednoho toku a směruje je dál podle označení
vyjadřujícího míru priority. Definuje ji standard IETF Diffserv RFC 2475.
Jelikož jsou toky dat Diffserv rozděleny do různých tříd a s vícero toky stejné
třídy se pracuje společně, označuje se tato technologie také jako Class of
Service (CoS, třída služeb). Používání termínů QoS a CoS je ale nejednotné. My
zde v následujícím textu použijeme pojem QoS pro obě technologie.
Jestliže chtějí podniková oddělení výpočetní techniky garantovat určitou úroveň
služeb, narazí patrně na dva problémy: Za prvé musejí všechny přístroje
používané v síti model kvality služeb podporovat; a za druhé je nutné, aby bylo
užité označení interpretováno vždy identicky. Vazba mezi označením služby a s
ní spojené požadované kvality je dána určitými pravidly, jimž se v množném
čísle anglicky říká Policies. Každá Policy (tedy jedno pravidlo, politika)
přitom sestává z podmínky a z ní vyplývající akce.
Rámec standardů COPS Každou politiku lze jednoduše realizovat manuální
konfigurací síťových komponent. Ve větších sítích však tento postup brzy narazí
na hranice možností správců. Zde je tedy třeba použít postupy dané například
standardy jako Common Open Policy Service (COPS), díky nimž lze automaticky
konfigurovat velké množství připojených zařízení.
Souprava protokolů COPS byla původně vyvinuta proto, aby se dosáhlo jednoty při
využití protokolu RSVP (Resource Reservation Protocol). Sdružení IETF však brzy
rozpoznalo univerzálnost tohoto přístupu a rozšířilo ho o další komponenty.
COPS definuje tři základní prvky, z nichž je složen celý systém:

PEP (Policy Enforcement Point, bod vynucování pravidla) označovaný jako COPS
klient prosazuje dodržování pravidla v síti. Existují různí klienti, kteří
mohou být implementováni v jediném síťovém zařízení, např. podporující současně
Diffserv stejně jako IPSec.

PDP (Policy Decision Point, bod rozhodování o pravidlu) stanovuje centrální
pravidla a podporuje současně nejrůznější typy COPS klientů.

Samotný protokol COPS, který pravidla zprostředkovává. Jedním z důležitých cílů
stanovených při vývoji protokolu COPS byla jeho snadná rozšiřitelnost. Každý
typ klienta může propůjčovat hlášením COPS svou vlastní strukturu a vlastní
význam. Mimo COPS standardizovalo IETF prostřednictvím COPS-RSVP také jednoho
klienta pro zpracování požadavků QoS prostřednictvím RSVP. COPS-PR definuje
klienta, který může být využíván univerzálně, zvláště při určování politik
Diffserv. Rozšiřuje model COPS o objektově orientované vlastnosti.
Konfigurační informace jsou přitom definovány do speciálních tříd, tzv.
Provisioning Classes (PRC). Jedna z instancí takové třídy se označuje
Provisioning Instance (PRI) a obsahuje konfigurační údaje pro koncový bod PEP.
Díky tomuto rozšíření lze uvnitř rodiny standardů COPS definovat typy klientů,
sledujících různé koncepce QoS. IETF specifikuje v současnosti jediný typ COPS
klienta pro IPSec, o dalších se diskutuje.
Otázky a odpovědi Protokol COPS pracuje na základě jednoduchého schématu otázka-
odpověď, kterým se zajišťuje jednoznačná identifikace klienta i neustálá
informovanost COPS serveru o jeho stavu. Během vytváření spojení dochází k
výměně informací o schopnostech a omezeních klienta. Nakonec klient obvykle
klade požadavek na konfiguraci, na který server zpravidla odpovídá příslušným
rozhodnutím. Server také může možnost konfigurování odeslat klientovi aktivně
předem.
Protokol COPS umožňuje síťovým komponentám podporovat vícero typů klientů a pro
každého z nich vytvářet a udržovat spojení s jiným PDP. Výsledné řešení se
proto dá dobře odstupňovat. Pro každý typ klienta smí existovat vždy jen jedna
aktivní konfigurační informace. Klient však může disponovat vícero
konfiguracemi, které lze aktivovat přes COPS server. Standard ale nespecifikuje
ani vyjádření, ani způsob ukládání pravidel v paměti, třeba v jednom adresáři
nebo u klienta. Způsoby signalizace QoS a užití pravidel nechává COPS rovněž
otevřené.
Katalog pravidel
Definice tříd (PRC) pro konfiguraci klientů jsou ukládány do databáze pravidel
PIB (Policy Information Base), která je známá jak COPS serveru, tak i klientům.
Třídy každého PIB sestávají ze tří skupin: základní pro určování základních
funkcí, ze tříd pro určování charakteristiky přístroje a nakonec ze tříd
umožňujících klasifikaci s možností filtrace pro IP a Ethernet.
Vedle PIB, které definují nový způsob komunikace s PEP, specifikuje COPS také
běžné způsoby pro řízení komponent sítě, jako např. protokol SNMP. V dokumentu
COPS-MIB jsou standardizovány další funkce umožňující jednoduché řízení
klienta. Jelikož je už dnes většina síťových přístrojů schopna pracovat s SNMP,
lze touto cestou konfiguraci COPS v síti snadno šířit.
1 1326 / pen









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.