|
Hoofdstuk 3 |
3.
Sessie- en transportlaag
3.1.1. Inleiding (H.320)
De videoconferencingstandaard voor ISDN is uitvoerig beschreven in een reeks ITU-T standaarden. ITU-T H.320 ook bekend onder de naam p * 64 (p star 64), is een soort paraplu- of overzichtsstandaard. De verschillende functies worden verder uitgewerkt in andere ITU-standaarden (tekening 59). Sommige zijn noodzakelijk (witte vakjes in tekening 59), andere optioneel (gekleurde vakjes in tekening 59).
Voor de 64Kbps-satelliettelefoon zijn slechts delen interessant. Datatransport, encryptie, far-end-camera-control en MCU-control (multipoint-control-unit: bij meer dan 2 gebruikers) zijn features die de beperkte bandbreedte nog zouden verkleinen. Ook H.261 annex D voor het doorsturen van stilstaande beelden wordt niet gebruikt.
Wel belangrijk zijn de multipexer en demultiplexer (H.221) die alle info in frames verpakt. Ook de C & I (controle en informatie) signalen (H.230) en de uitvoerig beschreven communicatieprocedures (H.242) zijn essentieel. Hiermee wordt onderhandeld over de “te gebruiken opties” bij het opzetten en tijdens de connectie.
Videocodering volgt de standaarden H.261 of H.263 (zie 2.1.3) en audiocodering de standaarden G.711, G.722 en G.728. Enkel deze laatste met zijn beperkte bandbreedte van 16Kbps is bruikbaar voor de satelliettelefoon (zie 2.2)
3.1.2. Multiplex en demultiplexlaag (H.221)
Het multiplexen is vrij eenvoudig en gebaseerd op synchrone detectie. Alle audio, video, synchronisatie-info (FAS of Frame alignment signal), configuratie-info (BAS of bitrate allocation signal) wordt gestructureerd in frames van 80 octets. De frameduur is 10 milliseconden. Na een opstartprocedure is de bitverdeling zoals voorgesteld in onderstaande tabel. Voor de video blijft 46,4Kbps over (64Kbps bandbreedte - 16Kbps G.728 audio - 0,8Kbps FAS - 0,8Kbps BAS).
|
Bit number |
The 10 ms H.221 frame met 16Kbps G728 |
Octet number |
|||||||
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
|
Speech |
A1 |
A2 |
V1 |
V2 |
V3 |
V4 |
V5 |
FAS1 |
1 |
|
A3 |
A4 |
V6 |
V7 |
V8 |
V9 |
V10 |
FAS2 |
2 |
|
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
: |
: |
: |
: |
: |
: |
: |
FAS8 |
8 |
|
|
: |
: |
: |
: |
: |
: |
: |
BAS1 |
9 |
|
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
: |
: |
V76 |
V77 |
V78 |
V79 |
V80 |
BAS8 |
16 |
|
|
: |
: |
V81 |
V82 |
V83 |
V84 |
V85 |
V86 |
17 |
|
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
A39 |
A40 |
: |
: |
: |
: |
: |
: |
20 |
|
|
Speech |
A01 |
A02 |
: |
: |
: |
: |
: |
: |
21 |
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
A39 |
A40 |
: |
: |
: |
: |
: |
: |
40 |
|
|
Speech |
A01 |
A02 |
: |
: |
: |
: |
: |
: |
41 |
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
A39 |
A40 |
: |
: |
: |
: |
: |
: |
60 |
|
|
Speech |
A01 |
A02 |
: |
: |
: |
: |
: |
: |
61 |
|
: |
: |
: |
: |
: |
: |
: |
: |
: |
|
|
A39 |
A40 |
V459 |
V460 |
V461 |
V462 |
V463 |
V464 |
80 |
|
Axx =
audiobit (bit A1 = most significant bit / bit A40 = least significant bit)
Vxxx =
videobit
Met de 8 BAS-bits/frame stuurt men informatieve boodschappen en commando’s bijvoorbeeld over de ondersteunde audio of video. Dit bepaalt op zijn beurt de bitposities in het frame. G.728 audio komt bijvoorbeeld altijd op bit 1 en 2 van een octet. De BAS en de FAS hebben altijd dezelfde positie in het frame. De video vult dan de rest van de bandbreedte op. De BAS komt in het volgende hoofdstuk verder aan bod.
De 8 FAS-bits/frame dienen voor twee soorten synchronisatie. Framesynchronistatie over een window van 2 frames (de sub-multiframes) en multiframesynchronistatie over een window van 16 frames (de multiframes).
Voor de framesynchronisatie gaat de ontvanger op zoek naar de bitstructuur zoals aangeduid in onderstaande tabel in de licht gekleurde vakjes. Bij de initialisatie moet dit gedurende 16 frames kloppen als het netwerk geen octet-timing voorziet. In de andere gevallen (vb. de ISDN-satelliettelefoon) is het signaal framesynchroon als de structuur “0011011”, “1” en “0011011” op de juiste plaatsen in opeenvolgende frames is gevonden. 3 opeenvolgende sub-multiframes met een foute structuur betekent verlies van synchronisatie.
Multiframesynchronisatie wordt normaal gebruikt bij het synchroniseren van meerdere kanalen bijvoorbeeld 2 * 64Kbps ISDN-kanalen. Bij een enkel kanaal is het niet noodzakelijk. Voor multiframesynchronisatie zoekt de ontvanger de bitsstructuur in de donkere vakjes van onderstaande tabel. Dit kan gecombineerd worden met genummerde multiframes. De bits N1 tot N4 duiden dan het nummer van het multiframe aan en bit N5 of nummering ondersteund (1) wordt of niet (0). 3 opeenvolgende multiframes met een foute structuur betekent verlies van de multiframesynchronisatie, 2 opeenvolgende multiframes met een juiste structuur herstel. Een ontvanger die multiframesynchroon is, brengt de zender op de hoogte door de A-bit op 0 ipv. 1 te zetten. Bij een enkel kanaal zonder multiframesynchronisatie, wordt A-bit op 0 ipv. 1 gezet als de ontvanger framesynchroon is. De A-bit is belangrijk bij het opzetten van de verbinding.
|
|
Sub-Multiframe
(SMF) |
Frame |
Bits
1 to 8 of FAS in every frame |
|||||||
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
||
|
Multiframe |
|
0 |
N1 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
SMF1 |
1 |
0 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
2 |
N2 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF2 |
3 |
0 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
4 |
N3 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF3 |
5 |
1 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
6 |
N4 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF4 |
7 |
0 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
8 |
N5 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF5 |
9 |
1 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
10 |
L1 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF6 |
11 |
1 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
12 |
L2 |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF7 |
13 |
L3 |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
|
|
14 |
TEA |
0 |
0 |
1 |
1 |
0 |
1 |
1 |
|
|
SMF8 |
15 |
R |
1 |
A |
E |
C1 |
C2 |
C3 |
C4 |
|
R =
reseved bit
Met de bits C1 tot C2 kan men een CRC (cyclic redundancy check) van een submultiframe doorsturen. Geen errors wordt aan de zender gemeld met een E-bit gelijk aan 0, errors met een E-bit gelijk aan 1.
De bits L1, L2 en L3 dienen voor kanaalaanduiding bij meerdere kanalen (voor ons niet van toepassing)
De TEA-bit (terminal equipment alarm) wordt op 1 gezet als de ontvanger een intern probleem heeft. TEA wordt enkel ondersteund wanneer multiframesynchronisatie ondersteund wordt.
3.1.3. C & I en communicatieprocedures (H.230 en H.242)
De BAS bestaat uit twee delen: een BAS-code (8 bits doorgestuurd met elk even frame) en een dubbele error-correction-code van de BAS (8 bits doorgestuurd met elk oneven frame). De BAS-codes deelt men nog eens op in twee delen: 3 bits voor de groep van commando’s/opties en 5 bits voor het specifieke commando/optie. Onderstaande tabel geeft een overzicht.
Het onderhandelen verloopt volgens een algemeen optie-commando-principe. Eerst maken beiden hun ontvangstopties bekend. Daarna kondigen commando’s (met een juiste CRC!) een mode-switch van de zender aan. Een voorbeeld van zo’n commando kan zijn: “bij het volgende submultiframe stuur ik een andere (door jouw ondersteunde) audio-codering”. Merk op dat de heen en terugweg niet noodzakelijk gelijke instellingen gebruiken.
|
Groepen |
Commands/capabitities |
Voorbeelden |
|
[000] |
Audio coding commando’s |
- Neutral (geen andere data behalve FAS en BAS) - G.711 (mu of
a-law/ framed of unframed [1]
) - G.722 (64, 56, 48 Kbps) - G.728 |
|
[001] |
Transfer rate
commando’s |
- n * 64 Kbps-kanalen - n * 384 Kbps-kanalen |
|
[010] |
Video en andere commando’s |
- Video off - H.261, H263, mpeg1 - Freeze picture (vasthouden van het laatste beeld) - Het blijven verfijnen van het laatste beeld
(speciale
voorzieningen in H263) - Encryptie on/off
(speciale procedure) - Loopbackfuncties - Restrictie (maatregelen bij 56Kbps ISDN) |
|
[011] |
Data commando’s |
- Datakanalen met verschillende bandbreedtes |
|
[100] |
Opties |
- G.711 (mu of a-law), G.722, G728 - n * B-kanalen, n * H0-kanalen |
|
[101] |
Opties |
- H.261 (QCIF of
CIF) - Maximum framerate - Mpeg1 - Mogelijkheid om bepaalde escape codes in [111] te gebruiken - Datakanalen |
|
[110] |
Opties |
|
|
[111] |
Escape codes |
- Escape codes naar
andere tabellen van commando’s of opties (bijvoorbeeld om geluid en beeld
te synchroniseren) - Voor commando’s of
opties langer dan 8 bits (vb. het ondersteunen van H.263 met zijn talrijke
opties zoals framerates,
framesize, pixelsize, soort motion-
compensation, bufferparameters, profielen, feedback voor error-compensatie, gedeeltelijk
freezen van het beeld, … ) |
Opmerking: Opties gebruiken
meestal een hiërarchie. Een “hogere” optie houdt dan alle “lagere”
opties in.
Onderstaande tekening 60 illustreert het opzetten van de sessie.
Wanneer het netwerk meldt dat de fysieke connectie is voorzien, stuurt terminal X G.711 met FAS en BAS. De BAS bevat een reeks opties die terminal X kan of wil gebruiken. Terminal Y antwoordt op een reeks opties altijd met een reeks eigen opties. Beide terminals blijven de reeksen herhalen. Ontvangt terminal X een A-bit (0) dan weet hij dat de andere kant synchroon is. Daarop zendt X nog 1 volledige reeks en sluit af met een commando die bijvoorbeeld een modeswitch tot gevolg heeft. Terminal Y kan simultaan hetzelfde doen.
Merk op dat de connectie begint in G.711 voor de compatibiliteit met digitale telefoontoestellen. De FAS en BAS bits zitten immers verscholen in de least significant bits van het spraaksignaal (zie framestructuur). Wanneer na verloop van tijd de terminal geen framing op het binnenkomend signaal ontdekt, wordt G.711 zonder FAS en BAS opgestuurd. De terminal blijft in dit geval wel zoeken naar FAS en BAS.
Ook tijdens de sessie kan een terminal reeksen opties doorsturen wanneer bijvoorbeeld nieuwe of minder opties bruikbaar zijn. De tegenpartij antwoordt altijd met een eigen reeks. Beiden passen zich zo snel mogelijk aan de nieuwe situatie aan door bijvoorbeeld nieuwe commando’s te sturen.
3.1.4. Besluit
Ondanks het gevaar voor fouten (bijvoorbeeld door te grote satelliet-delay-tijden voor de timers in H.320 [2] ) blijkt de standaard goed combineerbaar met de satelliettelefoon. Framesynchronisatie en communicatiecodes zitten in de 64Kbps-band. Ze nemen slechts een beperkte bandbreedte in (1,6 Kbps). Toch zijn er voldoende mogelijkheden om - ook tijdens de sessie - het beste uit de 62,4Kbps te halen, zeker bij het gebruik van de vele opties van H.263.
3.2. File transfer
Dit stukje bouwt verder op de lessen TCP/IP. Bij het lezen is een basiskennis van vooral TCP en PPP nuttig.
3.2.1. FTP
FTP (file transfer protocol) verschilt van de meeste andere TCP/IP-toepassingen omdat meerdere TCP-connecties gemaakt worden. Eén TCP-controle-kanaal blijft de hele sessie open. De TCP-datakanalen worden tijdelijk geopend wanneer een file moet doorgestuurd worden (zowel uploaden naar of downloaden van de server) of wanneer een lijst van de files (directory) wordt opgevraagd. FTP duidt het einde van de doorgestuurde file of directory aan door het datakanaal te sluiten.
Tekening 61 toont de interactie tussen de verschillende FTP-elementen. Bij het begin van de sessie luistert de server in de passieve-open-mode op poort 21. De client opent actief het TCP-datakanaal. De commando’s van de gebruiker worden vertaald in FTP-commando’s die over het datakanaal worden gestuurd. De server antwoordt over hetzelfde kanaal. Wanneer een gebruiker bijvoorbeeld een file opvraagt, zet de client een ephemeral poort (dit is een tijdelijke poort boven 1024) in de passieve-open-mode. De gebruikers-protocolvertaler geeft het poortnummer met een FTP-commando door aan de server. De server bevestigt de ontvangst van het poortnummer. De gebruikersprotocolvertaler stuurt nu een tweede commando met het verzoek de file te downloaden. De server zal actief het datakanaal openen en de file doorsturen. Merk op dat de kant van de server altijd het poortnummer 20 gebruikt.
Er bestaat een uitgebreide lijst met commando’s en antwoorden. Ze worden doorgezonden in NVT (network virtual terminal) ASCII-formaat. Dit is een variant van ASCII die elk karakter met 7 bits voorstelt en de 8ste most significant bit opvult met “0”. Het einde van een regel wordt doorgestuurd met 2 speciale tekens: “\r” (return) en “\n” (newline).
De commando’s (zie onderstaande tabel) gebruiken 4 letters voor het type. Eventuele extra informatie zoals bijvoorbeeld een filenaam, komt daarna.
|
Commando's (Client -> Server) |
Betekenis |
|
ABOR |
Speciaal (enig telnet-) commando om het
vorige commando ongedaan te maken en om een data-transfer
af te breken |
|
CWD naam |
Change Working
Directory: vergelijkbaar met CD voor DOS
|
|
LIST naam |
Directory opvragen |
|
PASS paswoord |
Paswoord doorsturen |
|
PORT xxx,xxx,xxx,xxx,yyy,zzz |
IP-adres (4 * xxx) en poortnummer (yyy *
256 + zzz) voor het opzetten van het datakanaal |
|
QUIT |
Afbreken van de FTP-sessie |
|
RETR naam |
File downloaden |
|
STOR naam |
File uploaden |
|
SYST |
De client vraagt welk systeem de server
gebruikt. Dit kan de manier van downloaden beïnvloeden (zie volgend
commando) |
|
TYPE A / I |
Er kan onderhandeld worden over het
gebruikte transportformaat Meest gebruikt zijn A (ASCI) en I
(binair) mode. |
|
USER naam |
Gebruikersnaam doorsturen |
De antwoorden gebruiken 3 cijfers. Hiermee weet het client-proces hoe hij het antwoord moet verwerken. Eventuele extra informatie zoals een welkomsboodschap van de server, is enkel voor de gebruiker. Deze info komt na de cijfers.
Tekening 62 op de volgende pagina’s geeft een uitgebreid overzicht van de FTP-procedure met voorbeelden van antwoorden en commando’s (schuingedrukt). Meer uitleg over de gebruikte symbolen staat na de tekening.
Uitleg Tekening 62
Bij het opzetten van een TCP-verbinding:
SYN is een TCP-vlag: voor het opzetten van de verbinding. Tegelijk worden de tellers (m:m en n:n) gesynchroniseerd. Het aantal doorgestuurde databytes per pakket staat tussen haakjes. De maximum windowsize van de ontvanger wordt aangeduid met win xxxxx, de TCP-optie “maximum segment size” met <mss 1460>. Dit komt overeen met de default-waarde van het onderliggend datalinkprotocol PPP (1500 Bytes - 40 Bytes headers). De ACK xxx duidt op het volgende verwachte bytenummer (relatief ten opzichte van de gesynchroniseerde tellers).
Bij het gebruik van een TCP-verbinding.
PSH is een TCP-vlag. Ze wordt op 1 gezet als de zendbuffer leeg is (zo wordt het ook meestal geïmplementeerd). “Schuingedrukte tekst” zijn de FTP-commando’s en antwoorden.
Bij het einde van een TCP-verbinding:
FIN is de TCP-vlag gebruikt voor het
stoppen van de TCP-verbinding. Merk op
dat hoewel het aantal verstuurde databytes (0) is de teller toch met 1 wordt
verhoogd (dit is trouwens ook zo voor de SYN-vlag).
Opmerkingen:
- Voor de eenvoud wordt de window-size enkel bij het opzetten van TCP-verbinding getoond. Gedurende de TCP-sessie gebeurt flow-control met aangepaste waardes.
- Ook het verzenden van ACK-pakketten is een dynamische gegeven. De bevestigingen moeten dus niet verlopen zoals aangegeven.
- Acties in het TCP-datakanaal en het TCP-controlekanaal kunnen gelijktijdig verlopen.
Bij het doorsturen van audio/video-files met de satelliettelefoon gaat het niet om het downloaden van files (met het commando RETR “filename”) maar om het uploaden naar een server (met het commando STOR “filename”). Fundamenteel verandert dit niet veel aan tekening 62. De client verzoekt de server te mogen uploaden (met de commando’s PORT en STOR ipv PORT en RETR). Hij stelt een ephemeral poort in de passieve open-status. De server doet de actieve opening. Het sluiten zal wel door de client gedaan worden. Het afsluiten van de dataconnectie betekent immers het einde van de doorgestuurde file.
3.2.2. TCP en satellietcommunicatie
TCP/IP is ontworpen voor netwerken. Twee problemen kunnen de performantie beperken wanneer de protocol-stack gecombineerd wordt met satellietverbindigen. Een eerste probleem heeft te maken met de lange delaytijden. Dit noemt men ook het long-fat-pipe probleem. Een tweede probleem heeft te maken de verzadigingsmaatregelen in TCP/IP.
Het long-fat-pipe probleem ontstaat wanneer veel data “onderweg” is (in de pijp zit). Dit kan omdat de pijp groot is (een grote bandbreedte) of omdat de pijp lang is (een grote delay of round-trip time). TCP houdt rekening met vertragingstijden. Aan de hand van een voorspellingalgoritme wordt bepaald hoelang een packet en de bevestiging (ACK) onderweg zullen zijn. Komt geen bevesting binnen een redelijke termijn (afhankelijk van die voorspelling) dan wordt het packet opnieuw gestuurd. Hoe beter de voorspelling, hoe beter de performantie (minder onnodige hertransmissies). Bij long-fat-pipes blijkt die voorspelling vooral bij high-speed-netwerken niet accuraat genoeg. ACK’s kunnen meerdere pakketten bevestigen waardoor onnauwkeurigheden in de voorspelling ontstaan. Een optie in TCP (de timestamp-optie) komt tegemoet aan de nood voor een nauwkeuriger voorspelling. Maar... in tegenstelling tot netwerken met variabele delay’s is de delay van de isdn-satelliettelefoon vrij constant. Het systeem is immers ook gemaakt voor spraak dat zeer weinig jitter (variabele vertraging) verdraagt. Hier zit dus geen probleem voor onze toepassing.
Er zit nog een addertje onder het gras bij long-fat-pipes. Dat heeft te maken met de gebruikte buffers. De volgende formule leert hoeveel data in de pijp zit:
Capaciteit v/d pijp = Bandbreedte v/d pijp * Round trip time
of in ons geval:
51.200 bits = 64.000 bps * 0,800 s
Voor een maximale throughput moet de zender minimaal 51.200 bits bufferruimte hebben. Een ACK moet het pakket immers bevestigen, voor het weggegooid mag worden. De buffer van de ontvanger moet even groot zijn. Dit heeft te maken met de flow control. De ontvanger beperkt het zenden met een advertised window (het TCP window-size-field). Wanneer de bufferruimte van de ontvanger groot genoeg is (minimum 51.200 bits), vormt dit advertised window geen beperking.
Het window-size-field in TCP is 16 bits wat neerkomt op een maximale window-grootte van 65.535 Bytes. Bij zeer grote long-fat-pipes kan dit niet voldoende zijn [3]. Voor onze toepassing is dit geen probleem. Wel interessant in deze context is na te gaan welke software toelaat de buffergrootte in te stellen. Enkele clients en servers op een rij:
Cuteftp (FTP-client): max zend en ontvangst buffer = 16384 Bytes
Leechftp (FTP-client): geen aanduidingen
G6 ftpserver: max ontvangst buffer = 65535 Bytes
WS_FTP: max zend en ontvangstbuffer = 4096 Bytes
Een ander mogelijk probleem bij satellietcommunicatie, zijn principes van TCP/IP om netwerkcongestie (verzadiging) te vermijden. Slow-start en fast recovery zijn uitgebreide congestie-controle-systemen. Hierbij worden steeds meer pakketten verzonden tot aan het verzadigingspunt van het netwerk, dan weer minder en geleidelijk terug meer,... Wanneer pakketten verloren gaan, gaat TCP/IP er vanuit dat netwerkverzadiging de oorzaak is. De congestie-controle-systemen zorgen dan automatisch voor minder verzonden pakketten. Voor gewone netwerken (die weinig last hebben van transmissiefouten) klopt de veronderstelling (pakketverlies door verzadiging) meestal. Mobiele communicatie heeft per definitie meer last van transmissiefouten. TCP/IP zal bij pakketverlies door de transmissiefouten bij mobiele communicatie ten onrechte de performantie naar beneden halen.
De kans op bitfouten bij de isdn-satelliettelefoon is klein. Typische waardes liggen tussen 1 fout op 1*106 en 1 fout op 1*107. De performantie van het circuit-swiched systeem zal wel wat zakken door een netwerkprotocol (TCP/IP) te gebruiken. De congestie-controle-principes verlagen hier de throughput. Dit neemt niet weg dat FTP gemakkelijk en betrouwbaar is.
3.2.3.
PPP (Point to
Point Protocol).
Voor de encapsulatie van TCP/IP in het ISDN B-kanaal wordt PPP gebruikt. Het is een eenvoudig datalinkprotocol gebaseerd op de structuur van HDLC. PPP kan men zowel voor synchrone (zoals de octet-timing bij ISDN) als asynchrone communicatie gebruiken. De niet gecomprimeerde versie van het frame ziet eruit als tekening 63.
De begin- en eindvlag is identiek als bij HDLC. Wanneer twee frames dadelijk op elkaar volgen, wordt slechts 1 vlag tussen de twee frames gebruikt. Als de byte 0x7e ook in de data voorkomt, wordt ze vervangen door de escape-byte 0x7d en 0x5e. De byte 0x7d in de data wordt op zijn beurt veranderd in 0x7d en 0x5d. Bytes onder 0x20 worden ook gewijzigd doorgestuurd omdat deze bytes dikwijls worden gebruikt als controletekens bij o.a. modems. Zo kan geen verwarring ontstaan.
Het adres en controle-veld hebben een vaste waarde. Deze velden dienen voor compatibiliteit met HDLC.
Het CRC-veld omvat het hele frame zonder de vlaggen en de wijzigingen door escapekarakters.
Met het protocolveld wordt het soort datagram aangeduid. In ons geval is de code voor IP-pakketten 0x0021. Men gebruikt speciale datagrammen voor het configureren van de link (0xc021: LCP of Link Control Protocol) en voor het configureren van het bovenliggend protocol (0x8021: NCP of Network Control Protocol). Met LCP wordt meestal beslist het protocolveld te beperken tot 1 byte en het adres- en controleveld weg te laten.
Voor onze toepassing kan NCP onderhandelen over een interessante TCP/IP-optie: de Van Jacobson header compressie. Bij een TCP-connectie zoals file transfer worden typisch honderden pakketten verstuurd. Veel van de informatie in de IP en TCP header blijft in zo’n sessie gelijk. De grijze velden in tekening 64 toont de informatie die meestal niet verandert. Een eenvoudige identificatie (<1 byte) kan deze velden in de meeste IP-pakketten vervangen. De IP-velden “total-lenght” en “header checksum” zijn overbodig omdat PPP het begin en einde van een frame herkent en CRC voorziet. De rest van de data vertoont dikwijls een grote correlatie. In de FTP-richting van de zender naar de ontvanger (datakanaal) veranderen bijvoorbeeld de ACK’s, het “sequence number” en de “packet identification” respectievelijk niet, met 1 of met vaste sprongen (zie tekening 62). Wanneer de zender en de ontvanger het vorige pakket bufferen, kunnen enkel de verschillen doorgestuurd worden. Met deze principes comprimeert Van Jacobson de 40 byte TCP/IP header tot gemiddeld 3 tot 5 bytes.
Dit laat ons toe een theoretische maximum throughput van onze ftp-toepassing te berekenen:
- het gecomprimeerd PPP-pakket: 4 Bytes overhead/pakket.
- het gecomprimeerde TCP/IP-pakket: 5 Bytes overhead/pakket.
- per pakket wordt maximaal 1460 Bytes data vervoerd [4] .
- die verhouding is 99,39% data t.o.v. 0,61% overhead. Dit komt neer op een theoretische maximum throughput van 63,6 Kbps voor de 64 Kbps ISDN.
In de praktijk is 56 Kbps een goede waarde. Oorzaak is waarschijnlijk het negatieve effect van het flow-control-mechanisme van TCP.