7. lekcija Datortīkli dr. dat. Valdis Vītoliņš 2011. gada pavasaris Pēc Scott Shenker Networks & Protocols http://inst.eecs.berkeley.edu/~ee122/

IP adresēšanas apkopojums IP pakešu pārsūtīšana Transporta slānis Plāns IP adresēšanas apkopojums IP pakešu pārsūtīšana Transporta slānis Uzticama piegāde neieskaitot: TCP detaļas Sastrēgumu kontroli 2 2

IP adresēšanas apkopojums 32-bitu skaitlis nosaka saskarnes Tiek izdalīts, nosakot tīkla adreses garumu (prefikss) Nevienveidīga hierarhija nodrošina mērogojamību un elastību Maršrutēšana tiek balstīta uz CIDR adresēm Ir vairāki rezervēti apgabali Adrešu apgabalus izdala sekojoši: ICANN  RIR  ISP  lietotāja tīkls  mītne Apskatīsim vēlāk Kā mītnes iegūst adresi (DHCP) Kā IP adresi piesaista tīkla saites adresei (ARP) 3 3

CIDR: hierarhiska adrešu izdalīšana Adreses sākums (priedēklis) ir mērogošanas pamats Adreses izdala nepārtrauktos apgabalos ar vienotu sākumu Maršrutēšanas likumus veido šiem kopīgajiem apgabaliem 12.253.128.0/17 12.0.0.0/8 12.0.0.0/15 12.253.0.0/16 12.2.0.0/16 12.3.0.0/16 : 12.3.0.0/22 12.3.4.0/24 12.3.254.0/23 12.253.0.0/19 12.253.32.0/19 12.253.64.0/19 12.253.64.108/30 12.253.96.0/18 4 4

Hierarhiskā struktūra Nodrošina ne tikai mērogojamību Bet arī vienkāršu deleģēšanu un kontroli ICANN  RIR  ISP  lietotāja tīkls  mītne Mērogošana atkārtojas atkal un atkal (arī DNS, kas būs nākamajā lekcijā) Mērogojamībā svarīga ir arī decentralizācija 5

Ļauj nosūtīt paketes uz vajadzīgo vietu Kam izmanto adresi? Ļauj nosūtīt paketes uz vajadzīgo vietu Ir līdzeklis, lai sasniegtu mērķi Bet nav mērķis To veic ar pakāpenisku pakešu pārsūtīšanu Ko tagad arī apskatīsim... 6

Pakešu pārsūtīšana 7 7

Katram maršrutētājam ir pārsūtīšanas tabula Pakešu pārsūtīšana Katram maršrutētājam ir pārsūtīšanas tabula Salāgo mērķa adresi … … ar izejošo saskarni (= saiti) Pārsūtīšanas tabulu veido: Maršrutēšanas algoritmi Statiski likumi Saņemot paketi No paketes IP iesākuma uzzina mērķa adresi Atrod to pārsūtīšanas tabulā Pārsūta paketi uz atbilstošu saskarni 8 8

Ar klašu adresēm tas ir vienkārši Adreses vecākie biti nosaka masku Maršrutēšanas tabula Ar klašu adresēm tas ir vienkārši Adreses vecākie biti nosaka masku A klase[0]: /8 B klase [10]: /16 C klase [110]: /24 Var atrast precīzu adreses atbilstību prefiksa izmanto kā maršrutēšanas sarakstu Kāpēc tas nestrādā ar CIDR? Adrese nenosaka masku CIDR adresēšana rada 2 problēmas Atrast atbilstību nav triviāli Adreses neatspoguļo tīkla topoloģiju 9

1. piemērs: Piegādātājs ar 4 klientiem Link 1 Link 4 201.143.0.0/22 201.143.4.0/24 201.143.5.0/24 201.143.6.0/23 Provider Link 2 Link 3 Prefix Link 201.143.0.0/22 Link 1 201.143.4.0.0/24 Link 2 201.143.5.0.0/24 Link 3 201.143.6.0/23 Link 4 10 10

Atbilstības atrašana Katrai adresei ir tikai 1 atbilstība Bet to nav viegli atrast Piemēram: 11001001 10001111 00000101 11010010 Pirmie 21 biti atbilst 4 prefiksiem Pirmie 22 biti atbilst 3 prefiksiem Pirmie 23 biti atbilst 2 prefiksiem Pirmie 24 biti atbilst tieši vienam prefiksam 11001001 10001111 000000−− −−−−−−− 201.143.0.0/22 11001001 10001111 00000100 −−−−−−− 201.143.4.0/24 11001001 10001111 00000101 −−−−−−− 201.143.5.0/24 11001001 10001111 0000011− −−−−−−− 201.143.6.0/23 11

2. piemērs: Klientu apvienošana Prefix Link 201.143.0.0/21 Provider 1 201.144.0.0/21 Provider 2 201.144.0.0/21 201.144.0.0/22 201.144.4.0/24 201.144.5.0/24 201.144.6.0/23 Provider 2 201.143.0.0/21 201.143.0.0/22 201.143.4.0/24 201.143.5.0/24 201.143.6.0/23 Provider 1 12 12

3. piemērs: Sarežģījumi Pārsūtīšanas tabulas paliek sarežģītas, kad adreses neataino tīkla topoloģiju 201.144.0.0/21 201.144.0.0/22 201.144.4.0/24 201.144.5.0/24 201.144.6.0/23 Provider 2 201.143.0.0/21 201.143.0.0/22 201.143.4.0/24 201.143.5.0/24 201.143.6.0/23 Provider 1 13 13

Unikālie prefiksi Provider 1 11001001 10001111 000000−− −−−−−−− 11001001 10001111 00000100 −−−−−−− 11001001 10001111 0000011− −−−−−−− 11001001 10010000 00000100 −−−−−−− Provider 2 11001001 10001111 00000101 −−−−−−− 11001001 10010000 000000−− −−−−−−− 11001001 10010000 00000101 −−−−−−− 11001001 10010000 0000011− −−−−−−− 14

Likumu vienkāršošana /21 masku izmanto vairumā gadījumu, /24 masku izmanto izņēmumiem 201.144.0.0/21 201.144.0.0/22 201.144.4.0/24 201.144.5.0/24 201.144.6.0/23 Provider 2 201.143.0.0/21 201.143.0.0/22 201.143.4.0/24 201.143.5.0/24 201.143.6.0/23 Provider 1 15 15

Garākā prefiksa atrašana Paketes mērķis: 11001001 10010000 00000100 01101101 Paketes mērķis: 11001001 10010000 00000101 01101101 Garākā prefiksa atrašana Provider 1 11001001 10001111 00000−−− −−−−−−− 201.143.0.0/21 11001001 10010000 00000100 −−−−−−− 201.144.4.0/24 Provider 2 11001001 10010000 00000−−− −−−−−−− 201.144.0.0/21 11001001 10001111 00000101 −−−−−−− 201.143.5.0/24 16

Garākā prefiksa atrašana CIDR adrešu maršruta atrašanu veic pēc garākā prefiksa (longest prefix meach – LPM) Iepriekš nevar pateikt, kad beidzas tīkla adrese Jāpārbauda bitu pa bitam LPM samazina maršrutēšanas tabulu Paātrina atrašanu Samazina nepieciešamo atmiņas apjomu Bet kā LPM strādā? Un kā to paātrināt? 17

LPM pārsūtīšana Forwarding Table prefix outgoing link destination 201.10.7.17 destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201: 11001001 10: 00001010 7: 00000111 17: 00010001 192: 11000000 18 18

LPM pārsūtīšana Forwarding Table prefix outgoing link destination 201.10.7.17 destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201: 11001001 10: 00001010 7: 00000111 17: 00010001 192: 11000000 19 19

LPM pārsūtīšana Forwarding Table prefix outgoing link destination 201.10.7.17 destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201: 11001001 10: 00001010 7: 00000111 17: 00010001 4: 00000100 83: 01010011 128: 10000000 20 20

LPM pārsūtīšana Forwarding Table prefix outgoing link destination 201.10.7.17 destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201: 11001001 10: 00001010 7: 00000111 17: 00010001 201: 11001001 10: 00001010 0: 00000000 21 21

LPM pārsūtīšana Forwarding Table prefix outgoing link destination 201.10.7.17 destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201: 11001001 10: 00001010 7: 00000111 17: 00010001 201: 11001001 10: 00001010 6: 00000110 22 22

Algoritmiska problēma: kā to darīt ātri? LPM pārsūtīšana Forwarding Table prefix outgoing link destination 192.0.0.0/4 2 4.83.128.0/17 1 201.10.0.0/21 3 201.10.6.0/23 201.10.7.17 201: 11001001 10: 00001010 7: 00000111 17: 00010001 2 Algoritmiska problēma: kā to darīt ātri? 23 23

Pa vienam pārlasa visus maršrutēšanas likumus Vienkāršs algoritms Pa vienam pārlasa visus maršrutēšanas likumus Pārbauda, vai adrese atbilst prefiksam Atceras atrastā ieraksta garumu un izmanto visgarāko Ja neatrod, izmanto noklusēto maršrutu Darbietilpība ir lineāra no ierakstu skaita Šodien maršrutētājiem var būt 200 000 – 250 000 ierakstu! Bet atrašanas laiks ir nanosekundes … jo tad tīklā pienāk nākamā pakete Tāpēc nepieciešami efektīvāki algoritmi, kas atbilst līniju ātrumiem Labāki algoritmi Realizēti aparatūrā 24 24

Saglabā maršrutus kā koku Adrešu koks Saglabā maršrutus kā koku Katrs adreses bits atbilst vienam koka līmenim Dažās virsotnēs ir atļautie prefiksi Kad pienāk pakete Pārlūko koku atbilstoši mērķa adresei Meklēšanas laiks: atkarībā no bitu skaita kokā 1 00* 0* 11* 100* 101* 25 25

Kā pārsūta mītne? Maršrutēšana ir vienkārša Vai pakete ir paredzēta mītnei (piem., 1.2.3.4/32) Nosūta mītnei Vai pakete paredzēta lokālam tīklam (piem., 1.2.3.0/25) Nosūta uz saskarni ar atbilstošu LAN adresi (ARP) Ta vai tā ir lokāla adrese, nosaka pēc tīkla maskas (piem., 255.255.255.128) Vai pakete ir ārējā tīkā Nosūta paketi lokālai vārtejai Piem., lokālā tīkla maršrutētājam vai Interneta piegādātājam Kā šos likumus nosaka Ar statisku adreses, tīkla maskas un vārtejas konfigurēšanu Dinamiski ar Dynamic Host Configuration Protocol ( DHCP) 26 26

Kā tiek atrastas mītnes? Kā pēdējais maršrutētājs atrod mītni? Katrai saskarnei ir unikāls nemainīgs identifikators MAC adrese (Media Access Control) - 2 slānis Kas ir iešūts tīkla saskarnē (NIC) Parast adrese ir plakana (nav hierarhiska) Tiek izveidota adrešu atrises (resolution) tabulu Salāgo MAC adresi ar IP adresi Izmanto Address Resolution Protocol (ARP) 1.2.3.4 1.2.3.7 1.2.3.156 ... host host host LAN router 27 27

5 min pauze Jautājumi? 28 28

Transporta slānis 29 29

Saziņa starp procesiem (piem., ligzdām) Transporta slāņa loma Lietojumu slānis Lietotņu saziņa Piem., HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP) Transporta slānis Saziņa starp procesiem (piem., ligzdām) Balstās uz tīkla slāni; atbalsta lietojumu slāni Piem., TCP un UDP Tīkla slānis Saziņa starp tīkla mezgliem Noslēpj konkrēto saišu realizāciju Piem., IP 30 30

logical end-end transport Transporta protokoli Nodrošina loģisko saziņu starp lietotņu procesiem, kas stādā dažādās mītnēs Darbojas mītnēs Sūtītājs: sadala lietotnes ziņojumus segmentos, un nodod tīkla slānim Saņēmējs: apvieno segmentus ziņojumos, nodot lietotņu slānim Ir izmantojami dažādi transporta protokoli Internetā: TCP, UDP, ICMP (galvenokārt) application transport network data link physical logical end-end transport network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 31 31

Interneta transporta protokoli Datagrammu ziņojumu serviss (UDP) Vienkāršs IP "labākā iespējamā" servisa paplašinājums Multipleksēšana/demultipleksēšana starp procesiem Uzticama, sakārtota piegāde (TCP) Savienojuma izveide un izbeigšana Salauzto pakešu izmešana Pakešu pārsūtīšana Plūsmas kontrole Sastrēgumu kontrole Ko nenodrošina Kavējuma vai caurlaidspējas garantijas Savienojumus, kas pārdzīvo IP adreses maiņu 32 32

16b iesākuma kontrolsumma versija iesāk. garums 8b servisa tips (TOS) 16b kopējais garums (B) 16b identifikācija 3b Karogi 13b fragmenta nobīde 8b dzīves laiks (TTL) 8b protokols 16b iesākuma kontrolsumma 32b avota IP adrese 32b mērķa IP adrese Opcijas (ja ir) Vērtums 33

4 5 Payload 16-bit Total Length (Bytes) 16-bit Identification Type of Service (TOS) 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload 34

4 5 Payload 16-bit Total Length (Bytes) 16-bit Identification Type of Service (TOS) 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP 17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address Payload 35

4 5 Payload 16-bit Total Length (Bytes) 16-bit Identification Type of Service (TOS) 16-bit Total Length (Bytes) 3-bit Flags 16-bit Identification 13-bit Fragment Offset 8-bit Time to Live (TTL) 6 = TCP 17 = UDP 16-bit Header Checksum 32-bit Source IP Address 32-bit Destination IP Address 16-bit Source Port 16-bit Destination Port More transport header fields …. Payload 36

Multipleksēšana un demultipleksēšana Mītne saņem IP datagrammas Katrai datagrammai ir avota un mērķa adreses, Katrā datagrammā ir transporta slāņa segments Katram segmentam ir avota un mērķa ports Mītne izmanto IP adreses un portu numurus, lai aizvadītu segmentu uz noteiktu ligzdu 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 37 37

Porti Kā noteikt, kurai lietotnei pienākas kuras paketes? Risinājums: katrai ligzdai nosaka portu Klientam ir jāzina servera ports Atsevišķi 16-bitu porti UDP unTCP (avota_IP, avota_ports, mērķa_IP, mērķa_ports) nosaka TCP savienojumu Kā ar UDP? Labi zināmie porti (0-1023): visi ir vienojušies, kas ir pievienots šiem portiem piem., ssh:22, http:80 Īslaicīgos portus (1024-65535) izmanto klienti Piem., pārlūkprogrammas, pļāpu lietotnes, vienranga tīkli 38 38

UDP: neuzticama ziņojumu nosūtīšana Vienkāršs starpprocesu saziņas veids Novērš garantētas nosūtīšanas papildu izmaksas Nosūta un saņem ziņojumus ligzdā User Datagram Protocol (UDP; RFC 768 - 1980!) IP un porta numurs nodrošina (de)multipleksēšanu Iespējama pakešu satura kļūdu kontrole (checksum field = 0 nozīmē “nepārbaudīt kontrolsummu”) SRC port DST port checksum length DATA 39 39

Kāpēc kādam vajadzīgs UDP? Precīzāka kontrole, kad un kā sūtīt datus Tiklīdz process iesūta datus ligzdā … UDP sagatavo un nosūta paketi Nav savienojuma izveides aiztures UDP vienkārši sūta datus bez jebkādiem priekšnoteikumiem … kas novērš nevēlamas aiztures Nav savienojuma stāvokļa Nav nepieciešami buferi, kārtas skaitļi, taimeri … … vienkāršāk apkalpot daudzus paralēlus klientus Nelieli paketes datu virstēriņi UDP iesākums ir tikai 8 baiti 40 40

Populāras lietotnes, kas izmanto UDP Multivides straumēšana Zaudēto/bojāto pakešu atkārtotai pārraidei nav jēgas, jo ir jau par vēlu Piem., telefona zvani, video konferences, spēles Jaunākie straumēšanas protokoli izmanto TCP (un HTTP) Vienkāršu pakalpojumu protokoli, piemēram, Domain Name System Savienojuma izveide dubultotu pakešu skaitu Ja nepieciešams, vienkāršāk lietotnei pārsūtīt datus “Address for bbc.co.uk?” “212.58.224.131” 41 41

Transmission Control Protocol (TCP) Savienojumu orientēts Tieša TCP savienojuma izveide un izbeigšana Piedāvā uzticamu datu straumi Nosūta un saņem baitu straumes, nevis ziņojumus Sastrēgumu kontrole Dinamiski pielāgojas tīkla caurlaidspējai Uzticama, sakārtota piegāde TCP pamatīgi strādā, lai nodrošināt uzticamu baitu straumi Lai arī ir datu bojājumi un zudumi Plūsmas kontrole Nodrošina, ka sūtītājs nepārslogo saņēmēju 42 42

Uzticama piegāde Kā tā tiek nodrošināta? Kā jūs sarunājaties trokšņainā telefona līnijā? Pozitīvs apstiprinājums (“Ack”) Saņēmējs tieši norāda, ka ir saņēmis TCP apstiprinājumi ir kumulatīvi (“Esmu saņēmis visu līdz #N”) Iespējams apstiprināt arī atsevišķus segmentus (“SACK”) Negatīvs apstiprinājums (“Nack”) “Neesmu saņēmis: …” Kā saņēmējs zina, ka kaut ko nav saņēmis? Vai to vienmēr var noteikt? (Izmanto TCP netieši izmantoto "ātro pārsūtīšanu") 43 43

Uzticama piegāde (turpinājums) Noildze Ja no saņēmēja ilgi nav ziņu, sūtīt vēlreiz Problēma: cik ilgi gaidīt? TCP izmanto novērtēto atbildes laiku (estimated RTT) Problēma: ko darīt ja neapstiprina atkārtotu pārraidi? TCP (u.c.) izmanto exponenciālo atkāpšanos (backoff) Nākamo pārsūtīšanu veic pēc 2* ilgāka laik, līdz sasniedz maksimāli pieļauto Samazina slodzi sastrēgumu laikā Pavisam cits uzticamības nodrošināšanas veids: sūtīt pārpalicīgus datus Telefona piemērs: “Tiksimies 14:00, atkārtoju, 14:00” Vienkārša kļūdu kontrole Zaudētos datus atgūst gandrīz momentā! Bet: iespējams tikai noteiktā zudumu diapazonā Un: tīklam rada papildu slodzi 44 44

TCP atbalsts garantētai piegādei Kārtas numuri Izmanto, lai noteiktu zudušos datus ... un lai saņemtos datus sakārtotu Kontrolsummas Izmanto, lai atklātu bojātos datus … saņēmējs šādu paketi nomet Ja netiek saņemta kļūda – atgriežas pie normālas pārraides Pārsūtīšana Sūtītājs pārsūta zudušos vai bojātos datus Noildzi nosaka pēc aprites laika (RTT) Ātrā pārsūtīšana straujai bojāto datu pārsūtīšanai 45 45

Veiktspējīgas uzticamības nodrošināšana 46 46

Vienkāršs "atkārtot pārraidi" (ARQ) Automatic Repeat Request Saņēmējs nosūta apstiprinājumu (ACK), kad ir saņēmis paketi Sūtītājs gaida ACK līdz iestājas noildze Viekāršs ARQ protokols Nosūti un gaidi Nosūti paketi un gaidi apstiprinājumu Sender Receiver Packet ACK Timeout Time 47 47

Cik ātri darbojas "nosūti un gaidi"? Pieņemam, ka sūtam no UCB uz Ņujorku: Caurlaidspēja = 1 Mb/s (megabits/sek) RTT = 100 msec Maximum Transmission Unit (MTU) = 1500 B = 12,000 b Nav citas slodzes un pakešu zudumu vai bojājumu Kāds ir aptuvenais "nosūti un gaidi" datu apmaiņas ātrums? Kas mainās, ja tīkla caurlaidspēja ir = 1 Gb/s? 48 48

Vairākas paketes lidojumā “Lidojumā” = “Neapstiprinātas” Sūtītāja problēma: cik daudz pakešu (baitu)? Saņēmēja problēma: cik daudz buferēt datiem, kas ir “virs apstiprinātā”? piem., datus nevar pārsūtīt, jo trūkst iepriekš sūtītie dati Pieņem, ka serviss nodrošina sakārtotu piegādi (kā TCP) 49 49

Pieļauj lielus datu apjomus “lidojumā” Slīdošais logs Pieļauj lielus datu apjomus “lidojumā” Ļauj sūtītājam skriet pa priekšu saņēmējam … tomēr, ne pārāk tālu pa priekšu Sending process Receiving process TCP TCP Last byte written Last byte read Receiver Window Sender Window Next byte needed Last byte ACKed Last byte received Last byte can send 50 50

Slīdošais logs (turpinājums) Sūtītājs un saņēmējs uztur logu, kurā tiek uzskaitīti dati, kas ir lidojumā, kurus sūtītājs ir nosūtījis, bet saņēmējs vēl nav saņēmis Loga kreisā mala: Sūtītājam: neapstiprināto datu sākums Saņēmējam: nenosūtīto datu sākums Sūtītājam: Loga izmērs = datu lidojumā apjoms Nosaka datu apmaiņas ātrums Sūtītājam vajag vismaz tik lielu, vai nedaudz lielāku buferi Saņēmējam: Loga izmērs = maksimālais nesaņemto datu daudzums Saņēmējam vajag vismaz šādā izmēra buferi 51 51

Kad sūtītājs saņem apstiprinājumu, logs virzās uz priekšu Slīdošais logs Kad sūtītājs saņem apstiprinājumu, logs virzās uz priekšu Sending process TCP Last byte written Sender Window Last byte ACKed Last byte can send 52 52

Kad sūtītājs saņem apstiprinājumu, logs virzās uz priekšu Slīdošais logs Kad sūtītājs saņem apstiprinājumu, logs virzās uz priekšu Sending process TCP Last byte written Sender Window Last byte ACKed Last byte can send 53 53

Saņēmējam logs virzās uz priekšu, kad sakārtotos datus savāc process Slīdošais logs Saņēmējam logs virzās uz priekšu, kad sakārtotos datus savāc process Receiving process TCP Last byte read Receiver Window Next byte needed Last byte received 54 54

Saņēmējam logs virzās uz priekšu, kad sakārtotos datus savāc process Slīdošais logs Saņēmējam logs virzās uz priekšu, kad sakārtotos datus savāc process Receiving process TCP Last byte read Next byte needed Receiver Window Last byte received 55 55

Slīdošais logs (turpinājums) Sūtītāja: logs bīdās uz priekšu, kad saņem apstiprinājumu Saņēmēja: logs virzās uz priekšu, kad process savāc datus Kas notiek, ja sūtītāja logs izstiepjas garāks par saņēmēja logu? Saņēmējs brīdina sūtītāju, kur beidzas saņēmēja logs (loga “labā mala”) Sūtītājs piekrīt nepārkāpt šo robežu Tas izveido savu logu tādu, lai tā mala nepārsniedz saņēmēja loga malu 56 56

Slīdošā loga veiktspēja Tas pats UCB  Ņujorka 1 Mb/s ar 100 msec RTT sūtītāja un saņēmēja logi = 100 Kb = 12.5 KB Cik ātri var pārraidīt? Kas notiek, ja ir 12.5 KB logs un 1 Gb/s tīkls? Lai pilnībā izmantotu tīklu, logs ir: Caurlaidspēja*aizture 1 Gb/s * 100 msec = 100 Mb = 12.5 MB Piezīme: lieli logi = daudzas paketes lidojumā 57 57

Balstīta uz garāko atbilstošo prefiksu Apkopojums IP pakešu pārsūtīšana Balstīta uz garāko atbilstošo prefiksu Tīkla gala sistēmas (mītnes) izmanto tīkla masku, lai noteiktu, vai pakete pieder lokālajam tīklam (LAN) ... un šajā gadījumā tās sūta paketes pa tiešo, izmantojot ARP lai noteiktu MAC adresi … ja pakete pieder citam tīklam ... tad paketi pārsūta lokālā tīkla vārtejai (maršrutētājam) To iestata manuāli, vai arī dinamiski ar DHCP Transporta protokoli Multipleksēšana/demultipleksēšana notiek, izmantojot portu numurus UDP nodrošina vienkāršu datagrammu servisu TCP nodrošina uzticamu baitu straumi Uzticamība uzreiz rada veiktspējas problēmas Piem. "Pārtrauc un gaidi" un "Slīdošais logs" 58 58