Dieses Dokument beschreibt eine End-to-End-ADSL-Architektur (Asymmetric Digital Subscriber Line), die Point-to-Point Protocol over Ethernet (PPPoE) verwendet.
In der aktuellen Umgebung von Access-Technologien ist es wünschenswert, mehrere Hosts an einem Remote-Standort über dasselbe Zugriffsgerät am Kundenstandort zu verbinden. Darüber hinaus müssen Zugriffskontroll- und Abrechnungsfunktionen ähnlich wie DFÜ-Services bereitgestellt werden, die das Point-to-Point Protocol (PPP) verwenden. Bei vielen Access-Technologien ist die kosteneffektivste Methode, mehrere Hosts mit dem Access-Gerät am Kundenstandort zu verbinden, über Ethernet. Darüber hinaus sollten die Kosten für dieses Gerät so gering wie möglich gehalten und die Konfigurationsanforderungen auf ein Minimum reduziert werden.
Bei der Bereitstellung von ADSL müssen Kunden Authentifizierung und Autorisierung im PPP-Stil über eine große Anzahl vorhandener CPE-Geräte (Legacy Bridging Customer Premises Equipment) unterstützen. PPPoE bietet die Möglichkeit, ein Netzwerk von Hosts über ein einfaches Bridging-Zugriffsgerät mit einem Remote-Zugriffskonzentrator oder Aggregationskonzentrator zu verbinden. Bei diesem Modell verwendet jeder Host seinen eigenen PPP-Stack. Daher wird dem Benutzer eine vertraute Benutzeroberfläche angezeigt. Sie können auf Steuerung, Rechnungsstellung und Servicetyp pro Benutzer zugreifen, nicht pro Standort.
Die Basisarchitektur setzt voraus, dass folgende Elemente bereitgestellt werden:
Hochgeschwindigkeits-Internetzugang und Unternehmenszugriff auf Endkunden, die PPPoE verwenden.
ATM als Core-Backbone-Technologie, implementiert durch den Cisco 6400 Universal Access Concentrator (UAC).
Diese Einschränkungen bei der Designimplementierung können die Nutzung dieser Architektur auf anderen Plattformen einschränken, aber PPPoE entwickelt sich ständig weiter. Lesen Sie die neuesten Versionshinweise für verwandte Produkte, um von den neuen und aktualisierten Funktionen zu profitieren.
Dieses Whitepaper basiert auf aktuellen Bereitstellungen sowie internen Tests, bei denen Cisco 6400 UAC verwendet wird. Dieses Whitepaper ist eine Fortsetzung des Dokuments PPPoA Baseline Architecture und verweist häufig darauf. Es wird davon ausgegangen, dass Sie das PPPoA-Whitepaper zur Basisarchitektur gelesen und die Grundlagen von PPP verstanden haben und dass Sie die Versionshinweise zur neuesten Softwareversion gelesen haben.
Wie in RFC 2516 angegeben, umfasst PPPoE zwei verschiedene Phasen: eine Erkennungsphase und eine PPP-Sitzungsphase. Wenn ein Host eine PPPoE-Sitzung initiiert, muss er zunächst eine Erkennung durchführen, um festzustellen, welcher Server die Anforderung des Clients erfüllen kann. Zweitens muss die Ethernet-MAC-Adresse des Peers identifiziert und eine PPPoE-Session-ID eingerichtet werden. Während PPP eine Peer-to-Peer-Beziehung definiert, ist die Erkennung von Natur aus eine Client-Server-Beziehung.
Im Erkennungsprozess erkennt ein Host (der Client) einen oder mehrere Zugriffskonzentratoren (die Server) und wählt einen aus. Wenn die Erkennung erfolgreich abgeschlossen ist, verfügen sowohl der Host als auch der ausgewählte Zugriffskonzentrator über die Informationen, um eine Punkt-zu-Punkt-Verbindung über Ethernet herzustellen. Nachdem eine PPP-Sitzung erstellt wurde, müssen sowohl der Host als auch der Zugriffskonzentrator die Ressourcen für eine virtuelle PPP-Schnittstelle zuweisen (dies ist wahrscheinlich nicht bei allen Implementierungen der Fall). Weitere Einzelheiten zur PPPoE-Spezifikation finden Sie in RFC 2516.
Die PPPoE-Architektur erbt die meisten Vorteile von PPP, die im Wählmodell und in der PPPoA-Architektur verwendet werden. In diesen Abschnitten werden einige der wichtigsten Vor- und Nachteile von PPPoE und ihre Unterschiede zu PPPoA aufgeführt.
Dies sind einige wichtige Vorteile von PPPoE und wie sie sich von PPPoA unterscheiden:
Pro Sitzung Authentifizierung basierend auf Password Authentication Protocol (PAP) oder Challenge Handshake Authentication Protocol (CHAP). Dies ist der größte Vorteil von PPPoE, wenn die Authentifizierung die Sicherheitslücke in einer Bridging-Architektur überwindet.
Pro Session Accounting ist möglich, sodass der Service Provider den Abonnenten basierend auf der Sitzungszeit für verschiedene angebotene Services berechnen kann. Der Service Provider kann auch eine minimale Zugriffsgebühr verlangen.
Sie können PPPoE für aktuelle CPE-Installationen verwenden, die nicht auf PPP aktualisiert werden können oder die nicht die Möglichkeit haben, PPPoA auszuführen, wodurch die PPP-Sitzung über das überbrückte Ethernet-LAN auf den PC ausgedehnt wird.
PPPoE behält die Point-to-Point-Sitzung bei, die von Internet Service Providers (ISPs) im aktuellen DFÜ-Modell verwendet wird. PPPoE ist das einzige Protokoll, das Point-to-Point over Ethernet ausführen kann, ohne dass ein zwischengeschalteter IP-Stack erforderlich ist.
Der Network Access Provider (NAP) oder Network Service Provider (NSP) können sicheren Zugriff auf ein unternehmenseigenes Gateway bereitstellen, ohne dass End-to-End-PVCs (Permanent Virtual Circuits) verwaltet werden müssen und keine Layer-3-Routing- und/oder Layer-2-Tunneling Protocol (L2TP)-Tunnel verwendet werden. Damit ist das Geschäftsmodell für den Verkauf von Großkundenservices und VPNs skalierbar.
PPPoE kann einen Host (PC)-Zugriff auf mehrere Ziele gleichzeitig bereitstellen. Sie können mehrere PPPoE-Sitzungen pro PVC durchführen.
Der NSP kann durch die Bereitstellung von Zeitüberschreitungen bei Inaktivität und Sitzungen mithilfe eines RADIUS-Servers (Remote Authentication Dial-In User Service) nach Industriestandard eine Überbelegung vornehmen.
Sie können PPP mit der Funktion "Service Selection Gateway" (SSG) verwenden.
Dies sind einige der wichtigsten Nachteile von PPPoE und wie sie sich von PPPoA unterscheiden:
Sie müssen PPPoE-Client-Software auf allen Hosts (PCs) installieren, die mit dem Ethernet-Segment verbunden sind. Das bedeutet, dass der Access Provider die CPE und die Client-Software auf dem PC verwalten muss.
Da die PPPoE-Implementierung RFC 1483-Bridging verwendet, ist sie anfällig für Broadcast-Stürme und mögliche Denial-of-Service-Angriffe.
Dies sind einige wichtige Punkte, die Sie vor der Implementierung dieser Architektur berücksichtigen sollten.
Die Anzahl der unterstützten Teilnehmer. Die Anzahl der erforderlichen PPPoE-Server hängt von der Anzahl der Sitzungen ab.
Legt fest, ob die PPP-Sitzungen am Aggregation Router des Service Providers beendet oder an andere Corporate Gateways oder ISPs weitergeleitet werden.
Legt fest, ob der Dienstanbieter oder das endgültige Dienstziel die IP-Adresse bereitstellt.
Bei mehr als einem Benutzer, ob alle Benutzer dasselbe Endziel oder denselben Enddienst erreichen müssen oder ob alle Benutzer unterschiedliche Serviceziele haben. Benötigen die Endabonnenten gleichzeitigen Zugriff auf mehrere Ziele?
Die PPPoE-Client-Software, die der Access Provider verwendet, und ob die Software getestet wurde, welches Betriebssystem der Host verwendet und ob das Betriebssystem eine intelligente Routing-Entscheidung treffen kann.
Legt fest, wie der Service Provider die Abonnenten pauschal, pro Sitzungsnutzung oder genutzten Services abrechnet.
Bereitstellung und Bereitstellung von CPEs, DSLAMs und Aggregation Points of Presence (POPs).
Das Geschäftsmodell für das NAP. Umfasst das Modell auch den Verkauf von Großhandelsdiensten wie sicherem Unternehmenszugang und Mehrwert-Services wie Sprach- und Videodienste? Sind NAPs und NSPs dieselbe Einheit?
Das Geschäftsmodell des Unternehmens. Ist sie mit einem unabhängigen lokalen Börsenbetreiber (ILEC), einem konkurrierenden lokalen Börsenbetreiber (CLEC) oder einem ISP vergleichbar?
Die Anwendungstypen, die der NSP dem Endkunden anbietet.
Das erwartete Upstream- und Downstream-Datenverkehrsvolumen. Berücksichtigen Sie NRP-Durchsatz, Traffic Engineering und alle QoS-Probleme.
In diesem Dokument wird erläutert, wie die PPPoE-Architektur für Service Provider auf unterschiedliche Geschäftsmodelle zugeschnitten ist und skaliert werden kann und wie die Provider mithilfe dieser Architektur davon profitieren können.
Dieser Abschnitt behandelt Probleme, die speziell für die PPPoE-Architektur gelten.
Vor der Bereitstellung einer Architektur ist es wichtig, das Geschäftsmodell des Service Providers und die vom Provider angebotenen Services zu verstehen. Sie müssen die Client-Software kennen, die auf dem PC verwendet wird. Die gängigste Software stammt von Routerware. Da die Client-Software auf einem PC installiert ist, muss der Techniker des Dienstanbieters über gute Kenntnisse dieses PCs und seines Betriebssystems verfügen.
Wie in RFC 2516 angegeben, darf die Option für die maximale Empfangseinheit (MRU) nicht mit einer Größe größer als 1492 verhandeln. Ethernet hat eine maximale Nutzlastgröße von 1.500 Oktetts. Der PPPoE-Header hat 6 Oktette und die PPP-Protokoll-ID 2 Oktette, daher darf die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) des PPP nicht größer als 1492 sein. Dies wird durch die Konfiguration der IP-MTU 1492 für virtuelle PPPoE-Vorlagenschnittstellen erreicht.
Standardmäßig ist keine virtuelle Zugriffsschnittstelle vorgeklont, wenn eine PPPoE-VPDN-Gruppe konfiguriert wird. Benutzer können die maximale Anzahl vorklonter virtueller Zugriffsschnittstellen ändern, indem Sie den globalen Befehl virtual-template <number> pre-clone <number> eingeben.
Um den Router vor Denial-of-Service-Angriffen zu schützen, ermöglicht PPPoE (standardmäßig), dass nur eine Sitzung von einer MAC-Adresse über einen VC bezogen werden kann. Benutzer können die Befehle pppoe session limit per MAC und pppoe session limit per vc ausgeben, um die Standardwerte zu ändern.
Der Abrechnungs-, Autorisierungs- und Authentifizierungsprozess entspricht dem von PPPoA. Der einzige Unterschied besteht darin, dass die derzeit für PPPoA verfügbare und für PPPoE nicht verfügbare VPI/VCI-basierte Authentifizierung die L2TP- und SSG-Architekturen für Großhandelsdienste verwenden kann.
Das CPE ist für reines RFC 1483-Bridging konfiguriert. Jedes CPE verwendet nur ein VPI/VCI-Paar, und alle PPPoE-Sitzungen, die von Hosts hinter diesem CPE initiiert werden, werden in diesem einzigen VC durchgeführt.
Die IP-Adressenzuweisung für den einzelnen Host, der den PPPoE-Client ausführt, basiert auf dem gleichen Prinzip wie die PPP-Aushandlung im Wählmodus-IPCP. Die Herkunft der IP-Adresse hängt von der Art des Dienstes ab, den der Teilnehmer erwirbt, und von der Endstelle der PPP-Sitzungen. PPPoE nutzt die DFÜ-Netzwerkfunktion von Microsoft Windows, und die zugewiesene IP-Adresse wird im PPP-Adapter wiedergegeben.
Die IP-Adressenzuweisung kann vom Zugriffskonzentrator erfolgen, der die PPPoE-Sitzungen beendet, oder im Fall von L2TP von den Home-Gateways. Die IP-Adresse wird für jede PPPoE-Sitzung zugewiesen.
Das CPE kann Network Address Translation/Dynamic Host Configuration Protocol (NAT/DHCP) nicht ausführen, da es überbrückt ist und ihm keine IP-Adresse zugewiesen ist.
So erreichen Sie das Serviceziel:
Beendigung von PPP-Sitzungen beim Service Provider
L2TP-Tunneling
Bei Verwendung von SSG
Ausführliche Erläuterungen zu diesen Architekturen werden in separaten Dokumenten behandelt.
Diese Version der PPPoE-Client-Software unterstützt die in RFC 2516 beschriebenen Erkennungs- und Sitzungsstufen. Die Entdeckungsphase ist in vier Schritten abgeschlossen. Nach Abschluss der Konferenz kennen beide Peers die PPPoE-Sitzungs-ID und die Ethernet-Adresse des Peers, die gemeinsam die PPPoE-Sitzung eindeutig definieren. Dies sind die Schritte:
Der Host sendet ein Initiierungspaket.
Der Host sendet das PADI-Paket (PPPoE active Discovery Initiation), bei dem destination_addr auf die Broadcast-Adresse festgelegt ist. Die PADI besteht aus einem Tag, der angibt, welcher Service-Typ angefordert wird.
Ein oder mehrere Zugriffskonzentratoren senden Angebotspakete.
Wenn der Zugriffskonzentrator oder der Router eine PADI empfängt, die er verwenden kann, sendet er ein PADO-Paket (PPPoE Active Discovery Offer). Die destination_addr ist die Unicast-Adresse des Hosts, der die PADI gesendet hat. Wenn der Zugriffskonzentrator die PADI nicht bedienen kann, darf er nicht mit einem PADO reagieren. Da die PADI gesendet wurde, kann der Host mehrere PADOs empfangen.
Der Host sendet ein Unicast-Sitzungsanforderungspaket.
Der Host durchsucht die empfangenen PADO-Pakete und wählt eine aus. Die Auswahl basiert auf den von jedem Zugriffskonzentrator angebotenen Services. Der Host sendet dann ein PADR-Paket an den von ihm ausgewählten Zugriffskonzentrator. Das Feld destination_addr wird auf die Unicast-Ethernet-Adresse des Zugriffskonzentrators oder des Routers festgelegt, der die PADO sendet.
Der ausgewählte Zugriffskonzentrator sendet ein Bestätigungspaket.
Wenn der Zugriffskonzentrator ein PADR-Paket empfängt, bereitet er sich auf den Beginn einer PPP-Sitzung vor. Er generiert eine eindeutige Session-ID für die PPPoE-Sitzung und antwortet dem Host mit einem PADS-Paket (Active Discovery Session-confirmation) für PPPoE. Das destination_addr-Feld ist die Unicast-Ethernet-Adresse des Hosts, der den PADR sendet.
Nach Beginn der PPPoE-Sitzung werden PPP-Daten wie in jeder anderen PPP-Kapselung gesendet. Alle Ethernet-Pakete sind Unicast.
Ein PPPoE-Paket mit aktivem Discovery Terminate (PADT) kann vom Host oder vom Zugriffskonzentrator jederzeit nach der Einrichtung einer Sitzung gesendet werden, um anzuzeigen, dass eine PPPoE-Sitzung beendet wurde.
Ausführlichere Erläuterungen finden Sie in RFC 2516.
Für ADSL gewinnt PPPoE an Popularität und ist nur der Nachfolger von PPPoA.
RFC 2516 - Eine Methode zur Übertragung von PPP over Ethernet (PPPoE)
RFC 1483 - Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2364 - Point-to-Point über AAL5