5. Protokollbetrieb
Die notwendige Einrichtung zum Tunneln einer PPP-Sitzung mit L2TP besteht aus zwei Schritten: (1) Einrichtung der Kontrollverbindung für einen Tunnel und (2) Einrichtung einer Sitzung, die durch eine eingehende oder ausgehende Anrufanforderung ausgelöst wird. Der Tunnel und die entsprechende Kontrollverbindung MÜSSEN eingerichtet werden, bevor ein eingehender oder ausgehender Anruf initiiert wird. Eine L2TP-Sitzung MUSS eingerichtet werden, bevor L2TP mit dem Tunneln von PPP-Frames beginnen kann. Mehrere Sitzungen können über einen einzelnen Tunnel existieren, und mehrere Tunnel können zwischen demselben LAC und LNS existieren.
5.1 Einrichtung der Kontrollverbindung
Die Kontrollverbindung ist die anfängliche Verbindung, die zwischen einem LAC und LNS erreicht werden muss, bevor Sitzungen aufgebaut werden können. Die Einrichtung der Kontrollverbindung umfasst die Sicherung der Identität des Peers sowie die Identifizierung der L2TP-Version, der Framing- und Bearer-Fähigkeiten des Peers usw.
Ein Drei-Nachrichten-Austausch wird verwendet, um die Kontrollverbindung einzurichten. Nachfolgend ein typischer Nachrichtenaustausch:
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
Das ZLB ACK wird gesendet, wenn keine weiteren Nachrichten für diesen Peer in der Warteschlange warten.
5.1.1 Tunnel-Authentifizierung
L2TP beinhaltet ein einfaches, optionales, CHAP-ähnliches [RFC1994] Tunnel-Authentifizierungssystem während der Einrichtung der Kontrollverbindung. Wenn ein LAC oder LNS die Identität des Peers authentifizieren möchte, den er kontaktiert oder von dem er kontaktiert wird, wird ein Challenge AVP in die SCCRQ- oder SCCRP-Nachricht aufgenommen. Wenn ein Challenge AVP in einem SCCRQ oder SCCRP empfangen wird, MUSS ein Challenge Response AVP im folgenden SCCRP bzw. SCCCN gesendet werden. Wenn die erwartete Antwort und die von einem Peer empfangene Antwort nicht übereinstimmen, MUSS die Einrichtung des Tunnels verhindert werden.
Um an der Tunnel-Authentifizierung teilzunehmen, MUSS ein einziges gemeinsames Geheimnis zwischen LAC und LNS existieren. Dies ist dasselbe gemeinsame Geheimnis, das für das Verstecken von AVPs verwendet wird (siehe Abschnitt 4.3). Siehe Abschnitt 4.4.3 für Details zur Konstruktion der Challenge- und Response-AVPs.
5.2 Sitzungseinrichtung
Nach erfolgreicher Einrichtung der Kontrollverbindung können einzelne Sitzungen erstellt werden. Jede Sitzung entspricht einem einzelnen PPP-Stream zwischen LAC und LNS. Im Gegensatz zur Einrichtung der Kontrollverbindung ist die Sitzungseinrichtung in Bezug auf LAC und LNS direktional. Der LAC fordert den LNS auf, eine Sitzung für einen eingehenden Anruf zu akzeptieren, und der LNS fordert den LAC auf, eine Sitzung zum Tätigen eines ausgehenden Anrufs zu akzeptieren.
5.2.1 Einrichtung eingehender Anrufe
Ein Drei-Nachrichten-Austausch wird verwendet, um die Sitzung einzurichten. Nachfolgend eine typische Ereignissequenz:
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
Das ZLB ACK wird gesendet, wenn keine weiteren Nachrichten für diesen Peer in der Warteschlange warten.
5.2.2 Einrichtung ausgehender Anrufe
Ein Drei-Nachrichten-Austausch wird verwendet, um die Sitzung einzurichten. Nachfolgend eine typische Ereignissequenz:
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
<- ZLB ACK
Das ZLB ACK wird gesendet, wenn keine weiteren Nachrichten für diesen Peer in der Warteschlange warten.
5.3 Weiterleitung von PPP-Frames
Sobald die Tunnel-Einrichtung abgeschlossen ist, werden PPP-Frames vom entfernten System am LAC empfangen, von CRC, Link-Framing und Transparenz-Bytes befreit, in L2TP gekapselt und über den entsprechenden Tunnel weitergeleitet. Der LNS empfängt das L2TP-Paket und verarbeitet den gekapselten PPP-Frame, als ob er auf einer lokalen PPP-Schnittstelle empfangen worden wäre.
Der Absender einer Nachricht, die mit einer bestimmten Sitzung und einem Tunnel verbunden ist, platziert die Session ID und Tunnel ID (von seinem Peer angegeben) im Session ID- und Tunnel ID-Header für alle ausgehenden Nachrichten. Auf diese Weise werden PPP-Frames über einen einzelnen Tunnel zwischen einem gegebenen LNS-LAC-Paar multiplexiert und demultiplexiert. Zwischen einem gegebenen LNS-LAC-Paar können mehrere Tunnel existieren, und innerhalb eines Tunnels können mehrere Sitzungen existieren.
Der Wert 0 für Session ID und Tunnel ID ist speziell und DARF NICHT als Assigned Session ID oder Assigned Tunnel ID verwendet werden. Für Fälle, in denen eine Session ID noch nicht vom Peer zugewiesen wurde (d. h. während der Einrichtung einer neuen Sitzung oder eines Tunnels), MUSS das Session ID-Feld als 0 gesendet werden, und das Assigned Session ID AVP innerhalb der Nachricht MUSS verwendet werden, um die Sitzung zu identifizieren.
5.4 Verwendung von Sequenznummern auf dem Datenkanal
Sequenznummern sind im L2TP-Header für Kontrollnachrichten und optional für Datennachrichten definiert (siehe Abschnitt 3.1). Diese werden verwendet, um einen zuverlässigen Kontrollnachrichtentransport (siehe Abschnitt 5.8) und eine optionale Datennachrichtensequenzierung bereitzustellen. Jeder Peer verwaltet separate Sequenznummern für die Kontrollverbindung und jede einzelne Datensitzung innerhalb eines Tunnels.
Im Gegensatz zum L2TP-Kontrollkanal verwendet der L2TP-Datenkanal keine Sequenznummern, um verlorene Datennachrichten erneut zu übertragen. Vielmehr können Datennachrichten Sequenznummern verwenden, um verlorene Pakete zu erkennen und/oder die ursprüngliche Sequenz von Paketen wiederherzustellen, die während des Transports möglicherweise neu angeordnet wurden.
5.5 Keepalive (Hello)
Ein Keepalive-Mechanismus wird von L2TP verwendet, um Tunnel-Ausfälle von längeren Perioden ohne Kontroll- oder Datenaktivität auf einem Tunnel zu unterscheiden. Dies wird erreicht, indem Hello-Kontrollnachrichten (siehe Abschnitt 6.5) eingefügt werden, nachdem eine bestimmte Zeitspanne seit dem Empfang der letzten Daten- oder Kontrollnachricht auf einem Tunnel verstrichen ist.
5.6 Sitzungsabbau
Der Sitzungsabbau kann vom LAC oder LNS initiiert werden und wird durch Senden einer CDN-Kontrollnachricht durchgeführt. Nach dem Löschen der letzten Sitzung KANN die Kontrollverbindung ebenfalls abgebaut werden (und wird typischerweise abgebaut).
5.7 Abbau der Kontrollverbindung
Der Abbau der Kontrollverbindung kann vom LAC oder LNS initiiert werden und wird durch Senden einer einzelnen StopCCN-Kontrollnachricht durchgeführt. Der Empfänger eines StopCCN MUSS ein ZLB ACK senden, um den Empfang der Nachricht zu bestätigen, und genügend Kontrollverbindungszustand beibehalten, um StopCCN-Neuübertragungen über mindestens einen vollständigen Neuübertragungszyklus ordnungsgemäß zu akzeptieren (falls das ZLB ACK verloren geht). Die empfohlene Zeit für einen vollständigen Neuübertragungszyklus beträgt 31 Sekunden (siehe Abschnitt 5.8).
Eine Implementierung kann einen gesamten Tunnel und alle Sitzungen auf dem Tunnel herunterfahren, indem sie das StopCCN sendet. Daher ist es nicht notwendig, jede Sitzung einzeln zu löschen, wenn der gesamte Tunnel abgebaut wird.
5.8 Zuverlässige Zustellung von Kontrollnachrichten
L2TP bietet einen zuverlässigen Transportdienst auf niedrigerer Ebene für alle Kontrollnachrichten. Die Nr- und Ns-Felder des Kontrollnachrichten-Headers (siehe Abschnitt 3.1) gehören zu diesem Transport. Die Funktionen der oberen Ebene von L2TP befassen sich nicht mit der Neuübertragung oder Reihenfolge von Kontrollnachrichten.
Die Nachrichten-Sequenznummer Ns beginnt bei 0. Jede nachfolgende Nachricht wird mit dem nächsten Inkrement der Sequenznummer gesendet. Die Sequenznummer ist somit ein frei laufender Zähler, der modulo 65536 dargestellt wird.
(Kapitel 5 abgeschlossen)