In diesem Dokument wird eine ADSL-Architektur (Asymmetric Digital Subscriber Line) beschrieben, die Point-to-Point Protocol over Ethernet (PPPoE) verwendet.
In der aktuellen Umgebung der Zugriffstechnologien ist es wünschenswert, mehrere Hosts an einem Remote-Standort über dasselbe Zugangsgerät am Kundenstandort zu verbinden. Darüber hinaus müssen die Zugriffskontroll- und Abrechnungsfunktionen ähnlich wie bei DFÜ-Services mit Point-to-Point Protocol (PPP) bereitgestellt werden. Bei vielen Access-Technologien erfolgt die Verbindung mehrerer Hosts mit dem Kundenstandort-Zugriffsgerät am kosteneffizientesten über Ethernet. Darüber hinaus ist es wünschenswert, den Aufwand für diese Vorrichtung möglichst gering zu halten und den Konfigurationsaufwand möglichst gering zu halten.
Kunden, die ADSL bereitstellen, müssen Authentifizierung und Autorisierung im PPP-Stil über eine große Anzahl vorhandener Bridging-Geräte für den Kundenstandort (CPE) unterstützen. PPPoE bietet die Möglichkeit, ein Netzwerk von Hosts über ein einfaches Bridging-Zugriffsgerät mit einem Remote-Access-Konzentrator oder einem Aggregation-Konzentrator zu verbinden. Bei diesem Modell verwendet jeder Host seinen eigenen PPP-Stack. Daher präsentiert es dem Benutzer eine vertraute Benutzeroberfläche. Sie können auf die Steuerung, die Abrechnung und den Servicetyp pro Benutzer und nicht pro Standort zugreifen.
Die Basisarchitektur geht davon aus, dass folgende Elemente bereitgestellt werden:
Hochgeschwindigkeits-Internetzugang und Unternehmenszugriff auf den Endkunden, der PPPoE verwendet.
ATM als Core-Backbone-Technologie, implementiert durch den Cisco 6400 Universal Access Concentrator (UAC)
Diese Einschränkungen bei der Designimplementierung können die Verwendung dieser Architektur auf anderen Plattformen einschränken. PPPoE entwickelt sich jedoch ständig weiter. Lesen Sie die neuesten Versionshinweise für verwandte Produkte, um von neuen und aktualisierten Funktionen zu profitieren.
Dieses Whitepaper basiert auf aktuellen Bereitstellungen und internen Tests, bei denen Cisco 6400 UAC zum Einsatz kommt. Dieses Dokument ist eine Fortsetzung des PPPoA Baseline Architecture-Dokuments und bezieht sich häufig darauf. Es wird davon ausgegangen, dass Sie das PPPoA-Whitepaper Baseline Architecture gelesen und sich mit den Grundlagen von PPP vertraut gemacht haben und die Versionshinweise für die neueste Softwareversion gelesen haben.
Wie in RFC 2516 angegeben, besteht PPPoE aus zwei unterschiedlichen Phasen: einer Erkennungsphase und einer PPP-Sitzungsphase. Wenn ein Host eine PPPoE-Sitzung initiiert, muss er zunächst eine Erkennung durchführen, um zu ermitteln, welcher Server die Anforderung des Clients erfüllen kann. Zweitens muss die Ethernet-MAC-Adresse des Peers identifiziert und eine PPPoE-Sitzungs-ID eingerichtet werden. Während PPP eine Peer-to-Peer-Beziehung definiert, ist die Erkennung grundsätzlich eine Client-Server-Beziehung.
Beim Erkennungsprozess erkennt ein Host (der Client) einen oder mehrere Zugriffskonzentratoren (die Server) und wählt einen aus. Wenn die Erkennung erfolgreich abgeschlossen wurde, verfügen sowohl der Host als auch der ausgewählte Access Concentrator über die erforderlichen Informationen, um eine Punkt-zu-Punkt-Verbindung über Ethernet herzustellen. Nachdem eine PPP-Sitzung aufgebaut 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 nutzt die meisten Vorteile des PPP, das im Einwahlmodell und in der PPPoA-Architektur verwendet wird. In diesen Abschnitten werden einige der wichtigsten Vor- und Nachteile von PPPoE und ihre Unterschiede zu PPPoA aufgeführt.
Dies sind einige der Hauptvorteile von PPPoE und wie sie sich von PPPoA unterscheiden:
Authentifizierung pro Sitzung basierend auf dem Password Authentication Protocol (PAP) oder Challenge Handshake Authentication Protocol (CHAP). Dies ist der größte Vorteil von PPPoE, da durch die Authentifizierung die Sicherheitslücke in einer Bridging-Architektur geschlossen wird.
Es ist eine Sitzungsabrechnung möglich, die es dem Dienstanbieter ermöglicht, dem Teilnehmer die Sitzungszeit für verschiedene angebotene Dienste in Rechnung zu stellen. Darüber hinaus kann der Service Provider eine minimale Zugangsgebühr verlangen.
Sie können PPPoE auf aktuellen CPE-Installationen verwenden, die nicht auf PPP aktualisiert werden können oder die PPPoA nicht ausführen können. Dadurch wird die PPP-Sitzung über das überbrückte Ethernet-LAN auf den PC erweitert.
PPPoE behält die Point-to-Point-Sitzung bei, die von Internet Service Providern (ISPs) im aktuellen Einwahlmodell 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) kann einen sicheren Zugriff auf ein Unternehmensgateway ohne End-to-End-PVCs (Permanent Virtual Circuits) und ohne Verwendung von Layer-3-Routing und/oder Layer-2-Tunneling-Protokoll-Tunneln (L2TP) bereitstellen. Dadurch ist das Geschäftsmodell für den Verkauf von Großkundendiensten und virtuellen privaten Netzen (VPNs) skalierbar.
PPPoE kann einem Host (PC) den Zugriff auf mehrere Ziele gleichzeitig ermöglichen. Pro PVC können mehrere PPPoE-Sitzungen stattfinden.
Der NSP kann durch die Bereitstellung von Leerlauf- und Sitzungszeitüberschreitungen mithilfe eines RADIUS-Servers (Remote Authentication Dial-In User Service) nach Branchenstandard für jeden Teilnehmer eine Überbelegung vornehmen.
Sie können PPP mit der SSG-Funktion (Service Selection Gateway) verwenden.
Dies sind einige der Hauptnachteile von PPPoE und wie sie sich von PPPoA unterscheiden:
Sie müssen die PPPoE-Client-Software auf allen Hosts (PCs) installieren, die mit dem Ethernet-Segment verbunden sind. Dies bedeutet, dass der Zugriffsanbieter 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 vor der Implementierung dieser Art von Architektur berücksichtigt werden sollten.
Die Anzahl der unterstützten Abonnenten Die Anzahl der erforderlichen PPPoE-Server hängt von der Anzahl der Sitzungen ab.
Legt fest, ob die PPP-Sitzungen am Aggregationsrouter des Service Providers beendet oder an andere Unternehmens-Gateways oder ISPs weitergeleitet werden.
Legt fest, ob der Service Provider oder das endgültige Service-Ziel die IP-Adresse bereitstellt.
Bei mehr als einem Benutzer kann es sein, ob alle Benutzer dasselbe Endziel oder denselben Enddienst erreichen müssen oder ob alle unterschiedliche Dienstziele haben. Benötigen die Endabonnenten gleichzeitigen Zugriff auf mehrere Ziele?
Die PPPoE-Client-Software, die vom Access Provider verwendet wird und ob die Software getestet wurde, das Betriebssystem, das der Host verwendet, und ob dieses Betriebssystem eine intelligente Routing-Entscheidung treffen kann.
Legt fest, wie der Service Provider die Abonnenten auf Grundlage einer Pauschalgebühr, einer Sitzungsnutzung oder der genutzten Services berechnet.
Bereitstellung und Bereitstellung von CPEs, DSLAMs und Aggregation Points of Presence (POPs)
Das Geschäftsmodell für den NAP. Umfasst das Modell auch den Verkauf von Vorleistungsdiensten wie sicheren Zugang für Unternehmen und Mehrwertdiensten wie Sprach- und Videoservices? Sind NAP und NSP identisch?
Das Geschäftsmodell des Unternehmens. Ist es mit einem unabhängigen lokalen Exchange Carrier (ILEC), einem konkurrierenden lokalen Exchange Carrier (CLEC) oder einem ISP vergleichbar?
Die Anwendungstypen, die der NSP dem Endteilnehmer anbietet.
Das erwartete vor- und nachgelagerte Datenflussvolumen Berücksichtigen Sie den NRP-Durchsatz, Traffic Engineering und QoS-Probleme.
In diesem Dokument wird erläutert, wie sich die PPPoE-Architektur für verschiedene Geschäftsmodelle von Service Providern anpasst und skaliert und wie diese Architektur den Providern zugute kommen kann.
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 von ihm angebotenen Services zu kennen. 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 Service Providers über gute Kenntnisse dieses PCs und seines Betriebssystems verfügen.
Wie in RFC 2516 angegeben, darf die Option für die maximale Empfangseinheit (Maximum Receive Unit, MRU) nicht mit einer Größe größer als 1492 verhandelt werden. Ethernet hat eine maximale Nutzlastgröße von 1500 Achtbitzeichen. Der PPPoE-Header hat 6 Oktetten, und die PPP-Protokoll-ID ist 2 Oktetten, sodass die maximale PPP-Übertragungseinheit (Maximum Transmission Unit, MTU) nicht größer als 1492 sein darf. Dies wird durch die Konfiguration der IP-MTU 1492 für PPPoE-Virtual-Template-Schnittstellen erreicht.
Bei der Konfiguration einer PPPoE-VPDN-Gruppe wird standardmäßig keine virtuelle Zugriffsschnittstelle vorab geklont. Benutzer können die maximale Anzahl der vorab geklonten virtuellen 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, kann mit PPPoE (standardmäßig) nur eine Sitzung von einer MAC-Adresse über einen VC bezogen werden. Benutzer können die Befehle pppoe session-limit per-mac und pppoe session-limit per-vc eingeben, um die Standardeinstellungen zu ändern.
Der Accounting-, Autorisierungs- und Authentifizierungsprozess ist mit dem von PPPoA identisch. Der einzige Unterschied besteht darin, dass die VPI/VCI-basierte Authentifizierung, die für PPPoA verfügbar und nicht für PPPoE verfügbar ist, derzeit die L2TP- und SSG-Architekturen für Großhandelsdienste verwenden kann.
CPE ist für reines RFC 1483-Bridging konfiguriert. Jedes CPE nutzt nur ein VPI/VCI-Paar, und alle PPPoE-Sitzungen, die von Hosts hinter diesem CPE initiiert werden, werden in dieser einzigen VC übertragen.
Die IP-Adressenzuweisung für den einzelnen Host, auf dem der PPPoE-Client ausgeführt wird, basiert auf demselben PPP-Prinzip bei der Wählmodus-IPCP-Aushandlung. Der Ursprung der IP-Adresse hängt vom Typ des Dienstes ab, den der Teilnehmer erwirbt, und davon, wo die PPP-Sitzungen enden. PPPoE nutzt die DFÜ-Netzwerkfunktion von Microsoft Windows, und die zugewiesene IP-Adresse spiegelt sich im PPP-Adapter wider.
Die Zuweisung der IP-Adressen 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.
Der 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 wurde.
So erreichen Sie das Service-Ziel:
Beendigung von PPP-Sitzungen beim Service Provider
L2TP-Tunneling
Bei Verwendung von SSG
Ausführliche Erläuterungen zu diesen Architekturen werden in separaten Papieren behandelt.
Diese Version der PPPoE-Client-Software unterstützt die in RFC 2516 beschriebenen Erkennungs- und Sitzungsphasen. Die Erkennungsphase gliedert sich in vier Schritte. Nach Abschluss des Vorgangs kennen beide Peers die PPPoE-Sitzungs-ID und die Ethernet-Adresse des Peers, die zusammen die PPPoE-Sitzung eindeutig definieren. Dies sind die Schritte:
Der Host sendet ein Initiierungspaket.
Der Host sendet das PPPoE-PADI-Paket (Active Discovery Initiation) mit festgelegter destination_addr an die Broadcast-Adresse. Der PADI besteht aus einem Tag, der angibt, welchen Servicetyp er anfordert.
Ein oder mehrere Zugriffskonzentratoren senden Angebotspakete.
Wenn der Zugriffskonzentrator oder der Router eine PADI empfängt, die er bedienen 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 den PADI nicht bedienen kann, darf er nicht mit einem PADO reagieren. Seit der Übertragung des PADI kann der Gastgeber mehr als einen PADO empfangen.
Der Host sendet ein Unicast-Sitzungsanforderungspaket.
Der Host durchsucht die empfangenen PADO-Pakete und wählt ein Paket aus. Die Auswahl richtet sich nach den Diensten, die von den einzelnen Zugangskonzentratoren angeboten werden. 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 den 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 Sitzungs-ID für die PPPoE-Sitzung und antwortet dem Host mit einem PPPoE-PADS-Paket (Active Discovery Session-Confirmation). Das Feld destination_addr ist die Unicast-Ethernet-Adresse des Hosts, der den PADR sendet.
Sobald die PPPoE-Sitzung beginnt, werden PPP-Daten wie bei jeder anderen PPP-Kapselung gesendet. Alle Ethernet-Pakete sind Unicast-Pakete.
Ein PPPoE-PADT-Paket (Active Discovery Terminate) kann vom Host oder vom Zugriffskonzentrator nach dem Aufbau einer Sitzung gesendet werden, um anzuzeigen, dass eine PPPoE-Sitzung beendet wurde.
Weitere Informationen finden Sie in RFC 2516.
Bei ADSL gewinnt PPPoE an Popularität und steht an zweiter Stelle hinter PPPoA.
RFC 2516 - A method to transmission PPP over Ethernet (PPPoE)
RFC 1483 - Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2364 - Point-to-Point over AAL5
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
10-Dec-2001 |
Erstveröffentlichung |