Point-to-Point-protokoll över Ethernet

**PPPoE och TCP/IP- protokollstack**
Ansökan	FTP	SMTP	HTTP	...	DNS	...
Transport	TCP				UDP
Internet	IP			IPv6
Nätverkstillgång	PPP
	PPPoE
	Ethernet

Point -to-Point Protocol over Ethernet ( PPPoE ) är ett nätverksprotokoll för att kapsla in Point-to-Point Protocol (PPP)-ramar inuti Ethernet- ramar. Den dök upp 1999, i samband med DSL -boomen som lösningen för att tunnla paket över DSL-anslutningen till ISP :s IP -nätverk och därifrån till resten av Internet . En nätverksbok från 2005 noterade att "De flesta DSL-leverantörer använder PPPoE, som tillhandahåller autentisering , kryptering och komprimering ." Typisk användning av PPPoE innebär att utnyttja PPP-faciliteterna för att autentisera användaren med ett användarnamn och lösenord, främst via PAP- protokollet och mer sällan via CHAP . Runt 2000 började PPPoE också bli en ersättningsmetod för att prata med ett modem anslutet till en dator eller router över ett Ethernet- LAN och ersatte den äldre metoden, som hade varit USB . Detta användningsfall, att ansluta routrar till modem via Ethernet är fortfarande extremt vanligt idag.

På kundens utrustning kan PPPoE implementeras antingen i en enhetlig gateway- enhet för bostäder som hanterar både DSL- modem och IP -routingfunktioner eller i fallet med ett enkelt DSL-modem (utan routingstöd), PPPoE kan hanteras bakom det på en separat Ethernet-router eller till och med direkt på en användares dator. (Stöd för PPPoE finns i de flesta operativsystem, allt från Windows XP , Linux till Mac OS X. ) På senare tid ^{[ när? ]} , använder vissa GPON -baserade (istället för DSL-baserade) bostadsgateways också PPPoE, även om statusen för PPPoE i GPON-standarderna är marginell.

PPPoE utvecklades av UUNET , Redback Networks (nu Ericsson) och RouterWare (nu Wind River Systems ) och är tillgänglig som en informativ RFC 2516.

I DSL-världen var PPPoE allmänt sett att köras ovanpå ATM (eller DSL) som den underliggande transporten, även om ingen sådan begränsning finns i själva PPPoE-protokollet. Andra användningsscenarier särskiljs ibland genom att som suffix en annan underliggande transport. Till exempel, PPPoEoE, när transporten är själva Ethernet, som i fallet med Metro Ethernet- nätverk. (I den här notationen skulle den ursprungliga användningen av PPPoE märkas PPPoEoA, även om det inte bör förväxlas med PPPoA , som är ett annat inkapslingsprotokoll.)

PPPoE har i vissa böcker beskrivits som ett " lager 2.5 "-protokoll, i någon rudimentär mening liknar MPLS eftersom det kan användas för att särskilja olika IP-flöden som delar en Ethernet-infrastruktur, även om bristen på PPPoE-switchar fattar routingbeslut baserat på PPPoE-huvuden begränsar tillämpligheten i det avseendet.

Ursprunglig motivering

I slutet av 1998 hade DSL-tjänstemodellen ännu inte nått den stora skalan som skulle få ner priserna till hushållsnivåer. ADSL-teknik hade föreslagits ett decennium tidigare. potentiella utrustningsleverantörer och operatörer insåg att bredband som kabelmodem eller DSL så småningom skulle ersätta uppringd tjänst, men hårdvaran (både kundlokaler och LEC ) stod inför en betydande kostnadshinder för låga kvantiteter . Initiala uppskattningar för lågkvantitetsdistribution av DSL visade kostnader i intervallet $300–$500 för ett DSL-modem och $300/månad åtkomstavgift från telekom, [behövd hänvisning] vilket var långt utöver vad en ^{hemanvändare skulle betala} . Därför var det initiala fokuset på små och hemföretagskunder för vilka en ~1,5 megabit T1-linje (vid tiden $800–1500 $ per månad) inte var ekonomisk, men som behövde mer än uppringd eller ISDN kunde leverera. Om tillräckligt många av dessa kunder banade väg, skulle kvantiteter driva priserna ner till där hemanvändaren kan vara intresserad.

Annan användningsprofil

Problemet var att småföretagskunder hade en annan användningsprofil än en uppringd användare för hemmabruk, inklusive:

Ansluta ett helt LAN till Internet;
Tillhandahållande av tjänster på ett lokalt LAN tillgängligt från den andra sidan av anslutningen;
Samtidig åtkomst till flera externa datakällor, såsom ett företags VPN och en allmän ISP;
Kontinuerlig användning under hela arbetsdagen, eller till och med dygnet runt.

Dessa krav lämpade sig inte för fördröjningen av anslutningsetablering av en uppringd process eller dess en-dator-till-en-ISP-modell, inte ens den många-till-en som NAT plus uppringd tillhandahöll . En ny modell krävdes.

PPPoE används huvudsakligen antingen:

med PPPoE-talande Internet DSL- tjänster där ett PPPoE-talande modem - router ( residential gateway ) ansluter till DSL-tjänsten. Här måste både ISP och modem-router tala PPPoE. (Observera att i det här fallet kallas PPPoE-över-DSL-sidan av saker ibland som PPPoEoA , för "PPPoE över ATM ".)
eller när ett PPPoE-talande DSL-modem är anslutet till en PPPoE-talande Ethernet-router med en Ethernet-kabel.

Tid till marknaden: enklare är bättre

Ett problem med att skapa ett helt nytt protokoll för att fylla dessa behov var tid. Utrustningen var tillgänglig omedelbart, liksom tjänsten, och en helt ny protokollstack ( Microsoft vid den tiden förespråkade fiberbaserade atm-celler-till-skrivbordet, och L2TP bryggde också, men var inte nära att slutföras) skulle ta så lång tid att implementera att möjlighetsfönstret kan glida förbi. Flera beslut togs för att förenkla implementering och standardisering i ett försök att snabbt leverera en komplett lösning.

Återanvänd befintliga mjukvarustackar

PPPoE hoppades kunna slå samman den utbredda Ethernet-infrastrukturen med den allestädes närvarande PPP, vilket gör det möjligt för leverantörer att återanvända sin befintliga programvara och leverera produkter inom en mycket nära sikt. I princip alla operativsystem vid den tiden hade en PPP-stack, och utformningen av PPPoE möjliggjorde ett enkelt shim vid linjekodningsstadiet för att konvertera från PPP till PPPoE. ^{[ citat behövs ]}

Förenkla hårdvarukraven

Konkurrerande WAN-tekniker (T1, ISDN) krävde en router i kundens lokaler. PPPoE använde en annan Ethernet-ramtyp, vilket gjorde att DSL-hårdvaran helt enkelt fungerade som en brygga , skickade vissa ramar till WAN och ignorerade de andra. Implementeringen av en sådan bro är flera storleksordningar enklare än en router.

Informations-RFC

RFC 2516 släpptes ursprungligen som en informativ (snarare än standardspår ) RFC av samma anledning: antagandeperioden för en standardspår RFC var oöverkomligt lång.

Framgång

PPPoE designades ursprungligen för att tillhandahålla ett litet LAN med individuella oberoende anslutningar till Internet i stort, men också sådant att protokollet i sig skulle vara tillräckligt lätt för att det inte skulle påverka den efterlängtade hemmaanvändningsmarknaden när det äntligen kom. Även om framgång i den andra frågan kan diskuteras (vissa klagar på att 8 byte per paket är för mycket) lyckades PPPoE uppenbarligen få tillräcklig volym för att få ner priset för tjänsten till vad en hemanvändare skulle betala.

Moderna användningsfall

Runt 2000 användes PPPoE-protokollet antingen (i) för att ansluta ett DSL-modem till en dator eller router, vilket ersatte den tidigare metoden att använda USB, eller (ii) PPP +PPPoE-trion av protokollrubriker användes för att ansluta en router till en nätverksnod, en protokollomvandlare, något längre uppströms tillhörande antingen ISP:n eller till en grossist långdistansoperatör som i sin tur ansluter till ISP:s IP-nätverk och sedan till internet.

Det första användningsfallet, router-till-modem-anslutningen, som involverar så kallad 'PPPoEoE' (PPPoE-protokolltrion över ett fysiskt Ethernet-LAN), används fortfarande mycket idag för att ansluta modem till routrar om PPP används.

Det andra användningsfallet, där PPPoE-protokolltrion används över en eller flera internetaccesslänkar som når uppströms till ett större eller mindre djup, används, enligt konsensus, fortfarande endast av historiska skäl. Men eftersom PPP fortfarande är populärt hos vissa internetleverantörer, antingen som ett tunnlingsprotokoll, behövs det där en internetleverantör använder en grossistoperatör/återförsäljare eller för att funktionerna i PPP önskas, eller båda.

nog, används Ethernet MAC- huvuden ibland i PPPoE-huvuden även när Ethernet-protokollet inte används, inte fysiskt närvarande i ett Ethernet-nätverk. Detta verkar inte tjäna något syfte förutom att lägga till ytterligare onödig header-overhead, så kallad bloat . Till exempel i fallet, som diskuteras nedan, med PPPoEoA, där det inte fanns något fysiskt Ethernet, bara ATM , lades inte bara ett onödigt Ethernet MAC-lager av header-overhead till utan även ett extra Ethernet-anpassningslager för att få Ethernet att passa ovanpå ATM .

I det andra användningsfallet tillför dessa ytterligare protokollrubriker en rejäl mängd svullnad och skadar därför prestanda med en liten mängd.

I det andra användningsfallet sträcker sig användningen av PPP+PPPoE+Ethernet MAC till ett variabelt avstånd uppströms. Det kan vara begränsat till den " första milen ": ett koppartvinnat par i ADSL eller VDSL2 / FTTC som involverar modem och inte längre, eller så kan det också användas längre uppströms och sträcker sig till en BRAS "Broadband Remote Access Server" eller "access concentrator" som kanske eller kanske inte hanterar inloggning men kommer säkert att vara en protokollomvandlare av något slag. I ett exempelfall sträcker sig PPPoE uppströms till och slutar vid en sådan nod som drivs av en grossistoperatör som konverterar till L2TP -tunnlingsprotokollet som tunnlar till ISP:s IP- POP ('punkt av närvaro').

Etapper

PPPoE har två distinkta steg:

PPPoE-upptäckt

Eftersom traditionella PPP-anslutningar upprättas mellan två ändpunkter över en seriell länk eller över en virtuell ATM-krets som redan har upprättats under uppringning, kommer alla PPP-ramar som skickas på tråden säkert att nå den andra änden. Men Ethernet-nätverk är multiaccess där varje nod i nätverket kan komma åt varannan nod. En Ethernet-ram innehåller hårdvaruadressen för destinationsnoden ( MAC-adress) . Detta hjälper ramen att nå den avsedda destinationen.

Innan man byter ut PPP-kontrollpaket för att upprätta anslutningen över Ethernet bör MAC-adresserna för de två ändpunkterna vara kända för varandra så att de kan kodas i dessa kontrollpaket. PPPoE Discovery-stadiet gör exakt detta. Det hjälper också till att upprätta ett sessions-ID som kan användas för ytterligare utbyte av paket.

PPP-session

När peerens MAC-adress är känd och en session har upprättats, startar sessionsstadiet.

PPPoE-upptäckt (PPPoED)

Även om traditionell PPP är ett peer-to-peer- protokoll, är PPPoE i sig en klient-server- relation eftersom flera värdar kan ansluta till en tjänsteleverantör över en enda fysisk anslutning.

Upptäcktsprocessen består av fyra steg mellan värddatorn som fungerar som klient och åtkomstkoncentratorn vid Internetleverantörens ände fungerar som server. De beskrivs nedan. Det femte och sista steget är sättet att stänga en befintlig session.

Klient till server: Initiering (PADI)

PADI står för PPPoE Active Discovery Initiation.

Om en användare vill "ringa upp" till Internet med hjälp av DSL, måste deras dator först hitta DSL-åtkomstkoncentratorn (DSL-AC) vid användarens internetleverantörs närvaropunkt ( POP). Kommunikation över Ethernet är endast möjlig via MAC-adresser . Eftersom datorn inte känner till MAC-adressen för DSL-AC:n skickar den ut ett PADI-paket via en Ethernet- sändning (MAC: ff:ff:ff:ff:ff:ff). Detta PADI-paket innehåller MAC-adressen för den dator som skickar det.

Exempel på ett PADI-paket:

Bildruta 1 (44 byte på tråd, 44 byte fångad) Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff PPP-over-Ethernet Discovery Version: 1 Typ 1 Kod Active Discovery Initiation (PADI) Sessions-ID: 0000 Nyttolastlängd: 24 PPPoE-taggar Tag: Service-Name Tag: Host-Uniq Binära data: (16 byte)

Src. (=källa) innehåller MAC-adressen till datorn som skickar PADI. Dst. (=destination) är Ethernet-sändningsadressen. PADI-paketet kan tas emot av mer än en DSL-AC. Endast DSL-AC-utrustning som kan tjäna taggen "Service-Name" ska svara.

Server till klient: Erbjudande (PADO)

PADO står för PPPoE Active Discovery Offer.

När användarens dator har skickat PADI-paketet, svarar DSL-AC med ett PADO-paket med hjälp av MAC-adressen som anges i PADI. PADO-paketet innehåller MAC-adressen för DSL-AC, dess namn (t.ex. LEIX11-erx för T-Com DSL-AC i Leipzig ) och namnet på tjänsten. Om mer än en POP:s DSL-AC svarar med ett PADO-paket, väljer användarens dator DSL-AC för en viss POP med det angivna namnet eller tjänsten.

Här är ett exempel på ett PADO-paket:

Bildruta 2 (60 byte på tråd, 60 byte fångad) Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df PPP-over-Ethernet Discovery Version: 1 Typ 1 Kod Active Discovery Offer (PADO) Sessions-ID: 0000 Nyttolastlängd: 36 PPPoE-taggar Tag: AC-Name String Data: IpzbrOOl Tag: Host-Uniq Binär Data: (16 byte)

AC-Name -> Stringdata innehåller AC-namnet, i detta fall "Ipzbr001" (Arcor DSL-AC i Leipzig) Src. innehåller MAC-adressen för DSL-AC. MAC-adressen för DSL-AC avslöjar också tillverkaren av DSL-AC (i det här fallet Nortel Networks) .

Klient till server: begäran (PADR)

PADR står för PPPoE active discovery request.

Ett PADR-paket skickas av användarens dator till DSL-AC efter mottagande av ett acceptabelt PADO-paket från DSL-AC. Den bekräftar acceptans av erbjudandet om en PPPoE-anslutning som gjorts av DSL-AC som utfärdar PADO-paketet.

Server till klient: sessionsbekräftelse (PADS)

PADS står för PPPoE Active Discovery Session-bekräftelse.

PADR-paketet ovan bekräftas av DSL-AC med ett PADS-paket och ett sessions-ID ges ut med det. Anslutningen till DSL-AC för den POP har nu upprättats helt.

Endera änden till den andra: uppsägning (PADT)

PADT står för PPPoE Active Discovery Termination. Detta paket avslutar anslutningen till POP. Det kan skickas antingen från användarens dator eller från DSL-AC.

Protokoll overhead

PPPoE används för att ansluta en PC eller en router till ett modem via en Ethernet-länk och den kan också användas för Internetåtkomst över DSL på en telefonlinje i PPPoE över ATM (PPPoEoA) över ADSL -protokollstack . PPPoE över ATM har den högsta omkostnaden av de populära DSL-leveransmetoderna, jämfört med till exempel PPPoA (RFC 2364).

Använd med DSL – PPPoE över ATM (PPPoEoA)

Mängden overhead som läggs till av PPPoEoA på en DSL-länk beror på paketstorleken på grund av (i) den absorberande effekten av ATM-cellutfyllnad (diskuteras nedan), som helt eliminerar ytterligare overhead av PPPoEoA i vissa fall, (ii) PPPoEoA + AAL5- overhead som kan orsaka att en hel extra 53-byte ATM-cell krävs, och (iii) i fallet med IP-paket kan PPPoE-overhead som läggs till paket som är nära maximal längd ('MRU') orsaka IP - fragmentering , vilket inbegriper också de två första övervägandena för båda de resulterande IP-fragmenten. Oavsett om man ignorerar ATM- och IP-fragmentering för tillfället, kan protokollhuvudets omkostnader för ATM-nyttolast på grund av att man väljer PPP + PPPoEoA vara så hög som 44 byte = 2 byte (för PPP) + 6 (för PPPoE) + 18 (Ethernet MAC, variabel ) + 10 (RFC 2684 LLC, variabel) + 8 (AAL5 CPCS). Denna overhead är den som erhålls när du använder LLC-huvudalternativet som beskrivs i RFC 2684 för PPPoEoA.

Jämför detta med ett mycket mer header-effektivt protokoll, PPP + PPPoA RFC 2364 VC-MUX över ATM+DSL, som bara har 10-byte overhead inom ATM-nyttolasten. (Faktum är att bara 10 byte = 2 byte för PPP + noll för RFC 2364 + 8 (AAL5 CPCS).)

Denna siffra på 44 byte AAL5 nyttolast kan minskas på två sätt: (i) genom att välja alternativet RFC 2684 att kassera 4-byte Ethernet MAC FCS, vilket minskar siffran 18 byte ovan till 14, och (ii) av med RFC 2684 VC-MUX-alternativet, vars overheadbidrag är bara 2 byte jämfört med 10 byte-overheaden för LLC-alternativet. Det visar sig att denna omkostnadsminskning kan vara en värdefull effektivitetsförbättring. Genom att använda VC-MUX istället för LLC är ATM-nyttolasten antingen 32 byte (utan Ethernet FCS) eller 36 byte (med FCS).

ATM AAL5 kräver att en 8-byte lång "CPCS"-trailer alltid måste finnas i slutet av den sista cellen ('högerjusterad') av körningen av ATM-celler som utgör AAL5-nyttolastpaketet. I LLC-fallet är den totala ATM-nyttolasten 2 + 6 + 18 + 10 + 8 = 44 byte om Ethernet MAC FCS är närvarande, eller 2 + 6 + 14 + 10 + 8 = 40 byte utan FCS. I det mer effektiva VC-MUX-fallet är ATM-nyttolasten 2 + 6 + 18 + 2 + 8 = 36 byte (med FCS), eller 2 + 6 + 14 + 2 + 8 = 32 byte (ingen FCS ) .

Men den verkliga omkostnaden i termer av den totala mängden ATM-nyttolastdata som skickas är inte bara ett fast tilläggsvärde – det kan bara vara antingen noll eller 48 byte (om man bortser från scenario (iii) som nämnts tidigare, IP-fragmentering). Detta beror på att ATM-celler har en fast längd med en nyttolastkapacitet på 48 byte, och att lägga till en större extra mängd AAL5-nyttolast på grund av ytterligare rubriker kan kräva att ytterligare en hel ATM-cell skickas som innehåller överskottet. De sista en eller två ATM-cellerna innehåller utfyllnadsbyte som krävs för att säkerställa att varje cells nyttolast är 48 byte lång.

Ett exempel: I fallet med ett 1500-byte IP-paket skickat över AAL5/ATM med PPPoEoA och RFC2684-LLC, och försummar slutlig cellutfyllnad för tillfället, börjar man med 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS trailer) = 1544 byte om Ethernet FCS finns, eller annars + 2 + 6 + 14 + 10 + 8 = 40 byte utan FCS. För att skicka 1544 byte över ATM krävs 33 48-byte ATM-celler, eftersom den tillgängliga nyttolastkapaciteten på 32 celler × 48 byte per cell = 1536 byte inte är tillräckligt. Jämför detta med fallet med PPP + PPPoA som vid 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS trailer) = 1510 byte passar i 32 celler. Så den verkliga kostnaden för att välja PPPoEoA plus RFC2684-LLC för 1500-byte IP-paket är en extra ATM-cell per IP-paket, ett förhållande på 33:32. Så för 1500 byte-paket är PPPoEoA med LLC ~3,125 % långsammare än PPPoA eller optimala val av PPPoEoA-huvudalternativ.

För vissa paketlängder kommer den verkliga ytterligare effektiva DSL-overheaden på grund av valet av PPPoEoA jämfört med PPPoA att vara noll om den extra header-overheaden inte räcker för att behöva en extra ATM-cell vid just den paketlängden. Till exempel, ett 1492 byte långt paket som skickas med PPP + PPPoEoA med RFC2684-LLC plus FCS ger oss en total ATM-nyttolast på 1492 + 44 = 1536 byte = 32 celler exakt, och overheaden i detta speciella fall är inte större än om vi använde det header-effektiva PPPoA-protokollet, vilket skulle kräva 1492 + 2 + 0 + 8 = 1502 byte ATM-nyttolast = 32 celler också. Fallet där paketlängden är 1492 representerar den optimala effektiviteten för PPPoEoA med RFC2684-LLC i förhållande, om inte ännu längre paket är tillåtna.

Att använda PPPoEoA med RFC2684 VC-MUX header-alternativet är alltid mycket effektivare än LLC-alternativet, eftersom ATM-overheaden, som tidigare nämnts, bara är 32 eller 36 byte (beroende på om detta är utan eller med Ethernet FCS-alternativet i PPPoEoA ) så att ett 1500 byte långt paket inklusive alla omkostnader av PPP + PPPoEoA med användning av VC-MUX motsvarar totalt 1500 + 36 = 1536 byte ATM-nyttolast om FCS är närvarande = 32 ATM-celler exakt, vilket sparar en hel ATM-cell.

Med korta paket, ju längre header-overheaden är desto större är sannolikheten att generera en extra ATM-cell. Ett värsta fall kan vara att skicka 3 ATM-celler istället för två på grund av en 44 byte header overhead jämfört med en 10 byte header overhead, så det tar 50 % mer tid att överföra data. Till exempel är ett TCP ACK-paket över IPv6 60 byte långt, och med overhead på 40 eller 44 byte för PPPoEoA + LLC kräver detta tre 48 byte ATM-cellers nyttolaster. Som en jämförelse passar PPPoA med omkostnader på 10 byte så totalt 70 byte in i två celler. Så den extra kostnaden för att välja PPPoE/LLC framför PPPoA är 50 % extra data som skickas. PPPoEoA + VC-MUX skulle dock vara bra: med 32 eller 36 byte overhead passar vårt IP-paket fortfarande i två celler.

I alla fall är det mest effektiva alternativet för ATM-baserad ADSL-internetåtkomst att välja PPPoA (RFC2364) VC-MUX. Men om PPPoEoA krävs är det bästa valet alltid att använda VC-MUX (till skillnad från LLC) utan Ethernet FCS, vilket ger en ATM-nyttolast på 32 byte = 2 byte (för PPP) + 6 (för PPPoE) + 14 (Ethernet MAC, ingen FCS) + 2 (RFC 2684 VC-MUX) + 8 (AAL5 CPCS trailer).

Tyvärr kräver vissa DSL-tjänster användning av slösaktiga LLC-huvuden med PPPoE och tillåter inte det effektivare VC-MUX-alternativet. I så fall, genom att använda en reducerad paketlängd, såsom att upprätthålla en maximal MTU på 1492, återvinns effektiviteten med långa paket även med LLC-huvuden och, som tidigare nämnts, genereras i så fall ingen extra slösaktig ATM-cell.

Overhead på Ethernet

På ett Ethernet LAN är overheaden för PPP + PPPoE fasta 2 + 6 = 8 byte , om inte IP-fragmentering skapas.

MTU/MRU

När ett PPPoE-talande DSL-modem skickar eller tar emot Ethernet-ramar som innehåller PPP + PPPoE nyttolast över Ethernet-länken till en router (eller PPPoE-talande enskild PC), bidrar PPP + PPPoE med ytterligare 8 byte = 2 (PPP) + 6 (PPPoE) som ingår i nyttolasten för varje Ethernet-ram. Denna tillagda overhead kan innebära att en reducerad maximal längdgräns (så kallad ' MTU ' eller ' MRU ' ) på 1500 − 8 = 1492 byte läggs på (till exempel) IP-paket som skickas eller tas emot, i motsats till de vanliga 1500- byte Ethernet ram nyttolast längdgräns som gäller standard Ethernet-nätverk. Vissa enheter stöder RFC 4638, som tillåter förhandling för användning av icke-standardiserade Ethernet-ramar med en 1508-byte Ethernet-nyttolast, ibland kallad "baby jumbo-ramar ", så att det tillåter en full 1500-byte PPPoE-nyttolast. Denna möjlighet är fördelaktig för många användare i de fall där företag som tar emot IP-paket (felaktigt) har valt att blockera alla ICMP- svar från att lämna sitt nätverk, en dålig praxis som förhindrar att sökvägs-MTU-upptäckt fungerar korrekt och som kan orsaka problem för användare som kommer åt sådana nätverk. om de har en MTU på mindre än 1500 byte.

PPPoE-till-PPPoA-konverterande ADSL-modem

Följande diagram visar ett scenario där ett Ethernet-anslutet ADSL-modem fungerar som en PPPoE-till- PPPoA -protokollomvandlare och tjänsteleverantören erbjuder en PPPoA-tjänst och inte förstår PPPoE. Det finns ingen PPPoEoA i denna protokollkedja. Detta är en optimalt protokolleffektiv design för ett separat ADSL-modem kopplat till en router via Ethernet.

I denna alternativa teknik är PPPoE bara ett sätt att ansluta DSL-modem till en endast Ethernet-router (igen, eller till en enda värddator). Här handlar det inte om den mekanism som används av en ISP för att erbjuda bredbandstjänster.

Draytek Vigor 110, 120 och 130 modemen fungerar på detta sätt.

Vid överföring av paket bundna till Internet skickar den PPPoE-talande Ethernet-routern Ethernet-ramar till det (även PPPoE-talande) DSL-modemet. Modemet extraherar PPP-ramar från de mottagna PPPoE-ramarna och skickar PPP-ramarna vidare till DSLAM genom att kapsla in dem enligt RFC 2364 (PPPoA), och konverterar på så sätt PPPoE till PPPoA.

**DSL Internetaccess arkitektur**
PC eller Gateway		DSL-modem		DSLAM		Fjärråtkomstserver		(ISP)
( IP )								(IP)
Ethernet	PPP					PPP	PPP	PPP
	PPPoE	PPPoE	PPPoA			PPPoA	L2TP	L2TP
	Ethernet	Ethernet	AAL5	AAL5	ryggrad	ryggrad	IP	IP
			bankomat	bankomat
			DSL	DSL

På diagrammet kan området som visas som "ryggrad" också vara ATM på äldre nätverk, men dess arkitektur är tjänsteleverantörberoende. På ett mer detaljerat, mer tjänsteleverantörsspecifikt diagram skulle det finnas ytterligare tabellceller i detta område.

Egendomar

Eftersom den etablerade punkt-till-punkt-anslutningen har en MTU lägre än den för standard Ethernet (vanligtvis 1492 vs Ethernets 1500), kan det ibland orsaka problem när Path MTU Discovery besegras av dåligt konfigurerade brandväggar . Även om högre MTU:er blir vanligare i leverantörernas nätverk, är lösningen vanligtvis att använda TCP MSS (Maximum Segment Size) "clamping" eller "rewrite", varvid åtkomstkoncentratorn skriver om MSS för att säkerställa att TCP-peers skickar mindre datagram. Även om TCP MSS-klämning löser MTU-problemet för TCP, kan andra protokoll som ICMP och UDP fortfarande påverkas.

RFC 4638 tillåter PPPoE-enheter att förhandla fram en MTU som är större än 1492 om det underliggande Ethernet-lagret är kapabelt till jumboramar .

Vissa leverantörer ( Cisco och Juniper , ^{[ citat behövs ]} till exempel) skiljer PPPoE[oA] från PPPoEoE (PPPoE över Ethernet), vilket är PPPoE som körs direkt över Ethernet eller andra IEEE 802 -nätverk eller över Ethernet bryggt över ATM , för att särskilja det från PPPoEoA (PPPoE över ATM), vilket är PPPoE som körs över en virtuell ATM-krets som använder RFC 2684 och SNAP -inkapsling av PPPoE. ^{[ citat behövs ]} (PPPoEoA är inte samma sak som Point-to-Point Protocol over ATM (PPPoA), som inte använder SNAP).

Enligt ett Cisco-dokument är PPPoEoE en variant av PPPoE där Layer 2-transportprotokollet nu är Ethernet eller 802.1q VLAN istället för ATM. Denna inkapslingsmetod finns i allmänhet i Metro Ethernet eller Ethernet digital subscriber line access multiplexer (DSLAM) miljöer. Den vanliga implementeringsmodellen är att denna inkapslingsmetod vanligtvis finns i byggnader med flera hyresgäster eller hotell. Genom att leverera Ethernet till abonnenten blir den tillgängliga bandbredden mycket rikligare och enklare att leverera ytterligare tjänster."

Det är möjligt att hitta DSL-modem, som till exempel Draytek Vigor 120, där PPPoE är begränsad till Ethernet-länken mellan ett DSL-modem och en partnerrouter, och ISP:n inte talar PPPoE alls (utan snarare PPPoA ) .

Post-DSL-användningar och några alternativ i dessa sammanhang

En viss metod för att använda PPPoE i samband med GPON (vilket innebär att skapa ett VLAN via OMCI) har patenterats av ZTE .

PPPoE över GPON används enligt uppgift av detaljhandelstjänsteleverantörer som Internode of Australias National Broadband Network , Orange of France, Filippinernas Globe Telecom och Italiens Aruba FTTH på OpenFiber offentliga GPON-nätverk.

RFC 6934, "Applicability of Access Node Control Mechanism to PON-based Broadband Networks", som argumenterar för användningen av Access Node Control Protocol i PON:er för – bland annat – autentisering av abonnentåtkomst och hantering av deras IP-adresser, och den första författaren till vilken är en Verizon-anställd, utesluter PPPoE som en acceptabel inkapsling för GPON: "Protokollinkapslingen på BPON är baserad på multiprotokollinkapsling över ATM Adaptation Layer 5 (AAL5), definierad i [RFC2684]. Detta omfattar PPP över Ethernet (PPPoE, definieras i [RFC2516]) eller IP over Ethernet (IPoE). Protokollinkapslingen på GPON är alltid IPoE."

Standarden 10G-PON (XG-PON) ( G.987 ) tillhandahåller 802.1X ömsesidig autentisering av ONU och OLT, förutom OMCI-metoden som överförts från G.984 . G.987 lägger också till stöd för autentisering av annan utrustning i kundlokaler utöver ONU (t.ex. i en MDU), även om detta är begränsat till Ethernet-portar, som också hanteras via 802.1X. (ONU:n antas snoopa EAP -inkapslade RADIUS- meddelanden i det här scenariot och avgöra om autentiseringen lyckades eller inte.) Det finns visst lite stöd för PPPoE specificerat i OMCI-standarderna, men bara när det gäller att ONU:n kan filtrera och lägga till VLAN-taggar för trafik baserat på dess inkapsling (och andra parametrar), vilket inkluderar PPPoE bland de protokoll som ONU måste kunna urskilja.

Bredbandsforumets TR-200 "Using EPON in the Context of TR-101" (2011), som också hänför sig till 10G-EPON , säger " OLT och multipelabonnenten ONU MÅSTE kunna utföra PPPoE Intermediate Agent funktion, som specificeras i avsnitt 3.9.2/TR-101."

En bok om Ethernet i den första milen noterar att DHCP uppenbarligen kan användas istället för PPPoE för att konfigurera en värd för en IP-session, även om den påpekar att DHCP inte är en fullständig ersättning för PPPoE om viss inkapsling också önskas (även om VLAN-bryggor kan fylla denna funktion) och att DHCP dessutom inte tillhandahåller (abonnent)autentisering, vilket tyder på att IEEE 802.1X också behövs för en "komplett lösning" utan PPPoE. (Den här boken förutsätter att PPPoE utnyttjas för andra funktioner i PPP förutom inkapsling, inklusive IPCP för värdkonfiguration och PAP eller CHAP för autentisering.)

Det finns säkerhetsskäl att använda PPPoE i en (icke-DSL/ATM) delad-mediummiljö, såsom kraftledningskommunikationsnätverk, för att skapa separata tunnlar för varje kund.

PPPoE används ofta på WAN-linjer, inklusive FTTx . Många FTTx bostadsgateways som tillhandahålls av ISP har integrerat routingfunktionerna.

Se även

externa länkar

RFC 2516 - En metod för att överföra PPP över Ethernet (PPPoE)
RFC 3817 - Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
RFC 4638 - Accommoding a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) som är större än 1492 i Point-to-Point Protocol over Ethernet (PPPoE)
RFC 4938 - PPP Over Ethernet (PPPoE)-tillägg för kreditflödes- och länkmått
US Patent 6891825 - Metod och system för att tillhandahålla åtkomst för flera användare till ett paketförmedlat nätverk
TR-043 - Protokoll vid U-gränssnittet för åtkomst till datanätverk med ATM/DSL, utgåva 1.0, augusti 2001