PPP og multilink PPP

Point-to-Point Protocol (PPP)  

PPP [33] er en protokoll for å overføre pakker mellom to endepunkter (peers) over full-dupleks linjer. Det er mulig å multiplekse flere protokoller (f.eks. IP og AppleTalk) over den samme PPP-linken.

PPP består av tre hovedkomponenter:

• En mentode for å pakke inn multi-protokoll datagrammer.
• En Link Control Protocol (LCP) for å kontrollere å etablere, configurere og teste dataforbindelsen.
• Et sett med Network Control Protocols (NCP) for å konfigurere nettverkslags protokoller.

Oppbyggingen av pakkene i PPP er (vist grafisk i figur ):

1.

Protokoll (8 eller 16 bit). Least significant bit i least significant octet skal være 1. Dette er ISO 3309 mekanisme for utvidelse av adressefelt.

2.

Informasjon. Her overføres datagrammet til protokollen spesifisert i protokollfeltet. Også kontrollprotokollene LCP og NCP overføres som datagrammer her.

3.

Padding. Alle pakker kan paddes. Det er opp til protokollen som overføres i informasjonsfeltet å avgjøre om, og tilfelle hvor mye, av pakken som er padding.

 

Figure:  Pakkeformat for PPP

Det er verdt å merke seg at ``the peer'' alltid er `den andre enden''. Dette er helt uavhengig av hvem som koblet opp den fysiske betegnelsen, f.eks. kan begge endepunktene kreve at peeren autentiserer seg. På grunn av dette kan spesifikasjonene for PPP være litt vanskelige å forstå hvis man tenker på klient og server, slik det gjerne oppleves ved oppkobling til en internettleverandør.

Protokollstakken som det arbeides med i denne oppgaven er vist i figur .

 

Figure:  Protokollstakken som brukes i denne oppgaven

PPP over asynkrone linjesvitsjede nett

Over linjesvitsjede nett (eller dedikerte linjer) bruker PPP HDLC for å ramme inn pakker [34]. Innpakking består av (vis grafisk i figur :

1.

Flagg (0x7E).

2.

Adressefelt (0xFF). Dette er adressen til ``alle stasjoner''. PPP tildeler ikke adresser til individuelle stasjoner.

3.

Kontrolloktett (0x03).

4.

Pakken som spesifisert over.

5.

Frame Check Sequence (16 bit). CRC sjekksum som gitt i ISO 3309 eller ITU-T X.25.

6.

Flagg (0c7E).

 

Figure:  Rammeformat for HDLC lik innramming av PPP-pakker

Flaggverdien 0x7E må escapes i pakken som overføres. 0x7D er valgt som escapeverdi. Bit-stuffing der 6. bit inverteres brukes for å overføre spesialtegn, dvs at 0x7D overføres som 0x7D, 0x5D og 0x7E overføres som 0x7D, 0x5E.

Alle data overføres med en startbit, 8 databiter og en stopbit.

Link Control Protocol

Etter at hardwarelaget er satt opp, må hver ende av PPP linken sende LCP pakker for å konfigurere forbindelsen. LCP består av tre pakketyper:

• Pakker for linkkonfigurasjon: Configure-Request, Configure-Ack, Configure-Nak og Configure-Reject. Disse brukes for å etablere og sette opp en forbindelse.
• Pakker for å avslutte link-laget: terminate-Request og Terminate-Ack.
• Pakker for vedlikehold av linken: Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply og Discard-Request.

Forhandlingen av parametre forgår ved at Configure-Request sendes til peer. En slik pakke kan inneholde ønske om flere parametre. Denne pakken kan besvares med Configure-Ack for parametre som godtas, Configure-Nak for parametre der verdien ikke kan godtas og Configure-Reject for parametre som ikke godtas (uansett verdi). Parametre forhandles frem ved at disse meldingene sendes mellom endepunktene inntil alle parametre som hver av endepunktene krever er forhandlet fram. Det kan skje at det ikke lykkes å forhandle fram alle parametre (f.eks. hvis et endepunkt krever mulitlink PPP mens det andre endepunktet ikke støtter det).

Blant parametrene som forhandles fram er MRU (maximum Receive Unit). Autentisering er også en del av LCP[33,27,15].

LCP er nærmere beskrevet i [33] ved hjelp av tilstandstabeller.

Network Control Protocol

De NCPene som brukes for å forhandle fram IP parametre for PPP kalles Internet Protocol Control Protocol (IPCP)[16]. Ved hjelp av IPCP forhandles det fram IP-adresser og IP-komprimering (se ).

Multilink PPP (MP)

  Multilink PPP [28] er en utvidelse til PPP som gjør det mulig å slå sammen flere uavhengige kommunikasjonskanaler slik at de oppfører seg som en logisk kanal. Denne sammenslåingen foregår altså på linklaget, og krever ingen endringer av IP-implementasjonen eller høyere nivås protokoller.

Denne protokollen er forholdsvis ny, den første spesifikasjonen er fra november 1994. Bakgrunnen for at den ble utviklet var et ønske om å kunne utnytte flere B-kanaler med ISDN forbindelser. Protokollen kan imidlertid brukes til å koble sammen et tilfeldig antall forbindelser med varierende båndbredde. Det er altså mulig å, for eksempel, bruke en GSM-kanal kontinuerlig og sette opp en høyhastighets satelittlink ved store dataoverføringer.

MP setter sammen flere uavhengige PPP forbindelser til en logisk forbindelse. Hver link som legges til den logiske (multi)linken er altså en uavhengig og fullverdig PPP-link. MP kan modeleres som et pseudolag som legges mellom linklaget og internettlaget og håndterer sammenkoblingen av flere fysiske kanaler. MP forhandles fram ved at et ønske om (Configure-Request) parameteren MRRU (Maximum-Receive-Reconstruct-Unit) sendes til peeren. Denne parameteren styrer hvor store pakker som tilsammen kan settes sammen hos det mottagende endepunktet. IP-datagram som sendes over MP settes sammen igjen i den nettverksutstryet som implementerer MP. Datagrammene sendes altså ikke fragmentert videre ut på nettet.

Det er opp til implementasjonen av MP om pakker skal deles opp, og hvor store hvert enkelt fragment skal være.

En PPP pakke som beskrevet i , deles opp i et antall fragmenter. Hver av disse fragmentene pakkes inn i en ny pakke, med dette formatet (vist grafisk i figur ):

1.

Protokoll (0x3D)

2.

Flagg (B,E,0,0,0,0,0,0) eller (B,E,0,0)

3.

Sekvensnummer (12 eller 24 bit)

4.

Fragment

Flagget B er satt på det første fragmentet, og E på det siste. Om sekvensnummeret skal være 12 eller 24 bit avgjøres av en LCP parameter.

 

Figure:  Pakkeformat for Multilink PPP

Van Jacobson header komprimering  

Van Jacobson komprimering av headere [14] er et system for å komprimere headerne i en TCP forbindelse. Et vanlig datagram med TCP har en header på 40 bytes (20 bytes IP og 20 bytes TCP). Disse pakkene overføres som egne protokoller i PPP.

Ved å utnytte flere egenskaper ved både TCP og IP oppnås det for de mest vanlige pakkene en 3 byte header. Alle forbindelser tildels et 8 bits nummer som brukes for å identifisere forbindelsen. Headere på 3 byte oppnås for TCP forbindelser for interaktiv bruk (små rammer) og bulk-data (store rammer). Denne komprimeringen oppnås bl.a. ved å kun overføre endring i vindusstørrelse og segmentnummer. Hvis flere TCP forbindelser benytter den samme linken overføres kun identifikatoren til forbindelsen hver gang en ny forbindelse benytter linjen. Dette gjør at headeren blir 3 eller 4 byte, der den 4. byten er identifikatoren ved bytte av forbindelse.

Alle pakker i forbindelse med oppsett og terminering av forbindelsen overføres i sin helhet (med 40 bytes header). Alle andre pakker komprimeres hvis de ikke er fragmentert.

Beregning av overhead med multilink PPP og TCP

Det er 5 forhold som bidrar til overhead med multilink PPP:

• HDLC innramming (6 byte)
• Escaping av tegn for å oppnå transparent overføring
• MP header (4 byte, hvis ikke annet forhandles fram)
• PPP header (1 byte, ingen av de vanligst brukte protokollene er tildelt 16-bits nummer [26].)
• IP header 20 bytes i tillegg til TCP header (20 bytes) Ved maksimal Van Jacobson kompresjon tilsammen 3 eller 4 bytes for IP og TCP header.
• Oppsett av TCP forbindelsen (5 TCP-pakker)

Samlet headerstørrelse vi kunne variere mellom 14 og 51 byte. Disse beregningene forutsetter Van Jacobson komprimering med 3 bytes TCP/IP header. I tillegg kommer escaping av tegn. Hvis man antar at alle tegn oversendes like ofte og 2 tegn må escapes, vil $\frac{2}{256} = 2,81\%$ av alle tegn escapes.

Antall bytes overhead (o) pr. antall bytes overførte nyttedata (n) er gitt i ligning . I denne ligningen er s antall bytes som overføres for å sette opp og terminere forbindelsen, e andel av tegnene som må escapes, l antall linker, o_l antall bytes overhead for hver pakke overført på en link, o_v størrelsen på Van Jacobsen headeren, p pakkestørrelse og o_p antall bytes overhead for hver pakke som overføres (PPP header).

 

$$o = \frac{s}{n} + \frac{l \cdot o_{l} + o_{p}}{p} \cdot \frac{n}{p} + e$$ (1)

Hvis man setter inn de vanligste verdiene for s = 205 + 10l (5 pakker med 40 byte TCP/IP header samt 1 byte PPP header, i tillegg til l linker med 6 byte MP/HDLC header), o_l=10, $e = 2.81\%$, o_p=3 og p=1600 blir o en funksjon av n og l som i ligning .

 

$$o(n,l) = \frac{205 + 10l}{n} + \frac{10l + 3}{1600} \cdot \frac{n}{1600} + 0.0281$$ (2)

Denne funksjonen er plottet i figur for l lik 1, 2, 3 og 4. Ved bulkoverføring av data bidrar økende antall linker lite til den totale overhead. I tillegg til dette kommer start og stop bit.

 

Figure:  o(n) for forskjellige l.