Fakulta elektrotechnická. Protokol IP

CˇESKE´ VYSOKE´ UCˇENI´ TECHNICKE´ Fakulta elektrotechnicka´

Semestra´lnı´ pra´ce z prˇedmeˇtu 37MK

Protokol IP

Vypracoval:

Alesˇ Va´vra

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Protokol IP Technologicky´m za´kladem, na ktere´m stojı´ cely´ dnesˇnı´ Internet, jsou protokoly TCP/IP (Transmission Control Protocol/Internet Protocol). Tato pocˇetna´ skupina protokolu˚, ktere´ se cˇasto rˇ´ıka´ take´ „rodina protokolu˚“ TCP/IP, pak ma´ svu˚j vlastnı´ za´klad, na ktere´m stavı´ a ze ktere´ho vycha´zı´. Je jı´m prˇenosovy´ protokol IP (Internet Protocol). Tento protokol je za´kladnı´m prˇenosovy´m mechanismem, ktery´ se stara´ o prˇenos dat, a cˇinı´ tak na nejnizˇsˇ´ı u´rovni spolecˇne´ pro vsˇechny sı´teˇ na ba´zi protokolu˚ TCP/IP. Protokol IP je ve sve´ podstateˇ jednotnou nadstavbou nad nejru˚zneˇjsˇ´ımi prˇenosovy´mi technologiemi, ktere´ zajisˇt’ujı´ skutecˇny´ (fyzicky´) prˇenos dat, naprˇ´ıklad nad Ethernetem, Token Ringem cˇi FDDI (Fiber Data Distributed Interface), nad dvoubodovy´mi spoji se´riove´ho typu, nad technologiı´ ATM (Asynchronous Transfer Mode) apod. Protokol IP vyuzˇ´ıva´ tyto mnohdy dosti odlisˇne´ prˇenosove´ technologie k tomu, aby vsˇude nabı´zel jednotne´ prˇenosove´ sluzˇby, stejny´ch kvalit i vlastnostı´, a zakry´val tak prˇ´ıpadna´ specifika toho, jak je urcˇita´ cˇa´st sı´teˇ fakticky realizova´na a jak doopravdy funguje.

Architektura TCP/IP Zkratka TCP/IP je obvykle cha´pa´na jen jako oznacˇenı´ dvou prˇenosovy´ch protokolu˚, pouzˇ´ıvany´ch v pocˇ´ıtacˇovy´ch sı´tı´ch, konkre´tneˇ protokolu˚ TCP a IP. Ve skutecˇnosti ale zkratka TCP/IP oznacˇuje celou skupinu protokolu˚, prˇicˇemzˇ TCP a IP jsou sice nejzna´meˇjsˇ´ı protokoly te´to skupiny, ale zdaleka ne jedine´. Prˇestozˇe architektura TCP/IP neodpovı´da´ rozvrstvenı´ podle referencˇnı´ho modelu ISO/OSI z hlediska komunikacˇnı´ch funkcı´ a hranic mezi nimi modelu OSI vcelku odpovı´da´. Na rozdı´l od sedmivrstve´ho referencˇnı´ho modelu OSI protokolovou architekturu TCP/IP tvorˇ´ı jen cˇtyrˇi vrstvy, ktery´mi jsou:

Obra´zek 1: Porovna´nı´ architektury TCP/IP s referencˇnı´m modelem OSI

• vrstva sı´t’ove´ho rozhranı´ – svy´mi funkcemi odpovı´da´ dveˇma nejnizˇsˇ´ım vrstva´m podle OSI fyzicke´ a spojove´. Ma´ na starosti vsˇe, co je spojeno s ovla´da´nı´m Semestra´lnı´ pra´ce

Va´vra Alesˇ

1

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

konkre´tnı´ prˇenosove´ cesty resp. sı´teˇ, a s prˇ´ımy´m vysı´la´nı´m a prˇ´ıjmem paketu˚. V ra´mci modelu TCP/IP nenı´ tato vrstva blı´zˇe specifikova´na, nebot’ je za´visla´ na pouzˇite´ prˇenosove´ technologii. • vrstva Internetu (mezisı´t’ova´ vrstva) – svy´mi funkcemi a sluzˇbami odpovı´da´ sı´t’ove´ vrstveˇ referencˇnı´ho modelu OSI (stara´ se o to, aby se jednotlive´ pakety dostaly od odesı´latele azˇ ke sve´mu skutecˇne´mu prˇ´ıjemci). Jejı´ funkce zahrnujı´ prˇedevsˇ´ım sı´t’ovou adresaci, smeˇrova´nı´ a prˇeda´va´nı´ datagramu˚ prˇes komunikacˇnı´ podsı´t’. • transportnı´ vrstva – transportnı´ vrstva odpovı´da´ transportnı´ vrstveˇ podle referencˇnı´ho modelu OSI, protozˇe poskytuje mechanismus pro koncovy´ prˇenos dat mezi dveˇma stanicemi. Nabı´zı´ transportnı´ sluzˇbu se spojenı´m za pouzˇitı´ protokolu TCP, nebo bez spojenı´ pomocı´ protokolu UDP. • aplikacˇnı´ vrstva – je nejvysˇsˇ´ı vrstvou sı´t’ove´ architektury TCP/IP a obsahuje vsˇechny protokoly poskytujı´cı´ uzˇivatelu˚m konkre´tnı´ aplikace. Aplikacˇnı´ protokoly podporujı´ jednak cˇisteˇ uzˇivatelske´ aplikace pro prˇenos souboru˚ a posˇtovnı´ch zpra´v, nebo pra´ci na vzda´lene´m zarˇ´ızenı´, a jednak administrativnı´ aplikace jako mapova´nı´ jmen a adres, management sı´teˇ apod.

Protokol IP verze 4 Protokol IP rˇ´ıdı´ vysı´la´nı´ datagramu˚ (TCP/IP pouzˇ´ıva´ mı´sto pojmu paket pro sı´t’ovou datovou jednotku pojem datagram) na za´kladeˇ sı´t’ovy´ch adres obsazˇeny´ch v jejich za´hlavı´ch a poskytuje sı´t’ovou sluzˇbu bez spojenı´. IP tedy nenavazuje spojenı´ pro prˇenos datagramu˚, ani neudrzˇuje zˇa´dne´ informace o datagramech, ktere´ prˇeda´va´ da´l. Kazˇdy´ datagram je samostatna´ datova´ jednotka, ktera´ musı´ obsahovat vsˇechny informace o adresa´tovi i odesı´lateli, cˇ´ıslo jeho porˇadı´ ve zpra´veˇ nebot’ datagramy se posı´lajı´ neza´visle na sobeˇ a porˇadı´ jejich dorucˇenı´ nemusı´ odpovı´dat porˇadı´ v jake´m byly odesla´ny. Dorucˇenı´ datagramu protokol IP nezarucˇuje, proto je tato sı´t’ova´ sluzˇba oznacˇova´na jako nespolehliva´, ale s nejlepsˇ´ı vu˚lı´ datagram dorucˇit (best effort). IP je nespolehlivy´ protokol, protozˇe v sobeˇ nema´ zabudovany´ zˇa´dny´ mechanismus pro detekci a korekci chyb v prˇena´sˇeny´ch datech (pouze kontroluje spra´vnost za´hlavı´ IP datagramu). Ma´ vsˇak snahu dodat data do cı´love´ sı´teˇ, ale nekontroluje zda skutecˇneˇ byla dorucˇena a prˇijata. Architektura TCP/IP nepouzˇ´ıva´ zˇa´dny´ spolehlivy´ protokol na sı´t’ove´ vrstveˇ, proto se spole´ha´ na protokoly vysˇsˇ´ıch vrstev, zˇe v prˇ´ıpadeˇ ztra´ty datagramu˚ zajistı´ jejich opeˇtovny´ prˇenos. Nespolehlivost IP vede k tomu, zˇe datagramy se mohou ztratit, mohou by´t duplikova´ny, prˇijı´t v jine´m porˇadı´ nebo se zpozˇdeˇnı´m, anizˇ by tyto proble´my IP sluzˇba detekovala. Forma´t datagramu IP verze 4 Podobneˇ jako kazˇdy´ jiny´ druh paketu cˇi ra´mce, ma´ i IP datagram (viz obra´zek 2) dveˇ za´kladnı´ cˇa´sti, a to rˇ´ıdı´cı´ cˇa´st tvorˇenou za´hlavı´m datagramu a datovou cˇa´st. Prˇi vlastnı´m prˇenosu se tento datagram vkla´da´ (jako data) do datove´ cˇa´sti ra´mce, se ktery´m pracuje bezprostrˇedneˇ nizˇsˇ´ı vrstva (vrstva sı´t’ove´ho rozhranı´). V za´hlavı´ jsou pak ru˚zne´ rˇ´ıdı´cı´ informace, potrˇebne´ pro dorucˇenı´ datagramu. Za´hlavı´ datagramu mu˚zˇe by´t maxima´lneˇ 60 oktetu˚ dlouhe´, ale beˇzˇneˇ se vyuzˇ´ıva´ minima´lnı´ de´lky za´hlavı´ 20 oktetu˚. Jednotliva´ pole datagramu majı´ na´sledujı´cı´ vy´znam: Semestra´lnı´ pra´ce

Va´vra Alesˇ

2

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Obra´zek 2: Forma´t datagramu protokolu IP verze 4

• Verze (version) – je prvnı´ polozˇkou za´hlavı´ IP datagramu. Tato polozˇka dlouha´ 4 bity obsahuje verzi IP protokolu. V te´to kapitole hovorˇ´ıme o IP protokolu verze 4, tudı´zˇ tato polozˇka je v nasˇem prˇ´ıpadeˇ rovna´ bina´rnı´ hodnoteˇ 4. • De´lka za´hlavı´ (header length) – indikuje de´lku za´hlavı´ jako pocˇet 32 bitovy´ch slov. Pole je dlouhe´ 4 bity, takzˇe jeho maxima´lnı´ hodnota je patna´ct 32 bitovy´ch slov, tedy 60 oktetu˚, a tı´m je da´na maxima´lnı´ de´lka za´hlavı´ IP datagramu. • Typ sluzˇby (ToS, Type of Service) – specifikuje (viz obra´zek 3a), jak ma´ smeˇrovacˇ zacha´zet s datagramem z hlediska priorit P (Precedence; prvnı´ 3 bity) a specificky´ch krite´riı´ v ra´mci kvality sluzˇby (na´sledujı´cı´ 4 bity), mezi neˇzˇ patrˇ´ı zpozˇdeˇnı´ D (delay), propustnost T (throughput), spolehlivost R (reliability) a cena C (cost). Lze tedy specifikovat datagram z hlediska minimalizace zpozˇdeˇnı´ cˇi ceny, nebo maximalizace propustnosti cˇi spolehlivosti, ale nedoporucˇuje se zˇa´dat o optimalizaci vı´ce jak dvou krite´riı´ najednou (implicitnı´ hodnota pole je 0000). Pole ToS se pouzˇ´ıva´ pro specifikaci priority dane´ho datagramu, moderneˇji pro doplnˇkovy´ mechanismus zajisˇteˇnı´ kvality sluzˇby (viz kapitola 1.5) prostrˇednictvı´m diferencovany´ch sluzˇeb, konkre´tneˇ ko´du DSCP (Differentiated Services Code Point). 6 bitu˚ DSCP (viz obra´zek. 3b) umı´ specifikovat azˇ 64 samostatny´ch sluzˇeb, poslednı´ dva bity jsou rezervova´ny pro pouzˇitı´ v aktualizacı´ch managementu nebo smeˇrova´nı´, nebo pro explicitnı´ ozna´menı´ o zahlcenı´ v IP sı´ti. • Celkova´ de´lka (total length) – toto pole uda´va´ de´lku cele´ho datagramu v oktetech (vcˇetneˇ za´hlavı´), ta mu˚zˇe by´t maxima´lneˇ 65 535 oktetu˚. De´lka datagramu je vzˇdy na´sobkem 32 bitu˚ (neˇkdy je proto potrˇeba doplnit do datagramu bity pro zarovna´nı´ tzv. padding) • Identifikace (identification) – identifikuje jednoznacˇneˇ datagram a pouzˇ´ıva´ se na podporu fragmentace, obvykle se hodnota zvysˇuje o jednicˇku pro kazˇdy´ dalsˇ´ı datagram.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

3

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Obra´zek 3: Struktura pole typ sluzˇby

• Na´veˇsti (flags) – pole v de´lce trˇ´ı bitu˚ (obr. 4), ktere´ jsou nutne´ pro fragmentaci; prvnı´ bit je vzˇdy nulovy´; druhy´ specifikuje, zda se datagram mu˚zˇe po cesteˇ fragmentovat, kde DF=1 znamena´ nefragmentovat (Don’t Fragment) a poslednı´ bit oznacˇuje, zda se jedna´ o poslednı´ fragment datagramu, kdy MF=1 znamena´, zˇe na´sledujı´ dalsˇ´ı fragmenty (More Fragments), a MF=0 znamena´ poslednı´ fragment.

Obra´zek 4: Struktura pole na´veˇsti

• Cˇı´slo fragmentu (fragment offset) – pole v de´lce 13 bitu˚ jednoznacˇneˇ urcˇuje porˇadı´ fragmentu v pu˚vodnı´m datagramu; a to za pomocı´ vzda´lenosti zacˇa´tku pole dat fragmentu od zacˇa´tku pu˚vodnı´ho datagramu v na´sobcı´ch 64 bitu˚. • Zˇivotnost (TTL, Time to Live) – uda´va´ maxima´lneˇ povoleny´ pocˇet skoku˚ v sı´ti, tedy pocˇet smeˇrovacˇu˚, ktery´mi je datagram posı´la´n da´le (osmibitove´ pocˇitadlo je nastavene´ ve zdrojove´ stanici a prˇi pru˚chodu smeˇrovacˇem se snizˇuje, pokud dosa´hne nuly, je datagram znicˇen). Specifikace zˇivotnosti datagramu slouzˇ´ı k vyloucˇenı´ nekonecˇne´ho bloudeˇnı´ neˇktery´ch datagramu˚ v sı´ti. • Protokol vysˇsˇı´ vrstvy (protocol) – obsahuje cˇ´ıselnou identifikaci protokolu vysˇsˇ´ı vrstvy (transportnı´ a smeˇrovacı´ protokoly a protokol hla´sˇenı´), ktery´ vyuzˇ´ıva´ datagram ke sve´mu transportu. • Zabezpecˇenı´ za´hlavı´ (header checksum) – kontrolnı´ soucˇet zabezpecˇujı´cı´ za´hlavı´ proti chyba´m, zabezpecˇuje se pouze za´hlavı´ a nikoli data. • Zdrojova´ adresa (source address) – 32 bitova´ adresa zdrojove´ stanice. • Cı´lova´ adresa (destination address) – 32 bitova´ adresa cı´love´ stanice. • Volitelne´ mozˇnosti (options) – dovolujı´ doplnit datagram o dalsˇ´ı informace, naprˇ. pro zabezpecˇenı´, za´znam cesty sı´tı´ nebo pro dodrzˇenı´ prˇedepsane´ cesty; vzhledem ke slozˇitosti zpracova´nı´ datagramu˚ obsahujı´cı´ch dalsˇ´ı informace, prˇedevsˇ´ım

Semestra´lnı´ pra´ce

Va´vra Alesˇ

4

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

ve smeˇrovacˇ´ıch, se toto pole veˇtsˇinou nepouzˇ´ıva´. Volitelne´ mozˇnosti jsou promeˇnne´ de´lky, proto neˇkdy musı´ na´sledovat vy´plnˇ (padding), ktera´ zarovna´ jejich de´lku do 32 bitu˚ nebo jejich na´sobku˚. • Prˇena´sˇena´ data (data) – obsahuje informace vysˇsˇ´ı vrstvy. Fragmentace Kazˇda´ sı´t’ma´ omezenı´ na maxima´lnı´ velikost datove´ jednotky, ktera´ po nı´ smı´ by´t vysla´na MTU (Maximum Transmission Unit). Termı´n MTU se ve skutecˇnosti pouzˇ´ıva´ na vsˇech vrstva´ch, nejtypicˇteˇji se ale MTU vztahuje k de´lce dat v ra´mci druhe´ vrstvy. Prˇi prˇechodu se sı´teˇ s veˇtsˇ´ım MTU do sı´teˇ s mensˇ´ım MTU je nutne´ prove´st fragmentaci (rozdeˇlenı´) pu˚vodnı´ho datagramu na neˇkolik mensˇ´ıch tak, aby se vesˇly do ra´mce podporovane´ho sı´tı´. Fragmentaci datagramu IPv4 do maxima´lneˇ povolene´ velikosti ra´mce na jednotlivy´ch sı´t’ovy´ch segmentech prova´deˇjı´ v prˇ´ıpadeˇ nutnosti smeˇrovacˇe, ale jen za prˇedpokladu, zˇe fragmentace nenı´ vysloveneˇ zaka´za´na, bitem DF obsazˇene´m v na´veˇsˇti . V tom prˇ´ıpadeˇ je smeˇrovacˇ nucen datagram znicˇit. Jednotlive´ fragmenty datagramu majı´ stejny´ forma´t jako „obycˇejne´“ datagramy, jsou jednoznacˇneˇ identifikova´ny (identification) a je urcˇeno jejich porˇadı´ (fragment offset, pozice v pu˚vodnı´m datagramu). Fragmenty se chovajı´ jako ostatnı´ datagramy a jsou smeˇrova´ny sı´tı´ naprosto neza´visle na sobeˇ. Mohou by´t dorucˇeny k cı´li v libovolne´m porˇadı´ a pro jejich opeˇtovne´ spra´vne´ slozˇenı´ do pu˚vodnı´ho datagramu slouzˇ´ı hodnoty pole fragment offset. Sestavova´nı´ fragmentu˚ do pu˚vodnı´ho datagramu se neprova´dı´ na cesteˇ v sı´ti, ale azˇ v koncove´m uzlu sı´teˇ. Smeˇrovacˇe po cesteˇ si fragmenty nijak nezaznamena´vajı´ do pameˇti. IP za´hlavı´ jednotlivy´ch fragmentu˚ obsahuje informace potrˇebne´ pro smeˇrova´nı´ fragmentu˚ sı´tı´. Sı´t’ova´ vrstva cı´love´ stanice je zodpoveˇdna´ za znovusestavenı´ datagramu, jeho kontrolu z hlediska IP funkcı´, odpouzdrˇenı´ IP za´hlavı´ a prˇeda´nı´ zbyly´ch dat vysˇsˇ´ı vrstveˇ. Pokud vsˇechny fragmenty nedorazı´ ve specifikovanou dobu, dosˇlo patrneˇ ke ztra´teˇ neˇktere´ho fragmentu po cesteˇ. Cı´lova´ stanice na´sledneˇ vsˇechny prˇijate´ fragmenty znicˇ´ı, protozˇe nemu˚zˇe sestavit pu˚vodnı´ datagram.

Protokol IP verze 6 Nova´ verze protokolu IP s cˇ´ıslem 6 (IPv6), byla vypracova´na v r. 1995 v du˚sledku jizˇ nedostatecˇne´ adresove´ a smeˇrovacı´ podpory prˇedchozı´ verze IPv4. Ru˚st na´roku˚ na nove´ adresy souvisı´ jednak s rozsˇirˇova´nı´m sı´tı´ a prˇipojova´nı´ se k Internetu, ale take´ s novy´mi inteligentnı´mi bezdra´tovy´mi koncovy´mi zarˇ´ızenı´mi. IPv6 podobneˇ jako IPv4 poskytuje datagramovou sluzˇbu, ale odlisˇuje se adresacı´ a forma´ty datagramu. Implementace IPv6 vyzˇaduje take´ zmeˇny v dalsˇ´ıch protokolech: ICMPv6 (Internet Control Message Protocol), smeˇrovacı´ch protokolech i v aplikacˇnı´ch protokolech. IPv6 sta´le nenı´ de facto normou, zatı´m je ve sta´diu na´vrhu normy. Vy´hody IPv6 oproti IPv4: – vy´razneˇ rozsˇ´ırˇeny´ adresnı´ prostor, – zjednodusˇenı´ forma´tu za´hlavı´ datagramu, – povinna´ podpora pro IPSec, – rozsˇ´ırˇena´ podpora pro mobilnı´ IP.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

5

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Datagram IP verze 6 IPv6 efektivneˇ prˇesouva´ volitelne´ informace do volitelny´ch rozsˇ´ırˇenı´ za´hlavı´. Povinne´ za´hlavı´ je fixnı´ de´lky 40 oktetu˚, ale obsahuje pouhy´ch osm polı´. Za povinny´m za´hlavı´m mohou na´sledovat dalsˇ´ı volitelna´ za´hlavı´, ktera´ jsou promeˇnne´ de´lky a jsou urcˇena bud’ pro zpracova´nı´ azˇ v koncovy´ch uzlech, nebo ve smeˇrovacˇ´ıch.

Obra´zek 5: Forma´t datagramu protokolu IP verze 6

Povinne´ za´hlavı´ Forma´t povinne´ho za´hlavı´ datagramu IPv6 s pevnou de´lkou 40 oktetu˚ se skla´da´ z na´sledujı´cı´ch polı´ (viz obra´zek 5): • Verze (version) – cˇ´ıslo verze protokolu. • Priorita (traffic class) – umozˇnˇuje zdroji identifikovat prioritu kazˇde´ho datagramu ve srovna´nı´ s ostatnı´mi datagramy od stejne´ho zdroje, prioritu z hlediska prˇenosu a z hlediska dorucˇenı´. • Oznacˇenı´ datove´ho toku (flow label) – oznacˇuje datagramy, vyzˇadujı´cı´ specia´lnı´ pe´cˇi prˇi zpracova´nı´ smeˇrovacˇi v sı´ti. Datovy´ tok je definova´n jako posloupnost datagramu˚ vyslany´ch z jednoho zdroje jednomu prˇ´ıjemci nebo skupineˇ prˇ´ıjemcu˚, pro neˇzˇ zdrojova´ stanice vyzˇaduje specia´lnı´ zacha´zenı´. Oznacˇenı´ datove´ho toku a prˇedchozı´ pole v za´hlavı´ umozˇnˇujı´ prˇ´ımo rˇesˇenı´ priority provozu a potrˇebne´ kvality sluzˇby, vcˇetneˇ rˇ´ızenı´ vyuzˇitı´ sˇ´ırˇky pa´sma. • De´lka dat (payload length) – uda´va´ de´lku zby´vajı´cı´ cˇa´sti datagramu, tj. de´lku vsˇech doplnˇkovy´ch za´hlavı´ a velikost datove´ho pole. Jelikozˇ je toto pole dlouhe´ 16 bitu˚, tak nejveˇtsˇ´ı de´lka prˇena´sˇene´ho IP datagramu mu˚zˇe by´t 65 535 oktetu˚. • Na´sledujı´cı´ za´hlavı´ (next header) – identifikuje typ za´hlavı´ bezprostrˇedneˇ na´sledujı´cı´ za povinny´m za´hlavı´m IPv6 datagramu.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

6

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

• Pocˇet skoku˚ (hop limit) – povoleny´ pocˇet zby´vajı´cı´ch pru˚chodu˚ smeˇrovacˇi na cesteˇ (obdoba pole TTL u IPv4), ktery´ kazˇdy´ smeˇrovacˇ na cesteˇ snı´zˇ´ı o jednicˇku (pokud dospeˇje k hodnoteˇ 0, nesmı´ datagram prˇedat da´l a musı´ vygenerovat zpra´vu ICMP). • Zdrojova´ adresa (source address) – adresa zdroje v de´lce 128 bitu˚. • Cı´lova´ adresa (destination address) – adresa zamy´sˇlene´ho prˇ´ıjemce v de´lce 128 bitu˚. Volitelna´ za´hlavı´ Za povinny´m za´hlavı´m IPv6 mohou na´sledovat neˇktera´ z volitelny´ch rozsˇirˇujı´cı´ch za´hlavı´. Pole na´sledujı´cı´ za´hlavı´ v povinne´m za´hlavı´ ukazuje jaky´ typ dat (jake´ za´hlavı´) na´sleduje za za´kladnı´m za´hlavı´m. Teoreticky mu˚zˇe ukazovat jizˇ na TCP segment nebo jiny´ protokol vysˇsˇ´ı vrstvy. Pokud ukazuje na dalsˇ´ı rozsˇirˇujı´cı´ za´hlavı´, pak i toto za´hlavı´ ma´ pole na´sledujı´cı´ za´hlavı´, ktere´ ukazuje na dalsˇ´ı za´hlavı´. Pokud dalsˇ´ı za´hlavı´ nena´sleduje specifikuje se transportnı´ protokol prostrˇednictvı´m cˇ´ısla protokolu. • Za´hlavı´ s mozˇnostmi skok od skoku (hop-by-hop options header) – toto pole obsahuje informace, ktere´ jsou urcˇeny pro smeˇrovacˇe prˇepravujı´cı´ datagram. Kazˇdy´ smeˇrovacˇ, ktery´ datagram prˇeda´va´ se musı´ tı´mto polem zaby´vat. • Za´hlavı´ s mozˇnostmi pro cı´lovou stanici (destination options header) – obsahuje volitelne´ informace pro cı´lovou stanici nebo vsˇechny cı´le podle smeˇrovacı´ho za´hlavı´. • Smeˇrovacı´ za´hlavı´ (routing header) – toto pole slouzˇ´ı odesı´lateli pro specifikaci adres smeˇrovacˇu˚, ktere´ musı´ by´t na cesteˇ navsˇtı´veny, cı´lova´ stanice musı´ pak toto za´hlavı´ pouzˇ´ıt pro cestu zpeˇt v obra´cene´m porˇadı´. • Za´hlavı´ pro fragmentaci (fragment header) – obsahuje informace urcˇene´ pro fragmentaci a znovusestavova´nı´ datagramu˚. Fragmentace vsˇak mu˚zˇe by´t provedena pouze ve zdrojove´ stanici, nikoli po cesteˇ smeˇrovacˇi, proto zdrojova´ stanice musı´ by´t schopna zjistit maxima´lnı´ velikost povolene´ datove´ jednotky na cesteˇ k cı´love´ stanici, aby datagram nebyl znicˇen. • Autentizacˇnı´ za´hlavı´ (authentication header) – zabezpecˇuje integritu a veˇrohodnost datagramu. • Za´hlavı´ zabezpecˇenı´ zapouzdrˇenı´ dat (encapsulating security payload) – zajisˇt’uje ochranu prˇena´sˇeny´ch dat v datagramu v kombinaci se zajisˇteˇnı´m autenticity a integrity dat. Zmeˇny oproti IPv4 Protokol IPv6 rˇesˇ´ı proble´m s IP adresami tak, zˇe mı´sto pu˚vodnı´ch 32 bitovy´ch adres pouzˇ´ıva´ adresy 128 bitove´. Prˇitom vsˇak nejde jen o pouhe´ mechanicke´ zveˇtsˇenı´ rozsahu adres, protozˇe to by jizˇ dnes nestacˇilo. Kromeˇ proble´mu s pocˇtem IP adres se za celou dobu existence protokolu˚ TCP/IP nastrˇa´dalo mnoho dalsˇ´ıch proble´mu˚ (cˇi alesponˇ pozˇadavku˚). Proto IPv6 prˇina´sˇ´ı mnoho dalsˇ´ıch zmeˇn oproti IPv4, a ne pouze novou velikost adres.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

7

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Kromeˇ samotne´ho rozsˇ´ırˇenı´ IP adres prˇina´sˇ´ı nova´ verze i mnohem propracovaneˇjsˇ´ı mozˇnosti prˇideˇlova´nı´ IP adres uzlu˚m sı´teˇ (vcˇetneˇ mozˇnosti dynamicke´ho prˇecˇ´ıslova´va´nı´). Protokol IPv6 umozˇnˇuje aplikovat ru˚zne´ strategie prˇideˇlova´nı´ IP adres i obecneˇjsˇ´ıho konfigurova´nı´ sı´t’ovy´ch uzlu˚. Naprˇ´ıklad takovy´m zpu˚sobem, zˇe konkre´tnı´ uzel si svou IP adresu urcˇ´ı sa´m, z cˇa´sti podle sve´ fyzicke´ (linkove´) adresy, a z cˇa´sti podle toho, co doka´zˇe zjistit o svy´ch sousedech. Pouzˇitı´ veˇtsˇ´ıch IP adres by mohlo take´ va´zˇny´m zpu˚sobem zhorsˇit proble´m s rozsahem smeˇrovacı´ch informacı´, nutny´ch pro dosazˇitelnost vsˇech uzlu˚ v jake´koli sı´ti. Zde je navı´c nutne´ pocˇ´ıtat s dalsˇ´ım zveˇtsˇova´nı´m pocˇtu˚ uzlu˚ (zejme´na v Internetu). Jako jedina´ mozˇnost se proto ry´suje tzv. hierarchicke´ smeˇrova´nı´, tedy jake´si „patrove´“ smeˇrova´nı´, kdy existujı´ ru˚zne´ u´rovneˇ „podrobnostı´ “ smeˇrovacı´ch informacı´. To znamena´ ,zˇe cˇ´ım je neˇjaka´ smeˇrovacı´ informace detailneˇjsˇ´ı, tı´m vı´ce zu˚sta´va´ lokalizova´na respektive tı´m me´neˇ je rozesı´la´na na vsˇechny strany. Dalsˇ´ı za´sadnı´ zmeˇnou je zabudova´nı´ prostrˇedku˚ na podporu ru˚zne´ho zpracova´nı´ ru˚zny´ch druhu˚ dat, vcˇetneˇ prˇednostnı´ho zpracova´nı´ urcˇity´ch druhu˚ dat (naprˇ´ıklad multimedia´lnı´ch prˇenosu˚, ktere´ vyzˇadujı´ dodrzˇova´nı´ pomeˇrneˇ prˇ´ısny´ch cˇasovy´ch krite´riı´, naprˇ´ıklad celkove´ho zpozˇdeˇnı´ cˇi pravidelnosti v dorucˇova´nı´). Veˇtsˇ´ı pozornost je v ra´mci protokolu IPv6 veˇnova´na i ota´zce bezpecˇnosti a zabezpecˇenı´ prˇenosu˚, zachova´nı´ integrity prˇena´sˇeny´ch dat. Sta´vajı´cı´ verze protokolu IP sice umozˇnˇuje urcˇita´ rozsˇ´ırˇenı´, ale ne v takove´ mı´rˇe, jaka´ by dnes byla zapotrˇebı´. Nova´ verze jde v tomto ohledu mnohem da´le a je sna´ze a efektivneˇji rozsˇirˇitelna´ o dalsˇ´ı funkce a vlastnosti.

Protokoly transportnı´ vrstvy Sı´t’ova´ vrstva, ktera´ poskytuje sluzˇby adresace a smeˇrova´nı´ datagramu˚, nezajisˇt’uje dorucˇenı´ datagramu˚ adresa´tu˚m, ani nezajisˇt’uje porˇadı´ jejich dorucˇenı´ cˇi dobu jejich dorucˇenı´. Proto nad sı´t’ovou vrstvou musı´ existovat vrstva starajı´cı´ se o koncovy´ prˇenos datovy´ch jednotek mezi odesı´latelem a prˇ´ıjemcem. Sluzˇba kterou tato vrstva nabı´zı´ vysˇsˇ´ım vrstva´m, mu˚zˇe by´t bud’ spolehliva´, nebo nespolehliva´. U TCP/IP se tato vrstva oznacˇuje jako transportnı´. Odpovı´da´ v podstateˇ transportnı´ vrstveˇ OSI, protozˇe poskytuje mechanismus pro koncovy´ prˇenos dat mezi dveˇma stanicemi. Nabı´zı´ transportnı´ sluzˇbu se spojenı´m nebo bez spojenı´ za pouzˇitı´ jednoho ze dvou protokolu˚. – Transmission Control Protocol (TCP) je transportnı´ protokol se spojenı´m. Poskytuje logicke´ spojenı´ mezi koncovy´mi aplikacemi, tedy spolehlivy´ prˇenos dat, ktery´ nebyl zajisˇteˇn datagramoveˇ orientovany´m IP. TCP vyuzˇ´ıva´ ke sve´ pra´ci aplikacˇnı´ protokoly vyzˇadujı´cı´ spolehlivou transportnı´ sluzˇbu jako naprˇ. FTP (File Transfer Protocol) cˇi TELNET. – User Datagram Protokol (UDP) je velmi jednoduchy´ transportnı´ protokol. UDP poskytuje nespolehlivou transportnı´ sluzˇbu bez spojenı´ pro ty aplikace, ktere´ od transportnı´ho protokolu nepozˇadujı´ zabezpecˇenı´ prˇenosu v takove´m rozsahu, jako je poskytuje TCP.

Kvalita sluzˇby v IP Kvalita sluzˇby (QoS, Quality of Service) je podle doporucˇenı´ ITU-T E.800 definova´na jako „souhrnny´ vy´sledek vy´konnosti sluzˇby, ktery´ urcˇuje stupenˇ spokojenosti uzˇivatele

Semestra´lnı´ pra´ce

Va´vra Alesˇ

8

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

sluzˇby.“ Vzhledem ke slozˇitosti definice pojmu „spokojenost uzˇivatele“, se veˇtsˇinou kvalita sluzˇby v prostrˇedı´ IP, charakterizuje vy´konnostı´ toku paketu˚ jednou nebo vı´ce sı´teˇmi. Cı´lem je dorucˇit pakety mezi koncovy´mi uzˇivateli podle urcˇity´ch krite´riı´. Kvalita sluzˇby prˇedstavuje kombinaci parametru˚. Mezi konkre´tnı´ dı´lcˇ´ı technicke´ sı´t’ove´ parametry pak patrˇ´ı ztra´ta paketu˚, zpozˇdeˇnı´ a jeho kolı´sa´nı´. Ztra´ta paketu˚ Ztra´ta paketu˚ v sı´ti mu˚zˇe mı´t nejru˚zneˇjsˇ´ı prˇ´ıcˇiny, ale veˇtsˇinou je du˚vodem prˇetı´zˇenı´ a zahlcenı´ sı´teˇ, kdy neˇktere´ smeˇrovacˇe nebo prˇepı´nacˇe nestacˇ´ı odbavovat prˇ´ıchozı´ pakety dostatecˇneˇ rychle, jejich fronty ve vyrovna´vacı´ch pameˇtech prˇetecˇou a dalsˇ´ı pakety musı´ by´t zahozeny. Ztra´ta paketu˚ prˇi aplikacı´ch neprobı´hajı´cı´ch v rea´lne´m cˇase nenı´ dobra´, ale nenı´ ani kriticka´. Aplikace zalozˇene´ na spolehlive´m transportnı´m protokolu TCP doka´zˇ´ı tolerovat urcˇite´ ztra´ty paketu˚, protozˇe se mohou spolehnout na jejich opeˇtovne´ vysla´nı´. Naproti tomu aplikace pracujı´cı´ v rea´lne´m cˇase, pouzˇ´ıvajı´cı´ nespolehliva´ transportnı´ protokol UDP, jsou citliveˇjsˇ´ı na ztra´tu paketu˚, protozˇe nejen zˇe jim chybı´ mechanismus pro opeˇtovne´ vysla´nı´ paketu˚, ale veˇtsˇinou by jim pozdeˇjsˇ´ı dorucˇenı´ paketu˚ nebylo moc platne´, naprˇ. hlasova´ konverzace. Zpozˇdeˇnı´ Zpozˇdeˇnı´ je doba, kterou paketu trva´ dostat se od zdroje k prˇ´ıjemci, tedy prˇekonat cestu sı´tı´ mezi koncovy´mi zarˇ´ızenı´mi. Zpozˇdeˇnı´ se skla´da´ ze zpozˇdeˇnı´ ko´dova´nı´m a serializacı´ a zpozˇdeˇnı´ prˇi prˇenosu (to jsou pevne´ hodnoty), a zpozˇdeˇnı´ ve fronteˇ na odbavenı´ a zpozˇdeˇnı´ prˇi prˇepı´na´nı´ v sı´ti, ktera´ se dynamicky meˇnı´. Kolı´sa´nı´ zpozˇdeˇnı´ Pakety nemusı´ v ra´mci dane´ konverzace prˇicha´zet od te´hozˇ zdroje vsˇechny se stejny´m zpozˇdeˇnı´m. Kolı´sa´nı´ zpozˇdeˇnı´ (jitter) je zpu˚sobeno zpozˇdeˇnı´m prˇi serializaci paketu˚ na pomaly´ch spojı´ch, rozdı´lech v de´lka´ch front v souvislosti se zahlcenı´m sı´teˇ. Chybovost Pakety jsou neˇkdy beˇhem cesty posla´ny sˇpatny´m smeˇrem, nebo smı´cha´ny dohromady, nebo narusˇeny. Prˇ´ıjemce toto musı´ detekovat, pokud byl paket zahozen pozˇa´da´ odesı´latele o jeho znovuvysla´nı´. V soucˇasne´ dobeˇ existujı´ dva hlavnı´ prˇ´ıstupy k implementaci QoS v IP. Jsou jimi: – Integrovane´ sluzˇby (Integrated services, ve zkratce IntServ) – Rozlisˇovane´ sluzˇby (Differentiated services, ve zkratce DiffServ) Integrovane´ sluzˇby V prˇ´ıpadeˇ integrovany´ch sluzˇeb aplikace ozna´mı´ pocˇ´ıtacˇove´ sı´ti sve´ pozˇadavky na prˇenos dat, neboli prˇ´ımo pozˇaduje urcˇitou kvalitu sluzˇby, naprˇ´ıklad urcˇitou minima´lnı´ propustnost a urcˇite´ maxima´lnı´ zpozˇdeˇnı´. Pocˇ´ıtacˇova´ sı´t’oveˇrˇ´ı zda je k dispozici dostatek prostrˇedku˚ pro uspokojenı´ pozˇadavku a rozhodne, zda pozˇadavku˚m vyhovı´ (admission control). V prˇ´ıpadeˇ, zˇe sı´t’nemu˚zˇe pozˇadavku˚m vyhoveˇt, spojenı´ nenı´ provedeno a aplikace se mu˚zˇe rozhodnout, zda pozˇa´da´ o me´neˇ na´rocˇnou kvalitu sluzˇby

Semestra´lnı´ pra´ce

Va´vra Alesˇ

9

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

poskytovanou sı´tı´. Pokud je pozˇadavku˚m vyhoveˇno, sı´t’musı´ o pozˇadavcı´ch informovat vsˇechny komponenty, naprˇ´ıklad smeˇrovacˇe v uzlech sı´teˇ, prˇes ktere´ bude probı´hat spojenı´, aby mohly pro dane´ spojenı´ rezervovat odpovı´dajı´cı´ objem prostrˇedku˚. Naprˇ´ıklad urcˇitou sˇ´ırˇku pa´sma spoje mezi dveˇma smeˇrovacˇi, urcˇitou velikost fronty paketu˚ uvnitrˇ smeˇrovacˇe, apod. K tomuto u´cˇelu slouzˇ´ı rezervacˇnı´ protokoly. Na podporu zajisˇteˇnı´ sˇ´ırˇky pa´sma pro urcˇity´ tok IP datagramu˚ existuje protokol pro rezervaci prostrˇedku˚ RSVP (Resource Reservation Protocol). Protokol vyuzˇ´ıva´ cı´lova´ stanice, ktera´ ocˇeka´va´ urcˇita´ data a chce si pro neˇ zajistit zarucˇeny´ pru˚chod sı´tı´. Protokol pak postupneˇ signalizacı´ zajisˇt’uje po cele´ cesteˇ sı´tı´ vsˇemi smeˇrovacˇi azˇ ke zdrojove´ stanici, zda vyzˇa´dana´ sˇ´ırˇka pa´sma mu˚zˇe by´t pro dany´ tok prˇideˇlena. Protokol garantuje sˇ´ırˇku pa´sma prostrˇednictvı´m vybudova´nı´ cesty mezi koncovy´mi uzly s dohodnuty´mi parametry ve specifikaci toku (data flow) v kazˇde´m smeˇrovacˇi nebo prˇepı´nacˇi na trˇetı´ vrstveˇ. Vzhledem k za´teˇzˇi propojovacı´ch zarˇ´ızenı´ zpu˚sobene´ sledova´nı´m stavu kazˇde´ rezervace pomocı´ RSVP ma´ protokol uplatneˇnı´ jen v mensˇ´ıch sı´tı´ch, nejle´pe v prˇ´ıstupovy´ch sı´tı´ch. RSVP je take´ preferovany´m mechanismem pro signalizaci QoS v podnikovy´ch sı´tı´ch, zejme´na pro sluzˇby typu hlas po IP a video po IP. RSVP nabı´zı´ jedinecˇnou prˇednost v tom, zˇe neprˇipousˇtı´ zˇa´dny´ nadbytecˇny´ paket, a pa´smo je tak dostupne´ pro jine´ vola´nı´ nebo spojenı´ po te´zˇe cesteˇ. Tento protokol je vsˇak pomeˇrneˇ slozˇity´, prˇina´sˇ´ı vy´znamnou rezˇii prˇi rˇ´ızenı´ chodu sı´teˇ. Proto se v poslednı´ dobeˇ objevujı´ na´vrhy jednodusˇsˇ´ıch rezervacˇnı´ch protokolu˚. Jejich implementace jsou vsˇak zatı´m jen experimenta´lnı´, nejsou beˇzˇneˇ k dispozici ve smeˇrovacˇ´ıch vy´znamny´ch vy´robcu˚. Acˇkoliv mozˇnost prˇesne´ specifikace pozˇadovane´ QoS je la´kava´, ukazuje se, zˇe tento prˇ´ıstup je prˇ´ılisˇ restriktivnı´ a jeho implementace prˇina´sˇ´ı ˇ ada interaktivnı´ch aplikacı´ nepotrˇebuje nutneˇ zajistit urcˇitou velkou cˇasovou rezˇii. R konkre´tnı´ pru˚chodnost nebo minima´lnı´ zpozˇdeˇnı´. Postacˇ´ı, kdyzˇ bude zajisˇteˇno, zˇe tyto parametry nebudou vy´razneˇ zhorsˇeny vlivem jine´ komunikace, kde je odezva vnı´ma´na uzˇivatelem mnohem citliveˇji. Navı´c, prˇi sta´le se zvysˇujı´cı´ch rychlostech pru˚chodu paketu˚ smeˇrovacˇi je trˇeba maxima´lneˇ zjednodusˇit zpracova´nı´ jednotlivy´ch procha´zejı´cı´ch paketu˚ a minimalizovat objem stavove´ informace (jakou je naprˇ´ıklad rezervace urcˇite´ QoS), kterou musı´ smeˇrovacˇe o jednotlivy´ch spojenı´ch udrzˇovat. Rozlisˇovane´ sluzˇby V poslednı´ dobeˇ pozornost obracı´ vı´ce k jine´mu prˇ´ıstupu implementace QoS, a to k rozlisˇovany´m sluzˇba´m. Na rozdı´l od integrovany´ch sluzˇeb vycha´zejı´ poskytovane´ sluzˇby z principu relativnı´ch priorit v prostrˇedı´ nespojovane´ sı´teˇ. Datove´ toky jsou agregova´ny do trˇ´ıd podle stejne´ho typu sluzˇby, takzˇe sı´t’ove´ prvky (s vy´jimkou hranicˇnı´ch) se nemusı´ starat o kazˇdy´ datovy´ tok zvla´sˇt’. Kazˇdy´ IP paket vstupujı´cı´ do sı´teˇ je oznacˇen znacˇkou, ktera´ rˇ´ıka´, jak ma´ by´t s paketem zacha´zeno, neboli urcˇuje trˇ´ıdu prˇenosu poskytnutou paketu. Mı´sto v za´hlavı´ IP datagramu urcˇene´ pro tuto znacˇku se nazy´va´ DSCP. Toto oznacˇenı´ probı´ha´ jen na vstupu do pocˇ´ıtacˇove´ sı´teˇ na tzv. ingress smeˇrovacˇi. Beˇhem prˇenosu paketu˚ pocˇ´ıtacˇovou sı´tı´ dalsˇ´ı smeˇrovacˇe pouze prˇecˇtou znacˇku kazˇde´ho paketu a rˇ´ıdı´ se podle nı´ prˇi zpracova´nı´ paketu. Pocˇet znacˇek je relativneˇ maly´. Smeˇrovacˇe prˇideˇlı´ urcˇite´ prostrˇedky kazˇde´ trˇ´ıdeˇ prˇenosu a zajisˇt’ujı´ urcˇity´ vztah mezi jednotlivy´mi trˇ´ıdami. Takto rozlehla´ sı´t’se nazy´va´ diffserv dome´na. Rozlehla´ pocˇ´ıtacˇova´ sı´t’ mu˚zˇe by´t rozdeˇlena na neˇkolik propojeny´ch diffserv dome´n. V kazˇde´ z nich probı´ha´ zpracova´nı´ paketu˚ samostatneˇ.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

10

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Obra´zek 6: Diffserv dome´na

Zpracova´nı´ paketu˚ smeˇrovacˇem na za´kladeˇ znacˇky paketu je oznacˇova´no jako PHB (PerHop-Behaviour).V soucˇasne´ dobeˇ jsou standardizovana´ dveˇ PHB: • Urychlene´ prˇeda´va´nı´ (EF, Expedited Forwarding) – nabı´zı´ absolutnı´ za´ruky na kolı´sa´nı´ zpozˇdeˇnı´ pro trˇ´ıdu provozu, je proto velmi slozˇite´ na zajisˇteˇnı´ a neefektivnı´, protozˇe poskytnutı´ sluzˇby EF dane´mu toku odpovı´da´ poskytnutı´ virtua´lnı´ho okruhu, cozˇ vede k nizˇsˇ´ımu vyuzˇitı´ sı´t’ovy´ch prostrˇedku˚. EF lze tedy poskytovat jen omezene´mu pocˇtu toku˚. EF PHB je vhodne´ pro implementaci virtua´lnı´ho pronajate´ho okruhu. • Zajisˇteˇne´ prˇeda´va´nı´ (AF, Assured forwarding) – umozˇnˇuje zarˇadit pakety do jedne´ ze cˇtyrˇ trˇ´ıd. Kazˇde´ trˇ´ıdeˇ je ve smeˇrovacˇ´ıch prˇideˇlen urcˇity´ objem prostrˇedku˚, naprˇ´ıklad velikost vyrovna´vacı´ pameˇti nebo kapacita vy´stupnı´ linky. V ra´mci kazˇde´ trˇ´ıdy pak mu˚zˇe by´t kazˇde´mu paketu prˇirˇazena jedna ze trˇ´ı priorit zahozenı´ paketu (drop precedence), ke ktere´mu mu˚zˇe dojı´t v prˇ´ıpadeˇ zahlcenı´. Smeˇrovacˇ musı´ odeslat paket majı´cı´ nizˇsˇ´ı hodnotu priority se stejnou nebo vysˇsˇ´ı pravdeˇpodobnostı´ nezˇ paket majı´cı´ vysˇsˇ´ı hodnotu priority. AF PHB se pouzˇ´ıva´ pro implementaci sluzˇeb, u ktery´ch je potrˇeba volitelna´ u´rovenˇ kvality prˇenosu. Rozdı´ly mezi IntServ a DiffServ IntServ (Integrated Services) spolu s protokolem RSVP poskytuje velmi jemne´ koncove´ garance sluzˇeb, ale potrˇebuje k tomu u´cˇast vsˇech smeˇrovacˇu˚, ktere´ musı´ udrzˇovat informaci o stavu kazˇde´ho toku paketu˚ a objem teˇchto stavovy´ch informacı´ s pocˇtem toku˚ za´koniteˇ roste. To se promı´ta´ do pozˇadavku˚ na pameˇt’ovou a procesnı´ kapacitu smeˇrovacˇu˚ a jejich slozˇitost. IntServ lze uplatnit naprˇ´ıklad v podnikove´ sı´ti ale ne v Internetu. DiffServ (Differentiated Services) poskytuje urcˇity´ druh diskriminace v za´vislosti na platbeˇ za sluzˇbu. Trˇ´ıdy provozu jsou prˇeddefinovane´ agrega´ty provozu, a tak jsou dostupne´ bez potrˇeby zvla´sˇtnı´ signalizace v sı´ti. Klasifikaci prova´deˇjı´ koncove´ syste´my, takzˇe management sı´teˇ je pro DiffServ jednodusˇsˇ´ı nezˇ u IntServ. To je ale do jiste´ mı´ry soucˇasneˇ nevy´hodou, protozˇe DiffServ za cenu jednoduchosti pra´ce sı´teˇ prˇesouva´ slozˇitost fungova´nı´ sı´teˇ k jejı´mu okraji (do oblasti poskytova´nı´ sı´teˇ a sluzˇeb konfigurace). DiffServ lze uplatnit i v rozsa´hly´ch sı´tı´ch, protozˇe mı´sto sledova´nı´ jednotlivy´ch toku˚ paketu˚ v sı´ti sleduje pouze agregovany´ provoz.

Semestra´lnı´ pra´ce

Va´vra Alesˇ

11

Cˇeske´ vysoke´ ucˇenı´ technicke´ v Praze

Fakulta elektrotechnicka´

Literatura [1] Puzˇmanova´, R.:TCP/IP v kostce, Kopp, Cˇeske´ Budeˇjovice, 2004 ´ vod do problematiky. Technicka´ zpra´va TEN–155 [2] Ubik, S.:QoS a diffserv – U CZ cˇ´ıslo 6/2000, http://www.ten.cz/doc/techzpravy/2000-6/diffserv.html, za´rˇ´ı 2000. [3] http://www.earchiv.cz

Semestra´lnı´ pra´ce

Va´vra Alesˇ

12