Link Control Protocol

Aufgabe und Ablauf

Das Link Control Protocol (LCP) ist ein Protokoll zur Steuerung einer Datenverbindung innerhalb des Point-to-Point Protocol (PPP). Es dient dazu, eine Punkt-zu-Punkt-Verbindung zu konfigurieren, aufzubauen, zu prüfen und wieder zu beenden.

Der Artikel spricht von vier Phasen der PPP-Kommunikation, führt jedoch fünf Schritte auf:

• Verbindungsaufbau und Konfigurationsaushandlung: Der PPP-Ausgangsknoten sendet LCP-Rahmen, um die Datenverbindung aufzubauen und ihre Eigenschaften auszuhandeln.

• Bestimmung der Verbindungsqualität: Optional wird getestet, ob die Qualität der Verbindung für Vermittlungsschichtprotokolle der entsprechenden OSI-Schicht ausreicht.

• Authentifizierung: Optional wird die Identität des Kommunikationspartners geprüft.

• Konfiguration der Vermittlungsschichtprotokolle: Der Ausgangsknoten sendet NCP-Rahmen. NCP steht für die Protokolle, mit denen beispielsweise IP, IPX oder AppleTalk ausgewählt und konfiguriert werden. Anschließend können Pakete dieser Protokolle übertragen werden.

• Verbindungsbeendigung: Die Verbindung bleibt aktiv, bis LCP- oder NCP-Rahmen sie beenden oder ein äußeres Ereignis eintritt, etwa Inaktivität oder eine Aktion des Benutzers.

Aufbau eines LCP-Pakets

Der LCP-Header besteht aus den Feldern Code, Identifier beziehungsweise Bezeichner, Length beziehungsweise Länge und Data beziehungsweise Daten.

• Code: Das Feld ist 8 Bit lang und bestimmt, welche Funktion ausgeführt werden soll.

• Bezeichner: Dieses Feld ist ebenfalls 8 Bit lang. Es dient dazu, zusammengehörige Anfragen und Antworten zu steuern beziehungsweise einander zuzuordnen.

• Länge: Das 16 Bit lange Feld gibt die Gesamtgröße des Pakets einschließlich des Headers an.

• Daten: Dieses Feld ist variabel lang und kann null oder mehr Bytes enthalten. Seine tatsächliche Größe ergibt sich aus dem Längenfeld. Es enthält eine oder mehrere Optionen.

Codes und ihre Funktionen

Die wichtigsten Werte des 8-Bit-Codefeldes sind:

• 0: Vendor Specific, also herstellerspezifisch (RFC 2153). • 1: Configure-Request, eine Anfrage zur Konfiguration. • 2: Configure-Ack, die Bestätigung einer Konfiguration. • 3: Configure-Nak, eine negative Antwort mit nicht akzeptierten beziehungsweise anzupassenden Angaben. • 4: Configure-Reject, die Zurückweisung einer Konfigurationsangabe. • 5: Terminate-Request, eine Anfrage zum Beenden der Verbindung. • 6: Terminate-Ack, die Bestätigung der Beendigung. • 7: Code-Reject, die Zurückweisung eines Codes. • 8: Protocol-Reject, die Zurückweisung eines Protokolls. • 9: Echo-Request, eine Echo-Anfrage. • 10: Echo-Reply, die Antwort auf eine Echo-Anfrage. • 11: Discard-Request, eine Anfrage, deren Paket verworfen werden soll. • 12: Identification (RFC 1570). • 13: Time-Remaining (RFC 1570).

Format und Arten der Konfigurationsoptionen

Eine LCP-Konfigurationsoption besitzt die Felder Option, Länge und Daten. Das Optionsfeld ist 8 Bit lang und bezeichnet die Art der Option. Auch das Längenfeld ist 8 Bit lang. Es gibt die gesamte Länge der Option in Bytes an, einschließlich der Felder Option und Länge. Die Gesamtlänge entspricht daher der Länge der eigentlichen Optionsdaten plus 2 Bytes. Das Datenfeld ist variabel und enthält null oder mehr Bytes mit den zur jeweiligen Option gehörenden Angaben.

Die aufgeführten Optionsnummern und Bedeutungen sind:

• 0: Vendor Specific (RFC 2153). • 1: Maximum-Receive-Unit, Länge 4 (RFC 1661). • 3: Authentication-Protocol, Länge mindestens 4 (RFC 1334, RFC 1661 und RFC 1994). • 4: Quality-Protocol, Länge mindestens 4 (RFC 1661). • 5: Magic-Number, Länge 6 (RFC 1661). • 7: Protocol-Field-Compression, Länge 2; als veraltet gekennzeichnet (RFC 1661). • 8: Address-and-Control-Field-Compression, Länge 2 (RFC 1661). • 9: FCS-Alternatives, Länge 3 (RFC 1570). • 10: Self-Describing-Pad, Länge 3 (RFC 1570). • 11: Numbered-Mode, Länge mindestens 4 (RFC 1663). • 12: Identification, Länge mindestens 8 (RFC 1570). • 13: Callback, Länge mindestens 3 (RFC 1570). • 14: Connect-Time; als veraltet gekennzeichnet. • 15: Compound-Frames, Länge 2; als veraltet gekennzeichnet (RFC 1570). • 16: Nominal-Data-Encapsulation; als veraltet gekennzeichnet. • 17: Multilink Max-Receive-Reconstructed-Unit (MRRU), Länge 4 (RFC 1990). • 18: Multilink Short Sequence Number Header Format, Länge 2 (RFC 1990). • 19: Multilink Endpoint Discriminator, variable Länge (RFC 1990). • 20: Proprietary. • 21: DCE-Identifier. • 22: MP+ Procedure Option, Länge 4 (RFC 1934). • 23: Link Discriminator for BACP, Länge 4 (RFC 2125). • 24: LCP-Authentication-Option. • 25: COBS, Consistent Overhead Byte Stuffing. • 26: Prefix Elision, variable Länge (RFC 2686). • 27: Multilink header format, Länge 4 (RFC 2686). • 28: Internationalization, Länge mindestens 7 (RFC 2484). • 29: Simple Data Link on SONET/SDH, Länge 2 (RFC 2823). • 30: bis zum 14. Oktober 2002 reserviert.

Als Beispiel nennt der Artikel eine MRU-Option für 1540 Bytes. Sie besteht aus dem Optionswert 0x01, der Länge 0x04 und dem Datenwert 0x0604.

Zentrale ausgehandelte Eigenschaften

Die Maximum Receive Unit (MRU) teilt dem Kommunikationspartner mit, welche maximale Paketgröße empfangen werden kann. Nach RFC 1661 beträgt der Standardwert 1500 Bytes. Der Sender darf auch kleinere Pakete übertragen.

Über die Option Authentication-Protocol wird das Authentifizierungsverfahren ausgehandelt. RFC 1661 nennt dafür das Password Authentication Protocol (PAP) und das Challenge Handshake Authentication Protocol (CHAP).

Mit der Option Quality-Protocol können die Kommunikationspartner ein Protokoll für den Austausch von Daten über die Qualität der Verbindung vereinbaren.