3. Protocol Overview (Protokollübersicht)
L2TP nutzt zwei Arten von Nachrichten: Kontrollnachrichten (control messages) und Datennachrichten (data messages). Kontrollnachrichten werden beim Aufbau, der Wartung und dem Abbau von Tunneln und Anrufen verwendet. Datennachrichten werden verwendet, um PPP-Frames zu kapseln, die über den Tunnel übertragen werden. Kontrollnachrichten nutzen einen zuverlässigen Kontrollkanal (reliable Control Channel) innerhalb von L2TP, um die Zustellung zu garantieren (siehe Abschnitt 5.1 für Details). Datennachrichten werden bei Paketverlust nicht erneut übertragen.
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
Abbildung 3.0 L2TP-Protokollstruktur
Abbildung 3.0 zeigt die Beziehung von PPP-Frames und Kontrollnachrichten über die L2TP-Kontroll- und Datenkanäle. PPP-Frames werden über einen unzuverlässigen Datenkanal übertragen, der zuerst durch einen L2TP-Header und dann durch einen Pakettransport wie UDP, Frame Relay, ATM usw. gekapselt wird. Kontrollnachrichten werden über einen zuverlässigen L2TP-Kontrollkanal gesendet, der Pakete in-band über denselben Pakettransport überträgt.
Sequenznummern müssen (MUST) in allen Kontrollnachrichten vorhanden sein und werden verwendet, um eine zuverlässige Zustellung auf dem Kontrollkanal bereitzustellen. Datennachrichten können (MAY) Sequenznummern verwenden, um Pakete neu zu ordnen und verlorene Pakete zu erkennen.
Alle Werte werden in ihre jeweiligen Felder platziert und in Netzwerkreihenfolge (höherwertige Oktette zuerst) gesendet.
3.1 L2TP Header Format (L2TP-Header-Format)
L2TP-Pakete für den Kontrollkanal und Datenkanal teilen ein gemeinsames Header-Format. In jedem Fall, in dem ein Feld optional ist, existiert sein Platz nicht in der Nachricht, wenn das Feld als nicht vorhanden markiert ist. Beachten Sie, dass die unten als optional markierten Felder Length, Ns und Nr zwar bei Datennachrichten optional sind, aber bei allen Kontrollnachrichten vorhanden sein müssen (MUST).
Dieser Header ist wie folgt formatiert:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 3.1 L2TP-Nachrichten-Header
Das Type (T) Bit gibt den Nachrichtentyp an. Es wird auf 0 für eine Datennachricht und auf 1 für eine Kontrollnachricht gesetzt.
Wenn das Length (L) Bit 1 ist, ist das Length-Feld vorhanden. Dieses Bit muss (MUST) für Kontrollnachrichten auf 1 gesetzt werden.
Die x-Bits sind für zukünftige Erweiterungen reserviert. Alle reservierten Bits müssen (MUST) bei ausgehenden Nachrichten auf 0 gesetzt und bei eingehenden Nachrichten ignoriert werden.
Wenn das Sequence (S) Bit auf 1 gesetzt ist, sind die Felder Ns und Nr vorhanden. Das S-Bit muss (MUST) für Kontrollnachrichten auf 1 gesetzt werden.
Wenn das Offset (O) Bit 1 ist, ist das Offset Size-Feld vorhanden. Das O-Bit muss (MUST) für Kontrollnachrichten auf 0 (Null) gesetzt werden.
Wenn das Priority (P) Bit 1 ist, sollte (SHOULD) diese Datennachricht bei ihrer lokalen Warteschlangenverwaltung und Übertragung bevorzugt behandelt werden. LCP-Echo-Anfragen, die als Keepalive für die Verbindung verwendet werden, sollten (SHOULD) beispielsweise im Allgemeinen mit diesem auf 1 gesetzten Bit gesendet werden. Ohne dies könnte ein temporäres Intervall lokaler Überlastung zu Interferenzen mit Keepalive-Nachrichten und unnötigem Verlust der Verbindung führen. Diese Funktion ist nur für Datennachrichten vorgesehen. Das P-Bit muss (MUST) für alle Kontrollnachrichten auf 0 gesetzt werden.
Ver muss (MUST) 2 sein, was die Version des in diesem Dokument beschriebenen L2TP-Datennachrichten-Headers angibt. Der Wert 1 ist reserviert, um die Erkennung von L2F [RFC2341] Paketen zu ermöglichen, sollten sie vermischt mit L2TP-Paketen eintreffen. Pakete, die mit einem unbekannten Ver-Feld empfangen werden, müssen (MUST) verworfen werden.
Das Length-Feld gibt die Gesamtlänge der Nachricht in Oktetten an.
Tunnel ID gibt den Bezeichner für die Kontrollverbindung an. L2TP-Tunnel werden durch Bezeichner benannt, die nur lokale Bedeutung haben. Das heißt, derselbe Tunnel erhält an jedem Ende des Tunnels unterschiedliche Tunnel-IDs. Die Tunnel-ID in jeder Nachricht ist die des beabsichtigten Empfängers, nicht des Absenders. Tunnel-IDs werden während der Erstellung eines Tunnels als Assigned Tunnel ID AVPs ausgewählt und ausgetauscht.
Session ID gibt den Bezeichner für eine Sitzung innerhalb eines Tunnels an. L2TP-Sitzungen werden durch Bezeichner benannt, die nur lokale Bedeutung haben. Das heißt, dieselbe Sitzung erhält an jedem Ende der Sitzung unterschiedliche Session-IDs. Die Session-ID in jeder Nachricht ist die des beabsichtigten Empfängers, nicht des Absenders. Session-IDs werden während der Erstellung einer Sitzung als Assigned Session ID AVPs ausgewählt und ausgetauscht.
Ns gibt die Sequenznummer für diese Daten- oder Kontrollnachricht an, beginnend bei Null und um eins (Modulo 2**16) für jede gesendete Nachricht inkrementierend. Weitere Informationen zur Verwendung dieses Feldes finden Sie in den Abschnitten 5.8 und 5.4.
Nr gibt die in der nächsten zu empfangenden Kontrollnachricht erwartete Sequenznummer an. Somit wird Nr auf das Ns der letzten in Reihenfolge empfangenen Nachricht plus eins (Modulo 2**16) gesetzt. In Datennachrichten ist Nr reserviert und muss (MUST), falls vorhanden (wie durch das S-Bit angezeigt), beim Empfang ignoriert werden. Weitere Informationen zur Verwendung dieses Feldes in Kontrollnachrichten finden Sie in Abschnitt 5.8.
Das Offset Size-Feld, falls vorhanden, gibt die Anzahl der Oktette nach dem L2TP-Header an, an denen erwartet wird, dass die Nutzdaten beginnen. Tatsächliche Daten innerhalb des Offset-Paddings sind undefiniert. Wenn das Offset-Feld vorhanden ist, endet der L2TP-Header nach dem letzten Oktett des Offset-Paddings.
3.2 Control Message Types (Kontrollnachrichtentypen)
Der Message Type AVP (siehe Abschnitt 4.4.1) definiert den spezifischen Typ der gesendeten Kontrollnachricht. Erinnern Sie sich aus Abschnitt 3.1, dass dies nur für Kontrollnachrichten gilt, das heißt Nachrichten mit auf 1 gesetztem T-Bit.
Dieses Dokument definiert die folgenden Kontrollnachrichtentypen (siehe Abschnitte 6.1 bis 6.14 für Details zur Konstruktion und Verwendung jeder Nachricht):
Kontrollverbindungsverwaltung (Control Connection Management)
- 0 (reserved) reserviert
- 1 (SCCRQ) Start-Control-Connection-Request
- 2 (SCCRP) Start-Control-Connection-Reply
- 3 (SCCCN) Start-Control-Connection-Connected
- 4 (StopCCN) Stop-Control-Connection-Notification
- 5 (reserved) reserviert
- 6 (HELLO) Hello
Anrufverwaltung (Call Management)
- 7 (OCRQ) Outgoing-Call-Request
- 8 (OCRP) Outgoing-Call-Reply
- 9 (OCCN) Outgoing-Call-Connected
- 10 (ICRQ) Incoming-Call-Request
- 11 (ICRP) Incoming-Call-Reply
- 12 (ICCN) Incoming-Call-Connected
- 13 (reserved) reserviert
- 14 (CDN) Call-Disconnect-Notify
Fehlermeldung (Error Reporting)
- 15 (WEN) WAN-Error-Notify
PPP-Sitzungssteuerung (PPP Session Control)
- 16 (SLI) Set-Link-Info