Anhang A. LDP-Labelverteilungsverfahren

Dieser Abschnitt spezifiziert das Labelverteilungsverhalten in Form der Reaktion des LSR auf die folgenden Ereignisse:

• Empfang einer Label Request Message;
• Empfang einer Label Mapping Message;
• Empfang einer Label Abort Request Message;
• Empfang einer Label Release Message;
• Empfang einer Label Withdraw Message;
• Erkennung einer neuen FEC;
• Erkennung einer Änderung des FEC-Next-Hop;
• Empfang einer Notification Message / Label Request Aborted;
• Empfang einer Notification Message / No Label Resources;
• Empfang einer Notification Message / No Route;
• Empfang einer Notification Message / Loop Detected;
• Empfang einer Notification Message / Label Resources Available;
• Erkennung, dass lokale Label-Ressourcen verfügbar geworden sind;
• Der LSR entscheidet, eine FEC nicht mehr labelzuvermitteln;
• Zeitüberschreitung einer zurückgestellten Label-Anforderung.

Die Spezifikation des LSR-Verhaltens als Reaktion auf ein Ereignis hat drei Teile:

1. Zusammenfassung. Ein Fließtext, der die Reaktion des LSR auf das Ereignis im Überblick beschreibt.

2. Kontext. Eine Liste von Elementen, auf die der Algorithmus-Teil der Spezifikation verweist. (Siehe 3.)

3. Algorithmus. Ein Algorithmus für die Reaktion des LSR auf das Ereignis.

Die Zusammenfassung kann Details der LSR-Reaktion auslassen, wie Buchhaltungsmaßnahmen oder Verhalten, das vom verwendeten Label-Ankündigungsmodus, Steuermodus oder Label-Beibehaltungsmodus des LSR abhängt. Die Absicht ist, dass der Algorithmus die LSR-Reaktion vollständig und eindeutig spezifiziert.

Die Algorithmen in diesem Abschnitt verwenden Verfahren, die in der MPLS-Architekturspezifikation [RFC3031] für Hop-by-Hop gerouteten Verkehr definiert sind. Diese Verfahren sind:

• Das Verfahren Label Distribution, das von einem nachgelagerten LSR durchgeführt wird, um zu bestimmen, wann ein Label für eine FEC an LDP-Peers verteilt wird. Die Architektur definiert vier Label Distribution-Verfahren:

  . Downstream Unsolicited Independent Control, in [RFC3031] PushUnconditional genannt.

  . Downstream Unsolicited Ordered Control, in [RFC3031] PushConditional genannt.

  . Downstream On Demand Independent Control, in [RFC3031] PulledUnconditional genannt.

  . Downstream On Demand Ordered Control, in [RFC3031] PulledConditional genannt.

• Das Verfahren Label Withdrawal, das von einem nachgelagerten LSR durchgeführt wird, um zu bestimmen, wann eine zuvor an LDP-Peers verteilte FEC-Label-Abbildung entzogen wird. Die Architektur definiert ein einziges Label Withdrawal-Verfahren. Wann immer ein LSR die Bindung zwischen einem Label und einer FEC löst, MUSS (MUST) er die FEC-Label-Abbildung von allen LDP-Peers entziehen, an die er die Abbildung zuvor gesendet hat.

• Das Verfahren Label Request, das von einem vorgelagerten LSR durchgeführt wird, um zu bestimmen, wann ausdrücklich angefordert wird, dass ein nachgelagerter LSR ein Label an eine FEC bindet und ihm die entsprechende Label-Abbildung sendet. Die Architektur definiert drei Label Request-Verfahren:

  . Request Never. Der LSR fordert nie ein Label an.

  . Request When Needed. Der LSR fordert ein Label an, wann immer er eines benötigt.

  . Request On Request. Dieses Verfahren wird von nicht label-zusammenführenden (non-label merging) LSRs verwendet. Der LSR fordert ein Label an, wenn er eine Anforderung für eines empfängt, zusätzlich dazu, wann immer er eines benötigt.

• Das Verfahren Label Release, das von einem vorgelagerten LSR durchgeführt wird, um zu bestimmen, wann eine zuvor empfangene Label-Abbildung für eine FEC freigegeben wird. Die Architektur definiert zwei Label Release-Verfahren:

  . Conservative Label retention, in [RFC3031] ReleaseOnChange genannt.

  . Liberal Label retention, in [RFC3031] NoReleaseOnChange genannt.

• Das Verfahren Label Use, das von einem LSR durchgeführt wird, um zu bestimmen, wann begonnen wird, ein FEC-Label zur Weiterleitung/Vermittlung zu verwenden. Die Architektur definiert drei Label Use-Verfahren:

  . Use Immediate. Der LSR verwendet ein von einem FEC-Next-Hop empfangenes Label sofort zur Weiterleitung/Vermittlung.

  . Use If Loop Free. Der LSR verwendet ein von einem FEC-Next-Hop empfangenes FEC-Label nur dann zur Weiterleitung/Vermittlung, wenn er festgestellt hat, dass er dadurch keine Weiterleitungsschleife verursacht.

  . Use If Loop Not Detected. Dieses Verfahren entspricht Use Immediate, es sei denn, der LSR hat eine Schleife in der FEC-LSP erkannt. Die Verwendung des FEC-Labels zur Weiterleitung/Vermittlung wird fortgesetzt, bis sich der Next Hop für die FEC ändert oder die Schleife nicht mehr erkannt wird.

  Diese Version von LDP enthält keinen Mechanismus zur Schleifenverhinderung; daher machen die folgenden Verfahren keinen Gebrauch vom Verfahren Use If Loop Free.

• Das Verfahren Label No Route (in [RFC3031] NotAvailable-Verfahren genannt), das von einem vorgelagerten LSR durchgeführt wird, um zu bestimmen, wie auf eine No Route-Benachrichtigung von einem nachgelagerten LSR als Antwort auf eine Anforderung einer FEC-Label-Abbildung reagiert wird. Die Architekturspezifikation definiert zwei Label No Route-Verfahren:

  . Request Retry. Der LSR sollte die Label-Anforderung zu einem späteren Zeitpunkt ausgeben.

  . No Request Retry. Der LSR sollte annehmen, dass der nachgelagerte LSR eine Label-Abbildung bereitstellen wird, wenn der nachgelagerte LSR einen Next Hop hat, und er sollte die Anforderung nicht erneut ausgeben.