MPLS Fast Reroute. Seminar: Datenkommunikation und verteilte Systeme WS03/04

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol MPLS Fast Reroute Seminar: Datenkommunikation und verteilte Systeme WS03/04 Xiaochun Xu Matrikelnummer: Betreuung: Rajendra Persaud Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhaltsverzeichnis 1 Multi-Protocol Label Switching Hintergrund und Motivation Wichtige Begriffe Label Switching Router (LSR) Label Edge Router (LER) Forwarding Equivalence Class (FEC) Label Switched Path (LSP) Paketfluß von MPLS RSVP-TE Eerweiterung zu RSVP für LSP Operationen von LSP-Tunnels Nachrichten im RSVP-TE PATH-Message RESV-Message Wichtige Objekte im RSVP-TE Paketfluß vom RSVP-TE LSP-Sicherung mit Fast Reroute Local Repair Techniken One-to-one Backup Facility Backup Erweiterungen zu RSVP-TE für Fast Reroute FAST REROUTE-Objekt DETOUR-Objekt Andere Objekte Paketfluß vom Fast Reroute One-to-one Backup Facility Backup Zusammenfassung 27 2

3 1 Multi-Protocol Label Switching 1.1 Hintergrund und Motivation Mit der raschen Entwicklung des Internets in den letzten Jahren haben sich die Technologien im IT Bereich auch stark geändert. Die Tendenz der Technologie-Entwicklung im IT Bereich ist der Ersatz von alten Technologien durch neue, also die Einführung von neuen Ansätzen statt einer Verbesserung von vorhandenen Konzepten. Da die Anzahl der Benutzer des Internets deutlich ansteigt und dementsprechend die Anforderung an Bandbreite immer höher wird, ist ein Mechanismus zur optimalen Steuerung und Verwaltung von Verkehrsflüssen beliebiger Anwendungen dringend erforderlich. Abbildung 1-1: MPLS Motivation In der obigen Abbildung wird eine häufig auftauchende Situation skizziert. Alle Verbindungen zwischen Routern haben eine Bandbreite von 2 Mbps. Am Router R B kommt ein Datenstrom A in Geschwindigkeit von 2 Mbps an, das nach R C geschickt werden soll. Weil der Pfad B C der kürzeste Pfad von R B nach R C ist, wird A auf B C geroutet. Gleichzeitig kommt ein anderes Paket B mit dem Zielort R D an R A an. Weil A B C D der kürzeste Weg von R A nach R D ist, möchte R A den Datenstrom B auch auf diesem Pfad routen, was einen Datenstau bei B C dann verursacht. Während des Datenstaus auf B C sind alle anderen Abschnitte jetzt aber FREI. Es wäre offensichtlich sinnvoll, dass man den Datenstrom B in dieser Situation auf einem anderen Pfad senden kann, z.b. auf A E F G D. 3

4 MPLS ist ein von der Internet Engineering Task Force (IETF) entwickelter und standardisierter Ansatz, der durch die Trennung der Datenströme von der Signalisierung eine Reihe von Diensten ermöglicht: a) Steuerung von Verkehrsflüssen (Traffic Engineering) b) Vereinfachtes und dadurch schnelles Weiterleiten von Layer 3 (IP) Paketen anhand fester Labels. c) Integration und Unterstützung etablierter Techniken wie ATM, Frame-Relay, PoS, etc. mit Hilfe der Unabhängigkeit von MPLS zwischen Layer 2 und 3. d) Kombination mit existierenden Routing-Protokollen wie OSPF, IS-IS, RIP etc. e) Einfacher Einsatz neuer Routing-Protokolle ohne Beeinflussung des Datenflusses. f) Einführung von QoS in IP-Netzen. Jedes Datenpaket aus nicht-mpls-netzen wird beim Eingang in eine MPLS-Domäne einer bestimmten Klasse anhand bestimmter Kriterien zugeordnet und es wird entsprechend ein geeignetes Label zugeteilt. Danach wird das Datenpaket nur mit Hilfe des Labels in der MPLS-Domäne weitergeleitet, ohne dass nochmals der Paketinhalt gelesen wird. Beim Ausgang der MPLS-Domäne wird das Label von dem Datenpaket entfernt und das Paket weiter in herkömmlichem Format transportiert. Weil der Inhalt eines Datenpakets nur einmal gelesen wird und innerhalb einer MPLS-Domäne nur noch das Label zur Entscheidung der Weiterleitung dient, ist schnelles Weiterleiten von Datenpaketen und einfacher Einsatz von neuen Routing-Algorithmen bzw. Kombination mit verschiedenen Routing- Protokollen möglich. MPLS bietet auch die Unterstützung von skalierbaren und verwaltbaren QoS-Anwendungen und somit lässt sich jeder Anwendung eine differenzierte Dienstgüte zuordnen. Die MPLS-Technologie wird bereits seit über zwei Jahren von Serviceprovidern und Großunternehmen eingesetzt. Mehrere der weltweit größten Weitverkehrsnetze nutzen dieses neue Verfahren. Eine andere Anwendung mit MPLS ist die neueste VPN-Lösung. MPLS-VPNs bieten im Vergleich zu traditionellen IP-VPNs eine bedeutend vereinfachte Dienstimplementierung. Darüber hinaus können MPLS-VPNs mit zunehmender Anzahl von Routern und Kunden problemlos skaliert werden. 1.2 Wichtige Begriffe Label Switching Routers (LSRs) und Label Edge Routers (LERs) bilden die Hauptkomponenten in einem auf MPLS basierenden Netz. Die LSRs werden im zentralen Bereich eingesetzt, während die LERs die Grenze des MPLS-Netzes bilden Label Switching Router (LSR) Ein Label Switching Router ermöglicht das schnelle Durchschalten von IP-Paketen anhand von festen Labels. Die Funktionsweise des Weiterleitens (Forwarding) von Paketen ist der- 4

5 jenigen von ATM oder Frame-Relay-Switches ziemlich ähnlich. Die Pakete werden beim Eintreffen am LSR auf deren Label untersucht und entsprechend der Forwarding Table mit dem neuen, für den nächsten Abschnitt gültigen Label an den nächsten Router weitergereicht. Das Label wird pro Leitungsabschnitt durch ein Label Distribution Protocol von LSR zu LSR, von LER zu LSR oder von LSR zu LER gegenseitig abgestimmt Label Edge Router (LER) Die LERs werden an der Schnittstelle eines herkömmlichen IP-Netzes zu einem MPLS- Netz, also an den Grenzen einer MPLS-Domäne, eingesetzt. Die Router unterstützen sowohl Schnittstellen der xdsl als auch der WAN- bzw. Backbone-Schnittstellen. Die LERs bilden die Endpunkte eines Übertragungskanals innerhalb des MPLS-Netzes. Die wichtigsten Aufgaben der LERs sind die Zuweisung und Entfernung von Labels. Sie bestimmen verschiedene Service-Aspekte für jedes eingehende Paket anhand mehrerer Kriterien, z.b. dessen Inhalt, dessen Zielort usw., und ordnen das Paket einer Übertragungsklasse und dem entsprechenden Label zu. Das Label wird dann beim Austrenen aus der MPLS-Domäne wieder vom LER entfernt. Anschließend wird das Paket im ursprünglichen Format weiter transportiert Forwarding Equivalence Class (FEC) Die Forwarding Equivalence Class repräsentiert eine logische Zuordnung von Paketen, welche alle nach den selben Übertragungskriterien übermittelt werden. Zu diesen Übertragungskriterien zählen alle Merkmale eines Pakets, z.b. die Quell- und Zieladresse, die erwünschte Service-Klasse, die Transport-Protokolle des Pakets (TCP oder UDP) usw.. Insbesondere können Pakete auch unterschiedlichen FECs zugeordnet werden, wenn ihre Quell- und Zieladressen gleich sind. Dies ist ein bedeutender Unterschied zu herkömmlichen IP-Netzen, da in IP-Netzen alle Pakete mit derselben Quell- und Zieladresse auf dem gleichen Weg durch das Netz gleichartig behandelt werden, was sehr häufig zum Datenstau führt. Eine Forwarding Equivalence Class wäre beispielsweise eine Menge von Paketen, bei welchen unterschiedliche Quell-Ethernet-Adressen mit einem speziellen IP-Adressenpräfix zusammen passen oder bei welchen die Zieladressen auf ein Adressenpräfix passen und zusätzlich die Type-of-Service-Felder denselben Wert enthalten. Eine andere Bedeutung der FEC ist, dass die Bestimmung einer FEC bzw. die Zuweisung von einem Label zu einer FEC bei der MPLS-Technik im Gegensatz zum konventionellen IP-Routing nur gerade einmal, nämlich am Zugang zum MPLS-Netz am Label Edge Router (LER) geschieht, wodurch sich das Weiterleiten innerhalb der MPLS-Domäne sehr schnell durchführen lässt Label Switched Path (LSP) Ein Label Switched Path ist ein physikalischer Übertragungskanal durch eine MPLS-Domäne, der von einer Folge von Labels eindeutig festgelegt wird. Für eine FEC wird zwischen je 5

6 zwei Routern auf dem Übertragungskanal ein Label mit Hilfe von geeigneten Signalisierungsprotokollen vereinbart, egal ob die beiden LSR oder ein LER und ein LSR sind. Beide Router halten in ihren Tabellen denselben Labelwert, welcher auf dem Link zwischen den beiden Anschlussports einen eindeutig virtuellen Pfadabschnitt identifiziert. Der sendende Router kennzeichnet somit alle Pakete zu einer spezifischen FEC gehörend mit demselben Label und schickt diese auf das Ausgangsport, während der empfangende Router am Eingangsport alle Pakete mit demselben Labelwert zur spezifischen FEC identifiziert und entsprechend seiner Tabelle weiter zum Ziel schickt. Die Verkettung der Labels und die damit verknüften virtuellen Pfadabschnitte bilden den Label Switched Path (LSP). Jeder so entstandene LSP ist unidirektional, weshalb eine beidseitige Kommunikation zwischen zwei Rechnern zwei LSPs braucht, die physikalisch ganz verschieden sein können, je nachdem, wie das Netzwerk belastet ist. Der LSP erfährt durch die Router die unterschiedlichen Durchlaufzeiten und Paketverluste usw. Die Gesamtheit der Übertragungscharakteristiken, wie Bitrate, Verzögerung, Verzögerungsvariation, Paketverlust usw. entscheidet über die Möglichkeit, ob den verschiedenen Anwendungen das nötige Übertragungsprofil zur Verfügung gestellt werden kann und somit lässt sich Quality of Service in IP-Netzen einführen. Eine der größten Vorteile von MPLS ist Explicit Routed LSP (ER-LSP), nämlich ein nach bestimmten Kriterien gesteuerter Pfad. Dazu wird durch ein geeignetes Routingprotokoll eine Liste von Loopback-Adressen von Routern, welche die Datenpakete durchlaufen sollen, ermittelt. Die Ermittlung des Pfades kann z.b. aufgrund eines erweiterten Shortest Path First Algorithmus, dem Constraint Shortest Path First Algorithmus (CSPF), welcher in der bisherigen einfachen Form in OSPF oder IS-IS Verwendung findet, erfolgen. Die Erweiterung besteht darin, dass neue Attribute der Leitung oder der Router, welche zur Erbringung von QoS notwendig sind, mitberücksichtigt werden. Die Liste der IP-Adressen wird bei der Anfrage von Labels mit entsprechender Signalisierungsnachricht, z.b. der RSVP-TE Path Message, mit auf den Weg geschickt. Jeder Router extrahiert daraus seinen nächsten Peer und schickt die resultierende Labelanfrage nach dem spezifizierten Pfad durch das Netz. 1.3 Paketfluß von MPLS In Abbildung 1-1 wird ein Paketfluss in einer MPLS-Domäne repräsentiert. Die dicken Linien bezeichnen den Übertragungskanal für ein IP-Paket, das bei R A ankommt und bei R D die MPLS-Domäne verlässt. Der LER R A stellt bei der Ankunft des IP-Pakets mit gewissen Kriterien fest, dass das IP-Paket zu der Forwarding Equivalence Class F EC 1 gehört. Danach schlägt R A in seiner internen Tabelle nach und sucht den der F EC 1 entsprechenden Eintrag aus, der das Ausgangslabel 8 und den nächsten Host R E speichert. Anschließend wird das Paket mit dem Label 8 beschriftet und dann an R E geschickt. R E bekommt das aus R A gesendete MPLS-Paket, extrahiert das Label 8 aus dem Paket und sucht das entsprechende Ausgangslabel 22 aus. Danach wird das Label 8 durch das neue Label 22 ersetzt. Während die Operation mit den Labels bei LER PUSH genannt ist, heißt dieser Vorgang in LSR SWAP. Analog zu R A schickt R E das modifizierte MPLS-Paket an R F dann weiter. 6

7 Bei R G wird das Label in derselben Weise geswapped und schließlich an R D weitergereicht. Der LER R D empfängt das Paket aus R G und führt die POP Operation aus, d.h. das Label 6 wird aus dem Paket entfernt. Schließlich dann routet er das ursprüngliche IP-Paket weiter. Abbildung 1-1: MPLS Packet Flow In diesem Kapitel wurden die wesentlichen Grundbegriffe im Zusammenhang mit MPLS erklärt und auch ein vereinfachtes Routingszenerio skizziert. In 1.3 wird aber einfach angenommen, dass die Tabellen bei den jeweiligen Routern schon existieren. Die Frage ist jetzt, wie solche Tabellen eigentlich entstehen. 7

8 2 RSVP-TE 2.1 Eerweiterung zu RSVP für LSP Die Erzeugung von Labels kann in einem MPLS-Netz vereinfacht auch als Trigger zwischen LSRs/LERs betrachtet werden, um Labels auszutauschen. Da die Labels nur lokale Gültigkeit zwischen zwei LSR/LER haben, stellt MPLS Mechanismen zur Verfügung, welche die Labels gegenseitig zwischen den Routern aushandeln. Wie erwähnt sind die Labels mit Forwarding Equivalence Classes (FECs) verbunden, welche wiederum einen Übertragungskanal mit unterschiedlichen Übertragungseigenschaften repräsentiert. Die Anbindung von Labels an eine FEC wird nach dem MPLS-Standard als Label Binding bezeichnet. Eine der aufwändigsten Funktionen bei MPLS ist die Label-Verteilung, nämlich die Label- Vergabe und die Label-Verbreitung. Die Verteilung der Labels erfolgt immer zwischen den LSRs mit einer Anfrage- und Antwort-Sequenz. Eine der von der MPLS-Architektur unterstützten Möglichkeiten der Label-Verteilung ist das erweiterte Resource ReSerVation Protocol for Traffic Engineering (RSVP-TE). RSVP- TE erweitert die Reservierung der Ressourcen und die Beeinflussung der Datenströme mit der Möglichkeit der Labelzuordnung. Mit anderen Objekten von RSVP-TE können auch Traffic Parameter zwischen LSR/LER ausgetauscht werden. Darüber hinaus bietet RSVP- TE noch die Möglichkeit von Pfadumleitung und Wiederherstellung. 2.2 Operationen von LSP-Tunnels Wie bei anderen alternativen Signalisierungsprotokollen, z.b. CR-LDP, wird als erstes ein Pfad mittels eines Routing-Algorithmus, z.b. Constraint Shortest Path First (CSPF), durch das Netz berechnet. CSPF kann dabei auch weitere Verbidungscharakteristiken berücksichtigen, z.b. Bitrate oder Delay. Das Ergebnis dieser Berechung ist eine Tabelle mit Loopback- oder Interface-IP-Adressen der im Pfad liegenden Router. Das Vorgehen außer der Berücksichtigung neuer Verbindungscharakteristiken wird im normalen RSVP bereits definiert und entspricht einer normalen RSVP-Prozedur. Danach wird eine RSVP PATH Message von dem Eingangs-LER erzeugt und an den nächsten LSR geschickt. Die Message wird mit einem neuen Objekt ergänzt, dem LABEL REQUEST-Objekt, und an die nächste im Explicite ROUTE-Object definierte IP-Adresse geschickt. Dieser Vorgang wiederholt sich bis zum am Zielhost nächstliegenden LER, also dem Ausgangs-LER. Dieser Ausgangs-LER leitet den dritten Schritt, die Reservierung der Ressourcen ein. Mit einer RESV Message wird die Reservierung der Ressourcen initiiert. Der Ausgangs-LER analysiert die Meldung, reserviert die Ressourcen wie Bitrate, Buffer, etc., ergänzt die Meldung mit einem LABEL-Object, das die angefragte FEC und das zugewiesene Label enthält und schaltet den LSP. Falls die Meldung den Eingangs-LER erreicht, wurde der LSP zwischen 8

9 den beiden LER aufgebaut. Ansonsten werden ResvErr Messages in Richtung Empfänger geschickt. 2.3 Nachrichten im RSVP-TE Wie bei anderen Signalisierungsprotokollen arbeitet RSVP-TE mit Nachrichten und Prozeduren. Die zwei wichtigsten Nachrichten in RSVP-TE sind PATH und RESV. Die PATH Message ist ein Explorer in der MPLS-Domäne, während die RESV Message die Rolle Pfadrecorder spielt. In RSVP-TE wird nur das Ordered Control unterstützt. Beim Ordered Control wird die Labelvergabe nur von dem Ausgang-LER eines LSPs initiiert und kanonisch rückgängig in Richtung Eingang-LER fortgesetzt PATH-Message Eine PATH Message fordert jeweils den nächsten LSR auf dem aufzubauenden Pfad auf, ein Label zu vergeben. Die Labelvergabe erfolgt erst sobald der nächste LSR ein Label von seinem Nachfolger erhalten hat. Falls eine PATH Message nicht verstanden werden kann, wird statt einer RESV Message eine PathErr Message zurückgeliefert. Eine PATH Message hat die folgende Struktur: <PATH Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP HOP> <TIME VALUES> [ <EXPLICIT ROUTE>] <LABEL REQUEST> [ <SESSION ATTRIBUTE> ] [ <POLICY DATA>... ] <sender descriptor> <sender descriptor> ::= <SENDER TEMPLATE> <SENDER TSPEC> [ <ADSPEC> ] [ <RECORD ROUTE> ] Die Bedeutung einzelner Objekte wird im nächsten Abschnitt erklärt RESV-Message Auf Anforderung der Labelvergabe in einer PATH Message wird eine RESV Message vom LSR/LER erzeugt und in die Gegenrichtung der PATH Message gesendet. Die Hauptaufgabe einer RESV Message besteht darin, die Informationen über den Erfolg des Pfadaufbaus dem vorherigen Router zu übermitteln und für jede Verbindungsstrecke ein lokal gültiges Label zu vereinbaren. Falls eine RESV Message nicht zu verstehen ist, wird ein ResvErr entsprechend initiiert. Allgemein wird eine RESV Message so aufgebaut: <RESV Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP HOP> <TIME VALUES> [ <RESV CONFIRM> ] 9

10 [ <POLICY DATA>... ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <FF flow descriptor list> <SE flow descriptor> <FF descriptor list> ::= <FLOWSPEC> <FILTER SPEC> <LABEL> [ <RECORD ROUTE> ] <FF flow descriptor list> <FF flow descriptor> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER SPEC> ] <LABEL> [ <RECORD ROUTE> ] <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list> <SE filter spec list> ::= <SE filter spec> <SE filter spec list> <SE filter spec> <SE filter spec> ::= <FILTER SPEC> <LABEL> [ <RECORD ROUTE> ] 2.4 Wichtige Objekte im RSVP-TE a). LABEL REQUEST Das LABEL REQUEST-Objekt wird in der PATH Message benutzt, um den Aufbau eines LSP anzudeuten. Es fordert den in Richtung Zieladresse folgenden LSR an, ein Label zur spezifischen FEC zuzuordnen und in die entsprechende RESV Message einzufügen. Das Objekt enthält auch die Informationen zu dem gewünschten Schicht-3-Protokoll, das beim LSP eingesetzt werden soll; somit können auch andere Transportprotokolle als das Internet Protocol für den LSP benutzt werden. b). LABEL Eine RESV Message kann ein LABEL-Objekt enthalten, das dem LABEL REQUEST- Objekt in der PATH Message entspricht. Ein Label wird zur eindeutigen Bezeichnung einer Verbindungsstrecke in der MPLS-Domäne benutzt. Es unterscheidet sich nach dem Zweck in zwei Sorten: Ausgangslabel und Eingangslabel. Ein Ausgangslabel zusammen mit der Ausgangsschnittstelle identifiziert den nächsten Hop, also die nächste Verbindungsstrecke. Im Vergleich dazu identifiziert ein Eingangslabel allein schon den vorhergehenden Router. c). EXPLICIT ROUTE (ERO) Das EXPLICIT ROUTE-Objekt ist eines der wichtigsten Objekte in RSVP-TE. Mit dem EXPLICIT ROUTE-Objekt kann ein explizit angegebener Pfad aufgebaut werden. Eine explizite Route ist beschrieben durch eine Liste von Gruppen von Knoten entlang des Pfades. 10

11 Eine solche Gruppe kann eine oder mehrere Knoten enthalten, über die ein Paket geroutet werden muss. Zum Beispiel: erkennt der Sender, dass es einen gemäß Bitrate zur Übertragung von Daten geeigneten Verbindungskanal gibt, kann er in die PATH Message das EXPLICIT ROUTE-Objekt einfügen, das die Liste von Knoten in diesem Kanal enthält, und die Daten über diesen Pfad transportieren. d). SESSION Das SESSION Objekt dient zur Identifizierung von logischen Tunnels. Wie erwähnt, bietet ein Label eine lokale Identifizierung einer Verbindungsstrecke in der MPLS-Domäne. Ein LSP bzw. ein logischer Tunnel kann zu jedem Zeitpunkt als Sequenz von Labels betrachtet werden. Weil Labels immer dynamisch zwischen je zwei LSR/LER vereinbart werden, hat eine Sequenz von Labels auch nur zeitliche Gültigkeit. Deshalb ist die Identifizierung eines LSP und eines logischen Tunnels während einer Sitzung durch ein Label nicht möglich. Außerdem ist allein mit einem Label keine Manipulation eines LSP möglich. Eine solche Manipulation kann z.b. die Beantragung von mehr Bandbreite oder schnelles Umleiten sein. Mit dem SESSION-Objekt kann ein logischer Tunnel, welcher aus mehreren LSPs bestehen könnte, während einer Sitzung eindeutig bestimmt und für einen bestimmten Zweck mit Hilfe des Subobjekts EXTENDED TUNNEL ID im SESSION-Objekt reserviert werden. Darüber hinaus ist ein Backup eines LSP und das Mapping zwischen LSPs und logischen Tunnels, was ein bedeutender Bestandteil von Fast Reroute ist, wegen der Identifizierung von LSPs erst durchführbar. e). SENDER TEMPLATE Während das SESSION-Objekt eine Identifikation für logische Tunnels bietet, wird das SENDER TEMPLATE-Objekt zur Identifizierung von LSPs benutzt. Das Objekt enthält die Senderadresse und eine LSP ID und bietet zusätzliche Informationen über den LSP als Ergänzung zum SESSION-Objekt an. f). SESSION ATTRIBUTE Ein anderes wichtiges Objekt in RSVP-TE ist das SESSION ATTRIBUTE-Objekt, was die Informationen zu Traffic Engineering, u.a. die Priorität des Aufbaus bzw. Behalten von LSPs oder die Optionen zu Backup von LSPs enthält und eine mit ATM oder Frame Relay vergleichbare Qualitätssicherung (QoS) ermöglicht. 2.5 Paketfluß vom RSVP-TE Wie in diesem Kapitel skizziert wurde, analysiert der Eingangs-LER ein ankommendes IP- Paket und ordnet das Paket einer FEC zu. Danach erzeugt der Eingangs-LER eine PATH 11

12 Message mit einem LABEL REQUEST und schickt diese Nachricht an den nächsten Router. Der Eingangs-LER folgende Router empfängt die Nachricht und schickt sie weiter an den nächsten Router. Dieser Vorgang wiederholt sich bis zum Ausgangs-LER und falls kein Fehler dabei auftritt, wird ein LABEL vom Ausgangs-LER vergeben und eine RESV Message erzeugt. Der Ausgangs-LER schickt die RESV Message auf demselben Pfad, über den die PATH Message transportiert wurde, in Richtung Quelladresse. Der direkte Vorgänger des Ausgangs-LER liest die RESV Message, speichert das vom Ausgangs-LER vergebene Label in seiner internen Tabelle, wählt ein freies Label aus und ersetzt das alte Label in der RESV Message durch das neue; schließlich schickt der LSR die modifizierte RESV Message an seinen Vorgänger. In dieser kanonischen Weise wird ein LSP mit einer Sequenz von Labels aufgebaut. Abbildung 2-1: RSVP-TE Packet Flow Jetzt wird das Beispiel aus Kapitel 1 berachtet, um Schritt für Schritt zu erklären, wie die Tabellen in Abbildung 1-1 entstanden sind. Der Router R A möchte für die Forwarding Equivalence Class F 1 einen LSP nach R D aufbauen. Er erzeugt einen Next Hop Label Forwarding Entry (NHLFE) E 1, welcher aus Ausgangslabel, Nächster Router und Operation besteht, und speichert das Mapping von F 1 zu E 1 in seiner FEC-to-NHLFE map. Da R A der Initiator des LSP ist, setzt er den Wert PUSH in dem Feld Operation. Mit einem 12

13 Routing-Algorithmus bestimmt R A den nächsten Router R E und trägt ihn im Feld Nächster Router ein. Anschließend erzeugt R A eine PATH Message mit einem LABEL REQUEST- Objekt und sendet die PATH Message an R E. R E erzeugt für den aufzubauenden LSP einen NHLFE E 2 mit der SWAP-Operation und R F als nächstem Router. Statt mit der FEC F 1 bildet E 2 mit einem Eingangslabel NULL ein Incoming Label Map (ILM) Mapping, und das Mapping wird lokal bei R E gespeichert. In der gleichen Art und Weise entstehen auch die NHLFE E 3 und E 4 sowie die ILMs bei R F und R G. Die letzte PATH Message in diesem Pfadaufbau wird von R G nach R D geschickt. Falls alles bis hier nicht scheitert, erzeugt R D einen NHLFE E 5. Weil R D der Endpunkt des aufzubauenden LSPs ist, muss er später von den auf dem LSP übertragenen Datenpaketen alle MPLS-relevanten Objekte entfernen und die Datenpakete im herkömmlichen Routingkonzept weiterrouten. Deswegen heißt diese Operation POP. Es ist hier auch klar, dass das Feld Nächster Router und das Feld Ausgangslabel mit nichts belegt werden, weil es keinen weiteren MPLS-Router auf dem LSP gibt. R D wählt dann ein freies Label 6 aus und speichert es mit E 5 als Eintrag in seiner ILM. Danach initiiert R D die Labelvergabe, indem er eine RESV Message mit dem Label 6 erzeugt und an seinen Vorgänger R G sendet. R G extrahiert die RESV Message von R D und setzt das Ausgangslabel in E 4 auf 6. Anschließend wählt R G ein freies Label 17 aus und setzt das E 4 entsprechende Eingangslabel auf 17. R G modifiziert dann noch die RESV Message von R D, indem er das Label 6 durch 17 ersetzt, und schickt die RESV Message an R F. In der gleichen Art und Weise werden die zwei ILM-Einträge bei R F und R E vervollständigt. Letztendlich bekommt R A die RESV Message von R E, setzt das Ausgangslabel in E 1 auf 8, womit wird der Pfadaufbau erfolgreich abgeschlossen ist. In diesem Kapitel wurde der Pfadaufbau mittels RSVP-TE auch exemplarisch erläutert. Bisher wurde angenommen, dass ein LSP nach dem Aufbau immer funktioniert, bis ein neuer LSP wegen geänderter Anforderungen eingerichtet werden muss. In der Tat ist aber kein Router 100 % intakt. Deshalb ist es sinnvoll, die LSPs so zu schützen, dass ein zufälliger Routerausfall auf dem LSP den Pakettransport nicht abbricht. Schnelles Umleiten (Fast Reroute) handelt von solchen Maßnahmen und wird im nächsten Kapitel behandelt. 13

14 3 LSP-Sicherung mit Fast Reroute Eine der wichtigsten Kriterien für Netzwerke ist die dauerhafte Zuverlässigkeit. Bei vielen Anwendungen wird kontinuierliche Datenübertragung in dem Sinne gefordert, dass die Datenübertragung nicht länger als dutzend Millisekunden abgebrochen werden soll. D.h., ein Routerausfall soll zu keiner großen Übertragungsverzögerung oder sogar zum Übertragungsabbruch führen und die Daten sollen schnell auf einen anderen Pfad umgeleitet werden. Ein typisches Beispiel für solche Anwendungen ist Voice over IP. Für solche Applikationen wäre ein Sicherungs- und Umleitungsmechanismus sehr sinnvoll. 3.1 Local Repair Techniken Seit langer Zeit existieren zwei Methoden zur Sicherung von LSPs (in diesem Kapitel bezieht sich LSP nur auf explizit gerouteter LSP), das One-to-One Backup und das Facility Backup. Obwohl diese beiden Methoden in vielen Hardwaren implemtiert wurden, gibt es bisher noch kein standardisiertes Konzept, das die beiden enthält und einheitlich behandelt. Deshalb ist Kompatibilität zwischen den Hardwaren durchaus ein großes Problem geworden. Bevor das neueste Konzept Fast Reroute mit RSVP-TE eingeführt wird, werden zuerst die beiden Backup Methoden erläutert One-to-one Backup Bei dem One-to-one Backup Mechanismus wird zwischen dem Vorgänger eines zu schützenden Knotens und einem seiner Nachfolger oder zwischen dem Anfangsrouter eines zu schützenden Links und einem flußabwärtigen Router ein alternativer LSP aufgebaut, falls es möglich ist. D.h. der Datenverkehr läuft durch den alternativen LSP statt durch den zu schützenden Knoten, falls er nicht intakt ist. Die folgende Abbildung skizziert das One-toone Backup Verfahren. Der vorhandene LSP L AEF GD von R A durch R E, R F und R G nach R D sollte geschützt werden. Dafür wird bei jedem Knoten auf dem LSP außer R D ein separater Backup-Pfad gesichert. Um die Verbindung zwischen R A und R E bzw. den Knoten R E zu schützen, sichert R A einen alternativen Pfad von R A durch R H und R I nach R F. Um die Verbindung zwischen R E und R F bzw. den Router R F zu schützen, sichert R E einen Prad von R E durch R I und R J nach R G. Der lokale Backuppfad beim R F ist analogerweise von R F durch R I, R J und R K nach R D. Der letzte Backupkanal für den LSP geht von R G nach R J und R K nach R D, welcher den Link von R G nach R D sichert. Angenommen, dass R H bis R K funktionieren, dann wird der LSP L AEF GD komplett gesichert, alle Daten durch L AEF GD werden problemlos schnell umgeleitet, falls irgend eine Verbindung oder ein Router auf dem L AEF GD ausfällt. Es ist klar, dass mindestens N 1 alternative LSP gebraucht werden, um ein LSP mit N Knoten zu sichern. Wie wir gesehen haben, werden bei den Backup-Pfaden einige Strecken wiederholt. Der Link von R I nach R J, von R J 14

15 durch R K nach R D tauchen jeweils zweimals in den Backup-LSPs auf. Abbildung 3-1: One-to-one Backup Facility Backup Wie wir gesehen haben, kann der One-to-one Backup Mechanismus jede potenziell ausfallende Verbindung auf einem LSP schützen. Nachteil dieser Methode ist, dass beim Backup eines LSP zu viele redundante LSP-Strecken erzeugt wurden, die zusammengefasst und eliminiert werden sollten. Die Idee von Facility Backup ist einfach die beste Ausnutzung einzelner LSP-Strecken. D.h. eine LSP-Strecke sollte möglichst viele LSP schützen, die durch diese Strecke umgeleitet werden können. Deshalb wird das Konzept auch Many-toone Backup genannt. Die folgende Abbildung zeigt ein Szenario, wo das Facility Backup eingesetzt wird. Die LSP-Strecke L EIJG ist ein sogenannter Bypass-Tunnel. L EIJG bietet einen alternativen Kanal für alle LSPs, die der Reihe nach durch R E und R G aber nicht durch R E R I R J R G laufen. Es ist klar, dass das Konzept jede Backup-Strecke gut ausnutzt. Der Nachteil dieses Konzepts gegenüber dem One-to-one Backup liegt drin, dass ein Bypass- Tunnel immer nur Teile eines LSP schützen kann. In diesem Beispiel wird durch L EIJG nur der Teil L EF G des LSP L AEF GD geschützt. Falls der Link AE oder GD nicht intakt ist, wird der Datenverkehr durch L AEF GD abgebrochen. Um ein LSP mit N Routern komplett 15

16 zu schützen, müssen auch mindestens N 1 Bypass-Tunnel aufgebaut werden. Das Ergebnis ist zwar ein bißchen überraschend und enttäuschend, weil die Anzahl der gebrauchten Bypass-Tunnel gleich der Anzahl der alternativen LSPs in dem One-to-one Konzept ist. Facility Backup hat aber den deutlichen Vorteil gegebüber One-to-One Backup, dass die N 1 Bypass-Tunnel nicht nur einen LSP schützen, sondern alle LSPs, die auf den N 1 Tunnel umgeleitet werden können. Abbildung 3-2: Facility Backup 3.2 Erweiterungen zu RSVP-TE für Fast Reroute Die Fast Reroute (FRR) Erweiterung zur RSVP-TE ist ein einheitliches Konzept zur Sicherung von Pfaden in MPLS-Domänen. Bevor diesem Konzept entstanden ist, haben viele Hardwarehersteller schon eigenständige Methoden zum Backup von LSPs entwickelt und in ihren Produkten eingesetzt. Davon werden das One-to-One und das Facility Backup am meistens benutzt. Die Hardwarehersteller versuchen immer, diese zwei Methoden einheitlich zusammenzufassen. Aber bisher gibt es noch keinen Standard, der eine einheitliche Implementation hätte und gleichzeitig die beiden Methode unterstützt. Die FRR Erweiterung zur RSVP-TE versucht eine einheitliche Signalisierung und Fehlerbehandlung mittels 16

17 RSVP-TE, so dass MPLS-Netzwerke sich untereinander gut verstehen und zusammenarbeiten können, egal ob das jeweilige Netzwerk gar keinen Sicherungsmechanismus hat, oder einen davon unterstützt, oder beide. Ein Datenpaket sollte umgeleitet werden, wenn auf dem LSP ein oder mehrere Router ausgefallen sind. Vielen Echtzeitanwendungen, wie z.b. Voice over IP (VoIP), fordern ein schnelles Umleiten innnerhalb dutzend Millisekunden. Um diese Anforderungen zu erfüllen, muss die Sicherung von Pfaden vor der Umlenkung durchgeführt werden, damit beim Umleiten keine Zeit für Pfad-Berechnung und -Aufbau in Anspruch genommen werden muss. Außerdem muss der Knoten für die Umlenkung im Sinne der Topologie so spät wie möglich gewählt werden, um redundante Umlenkungen zu vermeiden. In dem obigen Beispiel besteht der LSP aus fünf Routern R A, R E, R F, R G und R D. Falls nur der Router R G ausfällt, müssen die Datenpakete bei R F aber nicht bei R E umgeleitet werden. Der Grund für diese möglichst späte Umlenkung besteht drin, den LSP so wenig wie möglich zu verändern. Die FRR Erweiterung zu RSVP-TE erfüllt diese zwei Anforderungen und ermöglicht eine einfache Implementation zur Unterstützung der beiden Konzepte One-toone und Many-to-one Backup. Für diesen Zweck werden ein paar neue Objekte und einige neue Verhalten bei Behandlung von RSVP-TE Nachrichten definiert. Die zwei wichtigsten Komponenten in einem FRR-fähigen MPLS-Netzwerk sind der Point of local Repair (PLR) und der Merge Point (MP). Wie die Namen schon sagen, ist ein PLR ein Router, bei dem eine Kanalsicherung ausgeführt wird, während ein MP die Daten aus dem ordentlichen LSP und dem alternativen LSP manipuliert bzw. zusammenfasst. PLR und MP sind funktional unterschiedliche Begriffe, d.h. bei PLR und MP werden unterschiedliche Prozeduren ausgeführt und verschiedene Verhalten unterstützt. Ein Router kann als PLR oder als MP funktionieren oder gleichzeitig die beiden Rollen spielen. Falls ein Umleiten bei einem PLR erforderlich ist, leitet der PLR die Daten abweichend von dem originalen LSP auf dem alternativen LSP. Die Daten werden dann später bei dem MP analysiert, wiederherstellt und weitergeleitet. Durch die gut entworfenen Fehlernachrichten können alle MPLS-Router miteinander kommunizieren, egal, ob sie alle FRR-fähig sind FAST REROUTE-Objekt Das erste wichtige Objekt in FRR ist das FAST REROUTE-Objekt. Es wird benutzt zur Kontrolle des Backupkanals. Ein FAST REROUTE-Objekt wird jeweils beim Eingang- LER erzeugt und in die PATH-Message eingefügt, danach dürfen die LSRs auf dem einzurichtenden LSP es nicht mehr modifizieren. Das FAST REROUTE-Objekt spezifiziert die Aufbau- und Behaltenpriorität mit Hilfe der Felde Setup Priority und Holding Priority, die bevorzugte Backup Technik, die angeforderte Bandbreite und gibt die spezielle Anforderungen auf den Backup Pfad an. Die Setup Priority deutet die Priorität des Aufbaus eines Backup LSP an. Beim Aufbau eines neuen Backuppfades wird die Setup Priority mit der Setup Priority und Holding Priority anderer Pfade vergliechen. Die Session mit höherer Se- 17

18 tup Priority wird dann geschützt. Nachdem ein Backuppfad aufgebaut worden ist, spielt die Setup Priority keine Rollo mehr sondern die Holding Priority. Die von Sicherungskanälen belegten Netzwerkressourcen müssen nach Ende der Session oder bei Netzwerkressourcenmängeln wieder freigegeben werden. Falls die freien Netzwerkressourcen nicht ausreichend für alle Sicherungskanäle sind, muss es festgeslegt werden, welche Kanäle weiter behalten und welche freigegeben werden sollen. Die Holding Priority bietet ein Kriterium für diese Festlegung. Die Sicherungkanäle mit niedrigerer Holding Priority werden eher als die mit höherer Holding Priority gelöscht. Sie wird auch gelöscht, falls ein neuer Backuppfad mit höherer Setup Priority aufzubauen ist. Im FAST REROUTE-Objekt können noch andere Kriterien für den Backup-LSP bestimmt werden. Z.B. die Angabe der maximalen Anzahl der im Sicherungskanal enthaltenen Router, oder die Filter der Router, die umzugehen bzw. durchzulaufen sind. Mit einem Subobjekt im FAST REROUTE-Objekt kann ein LSR auch angeben, wieviel Bandbreite verlangt wird, was eine wichtige Rolle in Traffic Engineering spielt DETOUR-Objekt Ein anderes wichtiges Objekt in FRR ist das DETOUR-Objekt, welches nur im One-toone Backup zur Identifizierung von LSPs benutzt wird. Es wird von einem PLR in eine PATH-Message eingesetzt. Damit kann man bestimmen, welcher Router der Anfangspunkt eines Umweges ist und welcher Router nicht direkter Nachfolger des Anfangsrouters sein darf. Das Objekt spielt eine große Rolle für den MP, wenn er die aus verschiedenen Pfaden ankommenden Pakete manipuliert Andere Objekte Das SESSION ATTRIBUTE-Objekt und die neuen Subobjekten im RECORD ROUTE- Objekt enthalten mehrere Optionen für die Sicherung von LSPs. Wie in Abschnitt 2.4 f) erwähnt wurde, können die Informationen zur LSP-Sicherung im SESSION ATTRIBUTE- Objekt eingetragen werden. Durch Setzen von folgenden Werten in den Flags im SESSI- ON ATTRIBUTE-Objekt können die folgende Optionen bestimmt werden: a) Local protection desired, b) Label recording desired, c) SE Style desired, d) Bandwidth protection desired und e) Node protection desired. Die ersten drei Flags sind schon in RSVP-TE definiert und die letzten zwei sind neu in FRR hinzugekommen. Weitere Kriterien für die Backupkanäle können in den Flags im RECORD ROUTE-Objekt bestimmt werden. Zusätzlich zu zwei in RSVP-TE definierten Werten a) Local protection available und b) Local protection in use sind in FRR noch zwei neue Werte c) Bandwidth protection und d) Node protection definiert. Die Bedeutung bzw. die Nutzung einzelner Objekte werden später erklärt. Die folgende Tabelle zeigt die verfügbaren Flags in den drei oben genannten Objekten. 18

19 Objekt SESSION ATTRIBUTE RECORD ROUTE FAST REROUTE Flags Local protection desired Label record desired SE Style desired Bandwidth protection desired Node protection desired Local protection available Local protection in use Bandwidth protection Node protection One-to-one backup desired Facility backup desired Tabelle 3-1: Flags in SAO, RRO und FRO 3.3 Paketfluß vom Fast Reroute Um den Verlauf des FRR zu verstehen, müssen die Verhalten bei drei verschiedenen Klassen von LSRs in einer MPLS-Domäne genau analysiert werden. Für den Zweck FRR werden die LSRs auf einem LSP in drei Arten zugeteilt: Head-End LSR, Point of Local Repair und Merge Point. Head-End LSR ist der Anfangsrouter eines LSPs, welcher auch den Antrag auf Sicherungskanäle stellt. Point of Local Repair, kurz PLR, ist die Umlenkungsstelle. Merge Point ist der Router, der am Ende einer Umlenkung steht und die Datenpakete bzw. die Nachrichten aus dem LSP und dem Backupkanal zusammenpackt. Im folgenden werden die Verhalten bei diesen drei Klassen von LSRs besprochen. Head-end LSR Der Anfangsrouter eines LSP trifft die Entscheidung, ob ein Sicherungskanal für einen LSP überhaupt eingerichtet bzw. welche Backupmethode benutzt werden soll. Der Anfangsrouter muss immer die Flags Label recording desired und Local protection desired im SESSION ATTRIBUTE-Objekt setzen, falls ein Sicherungspfad erwünscht wird. Node protection desired und Bandwidth protection desired sollen auch gesetzt werden, falls die Knotensicherung und Bandbreitesicherung berücksichtigt werden muss. Um den Backuppfad besser zu kontrollieren, sollte der Anfangsrouter ein FAST REROUTE- Objekt in die PATH-Message einpacken, denn das FAST REROUTE-Objekt besagt zusätzlich zu dem SESSION ATTRIBUTE-Objekt, welche Backupmethode bevorzugt wird, wie lange der Backuppfad maximal sein darf und wie viel Bandbreite zur Verfügung gestellt werden muss. Ohne diese Informationen wird bei einem Point of Local Repair eins der beiden Sicherungskonzepte beliebig gewählt, welcher vielleicht nicht von dem Head-end LSR erwünscht wurde. Point of Local Repair Der Anfangsrouter eines Umwegs heißt Point of Local Repair (PLR). Wie der Name schon sagt, soll ein Point of Local Repair die lokale Sicherung 19

20 für einen LSP, durchführen. Zu den Hauptaufgaben eines PLR gehören die Initiierung des Backups eines LSP, Berechnung eines Backuppfades, die Durchführung der Pfadesicherung mit gewünschter Backup-Methode und die Verwaltung von originalen LSPs und deren Backupkanälen. Zur Verwaltung von LSPs zählen die Identifizierung von Backupkanälen, die Assoziation von Backupkanälen und deren originalen LSPs sowie die Zusammenfassung von Backupkanälen. Je nachdem, welches Backupkonzept bevorzugt wird, verhält ein PLR sich auch entsprechend unterschiedlich. Weil alle LSRs in einer FRR-fähigen MPLS-Domäne in der Lage sein müssen, LSPs zu sichern, müssen alle LSRs die Funktionalität eines PLR unterstützen. Grundlage Ein PLR muss als grundlegendes die Informationen zur Pfadsicherung verstehen und verarbeiten können. Solche Informationen werden mit den Flags im SES- SION ATTRIBUTE-, RECORD ROUTE- und FAST REROUTE-Objekt spezifiziert. Die Flags im SESSION ATTRIBUTE- und FAST REROUTE-Objekt sollen gesetzt werden, falls die entsprechenden Optionen erwünscht wurden. Im Vergleich dazu sind die Flags im RECORD ROUTE-Objekt nicht so selbsterklärend und relativ dynamisch. Ein PLR muss alle Flags im RECORD ROUTE-Objekt leeren, falls es noch keinen Sicherungspfad gibt. Ein PLR soll das Flag Local protection available setzen, falls ein Sicherungspfad zur Verfügung steht, oder leeren, falls ein vorhandener Sicherungspfad nicht mehr verfügbar wird. Bei einer Umlenkung von Datenpaketen muss ein PLR das Flag Local protection available setzen, um anzudeuten, dass die Datenpaketen gerade durch den Sicherungskanal übertragen werden. Falls der originale LSP wieder verfügbar wird und die Datenpaketen auf dem zu übertragen sind, muss das Flag wieder geleert werden. Ein PLR soll auch das Flag Node protection setzen, falls der direkte Nachfolger-LSR durch den Sicherungspfad geschützt wird, und das Flag leeren, falls es nicht der Fall ist. Die Manipulation mit dem Flag Node protection muss gemacht werden, wenn das Flag Node protection desired im SESSION ATTRIBUTE-Objekt gesetzt wird. Das Flag Bandwidth protection soll gesetzt werden, falls der Sicherungspfad die Bandbreitegarantie gewährleistet, ansonsten soll es geleert werden. Dies ist zu machen, wenn das Flag Bandwidth protection desired im SES- SION ATTRIBUTE-Objekt gesetzt wird. Identifizierung von Backupkanälen Falls ein LSR Backupkanäle für einen LSP aufbauen soll, muss er in der Lager sein, die Backupkanäle eindeutig zu identifizieren und die Datenpakete richtig zu routen. Die Identifizierung von Backupkanälen erfolgt mit zwei unterschiedlichen Schemen, auf Sender-Template oder Path basierend. Beim auf Sender- Template basierenden Schema benutzt der PLR das SESSION-Objekt und das LSP ID Feld mit zusätzlich seiner IP-Adresse im Feld IPv4 tunnel sender address, um einen Backuppfad zu idenfizieren. Falls der PLR auch der LSP-Initiator ist, muss er eine andere beliebige IP-Adresse als seine eigene ins Feld IPv4 tunnel sender address einfügen. Beim auf Path basierenden Schema werden die PATH-Messages vom originalen LSP und vom Backuppfad durch das DETOUR-Objekt unterschieden. In diesem Schema bleiben das SESSION- 20

21 und das SENDER TEMPLATE-Objekt unverändert. Zu beachten ist, dass das Schema nur beim One-to-one Backup benutzt werden kann. Falls ein Downstream-LSR mehrere PATH- Messages empfängt, welche dasselben SESSION- und SENDER TEMPLATE-Objekt und denselben Next-Hop haben, muss er diese PATH-Messages untersuchen und zusammenfassen. Ansonsten werden die RESV-Messages nicht mehr unterscheidbar, ob sie für den originalen Pfad oder den Backuppfad gesendet wurden. Dieser Knoten wird als Merge Point bezeichnet. Merge point Wie im obigen Abschnitt erwähnt wurde, ist ein Merge Point ein Router, der mehrere PATH-Messages zusammenführt und die RESV-Messages verteilt. Topologisch ist ein Merge Point der Endrouter eines Umwegs. Nach dem Merge Point wird nur noch eine PATH-Message gesendet, im Vergleich zu der LSP-Strecke zwischen dem PLR und dem MP, wo mehrere PATH-Messages unterwegs sind. Eine PATH-Message wird als die zu sendende PATH-Message festgestellt, fass sie keinen Konflikt mit anderen PATH-Messages im Sinne der gelaufenden und zulanfenden Routers bzw. kein DETOUR-Objekt oder ein FAST REROUTE-Objekt hat. Näher darauf wird hier nicht eingegangen. andere LSRs Da jeder in einer FRR-fähigen MPLS-Domäne liegende LSR auf einem LSP stehen kann, ist er möglicherweise auch ein PLR oder ein MP. Aus diesem Grund müssen alle LSRs in einer FRR-fähigen MPLS-Domäne die Funktionalitäten von PLR und MP unterstützen. Dank dem guten Entwurf der FRR-Erweiterung beeinflusst ein nicht FRR-fähiger LSR nur die LSPs, die durch ihn laufen. Somit können die FRR-fähigen und die nicht FRR-fähigen LSRs gut zusammenarbeiten One-to-one Backup In dem One-to-one Backup Konzept wird bei jedem potenziellen PLR ein Backuppfad erzeugt und dem jeweiligen originalen LSP zugeordnet. Falls ein PLR ein One-to-one Backup bieten soll, muss er eine PATH-Message für den Umweg-LSP erzeugen und den Backuppfad initiieren. Der PLR muss zuerst die Backuproute berechnen. Danach entscheidet er sich, welches der zwei Idenfizierungsschemen, nämlich das auf Sender-Template oder das auf Path basierende Schema benutzt wird. Er muss das Feld IPv4 (or IPv6) tunnel sender address verändern, falls das auf Sender-Template basierende Schema benutzt wird, oder ein DETOUR-Objekt in die PATH-Message einfügen, falls das auf Path basierende Schema benutzt wird. Beim auf Sender-Template basierenden Schema kann er seine IP in das Feld einfügen, falls er nicht der Initiator des originalen LSP ist, ansonsten muss er beliebig eine andere IP-Adresse als seine eigene auswählen und das Feld überschreiben. Hier könnte der PLR auch ein DETOUR-Objekt in die PATH-Message hinzufügen. Der PLR muss noch die drei Flags im SESSION ATTRIBUTE-Objekt Local protection desired, Bandwidth protection desired und Node protection desired leeren, weil diese Informationen nur für die Einrichtung des Backuppfades nötig sind. Außerdem kann er das Flag Label recording desired modifizieren, falls dies nötig ist. Der PLR muss die Felder Include-any, Exclude-any 21

22 und Include-all in das entsprechende SESSION ATTRIBUTE-Objekt kopieren, falls die PATH-Message des originalen LSP ein FAST REROUTE-Objekt enthält und das EXPLI- CIT ROUTE-Objekt nicht strikt ist. Der PLR muss noch das FAST REROUTE-Objekt von der PATH-Message des Backuppfades entfernen. Falls die PATH-Message des originalen LSP ein SENDER TSPEC-Objekt enthält, muss der PLR die Informationen über Bandbreite ins SENDER TSPEC-Objekt einschließen. Falls der Inhalt des FAST REROUTE- Objekts in der PATH-Message des originalen LSP oder der Next-Hop des originalen LSP geändert wurde, muss der PLR einen neuen Umweg initiieren. Sobald ein Umwegpfad schon erzeugt wurde, braucht er den Umweg nicht regelmäßig neu berechnen. Um die Route zwischen PLR und MP zu beschreiben, muss der PLR ein EXPLICIT ROUTE-Objekt mit den Subobjekten erzeugen, die der Route zwischen PLR und MP entsprechen. Bei Behandlung der Nachrichten von Downstream-LSRs muss ein PLR darauf achten, dass die Nachrichten aus dem originalen LSP und dem Umweg-LSP verschieden behandelt werden müssen. Die RESV-, ResvTear- und PathErr-Message von dem Umweg-LSP braucht er nicht weiterschicken, analog braucht er auch keine ResvErr- oder ResvConf- Message des origenalen LSP auf dem Umweg-LSP weiterleiten. Als Ausnahme gilt hier die PathTear-Message. Eine PathTear-Message wird geschickt, wenn eine Session beendet wird. In diesem Fall muss der PLR die PathTear-Message und die relevanten Nachrichten sowohl für den originalen LSP als auch für den Umweg-LSP behandeln und die beiden LSPs löschen. Eine andere Situation ist, dass der originale LSP nicht mehr funktioniert und eine ResvTear-Message von Downstream an PLR gesendet wird. In diesem Fall muss der PLR den Umweg-LSP einsetzen und alle Datenpakete auf dem Umweg-LSP umleiten. Deshalb braucht der PLR die ResvTear-Message nicht weiterzuleiten. Bei dem auf Sender-Template basierenden Identifizierungsschema kann ein MP mehrere PATH-Messages von den Backupkanälen und dem originalen LSP bekommen. Er erkennt den originalen LSP, indem er nach dem FAST REROUTE-Objekt sucht oder das Flag Local protection desired liest. Die PATH-Messages von originalen LSPs enthalten entweder ein FAST REROUTE-Objekt oder ein gesetztes Flag Local protection desired. Die PATH- Messages können nur zusammengeführt werden, falls die EROs vom MP bis Zielrouter gleich sind. Nach der Zusammenführung der PATH-Messages kann nur die PATH-Message des originalen LSP weitergesendet werden. Dieser Vorgang ordnet die Backupkanäle dem originalen LSP zu. Bei dem auf Path basierenden Identifizierungsschema kann ein MP mehrere PATH-Messages mit demselben SESSION- und SENDER TEMPLATE-Objekt bekommen. Der MP muss in dieser Situation das sogenannte Path State Merging durchführen, d.h. eine PATH-Message muss mit einem bestimmten Verfahren ausgewählt und weitergereicht werden. Das Auswahlverfahren wird hier nicht näher besprochen. Außer die Nachrichten an Zielrouter weiterzuleiten, muss ein MP auch die Nachrichten 22

23 in umgekehrter Richtung behandeln. Im Fall einer pfadrelevanten Message, z.b. RESV- Message oder PathErr-Message, muss ein MP sie auf dem richtigen Pfad transportieren. Im Fall einer sessionrelevanten Message, z.b. ResvTear-Message, muss der MP alle Pfade benachrichtigen. Der Grund dafür ist, dass ein LSP und seine Backupkanäle zum selben Zweck dienen und die Verfügbarkeit eines Pfades dieser Pfadgruppe die Verfügbarkeit eines anderen nicht beeinflussen darf. In der Abbildung 3-3 wird das One-to-one Backup bzw. die Umleitung der Datenpakete skizziert. Der Router R A ist hier der Head-end des LSPs und hat sich entschieden, den LSP L AEF GD zu schützen. Dafür setzt R A die Flags Local protection desired und Label recording desired und die anderen optionalen Flags im SESSION ATTRIBUTE-Objekt. Um anzudeuten, dass das One-to-one Backup bevorzugt wird, erzeugt R A ein FAST REROUTE- Objekt und setzt dessen Flag One-to-one backup desired. Danach initiiert R A den Pfadaufbau mit der RSVP-TE-Prozedur, die wir in Kapitel 2 besprochen haben. In diesem Beispiel wird der Router R E als PLR betrachtet. R E kann entweder gleichzeitig beim Pfadaufbau von L AEF GD oder erst nach der Etablierung von L AEF GD einen Backupkanal einrichten. Angenommen, dass R E einen Backupkanal initiiert, nachdem L AEF GD entstanden ist. Um den Backuppfad zu identifizieren, benutzt R E das auf Sender-Template basierende Schema. Als erstes erzeugt er eine Kopie der PATH-Message des originalen LSP für den Backup- Pfad. In der neuen PATH-Message muss er noch ein paar Änderungen vornehmen, damit der Backuppfad richtig aufgebaut und behandelt werden kann. Er schreibt seine eigene IP- Adresse in das Feld IPv4 tunnel sender address des SESSION-Objekts. Anhand des RRO- Objekts in der RESV-Message oder des ERO-Objekts in der PATH-Message des originalen LSP in dem Path State Block berechnet er einen Pfad, der den Abschnitt E F vermeidet, und zwar die Route E I J G D, und ersetzt das originale ERO-Objekt durch das neue mit der neu berechneten Route. Da diese PATH-Message für den Backuppfad gedacht ist, muss R E noch die Flags Local protection desired, Bandwidth protection desired und Node protection desired leeren. Weil der Backuppfad demselben Zweck wie dem des originalen LSP dient, muss R E auch die Anforderungen an den originalen LSP jetzt auf den Backuppfad anfordern. Dies kann z.b. die umzugehenden Knoten, die erwünschte Bandbreite usw. sein. Was zu beachten ist, dass die geforderte Bandbreite wird bei der Etablierung des Backuppfades nur berücksichtigt aber nicht reserviert. Letztlich muss R E noch das FRR-Objekt entfernen, falls es in der PATH-Message existiert. Nach der Modifizierung der PATH-Message sendet R E sie an R D. Weil der Abschnitt G D gleichzeitig auf dem originalen LSP und dem Backup-LSP liegt, spielt der R G die Rolle eines Merge Point und vergibt das Label 17 für die beiden Pfade, und zwar die Abschnitte F G und J G. Die Labels für die Verbindungsstrecken IJ und EI werden analog zu dem Beispiel im Kapitel 2 vergeben und somit ist der Backuppfad entstanden. 23