11. Átviteli réteg

(1)

UNIVERSITY OF SZEGED

D

epartment of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

11. Átviteli réteg

Dr. Bilicki Vilmos

Szoftverfejlesztés Tanszék

(2)

D

Tartalom

 ACL

 TCP/IP szállítási réteg

■ Bevezető

■ Viszony felépítés, menedzselés, befejezés

■ Három fázisú kézfogás

■ DOS

■ TCP szegmens

■ UDP szegmens

■ Torlódás vezérlés

■ Ablakozás

– Tachoe – Reno – Vegas

 Várakozási sor menedzselő algoritmusok

■ FIFO

■ RED

■ WRED

 NAT

 QoS

22-05-12 Számítógép Hálózatok 2

(3)

D

Források

 TCP/UDP

■ CCNA1 11

■ CCNA2 10

■ CCNP3 8

■ CCNP1 1

■ TCP : http://www.hep.ucl.ac.uk/~ytl/tcpip/background/tahoe-reno.html

 NAT

■ STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

http://www.faqs.org/rfcs/rfc3489.html

■ http://www.faqs.org/rfcs/rfc3027.html

■ Traditional IP Network Address Translator (Traditional NAT) http://www.faqs.org/rfcs/rfc3022.html

■ The IP Network Address Translator (NAT) http://www.faqs.org/rfcs/rfc1631.html

 QoS

■ http://www.cs.huji.ac.il/course/2005/com1/Presentations/Lessons/qos.pdf

■ http://www.cs.cmu.edu/afs/cs/academic/class/15441f01/www/lectures/lecture22.ppt

(4)

D

Bevezető

 IP

■ Legjobb szándék szerinti továbbítás

– Csomag vesztés – Sorrend csere

■ Aggregálás (1000 -> 10)

– Torlódás

■ Egy csomópont-egy cím (SNAP !)

– Több processz is futhat egy csomóponton

 Megoldások:

■ TCP

– Transmission Control Protocol

■ UDP

– Unacknowledged Transport Protocol

(5)

D

Miért kell torlódás vezérlés

 1986 októbere, az Internet első torlódásos összeomlása

■ Berkeley – LBL

■ 400 jard, 3 ugrás, 32 kbps

■ Az átvitel 1000-ed részére csökkent: 40 bps

 1988 Van Jacobson: TCP torlódás vezérlés

■ Ablakozó mechanizmus ACK segítségével

■ Vég-Vég

(6)

D

Transmission Control Protocol - TCP

 Egyszerű, robosztus

 Tulajdonságai:

■ Vég-Vég vezérlés

■ Viszony kezelés

■ Sorrendhelyes átvitel

■ Torlódás vezérlés

(7)

D

TCP szegmens formátum

(8)

D

UDP szegmens formátum

(9)

D

Portok

 1024 alatt jól ismert portok

 1024 fölött dinamikus

(10)

D

TCP viszony felépítés

 Három fázisú kézfogás

■ Szekvencia számok?

(11)

D

TCP ablakozás

 A sávszélesség adott

 Az átlagsebességet kell belőni

(12)

D

TCP Torlódás Vezérlés

 Ablak alapú vég-vég folyam vezérlés, a cél ACK csomaggal nyugtáz minden rendesen megérkezett csomagot. A forrás ezek hatására megnöveli az ablakot

(13)

D

TCP torlódás vezérlés

 Vég-Vég

■ Tachoe (Jacobson 1988)

– Slow start

– Congestion avoidance – Fast retransmit

■ Reno (Jacobson 1990)

– Fast recovery

■ Vegas (Bramko&Peterson 1994)

– Új torlódás elkerülő algoritmus

 Köztes csomópontok

■ RED (Floyd&Jacobson 1993)

■ REM (Athuraliya&Low 2000)

■ …

(14)

D

Tachoe

 Slow start

■ cwnd = 1, cwnd = cwnd + 1

■ cwnd < sstresh

(15)

D

Tachoe

 Congestion avoidance

■ cwnd >= sstersh

■ cwnd = cwnd + 1/cwnd

(16)

D

Tachoe

 Csomag vesztés

■ A torlódás jelének tekinti

■ Duplikált ACK

(17)

D

Tachoe

 Fast retransmit

■ A 3 ACK után mindjárt küldi

■ flightsize = min(awnd, cwnd)

■ sstersh = max(flightsize/2,2)

■ Slow start cwnd = 1

(18)

D

TCP reno

(19)

D

TCP Vegas

(20)

D

Denial of Service

(21)

D

NAT

 IP címek kimerülőben vannak

 Cím újrahasznosítás

■ DHCP

■ Network Address Translation

 RFC 1631(1994 – rövid távú megoldás!)

■ A csonk tartományokban a klienseknek csak nagyon kis része folytat kommunikációt a külvilággal (ez ma már nem feltétlenül igaz!)

– Belül privát cím tartomány – Kívül publikus cím tartomány

■ A TCP csomag fejlécében módosítani kell az ellenőrző összeget

■ Egyes protokolloknál le ki kell cserélni a címeket

■ A többit majd meglátjuk

(22)

D

Port Address Translation

 IP/port – IP/port

 Elnevezések:

■ Cisco – Port Address Translation

■ Network Address and Port Translation NAPT

■ IP masquerading

■ IP overloading

(23)

D

NAT TCP Terhelés elosztás

 Több különböző szerver ugyanazon az IP címen van meghirdetve

 A NAT ezek között különböző algoritmus szerint osztja a forgalmat (replikált

szerverek)

 Hasonlít a DNS megoldáshoz csak jobb mert a host gyorstárazhatja a DNS bejegyzést

 Csak az új TCP kapcsolatokra érvényes

 Nem robosztus (a NAT nem tudja melyik

szerver működok és melyik nem…)

(24)

D

NAT és Virtuális Szerverek

 Több különböző szervert/szolgáltatást tud egy címen kiajánlani

(25)

D

NAT

 Az Internetet független cím adminisztrációs zónákra osztja

 Az Internet sikere egyszerűségében rejlik

■ Vég-Vég (egyes funkciók csak a végpontokon végezhetőek el)

■ Nincs kapcsolatonkénti információ (állapotmentes)

■ Csak a végpontok menedzselnek állapotot (skálázható)

■ Az új alkalmazások minden további nélkül használhatóak

 A NAT ellentmond ezeknek az elveknek

■ Ha a NAT kiesik miden megszűnik

■ Ha újraindul, minden elveszik

 A tűzfal is ellentmond, de az azért mert ez a feladata

(26)

D

A NAT előnyei

 Az IP cím kiosztás független a szolgáltatótól (szolgáltató váltás)

 Sokkal nagyobb cím tartományunk van mint amekkorát kaphatnánk

 Csak az aktív csomópontoknak kell külső IP cím

 A csomagszűrő tűzfalakhoz hasonlóan semmit sem enged be ami nincs

megengedve

(27)

D

Problémák a NAT-tal

 Nem illik az Internet flexibilis vég-vég modelljébe

 Adott protokollokat ellehetetlenít

 Egy meghibásodási pont

 A Multihoming-ot megnehezíti

 A Privát címek használata cég

egyesüléseknél ,VPN-nél problémát okozhat

 A NATP, RSIP problémákat okozhat a publikus szolgáltatások esetén

 A beágyazott IP címet hordozó protokollok problémásak

 Hamis biztonság érzetét keltheti

(28)

D

Tipikus NAT variációk

 Teljes terelő (Full Cone)

■ Minden kérésnél a belső cím/port ugyanarra a külső cím/port-ra van kötve

■ Külső host a külső címre küldve tud a belsővel kommunikálni

 Szabályozott terelő (Restricted Cone)

■ Ugyanaz mint az előző, csak a külső alkalmazás csak akkor tud a belsővel kapcsolatba lépni, ha a belső ezt

kezdeményezi

 Port szabályozott terelő (Port Restricted Cone)

■ Ugyanaz mint az előző, csak portokra is vonatkozik

 Szimmetrikus

■ A külső címzettől függő cím hozzárendelés

■ Csak a csomagot megkapó külső címzett tud UDP választ küldeni

(29)

D

QoS Motiváció

 Az Internet jelenleg csak egy szolgáltatás osztályt támogat: “best-effort” szolgáltatás.

■ Nincs belépés korlátozás és biztosíték sem a kézbesítésre

 A jelenlegi alkalmazások elasztikusak.

■ Tolerálják a csomagvesztést és késleltetést

■ Alkalmazkodnak a torlódásokhoz

 A jövőbeli (Jelenbeli) valós idejű alkalmazások nem lesznek elasztikusak

 Mit módosítsunk az alkalmazásokat vagy az

Internetet?

(30)

D

Alkalmazás típusok

 Elasztikus alkalmazások

■ Gyorsabb-jobb de elviselik a rossz körülményeket is

■ Pl.: FTP

 Folyamatos média alkalmazások

■ Alsó és felső korlát az elfogadható teljesítményre

■ Időnként tudnak alkalmazkodni a megváltozó körülményekhez ”tolerant real time”

– Pl.: a videó keret sebesség változtatásával – “Network-aware” alkalmazások

 Szigorúan valós idejű alkalmazások

■ Szigorú követelmények – “intolerant real-time”

■ Pl.: vezérlő alkalmazások

(31)

D

A QOS javítása IP hálózatokban

 IETF csoportok dolgoznak néhány javaslaton a jobb QOS vezérlés érdekében az IP

hálózatokon

 RSVP, Differentiated Services, és Integrated

Services.

(32)

D

Áttekintés

 A QoS alapjai

 Integrated Services (Intserv)

 Differentiated Services (Diffserv)

 Resource ReSerVation Protocol (RSVP)

(33)

D

A QOS garanciák szabályai

 Egyszerű modell a torlódás

tanulmányozására (“Súlyzó Topológia”):

(34)

D

A QOS garanciák szabályai

 Telefon alkalmazás 1Mbps és egy FTP alkalmazás osztozik a 1.5 Mbps vonalon.

■ Az FTP burst-ök torlódásokat okozhatnak, az audió csomagokat eldobhatja a forgalomirányító

■ Az audió-nak szeretnénk prioritást adni az FTP-vel szemben.

 Első szabály: A csomagok megjelölése és egy forgalomirányító oldali szabály kell a különböző csomagok különböző kezeléséhez

(35)

D

A QOS garanciák szabályai

 Helytelenül viselkedő alkalmazás (az audio nagyobb sebességgel küldi a csomagokat mint 1Mbps).

 Második szabály: biztosítsunk védelmet az egyes forgalmi osztályoknak egymás ellen (isolation).

 Szabály mechanizmusok mellyel biztosítható a

források szabálykövető megtartása (sávszélesség);

 A széleken kell a jelölésnek és a szabály

kényszerítésnek megtörténnie:

(36)

D

A QOS garanciák szabályai

 A megjelölés és szabály kényszerítés alternatívája:

minden alkalmazás folyam részére egy

savszélesség rész lesz lefoglalva. Ez nem vezet hatékony sávszélesség kihasználáshoz.

 Harmadik szabály: Az izoláció mellett törekedni kell a hatékony erőforrás kihasználásra is.

(37)

D

A QOS garanciák szabályai

 A fizikai kapacitáson túl nem lehet folyamokat kiszolgálni

 Negyedik szabály: Kell egy hívás engedélyező

folyamat; az alkalmazás deklarálja az igényeit a

hálózat meg megmondja, hogy tudja-e teljesíteni .

(38)

D

Összefoglaló

(39)

D

Internet QoS rövid története

 Komoly kutatás a 80-as évek végén és a 90-es évek elején.

■ Telekommunikációs szemlélet.

 ATM QoS és az Integrated szolgáltatások ezen alapultak.

■ Folyamonkénti, szigorú QoS.

 Az utolsó 5 évben a fókusz a Differenciált szolgáltatások irányába tolódott

■ A fókusz a QoS folyam aggregátumok

irányába tolódott. Pl.: egy felhasználó összes

(40)

D

Csomag időzítés

 Fifo

 Prioritásos

 Round Robin

 Súlyozott Round Robin

(41)

D

Szabály mechanizmusok

Cél: korlátozzuk a forgalmat, hogy ne haladja meg a definiált paramétereket

Három gyakori kritérium:

 (Hosszú idejű) Átlagos sebesség: hány csomag küldhető idő egységenként (hosszú idő alatt)

■ Fontos kérdés: mi az időtartam hossz: 100 csomag 6 másodperc vagy 6000 csomag percenként!

 Csúcs sebesség: pl., 6000 pkts per min. (ppm) avg.;

1500 ppm peak rate

 (Max.) Burst Size: max. csomag szünet nélkül

(42)

D

Szabály mechanizmusok

Token Bucket: Burst Size,Average Rate.

 A kosár b zsetont tartalmaz

 r token/sec sebességgel gyártódnak amíg tele nem lesz a kosár

(43)

D

IETF Intserv

 per-flow/ folyam alapú QoS.

■ Specifikus alkalmazásokat támogat: videó folyam

■ Matematikai garanciákon alapul

 Problémák:

■ Komplexitás

■ Skálázhatóság

■ Üzleti modell

■ Díj számítás

(44)

D

Az Integrált Szolgáltatások elemei

 A szolgáltatás modell

■ Mit igér a hálózat?

 Szolgáltatás interfész

■ Hogyan mondja meg az alkalmazás, hogy mit szeretne?

 Csomag ütemezés

■ Hogyan elégíti ki a hálózat az igényeket?

 A garancia biztosítása

■ Hogyan kommunikálják le az ígéretet?

■ Hogyan menedzseli az új alkalmazások belépését?

(45)

D

Szolgáltatás modell

 A hálózat adat folyamokat támogatna különböző QoS-sel

■ Best effort

■ Prediktív vagy differenciált szolgáltatás

■ Szigorú garanciák (real-time)

 A szolgáltatások halmaza melyet egy hálózat támogat a szolgáltatás modell

■ Modell mely segítségével szolgáltatást lehet választani

– Pl.: ár/teljesítmény

(46)

D

Szolgáltatás modellek

 Garantált szolgáltatás

■ Szigorú valós idejű szolgáltatások

■ A felhasználó definiálja a forgalom karakterisztikáját és a szolgáltatás igényeket

■ Minden forgalomirányítónál erőforrás foglalás vezérlés

■ Matematikailag garantálja a sávszélességet, a késleltetést és a jittert

 Kontrolált terhelés.

■ Az alkalmazások alkalmazkodnak a körülményekhez egy teljesítmény ablakban

■ A felhasználó definiálja a forgalom karakterisztikáját és a szolgáltatás igényeket

■ Minden forgalomirányítónál erőforrás foglalás vezérlés

■ A garancia nem olyan erős mint az előzőben – pl., mérés alapú belépés engedélyezés

 Legjobb szándék szerinti

(47)

D

Szolgáltatás interfész

 A viszonyban definiálni kell a QoS paramétereket és a forgalom karakterisztikáját

 R-spec: a QoS igény (pl: sebesség r)

 T-spec: az adó forgalom karakterisztikáját specifikálja

 Jelzés protokoll szükséges az R és T specifikáció átvitelére:

■ RSVP

(48)

D

Engedélyezés

 A forgalomirányítók a T és az R

specifikáció alapján eldöntik, hogy tudják- e vállalni az új folyamot

(49)

D

Intserv: QoS ^ Erőforrás lefoglalás

■ Hívás felépítés, jelzés (RSVP)

■ forgalom, QoS deklarálás

■ elemenkénti engedélyezés

 QoS-sensitive scheduling

request/

reply

(50)

D

Differenciált Szolgáltatások

 Megpróbálja kiküszöbölni az alábbi hiányosságokat:

 Skálázhatóság: nagy sebességű hálózatoknál, nagy mennyiségű folyam esetén a

forgalomirányítókon nem nagyon jó állapotot karbantartani

 Flexibilis Szerviz Modellek: Az Intserv-nek csak két modellje volt; több relatív osztályt kell

definiálni (Platinum, Gold, Silver, …)

 Egyszerűbb jelzés: (mint az RSVP) sokan csak egy minőségi jellemzőt szeretnének meghatározni

(51)

D

Diffserv - Motiváció

 Csak a hálózatok szélein lehet finomhangolni

■ Lassabb vonalak

■ Pl.: levél szelektálás a postán

 Megjelöli a csomagokat egy mezővel.

■ Pl.: prioritás bélyeg

 A mag hálózat csak a mező alapján határozza meg a QoS paramétereket

■ Kevés típus, jól definiált viselkedés

■ Gyorsan kezelhető

 Evolution rather than revolution

(52)

D

Diffserv

 Egy architetúrát definiál és egy halmaz továbbító viselkedést

■ A szolgáltatókon múlik, hogy hogyan definiálják és implementálják a szolgáltatásokat ezen architektúrán

■ Sokkal flexibilisebb szolgáltatás modell, különböző szolgáltatók, különböző szolgáltatások

 A fő motiváció a Diffserv mögött a skálázhatóság

■ A gerinc hálózatot egyszerűnek tartja

 Folyam aggregátumokat kezel

(53)

D

Határ forg. ir. / Host funkciók

 Osztályozás: Megjelöli a csomagokat az

osztályozási szabályok alapján.

 Mérés: megméri, hogy egy adott folyam adott profilba esik-e.

 Jelölés: az adott profilba eső folyamot megjelöli.

 Kondícionálás: késleleti és ezután továbbítja vagy eldobja vagy átírja a

jelölést a forgalmon

(54)

D

Osztályozás és kondicionálás

 A csomag Type of Service (TOS) mezője IPv4, vagy Traffic Class mezője IPv6.

 6 bit a Differentiated Service Code Point (DSCP) ez eldönti a PHB-t amit a csomag kapni fog

 2 bitet nem használnak

(55)

D

Gerinc funkciók

 Továbbítás: a “Per-Hop-Behavior” vagy PHB alapján az egyes csomagokat

minden ugrásnál a TOS mezők alapján kezelik

 ELŐNY:

Nincs állapot kezelés a gerinc

forgalomirányítókon!

(56)

D

Továbbítás (PHB)

 PHB több különböző eredményre vezethet.

 PHB nem specifikálja a használandó mechanizmust

 Példa:

■ Class A x%-ot kap a kimenő vonalból

■ Class A csomagok mindég Class B csomagok előtt mennek ki

(57)

D

Továbbítás (PHB)

 Gyorsított továbbítás Expedited Forwarding (EF):

■ Garantál egy minimális sebességet az EF forgalomnak

■ Garantálja az izolációt (az EF forgalmaz nem zavarhatja meg más)

■ Csúcs sebesség alapján döntik el az engedélyezést

■ Lehetséges szolgáltatás: virtuális drót

(58)

D

Továbbítás (PHB)

 Biztos továbbítás, Assured Forwarding (AF):

■ AF 4 osztályt definiál bizonyos sebességgel és pufferekkel

■ Relatív szolgáltatások definiálására (gold,…)

■ Minden szolgáltatáson belül 3 eldobó prioritás

■ Hogyan hat ez ki a TCP-re?

■ A nem megfelelő forgalom át lesz osztályozva

(59)

D

Virtuális bérelt vonal

 A felhasználóknak egy dedikált forgalmi csatorna

■ Garantált sávszélesség a két pont között

■ Alacsony késleltetés, jitter.

 A belépés vezérlés teszi ezt lehetővé

(EF)

(60)

D

Differenciált Szolgáltatások kérdések

 AF és EF kutatási terület.

 Diffserv működéséhez sávszélesség menedzsment kell a gerincen.

■ Egyszerű az egyszerű szolgáltatásokhoz (EF), de nagyon komplex s lehet (egyezmények)

■ Sávszélesség bróker

 Mit kezdjenek olyan hálózatokkal melyek ezt nem támogatják, máshogyan támogatják

(61)

D

Az RSVP szerepe

 Az unicast/multicast forgalomirányító protokollok információit használja

 Minden résztvevőnél jelen van.

 Erőforrás foglalásokat továbbít.

 Minden ugrásnál ellenőrzik a

teljesíthetőséget, a sikertelen kísérletről

értesíti a kezdeményezőt

(62)

D

Reservation Protocol: RSVP

Upper layer protocols and applications

IP

Link layer modules

ICMP IGMP RSVP

IP service interface

Link layer service interface

(63)

D

RSVP célok

 Kapcsolatmentes hálózat:

■ Nem célja a forgalomirányítás.

■ Együtt kell élnie az útvonal változásokkal.

 Támogatnia kell a multicast-ot.

■ Különböző vevők különböző kepeségekkel rendelkeznek és más-más QoS-t szeretnének