03.02 IP sākumposms

Attēls 3.1 parāda IP paketes formātu. IP sākumposma parastais garums ir 20 baiti, izņemot gadījumus, kad izmanto paildus iespējas. 

TCP/IP protokolu sākumposmu attēlus turpmāk zīmēsim līdzīgi kā attēlā 3.1. Visnozīmīgākais bits ir ar numuru 0 pa kreisi, un 32-bitu vērtības vismazāk nozīmīgais bits ir ar numuru 31 pa labi.

4 baiti 32-bitu vērtībā tiek nosūtīti šādā secībā: vispirms biti 0-7, tad biti 8-15, tad 16-23, un visbeidzot 23-31 biti. Šo sauc par resgaļa baitu sakārtojumu, kas ir nepieciešamais baitu sakārtojums visiem bināriem veseliem skaitļiem TCP/IP sākumposmos, kad tos sūta pa tīklu. Šo sauc arī par tīkla baitu kārtību. Mašīnām, kuras glabā binārus veselus skaitļus citos formātos, piemēram tievgaļa formātā, jāpārveido šīs sākumposma vērtības tīkla baitu secībā pirms datu pārraidīšanas.

Pašreizējā protokola versija ir 4, t.i. IP dažreiz sauc par IPv4. Nodaļā 3.10 apskatīti daži priekšlikumi jaunai IP versijai.

Sākumposma garums ir definēts kā 32-bitu vārdu skaits sākumposmā, ieskaitot iespējas, ja tādas ir izmantotas. Tā kā tas ir 4-bitu lauks, tas ierobežo sākumposma garumu ar 60 baitiem. 8.nodaļā mēs redzēsim, ka šis ierobežojums padara dažas opcijas, piemēram, record route iespēju, mūsdienās neizmantojamu. Šī lauka parastā vērtība (kad nav iespēju) ir 5.

Lauks TOS (type-of-service) sastāv no 3-bitu precedences lauka (ko mūsdienās ignorē), 4 TOS bitiem un no 1 neizmantota bita, kura vērtībai jābūt 0. Minētie 4 TOS biti ir: minimizēt aizturi, maksimizēt caurlaidību, maksimizēt uzticamību un minimizēt naudas izmaksas. Konkrētai paketei var ieslēgt ne vairāk kā vienu no šiem 4 bitiem. Ja visi 4 biti ir 0, tad tas nozīmē normālu servisu. RFC 1340 [Reynolds and Postel 1992] norāda kā šos bitus jāuzstāda visām standartlietotnēm. RFC 1349 [Almquist 1992] satur dažus labojumus agrākam RFC un satur arī detalizētāku TOS funkcionalitātes aprakstu.

Attēls 3.2 parāda ieteicamās TOS lauka vērtības dažādām aplikācijām. Beigu kolonnā mēs parādām heksadecimālo vērtību, jo to mēs redzēsim

#pic("f_3_2.gif", "300") 3.2.attēls: Ieteicamās "type of service" lauka vērtības

Interaktīvās termināļu aplikācijas -

TOS funkciju šobrīd neatbalsta vairums TCP/IP implementāciju, toties jaunākas sistēmas, sākot ar 4.3BSD Reno to atbalsta. Jauni maršrutēšanas protokoli, piemēram, OSPF un IS-IS spēj pieņemt maršrutēšanas lēmumus, ņemot vērā šo TOS lauka vērtību.

2.10.nodaļā minējām, ka SLIP dziņi parasti nodrošina rindu izveidošanu pēc TOS vērtībām, atļaujot interaktīvam trafikam tikt apstrādātam pirms masveida datiem. Tā kā vairums implementāciju neizmanto TOS lauku, šo rindu veidošanu "ad hoc" veidā īsteno pats SLIP, kur draiveris apskata protokola lauku (lai noteiktu, vai tas ir TCP segments vai nē) un tad pārbauda avota un galapunkta TCP portu numurus, lai pārliecinātos, ka porta numurs atbilst kādam interaktīvam servisam. Kāda dziņa implementācijas komentārā ir paskaidrots, ka šis "riebīgais malurisinājums" vajadzīgs, jo vairums lietotņu implementāciju TOS lauku neuzstāda.

Pilnā garuma lauks ir pilns IP datagrammas garums baitos. Izmantojot šo lauku un sākumposma garuma lauku var uzzināt, kur sākas datu sadaļa IP datagrammā kā arī tās garumu. Tā kā šis ir 16-bitu lauks, tad lielākais iespējamais IP datagrammas garums ir 65535 baiti. (Iegaumējiet no #picref("f_2_5.gif","2.5.attēla"), ka datu posmam Hyperchannel ir MTU vienāds ar 65535. Tas nozīmē, ka MTU faktiski nav un Hyperchannel izmanto lielāko iespējamo IP datagrammu. Šis lauks mainās, kad datagrammu fragmentē, ko mēs aprakstīsim 11.5.nodaļā.

Lai gan ir iespējams nosūtīt 65535 baitus garu IP datagrammu, vairums datu posma slāņu tik garas datagrammas fragmentēs. Mītnei nav obligāti spēt apstrādāt datagrammu, kas ir garāka par 576 baitiem. TCP dala lietotāja datus gabalos, tādēļ šis ierobežojums neiespaido TCP. UDP gadījumā sastapsim vairākas lietotnes, kas aprakstītas vēlākās nodaļās (RIP, TFTP, BOOTP, DNS, SNMP) kuras lietotāja dati ir ierobežoti ar 512 baitiem, lai būtu zem šī 576 baitu limita. Faktiski vairums mūsdienu implementāciju (it īpaši tās, kuras atbalsta NFS atbalsta IP datagrammas, kas nedaudz garākas par 8192 baitiem.

Kopīgā garuma lauks ir obligāta IP sākumposm daļa, jo daži datu posmi (piemēram, Ethernet's) polsterē nelielus kadrus līdz minimālajam izmēram. Lai gan minimālā Ethernet kadra izmērs ir 46 baiti (#picref("f_2_1.gif", "2.1.attēls")), IP datagramma var būt īsāka. Ja kopējais lauka garums nebūtu norādīts, IP slānis nezinātu, cik daudz no 46-baitu Ethernet'a kadra patiesībā atbilst IP datagrammai.

Identifikācijas lauks unikāli nosaka katru mītnes sūtīto datagrammu. Katru reizi sūtot datagrammu, identifikators parasti palielinās par 1. Pie šī lauka atgriezīsimies, kad 11.5.nodaļā apskatīsim fragmentāciju un atkalsavākšanu. Kad runāsim par fragmentāciju, aplūkosim arī karogu lauku un fragmentācijas nobīdes lauku. 

RFC 791 [Postel 1981a] saka, ka identifikācijas lauku vajag izvēlēties augstākā slānī, kas liek IP slānim sūtīt datagrammu. Tas nozīmē, ka divām pēc kārtas sekojošām IP datagrammām, no kurām vienu ģenerē TCP un otru - UDP, varētu būt tas pats identifikācijas lauks. Lai gan tas ir normāli (atkalsavākšanas algoritms to apstrādā), vairums no Bērklija atvasināto implementāciju palielina kodola mainīgo IP slānī ikreiz, kad tiek nosūtīta jauna IP datagramma, neraugoties uz to, kurš augstāks slānis radīja datus šai IP datagrammai. Šo kodola mainīgo inicalizē uz vērtību, kas saistīta ar diennakts laiku, ko uzstāda, sāknējot sistēmu. 

Dzīves ilguma lauks (TTL) uzstāda augšējo robežu maršrutētāju skaitam, kuriem datagramma var iet cauri. Tā ierobežo datagrammas dzīves ilgumu. To inicializē sūtītājs uz kādu vērtību (bieži 32 vai 64) un to samazina par vieninieku katrs maršrutētājs, kurš datagrammu apstrādā. Kad lauka vērtība sasniedz 0, datagrammu izmet un sūtītājam sūta ICMP ziņojumu. Šis mehānisms novērš pakešu bezgalīgu ceļošanu pa maršrutētāju veidotām cilpām. Pie šī lauka atgriezīsimies 8.nodaļā, kad apskatīsim traceroute programmu. 

Mēs runājām par protokola lauku 1.nodaļā un parādījām, kā to IP lieto ienākošo datagrammu demultipleksēšanai. Tas identificē protokolu, kurš deva datus IP protokolam nosūtīšanai. 

Sākumposma kontrolsumma tiek aprēķināta tikai no IP sākumposma. Tā neatspoguļo datus, kuri seko sākumposmam. ICMP, IGMP, UDP un TCP visiem ir pašiem savas kontrolsummas, lai noķertu kļūdas viņu sākumposmos un datos.

Lai aprēķinātu IP kontrolsummu izejošai datagrammai, kontrolsummas lauku vispirms uzstāda uz 0. Tad sākumposmam izrēķina visu tajā ietilpstošo 16-bitu vārdu summu (visu sākumposmu uzlūko kā virkni, kas sastāv no 16-bitu vārdiem) un par kontrolsummu izvēlas šīs summas vērtības vieninieku papildinājumu. IP datagrammas saņēmējs izrēķina visu sākumposmā ietilpstošo 16-bitu vārdu summu (kontrolsummu ieskaitot). Ja sākumposmā nekas netika izmainīts, saņēmēja kontrolsummai jāsastāv tikai no vieniniekiem. Ja rezultāts nav tikai vieninieki (kontrolsummas kļūda), IP izmet saņemto datagrammu un neģenerē kļūdas ziņojumu. Augstākiem slāņiem pašiem jāpamana trūkstošā datagramma un jāsūta tā atkārtoti.

ICMP, IGMP, UDP un TCP visi izmanto to pašu kontrolsummas algoritmu, lai gan TCP un UDP ietver vairākus laukus no IP sākumposma papildus viņu pašu sākumposmam un datiem. RFC 1071 [Braden, Borman, and Partridge 1988] satur piezīmes par šīs Interneta kontrolsummas algoritma implementēšanu. Tā kā maršrutētājs bieži izmaina tikai TTL lauku (to samazinot par 1), maršrutētājs var par 1 palielināt kontrolsummu, kad tas sūta tālāk saņemto datagrammu, nevis rēķināt kontrolsummu no visa IP sākumposma par jaunu. RFC 1141 [Mallory and Kullberg 1990] apraksta efektīvu veidu, kā to izdarīt. Standarta BSD implementācija toties neizmanto šo palielināšanu par viens, kad pārsūta tālāk datagrammu. 

Katra IP datagramma satur avota IP adresi un galapunkta IP adresi. Šīs ir 32-bitu vērtības, ko aprakstījām 1.4.nodaļā. 

Beidzamais lauks - iespējas ir mainīga garuma saraksts ar papildinformāciju šai datagrammai. Pašlaik definētās iespējas ir sekojošas:

• uzticamība un ierobežojumu apstrāde; militāriem lietojumiem detalizētāku informāciju sk. RFC 1108 [Kent 1991]
• ieraksta maršrutu (liek katram maršrutētājam ierakstīt savu IP adresi. 7.3.nodaļa). 
• laikapunkti (liek katram maršrutētājam ierakstīt gan savu IP adresi, gan laiku. 7.4.nodaļa). 
• nestingrā avota maršrutēšana (norāda sarakstu ar IP adresēm, kuras datagrammai ir jāiziet. 8.5.nodaļa)
• stingrā avoita maršrutēšana (avots norāda IP adreses, bet šoreiz maršrutēšanai var lietot tikai sarakstā minētās adreses". 8.5.nodaļa).

Šīs iespējas izmanto reti un ne visas mītnes un maršrutētāji tās atbalsta. 

Iespēju lauks vienmēr beidzas uz 32-bitu vārda robežas. Nepieciešamības gadījumā pievieno polsterējuma baitus ar 0 vērtību. Tas nodrošina to, ka IP sākumposms vienmēr ir 32 bitu daudzkārtnis, kā tas prasīts sākumposma garuma laukam.