Széles körben használnak LAN-okat egyetlen épületen belül számítógépek összekapcsolására, a legtöbb nagy kiterjedésű hálózati infrastruktúra azonban kétpontos kapcsolatokra épül. A 4. fejezetben tárgyaljuk a LAN-okat. Itt most olyan kétpontos adatkapcsolati protokollokat fogunk vizsgálni, melyek az interneten két általános szituációban fordulnak elő. Az egyik esetben csomagokat küldenek át SONET optikai kapcsolatokon nagy kiterjedésű hálózatokban. Ezeket a kapcsolatokat széles körben használják például az internetszolgáltatók (ISP) hálózatában két különböző helyszínen található útválasztó összekapcsolására.
A második eset az internet szélén használatos, a telefonhálózatok előfizetői szakaszaiban megtalálható ADSL-kapcsolatok formájában. Ezeken keresztül több millió egyén és vállalat kapcsolódik az internetre.
Az internet is kétpontos kapcsolatokat igényel ilyen célokra ugyanúgy, ahogy a betárcsázós modemek (dial-up modem), a bérelt vonalak, a kábelmodemek és mások is. Egy szabványos protokollt, a PPP-t (Point-to-Point Protocol – kétpontos protokoll) használják csomagok küldésére az ilyen kapcsolatokon keresztül. A PPP-t az RFC 1661 definiálja, majd átdolgozták a RFC 1662-ben és a további RFC-kben is (Simpson, 1994a, 1994b). A SONET is és az ADSL is PPP-t használ, de mindkettő más módon.
A SONET – amelyről már ejtettünk szót a 2.6.4. szakaszban – a nagy kiterjedésű hálózatokban alkalmazott optikai kapcsolatot megvalósító fizikai rétegbeli protokoll, melyet leggyakrabban a kommunikációs hálózatok gerinchálózataiban használnak, beleértve a telefonhálózatokat is. Egy jól definiált sebességű bitfolyamot biztosít, például az OC-48 2,4 Gb/s sebességet határoz meg. Ezt a bitfolyamot adott darabszámú bájtot tartalmazó blokkokba (payload) rendezi, amelyeket 125 
s-onként ismétel, függetlenül attól, hogy van-e elküldendő felhasználói adat, vagy nincs.
Ahhoz, hogy csomagokat továbbítsunk ezeken a kapcsolatokon, valamilyen keretezési eljárásra lesz szükségünk, hogy megkülönböztessük az esetleges csomagokat attól a folyamatos bitfolyamtól, amelyben a csomagok továbbítódnak. Ennek biztosítására az IP-útválasztókon PPP-t futtatnak, ahogy azt a 3.23. ábrán láthatjuk.
3.23. ábra - Csomagok küldése SONET-en keresztül. (a) Egy protokollkészlet (b) Adategységek viszonya
A PPP egy korábbi, egyszerűbb protokoll továbbfejlesztése, amelyet SLIP-nek (Serial Line Internet Protocol – soros vonali internetprotokoll) neveznek. A PPP-protokollt hibakezelésre, kapcsolatok konfigurálására, több protokoll támogatására, hitelesítésre és több más célra használják. A lehetőségek széles tárházával rendelkezve három fő képessége van:
Olyan keretezési módszer, amely egyértelműen ábrázolja a keret végét és a következő keret kezdetét. A keretformátum megoldja a hibajelzést is.
Adatkapcsolati protokoll a vonalak felélesztésére, tesztelésére, az opciók megbeszélésére és a vonalak elegáns elengedésére, amikor már nincs rájuk szükség. Ezt a protokollt LCP-nek (adatkapcsolat-vezérlő protokoll – Link Control Protocol) nevezik.
Egy olyan megoldás a hálózati rétegbeli opciók megbeszélésére, amely független az alkalmazott hálózati rétegbeli protokolltól. A választott módszer az, hogy különböző NCP (Network Control Protocol – hálózatvezérlő protokoll) van mindegyik támogatott hálózati réteghez.
A PPP keretszerkezetét a tervezők a HDLC (High-level Data Link Control – magas szintű adatkapcsolati vezérlés) keretszerkezetéhez nagyon hasonlónak választották, mivel nem volt semmi okuk arra, hogy újra feltalálják a kereket.
A legfőbb különbség a PPP és a HDLC között az, hogy a PPP bájtalapú, a HDLC pedig bitalapú. Ez például abban nyilvánul meg, hogy a PPP bájtbeszúrást használ, és minden keret egész számú bájtot tartalmaz. A HDLC bitbeszúrást alkalmaz, és megenged, mondjuk, 30,25 bájtos kereteket is.
Van azonban egy másik fontos különbség is: a HDLC megbízható átvitelt biztosít csúszóablakkal, nyugtákkal és időzítőkkel úgy, ahogy azt korábban tanulmányoztuk. A PPP is képes megbízható átvitelt nyújtani zajos csatornákon, mint amilyenek például a vezeték nélküli hálózatok. A részleteket az RFC 1663-ban találjuk. A gyakorlatban azonban ezt ritkán használják. Helyette majdnem mindig a „számozatlan üzemmód” használatos az interneten, hogy összeköttetés nélküli, nyugtázatlan szolgáltatást nyújtson.
A PPP-keretek szerkezetét a 3.24. ábra mutatja be. Minden PPP-keret a szabványos HDLC-jelzőbájttal (0x7E, 01111110) kezdődik. Bájtbeszúrást alkalmaznak a 0x7D kivételbájttal, ha a jelzőbájt előfordul az Adat mezőben. A következő bájt az eredeti bájt és a 0x20 szám kizáró vagy (xor) kapcsolata, ami az 5. bitet megfordítja. Például a 0x7E bájtból bájtbeszúrás után a 0x7D 0x5E lesz. Ez azt jelenti, hogy a keret eleje és vége egyszerűen megtalálható a 0x7E bájtra való kereséssel, hiszen az nem fordulhat elő máshol. A vétel során a vett keretben a 0x7D bájtokat kell keresni, majd azokat eltávolítani, és a következő bájt és a 0x20 szám kizáró vagy kapcsolatát kell venni. Keretek közt mindössze egy jelzőbájt elegendő, több jelzőbájt a csatorna kitöltésére használható, ha nincs küldendő keret.
A keret kezdetét mutató jelzőbájt után következik a Cím mező, amelyik mindig a bináris 11111111 értékre van állítva, hogy jelezze, hogy minden állomásnak vennie kell a keretet. Ennek az értéknek a használatával elkerülhetjük az adatkapcsolati címek hozzárendelésének problémáját.
A Cím mezőt a Vezérlő mező követi, melynek alapértéke 00000011. Ez az érték a számozatlan keretet jelzi.
Mivel a Cím és a Vezérlő mezők mindig ugyanazok az alapbeállításban, az LCP biztosítja a szükséges mechanizmust a két résztvevő számára, hogy kihagyják ezeket a mezőket, és így megtakarítsanak 2 bájtot keretenként.
A negyedik mező a Protokoll mező. Ennek a feladata az, hogy megmutassa, hogy milyen csomag van az Adat mezőben. A 0 bittel kezdő értékeket az IP 4. és a 6. verziójának, valamint más hálózati rétegbeli protokolloknak (mint az IPX és az AppleTalk) definiálták. Az 1-es bittel kezdődő értékeket használják a PPP konfigurációs protokolljai, mint amilyen az LCP és a támogatott hálózati protokollokhoz tartozó NCP-k. A Protokoll mező hosszának alapértéke 2 bájt, de ez levihető 1 bájtra az LCP segítségével történő megegyezés alapján. A tervezők láthatólag nagyon óvatosak voltak, és feltételezték, hogy egyszer talán több mint 256 lehetséges protokoll lesz.
Az Adat mező változó hosszúságú, de legfeljebb a megegyezett maximumnak megfelelő méretű. Ha a hosszban nem egyeznek meg a felek a vonal beállítása alatt az LCP segítségével, az alapértelmezés 1500 bájt. Ha szükség van rá, az adat mezőt kitöltő bájtok követhetik.
Az Adat mező után az Ellenőrző összeg mező jön, amely rendszerint 2 bájtos, de a felek megegyezhetnek 4 bájtos ellenőrző összegben is. A 4 bájtos ellenőrző összeg valójában ugyanaz a 32 bites CRC, aminek a generátor polinomját a 3.2.2. szakasz végén megadtunk. A 2 bájtos ellenőrző összeg is egy szabványos CRC.
A PPP egy keretezési eljárás, amely különféle protokollok csomagjait képes továbbítani különböző fizikai rétegek felett. Ahhoz, hogy a PPP-t a SONET felett használjuk, az RFC 2615 ajánlásait kell követnünk [Malis és Simpson, 1999]. 4 bájtos ellenőrző összeg használatos, mivel ez az elsődleges eszköze a hiba felfedezésének a fizikai, adatkapcsolati és hálózati réteg felett. A Cím, Vezérlő és Protokoll mező tömörítése nem ajánlott, mivel a SONET kapcsolatok így is viszonylag nagy sebességgel működnek.
Van azonban egy szokatlan képessége is a PPP-nek. A PPP adatmezőjét tördelik (scrambling) (ahogy a 2.5.1. szakaszban leírtuk), mielőtt a SONET adatmezőjébe illesztik. A tördelés során az adatmezőt egy hosszú, ál-véletlen sorozattal kizáró vagy (xor) kapcsolatba hozzák, mielőtt továbbítják. Mindezt azért teszik, mert a SONET-nek a bitfolyamban gyakori bitváltásra van szüksége a szinkronizáció fenntartására. Ezek a váltások természetes módon kerülnek a beszédjelekbe, de az adatkommunikációban a felhasználó választja meg az elküldendő információt, és akár egy sok nullával feltöltött csomagot is elküldhet. Tördeléssel elhanyagolhatóvá tehető az esélye annak, hogy a felhasználó problémát tudjon okozni egy sok 0-t tartalmazó csomag elküldésével.
Mielőtt PPP-kereteket tudnánk küldeni SONET-vonalakon, a PPP-kapcsolatot fel kell építeni, és konfigurálni kell. A 3.25. ábrán ábrázoltuk azokat a fázisokat, melyeken a kapcsolat keresztülmegy, miközben felélesztjük, használjuk és elengedjük.
A kapcsolat kezdő állapota HALOTT, ami azt jelenti, hogy nincs fizikai rétegbeli összeköttetés. Miután a fizikai összeköttetés felépült, a kapcsolat a FELÉPÜLT állapotba kerül. Ezen a ponton a PPP-felek az Adat mezőben szállított LCP-csomagokat cserélnek, hogy a fentebb említett PPP-lehetőségekből válasszanak a kiépítendő kapcsolatra vonatkozólag. A kezdeményező fél felajánl opciókat, majd a válaszoló fél részben vagy egészben elfogadja vagy elutasítja azokat. A válaszoló alternatív opciókat is felajánlhat.
Ha az LCP-opciók megbeszélése sikeres, akkor a kapcsolat eléri a HITELESÍTETT állapotot. Ekkor a két fél ellenőrizheti egymás identitását. Ha a hitelesítés sikeres, akkor eljutunk a HÁLÓZAT állapotba, és egy sor NCP-csomagot küldenek a felek, hogy a hálózati réteget beállítsák. Nehéz általánosságban bármit is mondani az NCP-protokollokról, mivel mindegyik speciális valamely hálózati protokollra, és olyan konfigurációs kéréseket tesz lehetővé, melyek specifikusak arra a protokollra nézve. Például az IP esetén a legfontosabb ilyen lehetőség a kapcsolat két végpontjához IP-címek hozzárendelése.
A NYITOTT állapotot elérve lehetőség van a felhasználói adatok áramlására. Ebben az állapotban IP-csomagok továbbítása történik PPP-keretekben SONET-vonalakon keresztül. Ha az adatátvitel véget ért, akkor a kapcsolat a LEZÁRT állapotba kerül, majd innen a HALOTT állapotba ugrik a fizikai rétegbeli összeköttetés megszakadásakor.
Az ADSL segítségével sok millió lakossági előfizető kapcsolódik az internethez megabit/s nagyságrendű sebességgel ugyanazon az előfizetői szakaszon keresztül, amelyet a hagyományos telefonrendszer szolgáltatásához használnak. A 2.5.3. szakaszban leírtuk, hogyan lehet telepíteni egy DSL-modemet az előfizetői oldalon. A modem biteket küld az előfizetői szakaszon keresztül egy, a telefontársaságok helyi központjaiban lévő DSLAM (DSL Access Multiplexer – DSL hozzáférési multiplexer) nevű eszköznek. A következőkben áttekintjük, hogyan lehet csomagokat átvinni ADSL-kapcsolatokon.
A 3.26. ábrán egy áttekintő képet láthatunk az ADSL-lel használt protokollokról és eszközökről. Különböző hálózatokban különböző protokollokat használnak, így mi bemutatásra a legnépszerűbb esetet választottuk ki. Egy számítógép a lakásban – mondjuk egy PC – IP-csomagokat küld a DSL-modemnek az adatkapcsolati réteg felhasználásával, amilyen például az Ethernet is. A DSL-modem aztán elküldi ezeket az IP-csomagokat az előfizetői szakaszon keresztül a DSLAM részére egy olyan protokoll segítségével, amelyet most fogunk megvizsgálni. A DSLAM (vagy az implementációtól függően a hozzákapcsolt útválasztó) az IP-csomagokat kiveszi, és belépteti az ISP-szolgáltató hálózatába, hogy azok az interneten keresztül a címzetthez jussanak.
A protokollkészlet (nevezik protokollveremnek is), amelyet a 3.26. ábrán az ADSL-kapcsolat felett láthatunk, alulról az ADSL fizikai réteggel kezdődik. A réteg egy digitális modulációs eljáráson alapul, melyet ortogonális frekvenciaosztásos nyalábolásnak vagy más néven diszkrét többvivős modulációnak neveznek, ahogy a 2.5.3. szakaszban láttuk. A verem tetejéhez közel, az IP alatt találjuk a PPP-t. Ez ugyanaz a PPP, amit a 3.5.1. szakaszban tanulmányoztunk. Ugyanúgy működik az adatkapcsolat létesítésére, konfigurálására és IP-csomagok átvitelére.
Az ADSL és a PPP között helyezkedik el az ATM és az AAL5. Ezek olyan protokollok, melyekkel eddig még nem találkoztunk. Az ATM-et (Asynchronous Transfer Mode – aszinkron átviteli mód) az 1990-es évek elején tervezték, és hihetetlen méretű hírveréssel indították. Olyan hálózati megoldást ígért, amely a világ telekommunikációs problémáit véglegesen megoldja, amely a beszédet, az adatot, a kábeltelevíziót, a távírót, a postagalambot, a madzaggal egymáshoz erősített konzervdobozokat, a tam-tam dobokat és minden mást egyetlen integrált rendszerbe olvasztja, és megold mindenkinek mindent. Sajnos ez nem történt meg. Az ATM hibái nagyrészt hasonlóak voltak az OSI-protokollok hibáihoz, vagyis a rossz időzítés, a rossz technológia, a rossz implementáció és a rossz politika. Mindazonáltal az ATM sokkal sikeresebb volt, mint az OSI. Ugyan a világot nem hódította meg, de még mindig széles körben használják hozzáférési hálózatokban, amilyen a DSL, és WAN-kapcsolatokon a telefonhálózatok belsejében.
Az ATM olyan adatkapcsolati réteg, amely rögzített hosszúságú adategységek, ún. cellák átvitelén alapul. Az „aszinkron” jelző a nevében azt jelzi, hogy a cellákat nem kell folyamatosan küldeni, mint ahogy a biteket a szinkronvonalakon, például a SONET-en keresztül. A cellákat csak akkor kell átvinni, ha van valami elküldendő információnk. Az ATM összeköttetés-alapú technológia. Minden cella fejrészében van egy virtuális áramköri (virtual circuit) azonosító, amelyet az ATM-eszközök a cellák előre kiépített útvonalon történő továbbításánál használnak.
A cellák 53 bájt hosszúak, amiből 48 bájt a felhasználói adatoké, 5 bájt pedig a fejléc. A kis celláknak köszönhetően az ATM rugalmasan fel tudja osztani a rendelkezésre álló sávszélességet a különböző felhasználók között. Ez a képessége abban az esetben hasznos, amikor például adatot és valós idejű beszédet szeretnénk átvinni egyetlen adatkapcsolaton, elkerülve azt, hogy hosszú adatcsomagok nagy szórást okozzanak a beszéd mintáinak késleltetésében. A cella méretének szokatlan megválasztása (összehasonlítva például a sokkal természetesebbnek ható 2 hatványaival) is mutatja, hogy a politika milyen mértékben beleszólt az ATM tervezésébe. A 48 bájtos adatmező az Európa által szorgalmazott 32 bájtos cella és az Egyesült Államok által javasolt 64 bájtos cella közötti kompromisszum eredménye. Egy rövid összefoglalót olvashatunk az ATM-ről Siu és Jain [1995] munkájában.
Ahhoz, hogy adatokat küldjünk egy ATM-hálózaton keresztül, először az adatokat le kell képezni cellák sorozatára. A leképezést az ATM adaptációs rétege végzi egy „darabolás és összeállítás” (segmentation and reassembly) folyamat során. Számos adaptációs réteget definiáltak a különböző szolgáltatásokhoz, amelyek a periodikus beszédmintáktól egészen az adatcsomagokig terjed. A legfontosabb adaptációs réteg az adatcsomagok szállításához használt AAL5 (ATM Adaptation Layer 5 – 5. ATM adaptációs réteg).
A 3.27. ábra egy AAL5-keretet mutat. Fejléc helyett egy farokrészt tartalmaz, amely megadja a keret hosszát és tartalmaz egy hibajelzésre alkalmas 4 bájtos CRC-t. A CRC természetesen ugyanaz, mint amit a PPP és az IEEE 802 LAN-ok használnak (így az Ethernet is). Wang és Crowcroft [1992] megmutatták, hogy ez elég erős nem szokványos hibák (például cellasorrend változás) jelzésére. Az AAL5-keret adatmezője is tartalmaz kitöltést (padding), hogy a teljes hosszt 48 bájt többszörösére egészítse ki annak érdekében, hogy a keretet hiánytalanul cellákra lehessen osztani. Címekre nincs szükség a keretben, hiszen a cellák virtuális áramköri azonosítója gondoskodik a cellák célba juttatásáról.
Most, hogy megismerkedtünk az ATM-mel, már csak azt kell áttekintenünk, hogyan használja a PPP az ATM-et az ADSL esetében. Ezt ismét egy szabvány írja le, amelyet PPPoA-nak (PPP over ATM) neveznek. Ez a szabvány nem is igazán egy protokoll (ezért sem látjuk a 3.26. ábrán), hanem inkább egy specifikáció, amely azt adja meg, hogyan kell dolgozni mind PPP-keretekkel, mind AAL5 keretekkel. Leírása az RFC 2364-ben található [Gross és mások, 1998].
Az AAL5 adatmezőjébe csupán a PPP-protokollmező és PPP-adatmező került, ahogy azt a 3.27. ábrán látjuk. A protokollmező a DSLAM felé jelzi, hogy az adatmező egy IP-csomag vagy egy másik protokoll, például az LCP-csomagja. A szolgáltató oldalán tudják, hogy a cellák PPP-információt tartalmaznak, mivel egy ATM virtuális áramkör épült fel ennek érdekében.
Az AAL5-kereten belül PPP keretezésre nincs szükség, mivel semmilyen célja nem volna. Az ATM és az AAL5 ugyanis már biztosít keretezést, így bármilyen további keretezés értelmetlen volna. A PPP CRC ugyancsak felesleges, hiszen az AAL5 tartalmazza ugyanazt a CRC-t. Ez a hibajelzés kiegészíti az ADSL fizikai rétegének Reed–Solomon hibajavító kódolását és 1 bájtos CRC-jét, amelyet a rejtve maradt hibák jelzésére használnak. Ez a megoldás sokkal kifinomultabb hibakezelést biztosít, mint amikor csomagokat SONET-vonalon keresztül küldenek, ugyanis az ADSL-csatorna sokkal zajosabb.