11.

1
11. Átviteli réteg

• Dr. Bilicki Vilmos
• Szoftverfejlesztés Tanszék

2
Tartalom

• ACL
• TCP/IP szállítási réteg
• Bevezeto
• 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 menedzselo algoritmusok
• FIFO
• RED
• WRED
• NAT
• QoS

3
Források

• TCP/UDP
• CCNA1 11
• CCNA2 10
• CCNP3 8
• CCNP1 1
• TCP http//www.hep.ucl.ac.uk/ytl/tcpip/backgrou
  nd/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/Presenta
  tions/Lessons/qos.pdf
• http//www.cs.cmu.edu/afs/cs/academic/class/15441f
  01/www/lectures/lecture22.ppt

4
Bevezeto

• IP
• Legjobb szándék szerinti továbbítás
• Csomag vesztés
• Sorrend csere
• Aggregálás (1000 -gt 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
Miért kell torlódás vezérlés

• 1986 októbere, az Internet elso 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
Transmission Control Protocol - TCP

• Egyszeru, robosztus
• Tulajdonságai
• Vég-Vég vezérlés
• Viszony kezelés
• Sorrendhelyes átvitel
• Torlódás vezérlés

7
TCP szegmens formátum
8
UDP szegmens formátum
9
Portok

• 1024 alatt jól ismert portok
• 1024 fölött dinamikus

10
TCP viszony felépítés

• Három fázisú kézfogás
• Szekvencia számok?

11
TCP ablakozás

• A sávszélesség adott
• Az átlagsebességet kell beloni

12
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
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 (BramkoPeterson 1994)
• Új torlódás elkerülo algoritmus
• Köztes csomópontok
• RED (FloydJacobson 1993)
• REM (AthuraliyaLow 2000)

14
Tachoe

• Slow start
• cwnd 1, cwnd cwnd 1
• cwnd lt sstresh

15
Tachoe

• Congestion avoidance
• cwnd gt sstersh
• cwnd cwnd 1/cwnd

16
Tachoe

• Csomag vesztés
• A torlódás jelének tekinti
• Duplikált ACK

17
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
TCP reno
19
TCP Vegas
20
Denial of Service
21
NAT

• IP címek kimerüloben 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
  ellenorzo összeget
• Egyes protokolloknál le ki kell cserélni a
  címeket
• A többit majd meglátjuk

22
Port Address Translation

• IP/port IP/port
• Elnevezések
• Cisco Port Address Translation
• Network Address and Port Translation NAPT
• IP masquerading
• IP overloading

23
NAT TCP Terhelés elosztás

• Több különbözo szerver ugyanazon az IP címen van
  meghirdetve
• A NAT ezek között különbözo 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
  muködok és melyik nem)

24
NAT és Virtuális Szerverek

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

25
NAT

• Az Internetet független cím adminisztrációs
  zónákra osztja
• Az Internet sikere egyszeruségében rejlik
• Vég-Vég (egyes funkciók csak a végpontokon
  végezhetoek 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 megszunik
• Ha újraindul, minden elveszik
• A tuzfal is ellentmond, de az azért mert ez a
  feladata

26
A NAT elonyei

• 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ülso IP cím
• A csomagszuro tuzfalakhoz hasonlóan semmit sem
  enged be ami nincs megengedve

27
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
Tipikus NAT variációk

• Teljes terelo (Full Cone)
• Minden kérésnél a belso cím/port ugyanarra a
  külso cím/port-ra van kötve
• Külso host a külso címre küldve tud a belsovel
  kommunikálni
• Szabályozott terelo (Restricted Cone)
• Ugyanaz mint az elozo, csak a külso alkalmazás
  csak akkor tud a belsovel kapcsolatba lépni, ha a
  belso ezt kezdeményezi
• Port szabályozott terelo (Port Restricted Cone)
• Ugyanaz mint az elozo, csak portokra is
  vonatkozik
• Szimmetrikus
• A külso címzettol függo cím hozzárendelés
• Csak a csomagot megkapó külso címzett tud UDP
  választ küldeni

29
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övobeli (Jelenbeli) valós ideju alkalmazások
  nem lesznek elasztikusak
• Mit módosítsunk az alkalmazásokat vagy az
  Internetet?

30
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 felso korlát az elfogadható
  teljesítményre
• Idonké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 ideju alkalmazások
• Szigorú követelmények intolerant real-time
• Pl. vezérlo alkalmazások

31
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
Áttekintés

• A QoS alapjai
• Integrated Services (Intserv)
• Differentiated Services (Diffserv)
• Resource ReSerVation Protocol (RSVP)

33
A QOS garanciák szabályai

• Egyszeru modell a torlódás tanulmányozására
  (Súlyzó Topológia)

34
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.
• Elso szabály A csomagok megjelölése és egy
  forgalomirányító oldali szabály kell a különbözo
  csomagok különbözo kezeléséhez

35
A QOS garanciák szabályai

• Helytelenül viselkedo 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öveto 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
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 eroforrás kihasználásra is.

37
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élyezo
  folyamat az alkalmazás deklarálja az igényeit a
  hálózat meg megmondja, hogy tudja-e teljesíteni .

38
Összefoglaló
39
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 folyama

40
Csomag idozítés

• Fifo
• Prioritásos
• Round Robin
• Súlyozott Round Robin

41
Szabály mechanizmusok

• Cél korlátozzuk a forgalmat, hogy ne haladja meg
  a definiált paramétereket
• Három gyakori kritérium
• (Hosszú ideju) Átlagos sebesség hány csomag
  küldheto ido egységenként (hosszú ido alatt)
• Fontos kérdés mi az idotartam 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
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
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
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
Szolgáltatás modell

• A hálózat adat folyamokat támogatna különbözo
  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
Szolgáltatás modellek

• Garantált szolgáltatás
• Szigorú valós ideju 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 eroforrá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 eroforrás foglalás
  vezérlés
• A garancia nem olyan eros mint az elozoben
• pl., mérés alapú belépés engedélyezés
• Legjobb szándék szerinti

47
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
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
Intserv QoS

• Eroforrás lefoglalás
• Hívás felépítés, jelzés (RSVP)
• forgalom, QoS deklarálás
• elemenkénti engedélyezés

request/ reply
50
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égu hálózatoknál, nagy
  mennyiségu 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, )
• Egyszerubb jelzés (mint az RSVP) sokan csak egy
  minoségi jellemzot szeretnének meghatározni

51
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 mezovel.
• Pl. prioritás bélyeg
• A mag hálózat csak a mezo alapján határozza meg a
  QoS paramétereket
• Kevés típus, jól definiált viselkedés
• Gyorsan kezelheto
• Evolution rather than revolution

52
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özo szolgáltatók, különbözo szolgáltatások
• A fo motiváció a Diffserv mögött a skálázhatóság
• A gerinc hálózatot egyszerunek tartja
• Folyam aggregátumokat kezel

53
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 eso 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
Osztályozás és kondicionálás

• A csomag Type of Service (TOS) mezoje IPv4, vagy
  Traffic Class mezoje 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
Gerinc funkciók

• Továbbítás a Per-Hop-Behavior vagy PHB alapján
  az egyes csomagokat minden ugrásnál a TOS mezok
  alapján kezelik
• ELONY
• Nincs állapot kezelés a gerinc forgalomirányítókon
  !

56
Továbbítás (PHB)

• PHB több különbözo eredményre vezethet.
• PHB nem specifikálja a használandó mechanizmust
• Példa
• Class A x-ot kap a kimeno vonalból
• Class A csomagok mindég Class B csomagok elott
  mennek ki

57
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
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 megfelelo forgalom át lesz osztályozva

59
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 lehetové (EF)

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

• AF és EF kutatási terület.
• Diffserv muködéséhez sávszélesség menedzsment
  kell a gerincen.
• Egyszeru az egyszeru 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
Az RSVP szerepe

• Az unicast/multicast forgalomirányító protokollok
  információit használja
• Minden résztvevonél jelen van.
• Eroforrás foglalásokat továbbít.
• Minden ugrásnál ellenorzik a teljesíthetoséget, a
  sikertelen kísérletrol értesíti a kezdeményezot

62
Reservation Protocol RSVP
Upper layer protocols and applications
IP service interface
IP
ICMP
IGMP
RSVP
Link layer service interface
Link layer modules
63
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özo vevok különbözo kepeségekkel
  rendelkeznek és más-más QoS-t szeretnének
• A csoport tagság változás ne legyen költséges
• A foglalások aggregálhatóak
• Át tudja adni a foglalásokat más küldoknek
• Vezérlés költség csökkentés.
• Moduláris felépítés
• Eredmény
• Vevo orientált
• Soft-state

64
Vevo kezdeményezésu

• A vevo kezdeményezi a foglalás a fa mentén
• A multicast fa meglétét feltételezi
• Az, hogy meddig kell a kérésnek utazni a kérés
  tartalmától függ
• Tulajdonságok
• Jól skálázható párhuzamos muveletek
  (csatlakozás/lecsatlakozás).
• Heterogén vevo állomány

65
Soft State

• A forgalomirányítók ideiglenes állapotot tartanak
  fenn.
• Periodikusan frissíteni kell.
• Alternatíva Hard state
• Nincs periodikus frissítés.
• Az állapot megmarad.
• Expliciten el kell távolítani.
• Problémás
• Soft state
• Alkalmazkodik az útvonal változásokhoz
• Hibaturo

66
RSVP Szolgáltatás modell

• Minden adatfolyamra külön.
• PATH/RESV üzenetek periodikusan.
• Egy irány
• Ha nem sikerült akkor hiba üzenet.
• Nincs ack üzenet.
• Üzenet típusok
• PATH message
• T-Spec
• RESV message
• R-Spec
• Szuro
• CONFIRMATION message
• Generated only upon request.
• Unicast to receiver when RESV reaches node with
  established state.
• TEARDOWN message
• ERROR message (if PATH or RESV fails)

67
Tartalom

• ACL
• TCP/IP szállítási réteg
• Bevezeto
• 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 menedzselo algoritmusok
• FIFO
• RED
• WRED
• NAT
• QoS