Punkt-til-punkt-protokoll over Ethernet- Point-to-Point Protocol over Ethernet

PPPoE og TCP/IP protokollstabel

applikasjon	FTP	SMTP	HTTP	...	DNS	...
Transportere	TCP				UDP
Internett	IP			IPv6
Nettverkstilgang	OPS
	PPPoE
	Ethernet

Den Point-to-Point Protocol over Ethernet ( PPPoE ) er en nettverksprotokoll for innkapsling av Point-to-Point Protocol (PPP) rammer inne Ethernet rammer. Det dukket opp i 1999, i forbindelse med bommen av DSL som løsning for tunnel pakker over DSL-tilkobling til ISP 's IP -nettverk, og derfra til resten av Internett . En nettverksbok fra 2005 bemerket at "De fleste DSL -leverandører bruker PPPoE, som gir autentisering , kryptering og komprimering ." Typisk bruk av PPPoE innebærer å utnytte PPP -fasilitetene for å autentisere brukeren med et brukernavn og passord, hovedsakelig via PAP -protokollen og sjeldnere via CHAP .

På utstyret i kunden kan PPPoE implementeres enten i en enhetlig gateway- enhet som håndterer både DSL- modem og IP-rutingfunksjoner , eller i tilfelle et enkelt DSL-modem (uten routingsstøtte), kan PPPoE håndteres bak det på en separat Ethernet-ruter eller til og med direkte på en brukers datamaskin. (Støtte for PPPoE finnes i de fleste operativsystemer, alt fra Windows XP , Linux til Mac OS X. ) Nylig bruker noen GPON -baserte (i stedet for DSL -baserte) boliggateways også PPPoE, selv om statusen til PPPoE i GPON -standarder er marginale.

PPPoE ble utviklet av UUNET , Redback Networks (nå Ericsson) og RouterWare (nå Wind River Systems ) og er tilgjengelig som informasjons -RFC 2516.

I verden av DSL ble PPPoE vanligvis forstått å kjøre på toppen av minibank (eller DSL) som den underliggende transporten, selv om det ikke finnes noen slik begrensning i selve PPPoE -protokollen. Andre bruksscenarier kjennetegnes noen ganger ved å sette en annen underliggende transport som et suffiks. For eksempel PPPoEoE, når transporten er Ethernet selv, som i tilfellet med Metro Ethernet -nettverk. (I denne notasjonen vil den opprinnelige bruken av PPPoE bli merket PPPoEoA, selv om den ikke skal forveksles med PPPoA , som er en annen innkapslingsprotokoll.)

PPPoE har blitt beskrevet i noen bøker som en " lag 2.5 " -protokoll, i noen rudimentær forstand som ligner på MPLS fordi den kan brukes til å skille mellom forskjellige IP -strømmer som deler en Ethernet -infrastruktur, selv om mangelen på PPPoE -svitsjer som tar rutingbeslutninger basert på PPPoE -overskrifter begrenser anvendeligheten i den forbindelse.

Opprinnelig begrunnelse

På slutten av 1998 hadde DSL -tjenestemodellen ennå ikke nådd den store skalaen som ville bringe prisene ned til husholdningsnivået. ADSL -teknologi hadde blitt foreslått et tiår tidligere. Potensielle utstyrsleverandører og transportører anerkjente at bredbånd som kabelmodem eller DSL til slutt ville erstatte oppringningstjeneste , men maskinvaren (både kundelokaler og LEC ) sto overfor en betydelig kostnadsbarriere med lav mengde . Innledende estimater for distribusjon av DSL med lav mengde viste kostnader i området $ 300– $ 500 for et DSL-modem og $ 300/måned tilgangsgebyr fra telekommunikasjonen, som var langt utover hva en hjemmebruker ville betale. Dermed var det første fokuset på små og hjemmekontorskunder som en ~ 1,5 megabit T1 -linje (på den tiden $ 800– $ 1500 per måned) ikke var økonomisk, men som trengte mer enn oppringning eller ISDN kunne levere. Hvis nok av disse kundene banet vei, ville mengder føre prisene ned til der oppringningsbrukeren til hjemmebruk kan være interessert.

Ulike bruksprofiler

Problemet var at små bedriftskunder hadde en annen bruksprofil enn en oppringningsbruker til hjemmebruk, inkludert:

• Koble et helt LAN til Internett;
• Tilby tjenester på et lokalt LAN tilgjengelig fra den andre siden av tilkoblingen;
• Samtidig tilgang til flere eksterne datakilder, for eksempel en virksomhets VPN og en generell Internett -leverandør;
• Kontinuerlig bruk hele arbeidsdagen, eller til og med døgnet rundt.

Disse kravene egner seg ikke til etterslepet i forbindelse med opprettelsen av tilkoblingen i en oppringingsprosess eller en datamaskin-til-en-ISP-modell, eller til og med den mange-til-en som NAT pluss oppringning ga. En ny modell var nødvendig.

PPPoE brukes hovedsakelig enten:

• med PPPoE-talende Internett- DSL- tjenester der et PPPoE-talende modem - ruter ( boliggateway ) kobles til DSL-tjenesten. Her må både ISP og modem-ruter snakke PPPoE. (Vær oppmerksom på at i dette tilfellet blir PPPoE-over-DSL-siden av ting tidvis referert til som PPPoEoA , for 'PPPoE over ATM '.)
• eller når et PPPoE-talende DSL-modem er koblet til en PPPoE-talende Ethernet-bare ruter med en Ethernet-kabel.

Tid til markedet: enklere er bedre

Et problem med å lage en helt ny protokoll for å dekke disse behovene var tid. Utstyret var tilgjengelig umiddelbart, i likhet med tjenesten, og en helt ny protokollbunke ( Microsoft på det tidspunktet tok til orde for fiberbaserte minibanker-til-skrivebordet, og L2TP brygges også, men var ikke i nærheten av ferdigstillelse) ville ta så lang tid å implementere at mulighetsvinduet kan skli forbi. Flere beslutninger ble tatt for å forenkle implementering og standardisering i et forsøk på å levere en komplett løsning raskt.

Gjenbruk eksisterende programvarestabler

PPPoE håpet å slå sammen den utbredte Ethernet -infrastrukturen med den allestedsnærværende PPP, slik at leverandører kan gjenbruke eksisterende programvare og levere produkter på kort sikt. I hovedsak hadde alle operativsystemer den gangen en PPP-stabel, og utformingen av PPPoE tillot en enkel mellomlegg på linjekodingsstadiet for å konvertere fra PPP til PPPoE.

Forenkle maskinvarekravene

Konkurrerende WAN -teknologier (T1, ISDN) krevde en ruter i kundens lokaler. PPPoE brukte en annen Ethernet -rammetype, som gjorde det mulig for DSL -maskinvaren å fungere som en bro , som passerte noen rammer til WAN og ignorerte de andre. Implementering av en slik bro er flere størrelsesordener enklere enn en ruter.

Informasjons -RFC

RFC 2516 ble opprinnelig utgitt som en informativ (i stedet for standardspor ) RFC av samme grunn: adopsjonstiden for en standardspor-RFC var uoverkommelig lang.

Suksess

PPPoE ble opprinnelig designet for å gi et lite LAN med individuelle uavhengige tilkoblinger til Internett generelt, men også slik at selve protokollen ville være lett nok til at den ikke ville påvirke markedet for hjemmebruk når den endelig kom. Selv om suksess i den andre saken kan diskuteres (noen klager over at 8 byte per pakke er for mye), lyktes PPPoE klart å bringe tilstrekkelig volum til å få prisen for tjenesten ned til hva en hjemmebruker ville betale.

Stadier

PPPoE har to forskjellige stadier:

PPPoE -oppdagelse

Siden tradisjonelle PPP-tilkoblinger etableres mellom to endepunkter over en seriell kobling eller over en virtuell minibank som allerede er etablert under oppringning, kommer alle PPP-rammer som sendes på ledningen til å nå den andre enden. Men Ethernet-nettverk er multi-access hvor hver node i nettverket kan få tilgang til hver annen node. En Ethernet -ramme inneholder maskinvareadressen til destinasjonsnoden ( MAC -adressen ). Dette hjelper rammen med å nå den tiltenkte destinasjonen.

Derfor, før du utveksler PPP -kontrollpakker for å etablere tilkoblingen over Ethernet, bør MAC -adressene til de to endepunktene være kjent for hverandre, slik at de kan bli kodet i disse kontrollpakkene. PPPoE Discovery -scenen gjør akkurat dette. Det hjelper også med å etablere en sesjons -ID som kan brukes til videre utveksling av pakker.

PPP -økt

Når MAC -adressen til kollegaen er kjent og en økt er etablert, starter sesjonsfasen.

PPPoE discovery (PPPoED)

Selv om tradisjonell PPP er en node-til-node- protokoll, er PPPoE iboende et klient-server- forhold siden flere verter kan koble seg til en tjenesteleverandør via en enkelt fysisk tilkobling.

Oppdagelsesprosessen består av fire trinn mellom vertsmaskinen som fungerer som klienten og tilgangskonsentratoren ved Internett -leverandørens ende fungerer som serveren. De er skissert nedenfor. Det femte og siste trinnet er måten å lukke en eksisterende økt på.

Klient til server: initiering (PADI)

PADI står for PPPoE Active Discovery Initiation.

Hvis en bruker ønsker å "slå opp" til Internett ved hjelp av DSL, deretter datamaskinen først må finne DSL-tilgang konsentrator (DSL-AC) på brukerens internettleverandør er poenget med tilstedeværelse (POP). Kommunikasjon over Ethernet er bare mulig via MAC -adresser . Siden datamaskinen ikke kjenner MAC-adressen til DSL-AC, sender den ut en PADI-pakke via en Ethernet- kringkasting (MAC: ff: ff: ff: ff: ff: ff). Denne PADI -pakken inneholder MAC -adressen til datamaskinen som sender den.

Eksempel på en PADI-pakke:

Frame 1 (44 bytes on wire, 44 bytes captured)
Ethernet II, Src: 00:50:da:42:d7:df, Dst: ff:ff:ff:ff:ff:ff
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Initiation (PADI)
  Session ID: 0000
  Payload Length: 24
PPPoE Tags
  Tag: Service-Name
  Tag: Host-Uniq
    Binary Data: (16 bytes)

Src. (= kilde) inneholder MAC -adressen til datamaskinen som sender PADI.
Dst. (= destinasjon) er Ethernet -kringkastingsadressen.
PADI-pakken kan mottas av mer enn én DSL-AC. Bare DSL-AC-utstyr som kan betjene "Service-Name" -taggen, bør svare.

Server til klient: tilbud (PADO)

PADO står for PPPoE Active Discovery Offer.

Når brukerens datamaskin har sendt PADI-pakken, svarer DSL-AC med en PADO-pakke, ved hjelp av MAC-adressen som er levert i PADI. PADO-pakken inneholder MAC-adressen til DSL-AC, navnet (f.eks. LEIX11-erx for T-Com DSL-AC i Leipzig ) og navnet på tjenesten. Hvis mer enn én POPs DSL-AC svarer med en PADO-pakke, velger brukerens datamaskin DSL-AC for en bestemt POP ved å bruke det angitte navnet eller tjenesten.

Her er et eksempel på en PADO -pakke:

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:40:7b:f3:8a, Dst: 00:50:da:42:d7:df
PPP-over-Ethernet Discovery
  Version: 1
  Type 1
  Code Active Discovery Offer (PADO)
  Session ID: 0000
  Payload Length: 36
PPPoE Tags
  Tag: AC-Name
    String Data: IpzbrOOl
  Tag: Host-Uniq
    Binary Data: (16 bytes)

AC- navn-> Strengdata inneholder AC-navnet, i dette tilfellet “Ipzbr001” (Arcor DSL-AC i Leipzig)
Src. innehar MAC-adressen til DSL-AC.
MAC-adressen til DSL-AC avslører også produsenten av DSL-AC (i dette tilfellet Nortel Networks ).

Klient til server: forespørsel (PADR)

PADR står for PPPoE aktiv oppdagelsesforespørsel.

En PADR-pakke sendes av brukerens datamaskin til DSL-AC etter mottak av en akseptabel PADO-pakke fra DSL-AC. Den bekrefter tilbudet om en PPPoE-tilkobling fra DSL-AC som utsteder PADO-pakken.

Server til klient: sesjonsbekreftelse (PADS)

PADS står for PPPoE Active Discovery Session-bekreftelse.

PADR-pakken ovenfor blir bekreftet av DSL-AC med en PADS-pakke, og en sesjons-ID blir gitt ut med den. Forbindelsen med DSL-AC for den POP-en er nå fullstendig etablert.

Enten ende til annen ende: avslutning (PADT)

PADT står for PPPoE Active Discovery Termination. Denne pakken avslutter forbindelsen til POP. Den kan sendes enten fra brukerens datamaskin eller fra DSL-AC.

Overordnet protokoll

PPPoE brukes til å koble en PC eller en ruter til et modem via en Ethernet -kobling, og den kan også brukes i Internett -tilgang over DSL på en telefonlinje i PPPoE over ATM (PPPoEoA) over ADSL -protokollstabel . PPPoE over ATM har den høyeste overheaden til de populære DSL -leveringsmetodene, sammenlignet med for eksempel PPPoA (RFC 2364).

Bruk med DSL - PPPoE over ATM (PPPoEoA)

Mengden overhead som er lagt til av PPPoEoA på en DSL-lenke, avhenger av pakkestørrelsen på grunn av (i) den absorberende effekten av ATM-cellepolstring (omtalt nedenfor), noe som helt avbryter ytterligere overhead av PPPoEoA i noen tilfeller, (ii) PPPoEoA + AAL5 overhead som kan føre til at en ekstra 53-byte ATM-celle kreves, og (iii) når det gjelder IP-pakker, kan PPPoE-overhead lagt til pakker som er nær maksimal lengde ( ' MRU ' ) forårsake IP-fragmentering , noe som innebærer også de to første vurderingene for begge de resulterende IP -fragmentene. Imidlertid ignorerer vi ATM- og IP -fragmentering for øyeblikket, kan overskriften til protokolloverskriften for ATM -nyttelast på grunn av valg av PPP + PPPoEoA være så høy som 44 byte = 2 byte (for PPP) + 6 (for PPPoE) + 18 (Ethernet MAC, variabel ) + 10 (RFC 2684 LLC, variabel) + 8 (AAL5 CPCS). Denne overhead er den som oppnås ved bruk av LLC -topptekstalternativet beskrevet i RFC 2684 for PPPoEoA.

Sammenlign dette med en langt mer header-effektiv protokoll, PPP + PPPoA RFC 2364 VC-MUX over ATM + DSL, som bare har 10 byte overhead i minibankens nyttelast. (Faktisk bare 10 byte = 2 byte for PPP + null for RFC 2364 + 8 (AAL5 CPCS).)

Dette tallet på 44 bytes AAL5 nyttelastoverhead kan reduseres på to måter: (i) ved å velge alternativet RFC 2684 for å kaste 4-byte Ethernet MAC FCS, noe som reduserer tallet på 18 byte over til 14, og (ii) med ved hjelp av RFC 2684 VC-MUX-alternativet, hvis overheadbidrag bare er 2 byte sammenlignet med 10 byte overhead for LLC-alternativet. Det viser seg at denne overheadreduksjonen kan være en verdifull effektivitetsforbedring. Ved bruk av VC-MUX i stedet for LLC er ATMs nyttelast overhead enten 32 byte (uten Ethernet FCS) eller 36 byte (med FCS).

ATM AAL5 krever at en 8-byte lang "CPCS" -henger alltid må være tilstede helt i enden av den siste cellen ("riktig begrunnet") i kjøringen av ATM-celler som utgjør AAL5 nyttelastpakken. I LLC -tilfellet er den totale ATM -nyttelasten 2 + 6 + 18 + 10 + 8 = 44 byte hvis Ethernet MAC FCS er tilstede, eller 2 + 6 + 14 + 10 + 8 = 40 byte uten FCS. I det mer effektive VC-MUX-tilfellet er minibankens nyttelast 2 + 6 + 18 + 2 + 8 = 36 byte (med FCS), eller 2 + 6 + 14 + 2 + 8 = 32 byte (ingen FCS).

Imidlertid er den sanne overhead når det gjelder den totale mengden av ATM -nyttelastdata som sendes, ikke bare en fast tilleggsverdi - den kan bare være enten null eller 48 byte (bortsett fra scenario (iii) nevnt tidligere, IP -fragmentering). Dette er fordi ATM -celler har en fast lengde med en nyttelastkapasitet på 48 byte, og å legge til en større ekstra mengde AAL5 nyttelast på grunn av flere overskrifter kan kreve at en hel minibank til sendes med overskuddet. De siste en eller to minibankene inneholder polstringsbyte etter behov for å sikre at hver celles nyttelast er 48 byte lang.

Et eksempel: I tilfelle av en 1500-byte IP-pakke sendt over AAL5/ATM med PPPoEoA og RFC2684-LLC, og forsømmelse av siste cellepolstring for øyeblikket, starter man med 1500 + 2 + 6 + 18 + 10 + 8 (AAL5 CPCS trailer) = 1544 byte hvis ethernet FCS er tilstede, ellers + 2 + 6 + 14 + 10 + 8 = 40 byte uten FCS. For å sende 1544 byte over minibank krever 33 48-byte minibanker, siden tilgjengelig nyttelastkapasitet på 32 celler × 48 byte per celle = 1536 byte ikke er nok. Sammenlign dette med PPP + PPPoA som på 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (CPCS trailer) = 1510 byte passer i 32 celler. Så den virkelige kostnaden ved å velge PPPoEoA pluss RFC2684-LLC for 1500-byte IP-pakker er en ekstra minibank per IP-pakke, et forhold på 33:32. Så for 1500 bytepakker er PPPoEoA med LLC ~ 3.125% tregere enn PPPoA eller optimale valg av PPPoEoA -overskriftsalternativer.

For noen pakkelengder vil den sanne ekstra effektive DSL -overhead på grunn av valg av PPPoEoA sammenlignet med PPPoA være null hvis den ekstra toppteksten ikke er nok til å trenge en ekstra minibank ved den aktuelle pakkelengden. For eksempel gir en 1492 byte lang pakke sendt med PPP + PPPoEoA ved bruk av RFC2684-LLC pluss FCS oss en total ATM nyttelast på 1492 + 44 = 1536 byte = 32 celler nøyaktig, og overhead i dette spesielle tilfellet er ikke større enn hvis vi brukte den toppeffektive PPPoA-protokollen, som også ville kreve 1492 + 2 + 0 + 8 = 1502 bytes ATM nyttelast = 32 celler. Saken der pakkelengden er 1492 representerer den optimale effektiviteten for PPPoEoA med RFC2684-LLC i forhold, med mindre enda lengre pakker er tillatt.

Å bruke PPPoEoA med RFC2684 VC-MUX header-alternativet er alltid mye mer effektivt enn LLC-alternativet, siden ATM-overhead, som nevnt tidligere, bare er 32 eller 36 byte (avhengig av om dette er uten eller med ethernet FCS-alternativet i PPPoEoA ) slik at en 1500 byte lang pakke inkludert alle overheader av PPP + PPPoEoA ved bruk av VC-MUX tilsvarer totalt 1500 + 36 = 1536 bytes ATM nyttelast hvis FCS er til stede = 32 ATM-celler nøyaktig, og sparer dermed en hel ATM-celle.

Med korte pakker, jo lengre overskriften er, desto større er sannsynligheten for å generere en ekstra minibank. I verste fall kan det være at du sender 3 minibanker i stedet for to på grunn av en overhead på 44 byte sammenlignet med en overhead på 10 byte, så det tar 50% mer tid å overføre dataene. For eksempel er en TCP ACK -pakke over IPv6 60 byte lang, og med overhead på 40 eller 44 byte for PPPoEoA + LLC krever dette tre 48 byte ATM -cellers nyttelast. Som en sammenligning, PPPoA med overhead på 10 byte, så totalt 70 byte passer inn i to celler. Så ekstrakostnaden ved å velge PPPoE/LLC fremfor PPPoA er 50% ekstra data sendt. PPPoEoA + VC-MUX ville imidlertid være bra: med 32 eller 36 byte overhead, passer vår IP-pakke fortsatt i to celler.

I alle tilfeller er det mest effektive alternativet for ATM-basert ADSL internettilgang å velge PPPoA (RFC2364) VC-MUX. Men hvis PPPoEoA er påkrevd, er det beste valget alltid å bruke VC-MUX (i motsetning til LLC) uten Ethernet FCS, noe som gir en ATM-nyttelast på 32 byte = 2 byte (for PPP) + 6 (for PPPoE) + 14 (Ethernet MAC, ingen FCS) + 2 (RFC 2684 VC-MUX) + 8 (AAL5 CPCS trailer).

Dessverre krever noen DSL-tjenester bruk av sløsing med LLC-overskrifter med PPPoE og tillater ikke det mer effektive VC-MUX-alternativet. I så fall gjenoppretter bruk av en redusert pakkelengde, for eksempel å håndheve en maksimal MTU på 1492, effektivitet med lange pakker, selv med LLC -overskrifter, og som nevnt tidligere genereres ingen ekstra sløsing med minibanker.

Overhead på Ethernet

På et Ethernet LAN er overhead for PPP + PPPoE en fast 2 + 6 = 8 byte , med mindre IP -fragmentering produseres.

MTU/MRU

Når et PPPoE-talende DSL-modem sender eller mottar Ethernet-rammer som inneholder PPP + PPPoE nyttelast over Ethernet-lenken til en ruter (eller PPPoE-talende enkelt PC), bidrar PPP + PPPoE med en ekstra overhead på 8 byte = 2 (PPP) + 6 (PPPoE) inkludert i nyttelasten til hver Ethernet -ramme. Denne ekstra overhead kan bety at en redusert maksimal lengdegrense (såkalt ' MTU ' eller ' MRU ' ) på 1500-8 = 1492 byte pålegges (for eksempel) IP-pakker sendt eller mottatt, i motsetning til de vanlige 1500- byte Ethernet -ramme nyttelastlengdegrense som gjelder for standard Ethernet -nettverk. Noen enheter støtter RFC 4638, som tillater forhandlinger om bruk av ikke-standardiserte Ethernet-rammer med en 1508-byte Ethernet-nyttelast, noen ganger kalt 'baby jumbo-rammer ', slik at en full PPPoE-nyttelast på 1500 byte tillates. Denne muligheten er fordelaktig for mange brukere i tilfeller der selskaper som mottar IP -pakker (feil) har valgt å blokkere alle ICMP -svar fra å gå ut av nettverket, en dårlig praksis som forhindrer at MTU -oppdagelse fungerer korrekt og som kan forårsake problemer for brukere som får tilgang til slike nettverk. hvis de har en MTU på mindre enn 1500 byte.

PPPoE-til-PPPoA-konverteringsmodem

Følgende diagram viser et scenario der et modem fungerer som en PPPoE-til- PPPoA- protokollomformer og tjenesteleverandøren tilbyr en PPPoA-tjeneste og ikke forstår PPPoE. Det er ingen PPPoEoA i denne protokollkjeden. Dette er en optimalt effektiv design for et eget modem som er koblet til en ruter via ethernet.

I denne alternative teknologien er PPPoE bare et middel for å koble DSL-modemer til en Ethernet-ruter (igjen, eller til en enkelt vert-PC). Her er det ikke opptatt av mekanismen som brukes av en ISP for å tilby bredbåndstjenester.

Modemene Draytek Vigor 110, 120 og 130 fungerer på denne måten.

Når du sender pakker som er koblet til Internett, sender den PPPoE-talende Ethernet-ruteren Ethernet-rammer til det (også PPPoE-talende) DSL-modemet. Modemet trekker ut PPP -rammer fra de mottatte PPPoE -rammene, og sender PPP -rammene videre til DSLAM ved å kapsle dem i henhold til RFC 2364 (PPPoA), og konvertere dermed PPPoE til PPPoA.

DSL Internett -tilgangsarkitektur

PC eller Gateway		DSL -modem		DSLAM		Server for ekstern tilgang		(ISP)
( IP )								(IP)
Ethernet	OPS					OPS	OPS	OPS
	PPPoE	PPPoE	PPPoA			PPPoA	ryggrad	ryggrad
	Ethernet	Ethernet	AAL5	AAL5	ryggrad	ryggrad	IP	IP
			Minibank	Minibank
			DSL	DSL

På diagrammet kan området vist som 'ryggrad' også være minibank på eldre nettverk, men arkitekturen er avhengig av tjenesteleverandør. På et mer detaljert, mer tjenesteleverandørspesifikt diagram vil det være flere tabellceller i dette området.

Quirks

Siden den etablerte punkt-til-punkt-tilkoblingen har en MTU lavere enn standard Ethernet (vanligvis 1492 vs Ethernet 1500), kan det noen ganger forårsake problemer når Path MTU Discovery blir beseiret av dårlig konfigurerte brannmurer . Selv om høyere MTU -er blir mer vanlig i tilbyders nettverk, er løsningen vanligvis å bruke TCP MSS (Maximum Segment Size) "klemming" eller "omskriving", hvorved tilgangskonsentratoren omskriver MSS for å sikre at TCP -jevnaldrende sender mindre datagrammer. Selv om TCP MSS -klemming løser MTU -problemet for TCP, kan andre protokoller som ICMP og UDP fortsatt påvirkes.

RFC 4638 lar PPPoE -enheter forhandle om en MTU på større enn 1492 hvis det underliggende Ethernet -laget er i stand til å samle rammer .

Noen leverandører ( Cisco og Juniper , for eksempel) skiller PPPoE [oA] fra PPPoEoE (PPPoE over Ethernet), som er PPPoE som kjører direkte over Ethernet eller andre IEEE 802 -nettverk eller over Ethernet broet over ATM , for å skille det fra PPPoEoA ( PPPoE over ATM), som er PPPoE som kjører over en virtuell minibank med RFC 2684 og SNAP -innkapsling av PPPoE. (PPPoEoA er ikke det samme som Point-to-Point Protocol over ATM (PPPoA), som ikke bruker SNAP).

I følge et Cisco -dokument er "PPPoEoE en variant av PPPoE der Layer 2 transportprotokollen nå er Ethernet eller 802.1q VLAN i stedet for ATM. Denne innkapslingsmetoden finnes vanligvis i Metro Ethernet eller Ethernet digitale abonnentlinjetilgangsmultiplexer (DSLAM) miljøer. Den vanlige distribusjonsmodellen er at denne innkapslingsmetoden vanligvis finnes i bygninger eller hoteller på flere leietakere. Ved å levere Ethernet til abonnenten er den tilgjengelige båndbredden mye mer rik og det er lettere å ytterligere levere tjenester. "

Det er mulig å finne DSL -modemer, for eksempel Draytek Vigor 120, hvor PPPoE er begrenset til Ethernet -koblingen mellom et DSL -modem og en partneringrouter, og Internett -leverandøren snakker ikke PPPoE i det hele tatt (men heller PPPoA ).

Post-DSL bruk og noen alternativer i disse sammenhengene

En bestemt metode for bruk av PPPoE i forbindelse med GPON (som innebærer å lage et VLAN via OMCI ) har blitt patentert av ZTE .

PPPoE over GPON brukes angivelig av detaljhandelstjenesteleverandører som Internode i Australias nasjonale bredbåndsnettverk , Rumensias RCS & RDS (for deres "Fiberlink" -kunder - GPON selges som Ethernet -porter i MDU -er ), Orange France, Philippines ' Globe Telecom og Sør -Afrikas Openserve .

RFC 6934, "Applicability of Access Node Control Mechanism to PON based Broadband Networks", som argumenterer for bruk av Access Node Control Protocol i PON for blant annet å autentisere abonnentadgang og administrere IP -adressene deres, og den første forfatteren av er en Verizon-ansatt, utelukker PPPoE som en akseptabel innkapsling for GPON: "Protocol encapsulation on BPON is based on multi-protocol encapsulation over ATM Adaptation Layer 5 (AAL5), defined in [RFC2684]. Dette dekker PPP over Ethernet (PPPoE, definert i [RFC2516]) eller IP over Ethernet (IPoE). Protokollinnkapslingen på GPON er alltid IPoE. "

Den 10G-PON (XG-PON) standard ( G.987 ) sørger for 802.1X gjensidig autentisering av ONU og OLT, foruten OMCI metoden båret frem fra G.984 . G.987 legger også til støtte for autentisering av annet kunde-lokalt utstyr utover ONU (f.eks. I en MDU), selv om dette er begrenset til Ethernet-porter, også håndtert via 802.1X. (ONU antas å snuse EAP -innkapslede RADIUS -meldinger i dette scenariet og avgjøre om autentiseringen var vellykket eller ikke.) Det er noe modicum -støtte for PPPoE spesifisert i OMCI -standardene, men bare når det gjelder at ONU kan filtrere og legge til VLAN -koder for trafikk basert på innkapslingen (og andre parametere), som inkluderer PPPoE blant protokollene som ONU må kunne skille.

The Broadband Forum 's TR-200 "Bruke EPON i sammenheng med TR-101" (2011), som også gjelder 10G-EPON , sier "OLT og fler abonnent ONU må være i stand til å utføre PPPoE Intermediate Agent funksjon, som spesifisert i avsnitt 3.9.2/TR-101. "

En bok om Ethernet i den første milen bemerker at DHCP åpenbart kan brukes i stedet for PPPoE for å konfigurere en vert for en IP -økt, selv om den påpeker at DHCP ikke er en komplett erstatning for PPPoE hvis noen innkapsling også er ønsket (selv om VLAN -broer kan oppfylle denne funksjonen) og at DHCP dessuten ikke gir (abonnent) autentisering, noe som tyder på at IEEE 802.1X også er nødvendig for en "komplett løsning" uten PPPoE. (Denne boken antar at PPPoE er utnyttet for andre funksjoner i PPP i tillegg til innkapsling, inkludert IPCP for vertskonfigurasjon, og PAP eller CHAP for autentisering.)

Det er sikkerhetsgrunner for å bruke PPPoE i et (ikke-DSL/ATM) miljø med delt medium, for eksempel kommunikasjonsnett for kraftlinjer , for å lage separate tunneler for hver kunde.

PPPoE er mye brukt på WAN -linjer, inkludert FTTx . Mange FTTx boliggateway levert av ISP har integrert rutingfunksjonene.

Se også

• Innkapsling med flere protokoller over minibank
• Point-to-Point Protocol-demon
• Point-to-Point Tunneling Protocol
• Point-to-Point Protocol over ATM (PPPoA)
• Point-to-Point Protocol over X (PPPoX)

Referanser

Eksterne linker

• RFC  2516 - En metode for overføring av PPP over Ethernet (PPPoE)
• RFC  3817 - Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)
• RFC  4638 -Plass til en maksimal transittenhet/maksimal mottaksenhet (MTU/MRU) større enn 1492 i punkt-til-punkt-protokollen over Ethernet (PPPoE)
• RFC  4938 - PPP Over Ethernet (PPPoE) -utvidelser for kredittflyt og lenketall
• US Patent 6891825 - Metode og system for å gi tilgang til flere brukere til et pakkeskiftet nettverk
• TR -043 - Protokoller ved U -grensesnittet for tilgang til datanettverk ved bruk av ATM/DSL, utgave 1.0, august 2001