Materialet får användas enligt CreativeCommons(by,nc,sa). Läs mer om kopieringsrättigheter här

Internetteknik för dummies

Dessa sidor är under utveckling och kommer så att vara ett bra tag framöver, eftersom det är mycket som borde behandlas och tiden för att vidareutveckla är knapp. Synpunkter mottages tacksamt och fler medförfattare är välkomna. Testpiloter också.

Radioamatörvinkeln

Ett sådant område är amatörradiospecifika applikationer, tillämpningar och tjänster, exempelvis fjärrstyrning av kortvågsstationer, repeaternät med eller utan talgrupper (dmr, echolink, svxlink, etc), aprs-tracking, epost över kortvåg, tjattar (tex fldigi, js8call), BBS, signalstyrkerapportering (wsprnet), med mera.

Ett annat sådant område är speciella kommunikationslänkar via radio på amatörradiofrekvenser med olika moduleringsmetoder, exempelvis ax25 - paketradio, ardop, wsjt/ft8, js8, npr70, 23cm paketradio, etc.

Ett tredje område är samhällsnyttan av att kunna tillhandahålla kommunikation genom att göra radioamatörutrustningar tillgängliga för beredskapsändamål när alternativen är otillräckliga eller saknas. Internet hjälper också till att upprätthålla det globala mänskliga nätverket av radioamatörer som ständigt passar etern och inte sällan är först att larma om naturkatastrofer och andra extraordinära omständigheter som kräver omedelbar uppmärksamhet.

Radioamatörspecifika aktiviteter inom Internetteknikområdet växte fram samtidigt som Internet. I Sverige började en pionjärfas redan under 1980-talet och blev mycket aktiv under 1990-talet med fokus på "packet radio". En vanlig tillämpning var BBS-system med chat och epost. Den dominerande länkteknologin var åtminstone inledningsvis ax25. Pionjärfasen kulminerade vid millennieskiftet och ebbade successivt ut under det första decenniet därefter när pionjärerna sökte sig till nya utmaningar.

Regulatoriska förändringar, teknisk utveckling och en överenskommelse med adressägaren ARDC och det svenska universitetsnätet Sunet om Internettransit ledde 2012 till en omstart som gjorde det möjligt för det svenska radioamatörsamhället att bygga ett eget icke-kommersiellt Internetsegment drivet med frivilligkrafter. Föreningen AMPRNet Sverige bildades 2016 för att ge arbetet en hållbar organisatorisk plattform.

Nu, ett drygt decennium efter omstarten, har detta radioamatördrivna nät nått en nivå där det krävs fler frivilliga inblandade i drift och utveckling med bredare och djupare kunskaper inom Internetteknikområdet. Det är motiveringen bakom arbetet att ta fram utbildningsmaterialet. I denna första version är tanken att erbjuda en röd tråd på en inte alltför avancerad nivå med pekare till fördjupningar för den som vill gräva djupare.

Studieupplägg

laborationsspår

Wireshark

iperf3

Syftet med laborationskursen är att få igång strömsnåla amprnet-noder vid deltagarnas QTHn som plattform för experiment och lärande och på samma gång skapa redundant funktionalitet som gör nätet mer robust, så att viktiga funktioner fungerar regionalt/lokalt även om en och annan länk går ner.

I laborationskursen ingår övningar som syftar till att koppla upp sig mot AMPRNet från sitt/sina QTH. Det kan ske med direktlänk om det finns en accesspunkt inom räckhåll, eller tunnel genom ett kommersiellt abonnemang. Observera att regelverket för individuella medlemmar inte tillåter att en direktuppkoppling ersätter ett kommersiellt abonnemang.

Laborationskursen är utvecklad för enkortsdatorn Raspberry Pi (i fortsättningen kallad Rpi) som ägs av en utbildningsstiftelse och har ett starkt utbildningsfokus. Rpi har hittills varit mycket prisvärd, inte minst på grund av allt stöd för utveckling som tillverkaren ger. Just nu är leveranstiderna långa och priserna stiger på andrahandsmarknaden. Alla modeller duger men det är en fördel att ha en ethernetport (B-modellerna).

Det finns några liknande maskinvarumässiga alternativ, tex BeagleBone Black och några olika Odroid-modeller, som kan använda en mindre del av det otroligt rika utbud av programvara och utbildningsmaterial som tagits fram för RaspberryPi. Det saknas alternativ med samma starka utbildningsfokus. Prestandamässigt är de likvärdiga.

Vad är Internet

Internet (med stort I) kan beskrivas som ett globalt nätverk av stora nätverk (WAN) av lokala nätverk (LAN) sammankopplade via kommunikationslänkar över något medium (koppar, optiskt medium, etern) mellan nätverkselement. Exempel på nätverkselement kan vara en dator (ibland kallad värd), en router, en switch eller en hub. Ett LAN kopplar ihop lokala värdar, oftast datorer som kör olika nätverkstillämpningar. Lokala nät kommunicerar oftast punkt-till-multipunkt, i nät där alla kan höra varandra, medan de oftast kopplas ihop punkt till punkt. De lokala näten (LAN) fick en central roll tidigt. Internet har fått sitt namn som nätet som knyter ihop alla LAN här i världen. Mer om detta senare.

Kommunikationen sker via paket, datagram, som skickas mellan de olika nätverkselementen. Man kallar nätet paketväxlat till skillnad från ett kretskopplat nät som tillhandahåller en exklusiv uppkoppling punkt-till-punkt medan kommunikation pågår. Paket skickas helt beroende av varandra mellan många olika parter, vilket ställer speciella krav bland annat på köhantering av olika slag inne i nätet. Skickar man in för många paket, får men trafikstockning (congestion) och riskerar att en del paket kan förloras. I ett kretskopplat får man en spärr utanför nätet om för många vill kommunicera. I ett paketväxlat nät får man trafikstockning inne i nätet som måste hanteras.

Internet byggs och drivs i segment av Internetoperatörer av olika storlek. Internetoperatörer med global närvaro som utbyter trafik direkt med varandra (så kallad peering) kallas nivå ett-operatörer. Antalet sådana är relativt litet. Man pratar om en Nivå-ett-klubb. Peering sker ofta i en Internetknutpunkt (IX) som erbjuder samlokalisering av utrustning från flera operatörer. Exempel på en större IX-operatör aktiv på flera platser i Sverige är Netnod. Exempel på en liten lokal knutpunkt i Stockholmsområdet är solix.

Operatörer på lägre nivåer (tier 2...n) måste få transit via operatörer på högre nivå för att nå hela Internet. Det räcker inte med peering med operatörer på lägre nivåer.

AMPRNet Sverige är ett Internetsegment. Det består av regionala subnät som drivs och används av amatörradioföreningar och FRO-avdelningar med ett eller flera lokala subnät vid sina QTH. De regionala subnäten får alla Internettransit via Sunet och kan därför ses som accessnät till Sunet. Ambitionen är dock att de regionala näten så långt som möjligt ska fungera regionalt eller lokalt, efter bästa förmåga, även om kontakten med Sunet eller egna länkar av någon anledning bryts. Det medför speciella utmaningar som vi kommer att diskutera nedan.

Sunet utbyter trafik med kommersiella operatörer i Sverige via Netnods IXar och får sin Internettransit via Nordunet, som i sin tur är anslutet för peering vid flera IXar i Europa och Nordamerika och får transit via Géant, det EU-finansierade ryggradsnätet för forskning och utbildning, som i sin tur är anslutet till ryggradsnät för forskning och utbildning på andra kontinenter, exempelvis Ubuntunet WACREN och ASREN i Afrika, Internet2 i USA, Canarie i Kanada, RedClara i Sydamerika, TEIN i Asien, etc.

Internetarkitekturen

Kommunikationssystem av denna typ är komplexa. Komplexitet hanteras genom att strukturera, dvs dela upp i mindre delar, och studera en bit i taget. Ett standardiserat sätt att strukturera kommunikationssystem är i “skiktade kommunikationssystemarkitekturer”.

Standardisering inom Internetområdet sköts av IETF genom en RFC-process (Request For Comments). Alla RFC är tillgängliga via IETFs RFC-arkiv. Kraven för att fatta beslut brukar beskrivas som "Rough consensus and working code".

Internetarkitekturen består enligt RFC1122 och RFC1123 av skikten applikation, transport, nätverk och länk. Varje skikt erbjuder sin användare en eller flera specifika tjänster. Dessa tjänster implementeras i skiktet genom kommunikationsprotokoll, dvs regler för hur inblandade kommunicerande parter (protokollentiteterna) ska tilltala och svara varandra. Man utbyter väldefinierade sekvenser av så kallade protokollprimitiver, till exempel connect_request, connect_respons, connection_established, disconnect_request, etc.

Applikationskiktet

Exempel på applikationsprotokoll är SSH för fjärrinloggning, HTTP och HTTPS för kommunikation mellan en web-server och en webbrowser, FTP för filöverföring mellan en filserver och en klient, SMTP, IMAP och POP3 för epost, VoIP för talkommunikation/telefoni och RTSP för streaming audio/video.

Det finns också några så kallade nätverkstjänster på applikationsnivå som vi kommer att titta närmare på, främst "nummerkatalogen" DNS för hantering av domännamn och "nätklockan" NTP som distribuerar rätt tid. Dessa behöver båda finnas tillgängliga regionalt/lokalt om nätet bitvis trillar isär.

Applikationsprotokollen definierar typ av meddelanden som utväxlas, deras syntax och semantik, möjliga meddelandesekvenser och krav på transporttjänstens kvalitet (QoS). Vissa applikationer behöver 100% tillförlitlighet medan andra kan acceptera viss risk för dataförluster. Några applikationer, tex telefoni, kräver låg fördröjning och/eller låg variation i fördröjningen (jitter) och har krav på överföringskapacitet men är inte känsliga för att enstaka bitar blir fel eller tappas bort. Andra applikationer, tex epost, är mindre noga med just dessa parametrar men kräver att data kommer fram felfritt. Det kan också förekomma krav på konfidentialitet och dataintegritet som delvis måste lösas redan på applikationsnivå i själva applikationsprotokollet, tex genom SSL/TLS (Secure Socket Layer och Transport Layer Security). HTTPS är ett sådant exempel.

Applikation	Tolerans mot	Krav på
	Dataförlust	Överföringskapacitet	Fördröjning	Jitter
Filöverföring	nej	Elastisk	nej	nej
Epost	nej	Elastisk	nej	nej
Webaccess	nej	Elastisk	nej	nej
Texttjatt	nej	Elastisk	ja och nej
Audioströmning	ja	5 kbps-5Mbps	< 5s	nej
Videoströmning	nja	10kbps-5Mbps	< 5s	nej
Interaktiv audio	nja	5 kbps-5Mbps	< 100ms	ja
Interaktiv video	nja	10kbps-5Mbps	< 100ms	ja
interaktiva spel	nja	10kbps-5Mbps	< 50ms	ja

Några examensuppgifter:

Specificera, presentera och implementera en applikation som säkert (SSL/TLS) överför en bit peer-peer som på mottagarsidan används till att tända/släcka en LED kopplad till en rpi/gpio-38/39.
Sätt upp en nivå1-klocka
Sätt upp en DNS-server för din egen nod och dess närmaste omgivning

Transportskiktet

"socket"

Hur socketprorammering går till mer i detalj illustreras här med ett enkelt lärorikt klient-server-exempel inspirerat av [Kurose]. Titta gärna igenom exemplen, särskilt while-loopen som definierar respektive protokollentitets arbetsprocess. De är skrivna i programmeringsspråket python som är relativt intuitivt att förstå och lätt att köra interpreterat, dvs utan kompilering. Återvänd till dem då och då efter att ha läst mer om transportprotokollen nedan. Kopiera gärna ned dem och kör dem i din laptop eller Rpi. Det går att ha både server och klient på samma dator.

Servicekvalitet

Eftersom kraven på kommunikationen kan variera mellan olika applikationer, behöver transporttjänsten kunna uppfylla olika krav.

De två viktigaste transportprotokollen är det förbindelselösa UDP och det förbindelseorienterade TCP

UDP erbjuder bara "best-effort" utan återkoppling till avsändaren, medan TCP erbjuder

felfri dataöverföring, dvs kontroll av att alla datagram kommer fram i rätt ordning genom användning av sekvensnummer, felkontroll, kvittenser och omsändning av bortkomna eller felaktiga datagram,
flödeskontroll för att förhindra att sändaren dränker mottagaren och
överbelastningskontroll (congestion control) för att undvika att nätet emellan sändare och mottagare blir överbelastat. Det görs i pricip genom att avsändaren börjar sända paket i en relativt låg takt, ökar takten successivt, håller koll på återkoppling om paketförluster och stryper sändaren när nätet sådana tas emot.

Både UDP och TCP delar hanterar datagram som är längre än en specificerad maximal längd (MTU) genom att sändarsidans transportprocess delar upp meddelanden från applikationen i mindre transportsegment som skickas till mottagarsidans transportprocess via nätverksskiktet. Mottagarsidans transportprocess sätter samman segmenten igen i rätt ordning och skickar upp till applikationen.

Vare sig TCP eller UDP erbjuder leveranstidsgarantier eller viss överföringskapacitet, som snarare ställer krav på länknivåns kapacitet, eller säkerhet (konfidentialitet, dataintegritet) som ställer krav på applikationsnivå (Se SSL ovan)-

När applikationen slutfört förhandlingen med transporttjänsten på avsändarsidan och fört över applikationsdata, lägger transporttjänsten till ett transporthuvud och skickar paketet vidare till vidare till nätverkstjnsten.


  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |       |C|E|U|A|P|R|S|F|                               |
   | Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
   |       |       |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           [Options]                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               :
   :                             Data                              :
   :                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Nätverksskiktet

På nätverksnivån finns bara ett protokoll, IP, Internetprotokollet. Det är en av anledningarna till Internets oförutsedda framgång. Alla tillämpningar använder ett och samma nätverksprotokoll med ett occh samma standardiserade format som kan skickas över alla typer av länkar. IP befinner sig dock sedan en tid i en övergångsfas mellan två versioner, IPv4 och IPv6, beroende på att antalet bitar som definierar adressrymden har fått lov att ökas från 32 till 128, på grund av den oväntade framgången.
Standarden för ett ipv4-datagram finns beskriven i RFC791 från 1981.
Den senaste versionen av standarden för ett ipv6-datagram finns beskriven i RFC8200 från 2017.
Vi fokuserar till att börja med på IPv4.

Nätverksnivån - IPv4

Nätverksskiktet intar alltså en särställning genom att alla applikationer använder ett och samma nätverksprotokoll, Internetprotokollet IP som är paketorienterat med ett standardiserat paketformat.

Paketformat

RFC791

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fält 1 (4 bitar) Version 0100 (dvs decimalt 4)
Fält 2 (4 bitar) Huvudlängd. Kan variera. De flesta paket saknar optioner och minimilängden bir då 20 oktetter.
Fält 3 (8 bitar) Typ av service (ToS)
Fält 4 (16 bitar) anger den totala längden av datagrammet i oktetter, inklusive både huvud och data. Maximal längd blir 65535 oktetter. Normallängd är 1500 oktetter som ryms i en Ethernet-ram.
Fält 5-7 (16+4+12 bitar) Identification, Flags, Fragment offset, används vid fragmentering av ett datagram större än MTU för att kunna defragmentera korrekt på mottagasidan.
Fält 8 (8 bitar) ttl (time to live) Nedräknas av varje router. Paketet slängs om ttl blir noll för att förhindra att ett vilset paket cirkulerar i nätet i evighet.
Fält 9 (8 bitar) Protokoll Anger vilket protokoll som har beställt leveransen av datafältet. TCP = 6, UDP = 17 Fullständig lista finns hos IANA
Fält 10 (16 bitar) Huvudets checksumma
Fält 11 (32 bitar) Sändarens adress
Fält 12 (32 bitar) Mottagarens adress
Fält 13-14 (24+8 bitar) Options, padding
Data (payload) Vanligen ett TCP- eller UDP-segment eller ICMP-data

Adressering

En ipv4-adress består allltså av 32 bitar/4 oktetter som normalt utläses en oktett i taget i decimalt format (0-255) med en punkt emellan varje oktett, adressen 0 utläses alltså 0.0.0.0 och adressen 4294967295 (32 ettor) utläses 255.255.255.255. Adressen för resolver.amprnet.se 44.5.6.7 blir binärt 00101100 00000101 00000110 00000111

Subnät

Som tidigare påpekat, fick de lokala näten (LAN) en central roll tidigt i Internetutvecklingen. LAN-teknologierna, numera oftast ethernet och WiFi är nästan uteslutande sådana som stöder kommunikation där alla kan höra varandra, punkt-till-multipunkt. De som kan höra varandra tillhör en och samma broadcast-region. De behöver ingen router. Först när någon i LANet vill kommunicera med någon i ett annat LAN, behövs en router, eller gateway, som styr iväg trafiken åt det hållet. Detta faktum har påverkat addresseringen. LAN har en särställning. De minst sigifikanta bitarna (bitarna till höger) kan, med hjälp av en nätmask reservera ett så kallat subnät med egen nätadress och broadcastadress. De mest signifikanta bitarna kallas prefix.

Nätmasken består alltså, liksom ipv4-adressen, av ett 32-bitars ord (fyra oktetter), där alla bitar från vänster som definerar prefixet är ettor och alla bitar till höger som definierar subnätet är nollor.

Inledningsvis avsattes hela oktetter för subnät. Man pratade om adressklasserna A, B och C. A-nät hade en oktett för nätadressen och tre oktetter för adresser inom subnätet, B-nät hade två av varje och C-nät tre oktetter för nätadress och en oktett för subnätet.

Snart insåg man att klassindelningen medförde en ineffektiv användning av adressrymden och övergick till klasslös adressering, CIDR som tillåter godtycklig uppdelning av de 32 bitarna i adressen.

Nätmasken kan endera anges på samma sätt som adressen eller genom att efter adressen ange hur många bitar av nätmasken är ettor (kallas också prefix-längd). Om en oktett reserveras för subnätet får vi nätmasken 255.255.255.0 som är samma sak som /24. Om 4 bitar avsätts för subnätet blir masken 255.255.255.240 eller /28. Den första och sista adressen i subnätet är reserverade adresser, den första anger att det är själva nätet som avses. Den sista adressen är broadcastadressen som alla värdar i subnätet ska lyssna på. Övriga adresser kan användas för nätverkselement, tex värdar och gateway-router. Ett /28-subnät får allså 14 användbara adresser medan ett /24-subnät får 254. En inte ovanlig praxis är att sätta routern först och sedan övriga värdar, men det är inte ett krav. Det minsta subnät som CIDR tillåter är /30, dvs fyra adresser. Eftersom en punkt-till-punkt-länk inte behöver någon brodcastadress och behovet av att spara ipv4-adresser växte, bestämde man sig i rfc3021 för att i detta specialfall tillåta användning av ett /31-nät. De flesta, dock ej alla, routertillverkare stöder denna rfc.

DHCP

NAT

Tunnling

IP-IP tunneling

Forwarding/Vidarebefordran och Routing/vägvalsplanering

Forwarding/vidarebefordran handlar om att så snabbt som möjligt vidarebefordra ett mottaget datagram den väg som ruttabellen anger från inkommande till utgående interface när ett datagram anländer. All information finns redan lokalt.
Routing/vägvalsplanering handlar om att sätta upp ruttabellen som anger till vilken adress/vilket interface ett mottaget datagram ska vidarebefordras, om ett datagram anländer. Beslutsunderlaget kräver information från andra routrar.

Datagramvidarebefordran/Forwarding

prestandaparameter

Den tidskritiska processen består av ett antal steg som kan tas redan på inkommande interface

Ett inkommande länknivåpaket orsakar ett avbrott, checkas för bitfel och placeras i en in-buffert.
Datagrammen i paketen i in-bufferten lämnas till IP-nivån, ett i taget, där de defragmenteras och kollas.
Om allt är OK vidtar själva vidarebefordransproceduren genom att slå upp utgående interface i den av routingprotokollen sinnrikt förberedda FIB-tabellen (Forward Information Base). I linux finns denna att beskåda i katalogen /proc/net/fib_trie. Den i Linux använda sökalgortimen fib_trie.c bygger på denna rapport. Lämna över till lokal socket eller utgående interface.
Eventuell oönskad routing kollas, TTL minskas. ICMP-paket skickas till avsändaren om problem uppstått, annars fragmenteras datagrammet och lämnas över till utgående länknivå där det placeras i en ram i ett länknivåpaket och skeduleras för avsändning.

Vägvalsplanering/Routing

statisk routing

dynamisk routing

Vägvalsalgoritmerna kan vara centraliserade algoritmer som utgår från en helhetsbild av nätet där alla noder har samma kunskap om nätets topologi och länkkostnader, exempelvis link-state-algoritmer (LS) som används bland annat av OSPF, eller distribuerade algoritmer där noderna har kunskap om sin närmaste omgivning men inte hela bilden, exempelvis distans-vektor-algoritmen (DV) som används av bland annat RIP och BGP.

Länkstatus-algoritmen (LS)

Den vanligast använda LS-algoritmen är "Dijsktras algoritm" som hittar vägen med minsta kostnad ("shortest path") från en nod till varje annan nod i nätet. Algoritmen är iterativ. Varje iteration lägger till ett steg av vägen. Utvalda rutter placeras i routingtabellen och forwarding-tabellen.

Den som är intresserad av detaljerna i Dijkstra-algoritmen kan lätt hitta animerade diagram eller exekverbar python-kod som implementerar den på nätet, tex här eller här.

Distansvektor-algoritmen (DV)

Den som är intresserad av detaljerna i algoritmen kan lätt hitta animerade diagram eller exekverbar python-kod som implementerar algoritmen, exempelvis här

Jämförelse mellan LS och DV-algoritmerna

Konvergenshastigheten är lägre för DV-algoritmen än för LS-algoritmen och routing-loopar kan förekomma innan den har konvergerat.

Robustheten mot felande noder som är något större för LS-algoritmen, eftersom status för varje länk rapporteras separat och varje nod beräknar sin egen ruttabell, än för DV-algoritmen där felaktiga distansvektorelement kan påverka flera, i värsta fall alla, rutter.

Autonoma System (AS), Intranet- och Interdomän-routing

Autonoma System

bgp

Autonoma System är numrerade med 16-bitars heltal (två oktetter) upp till 65535. Intervallet 64512 - 65535 är reserverat för privata AS som vanligtvis används för AS som är anslutna till endast ett annat AS.

AMPRNET är uppdelat i regionala nät som alla är anslutna till Sunet. De regionala näten använder OSPF för sin intranet-routing. Några använder BGP med privat AS-nummer för sin anslutning till Sunet medan några har satt upp sin anslutning med statisk routing.

ospf

bgp

ICMP

ICMP type	Code	Description
0	0	echo reply to ping
3	0	destination network unreachable
3	1	destination host unreachable
3	2	destination protocol unreachable
3	3
3	6	destination network unknown
3	7	destination host unknown
4	0	source quench (congestion control)
8	0	echo request
9	0	router advertisement
10	0	router discovery
11	0	ttl expired
12	0	ip header bad

Länkskiktet

Vi använder två i grunden olika kommunikationsprinciper på länknivå: en-till-en (punkt-till-punkt) och en-till-många (punkt-till-multipunkt, broadcast).

En-till-många används oftas i lokala näverk (LAN) över medier som lätt delas så att flera noder kan höra varandra, tex via radio eller koppartråd, typ wlan eller ethernet. Då krävs också ett medium access-protokoll (MAC) som fördelar sändningstillstånd mellan noderna så att man inte pratar i mun på varandra. Det finns en rad olika MAC-protokoll. Man kan ha en ordförande som fördelar ordet eller noderna lyssnar och börjar sända när det är tyst Man hör om flera börjar samtidigt, tystnar och försöker i nästa lucka. Blir man för många, delar man upp sig i flera LAN.

En-till-en används oftare för att knyta ihop lokala nätverk som utser en av sina noder till gateway.

Som tidigare nämnts, kom de lokala näten först, historiskt. Internet har fått sitt namn just som nätet som knyter ihop alla LAN här i världen.

De tjänster som förväntas av länkskiktet är dels att hantera access till ett medium (MAC-protokollet), koppar/fiber-tråd eller radio, dels att kontrollera att paketen kommer fram felfritt. Om felfrekvensen över det speciella mediet är så låg att man inte behöver kolla i varje steg, kan man överlåta den kontrollen till TCP, på port-till-port-nivå. Annars behövs mekanismer för att upptäcka, och vid behov om möjligt till och med rätta bitfel (CRC och forward error correction - FEC), eller ta till sekvensnummer och omsändning (arq) (LLC-protokollet).

Länknivån faller standardiseringsmässigt utanför Internetramen. De numera dominerande länkprotokollen, Ethernet och WiFi/wlan, standardiseras av IEEE802. Vi tittar i första omgången närmare på 802.3 (ethernet) och och 802.1 (vlan). Så småningom kommer vi också till 802.11 (wlan)

IEEE802.3 Ethernet

Ett Ethernetpaket inleds med en 7+1 oktetters bitsekvens (preamble) avsedd att synkronisera sändare och mottagare. Därefter kommer en Ethernetram som innehåller destinations- och sändaradress, 6 oktetter var, och sedan ytterligare 6 oktetter för protokollparametrar (q-tag, typ) som vi återkommer till senare. Därefter kommer själva lasten, dvs datagrammet/IP-paketet. Som nämnts tidigare är ett IPv4-paket minst 22 oktetter långt och segmenteras om det är längre än en angiven maximal längd (MTU). Om inte annat anges är MTU=1500 oktetter. Sist i Ethernetpaketet, efter Ethernetramen, är 4 oktetter reserverade för en 32-bitars CRC-kod. Mellan varje paket ska det finnas ett tomrum motsvarande 12 oktetter.

 | Preamble (7+1) | Mottagare (6) | Sändare (6) | Parametrar (6) | Datagram (22-1500) | CRC (4) | Tomt (12) |

IEEE802.1 VLAN - Virtuella LAN

WiFi - IEEE 802.11 WLAN

 | ramstyrning  | period | tx-adress | rx-adress | gw-adress | #sekv. | adhoc | datagram | CRC |
              | (2) se nedan |   (2)  |    (6)    |    (6)    |    (6)    |  (2)   |  (6)  | (0-2312) | (4) |

    Ramformat (storlek i oktetter ovan, storlek i bitar nedan)
    
              | version | typ | subtyp | till | från | frag | omtag | pwr | mer data | WEP | res |
              |   (2)   | (2) |  (4)   |  (1) |  (1) |  (1) |  (1)  | (1) |   (1)    | (1) | (1) |