<reference title="RSVP-TE: Extensions to RSVP for LSP Tunnels" url="https://www.rfc-editor.org/rfc/rfc3209.txt" rfc="3209" lang="de" translators="["AI"]" />
RFC 3209
RSVP-Erweiterungen für LSP-Tunnel (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Diese Übersetzung basiert auf dem englischen Originaltext https://www.rfc-editor.org/rfc/rfc3209.txt und wurde absatzweise übersetzt, wobei alle Abschnitte, Bit-Diagramme, Codeblöcke und Tabellen beibehalten wurden.
Metadaten des englischen Originaltexts
- Dokumenttitel: RSVP-TE: Extensions to RSVP for LSP Tunnels
- Kategorie: Standards Track
- Status: Proposed Standard
- Autoren: D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow
- Datum: Dezember 2001
Network Working Group
| Network Working Group | D. Awduche |
| Request for Comments (RFC): 3209 | Movaz Networks |
| Kategorie: Standards Track | L. Berger |
| MPLS Network Working Group | |
| D. Gan | |
| Juniper Networks, Inc. | |
| T. Li | |
| Procket Networks | |
| V. Srinivasan | |
| G. Swallow | |
| Cisco Systems, Inc. | |
| Dezember 2001 |
RSVP-Erweiterungen für LSP-Tunnel (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Status dieses Memorandums
Dieses Memorandum definiert ein Internet-Standard-Track-Protokoll für die Internet-Gemeinschaft. Die Verteilung dieses Memorandums unterliegt keinen Einschränkungen.
Urheberrechtshinweis
Copyright (C) The Internet Society (2001). Alle Rechte vorbehalten.
Dieses Dokument und seine Übersetzungen können kopiert und anderen Personen zur Verfügung gestellt werden und gelten beim Kopieren, Darstellen, Zitieren oder anderweitigen Verwenden als gebührenfrei, sofern alle oben genannten Kopien und abgeleiteten Werke diesen Urheberrechtshinweis sowie die in diesem Dokument genannten Rechte, Einschränkungen und Haftungsausschlüsse enthalten. Das Dokument selbst darf jedoch in keiner Weise verändert werden, beispielsweise durch Entfernen des Urheberrechtshinweises oder der Verweise auf die Internet Society oder andere Internet-Organisationen, außer wenn dies für die Zwecke des Internet-Standardisierungsprozesses erforderlich ist, in welchem Fall die in den Internet-Standards definierten Urheberrechtsverfahren befolgt werden müssen, oder wenn dies erforderlich ist, um es in eine andere Sprache als Englisch zu übersetzen.
Die oben gewährten eingeschränkten Genehmigungen sind dauerhaft und werden von der Internet Society oder ihren Rechtsnachfolgern oder Abtretungsempfängern nicht widerrufen.
Dieses Dokument und die darin enthaltenen Informationen werden „WIE BESEHEN“ (AS IS) zur Verfügung gestellt, und DIE INTERNET SOCIETY UND DIE INTERNET ENGINEERING TASK FORCE LEHNEN ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GARANTIEN AB, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF, JEGLICHE GEWÄHRLEISTUNG DASS DIE NUTZUNG DER HIERIN ENTHALTENEN INFORMATIONEN KEINE RECHTE VERLETZT ODER STILLSCHWEIGENDE GARANTIEN DER MARKTGÄNGIGKEIT ODER DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.
Danksagung
Die Finanzierung der RFC-Editor-Funktion wird derzeit von der Internet Society bereitgestellt.
Zusammenfassung
Dieses Dokument beschreibt Erweiterungen des „Resource Reservation Protocol“ (RSVP) (Version 1), um in IP-Netzwerken und Netzwerken mit Multiprotocol Label Switching (MPLS) Label-Switching-Pfade (LSPs) einzurichten, die einem explizit angegebenen Routen folgen und Einschränkungen des Traffic Engineerings unterworfen sein können. Diese Pfade werden als „LSP-Tunnel für Traffic Engineering“ oder kurz „TE LSP“ bezeichnet. Die Fähigkeit eines Label-Switching-Pfads, einer expliziten Route zu folgen und möglicherweise Einschränkungen des Traffic Engineerings unterworfen zu sein, ist ein wichtiges Baustein vieler Traffic-Engineering-Strategien von Dienstanbietern und wird auch von der MPLS-Architektur gefordert. Dieses Dokument schlägt eine RSVP-Erweiterung zur Einrichtung von explizit gerouteten LSP-Tunneln mit Traffic-Engineering-Einschränkungen vor. Es definiert ferner zusätzliche Objekte zum Aufzeichnen und Unterstützen der Angabe einer expliziten Route in RSVP-Nachrichten sowie mehrere Objekte zur weiteren Steuerung der Richtlinien zum Einrichten von LSP-Tunneln. Darüber hinaus definiert dieses Dokument eine „Hello“-Nachricht zum Testen der Erreichbarkeit zwischen RSVP-Nachbarn.
1. Einleitung
Dieses Dokument beschreibt Erweiterungen des Resource Reservation Protocol (RSVP, Version 1 [RFC 2205]), um die Einrichtung von „Label-Switching-Pfad-Tunneln für Traffic Engineering“ (im Folgenden „TE LSP“ oder „LSP-Tunnel“) in IP- und MPLS-Netzwerken zu unterstützen. Eine Übersicht über MPLS finden Sie in [RFC 3031]; eine Übersicht über Traffic Engineering (TE) mit MPLS finden Sie in [RFC 2702]. Abschnitt 2 gibt eine Übersicht. Abschnitt 3 beschreibt die RSVP-Nachrichtenformate zum Einrichten von LSP-Tunneln. Abschnitt 4 beschreibt die erweiterten RSVP-Objekte zum Einrichten von LSP-Tunneln. Abschnitt 5 beschreibt die „Hello“-Erweiterung. Abschnitt 6 beschreibt Sicherheitsüberlegungen. Abschnitt 7 beschreibt die RSVP-Nachrichtenverarbeitung durch MPLS-Label-Switching-Router (LSR). Abschnitt 8 definiert Optionen zur Signalisierung von LSP-Tunneln. Abschnitt 9 beschreibt die Abwärtskompatibilität mit RSVP. Abschnitt 10 zeigt Bereiche auf, in denen diese Spezifikation künftig erweitert werden könnte. Abschnitt 11 enthält die Referenzen. Anhang A enthält die Fehlerbehandlung. Anhang B enthält die RSVP-Nachrichtenverarbeitung in LSRs mit Mehrprotokollunterstützung. Abschnitt 12 ist ein Dank. Abschnitt 13 enthält die Adressen der Autoren. Abschnitt 14 enthält den Urheberrechtshinweis zu diesem Memorandum.
1.1 Begriffe
Die in diesem Dokument verwendeten Begriffe und Konventionen sind in [RFC 3031] und [RFC 2702] angegeben. Zur Bequemlichkeit des Lesers werden einige dieser Definitionen nachstehend wiederholt.
Label-Switching-Router (LSR): Router oder Switch, der Label-Switching versteht und Pakete basierend auf dem Label-Wert weiterleiten kann.
Label-Switching-Pfad (LSP): Für eine bestimmte Menge von Paketen definiert durch den von den Paketen durchlaufenen Pfad und die Menge der LSRs, auf denen das Label-Switching-/Weiterleitungsverhalten zur Einrichtung dieses Pfads etabliert wurde. Der Label-Switching-Pfad eines Pakets wird durch den vom Ingress-LSR auf das Paket angewandten Label-Stapel identifiziert. Ein für Traffic Engineering verwendeter und einer expliziten Route folgender LSP wird auch häufig „LSP-Tunnel“ genannt.
Downstream (Stromabwärts): Auf einem LSP oder Label-Switching-Pfad die Richtung vom Ingress zum Egress.
Upstream (Stromaufwärts): Auf einem LSP oder Label-Switching-Pfad die Richtung vom Egress zum Ingress.
LSP-Tunnel: Ein vom Ingress-LSR initiierter Label-Switching-Pfad, dessen Pakete auf eine Weise gekapselt werden, sodass die LSRs entlang des LSP beim Weiterleiten den IP-Header der Pakete nicht untersuchen. Das heißt, die LSRs in der Mitte des Tunnels werden über die im Inneren gekapselten Pakete „blind“ gemacht. In RSVP-TE wird der LSP-Tunnel durch das SESSION-Objekt identifiziert.
Ingress-LSR: LSR, der die erste Label-Ebene auf den LSP-Tunnel anwendet. Der Ingress-LSR ist auch der Initiator der Einrichtung des LSP-Tunnels.
Egress-LSR: LSR, der die äußerste Label-Ebene des LSP-Tunnels entfernt. Der Egress-LSR ist der endgültige Endpunkt des LSP-Tunnels.
Traffic Engineering: Der Prozess der Abbildung von Verkehr auf die physische Topologie des Netzwerks unter Berücksichtigung technischer oder geschäftlicher Einschränkungsmetriken (einschließlich, aber nicht beschränkt auf, Bandbreitenmanagement, Auslastungsmetriken, Stauungsmanagement und die Erfüllung von Quality-of-Service-Anforderungen).
Explizite Route (Explicit Route): Eine vom Ingress-LSR bei der Initiierung der Einrichtung eines LSP-Tunnels vorab festgelegte Liste von Knoten oder abstrakten Knoten (beispielsweise eines autonomen Systems). Diese Liste legt die Menge der Knoten und/oder Schnittstellen fest, die ein LSP-Tunnel während seiner Einrichtung durchlaufen muss.
Abstrakter Knoten (Abstract Node): Eine Folge von null oder mehr einfachen Knoten (d. h. Host oder Router) ohne dazwischenliegende Knoten.
Explicit Route Object (ERO): Besteht aus einer geordneten Liste von expliziten Route-Elementen (Subobjekten), wobei jedes Element vom Typ strict (streng) oder loose (lose) sein kann und eine explizite Route entlang einer Folge abstrakter Knoten angibt. Das ERO wird in der Path-Nachricht transportiert.
Record Route Object (RRO): Besteht aus einer geordneten Liste von Route-Elementen (Subobjekten) und zeichnet den tatsächlichen Pfad des LSP-Tunnels auf. Das RRO wird in Path- und Resv-Nachrichten transportiert.
Traffic-Engineering-Tunnel: Ein zu Traffic-Engineering-Zwecken eingerichteter und gepflegter LSP-Tunnel. Ein Traffic-Engineering-Tunnel muss nicht dem IGP-Kürzesten-Pfad folgen und kann mehreren Einschränkungen unterworfen sein.
1.2 Überblick über das Dokument
Dieses Dokument beschreibt die Erweiterungen an RSVP, die es ermöglichen, LSP-Tunnel in IP- und MPLS-Netzwerken einzurichten. Insbesondere beschreibt dieses Dokument die RSVP-Objekte für folgende Zwecke:
- Anfordern eines Labels beim Einrichten eines LSP-Tunnels;
- Transport von expliziten Routing-Informationen beim Einrichten eines LSP-Tunnels;
- Transport von Traffic-Engineering-Spezifikationen (Bandbreite, Farbe, Resource-Class-Affinität usw.);
- Transport von Richtlinien- und Preempt-Informationen (Priorität, Preemptbarkeit);
- Transport der Identifizierungsattribute der LSP-Tunnel-Sitzung.
Darüber hinaus definiert dieses Dokument die RSVP-Nachrichtenverarbeitungsregeln zum Einrichten von LSP-Tunneln mit Traffic-Engineering-Einschränkungen, einschließlich Einrichtung, Abbau, Rerouting und Preemption.
2. Überblick
RSVP [RFC 2205] ist ein Protokoll zum Einrichten und Warten von Verteilungsbäumen in IP-Netzwerken (Internet Protocol) für Multicast- oder Unicast-Datenübertragung. RSVP-Nachrichten werden entlang des Verteilungsbaums (unicast oder multicast) in Richtung der Datenflussroute weitergeleitet. Im empfängerinitiierten RSVP-Reservierungsmodell sendet der Empfänger eine „Resv“-Nachricht an den Sender und reserviert dabei Ressourcen entlang des Pfads. Im senderinitiierten RSVP-Modell sendet der Sender eine „Path“-Nachricht an den Empfänger, um den Zustand entlang des Pfads zu etablieren und den Verkehr zu charakterisieren.
Dieses Dokument beschreibt Erweiterungen an RSVP zur Unterstützung der Einrichtung von Label-Switching-Pfaden (LSPs) als Tunnel. Diese Erweiterungen ermöglichen es RSVP, in MPLS-Netzwerken Label-Switching-Pfade einzurichten, und ermöglichen es in IP-Netzwerken, „symbolische“ TE-LSPs einzurichten (d. h., obwohl es in einem IP-Netzwerk kein echtes Label-Switching gibt, kann RSVP dennoch einen explizit gerouteten, eingeschränkten Zustand mit derselben Semantik wie ein MPLS-TE-LSP-Tunnel etablieren und pflegen).
Dieses Dokument definiert folgende Erweiterungen an RSVP:
- Transport einer Label-Anforderung und Label-Bindung in RSVP-Nachrichten;
- Transport einer expliziten Route in RSVP-Nachrichten;
- Transport von Traffic-Engineering-Spezifikationen in RSVP-Nachrichten;
- Transport von Sitzungsattributen für Richtliniensteuerung und Preemption in RSVP-Nachrichten;
- Transport einer „Hello“-Nachricht zwischen RSVP-Nachbarn zum Testen der Erreichbarkeit.
Die folgenden Abschnitte beschreiben diese Erweiterungen im Detail.
2.1 Einrichten eines LSP-Tunnels
Um einen LSP-Tunnel einzurichten, sendet der Ingress-LSR eine Path-Nachricht an den Egress-LSR. Die Path-Nachricht transportiert:
- das LABEL_REQUEST-Objekt, mit dem ein Label für den LSP-Tunnel angefordert wird;
- das optionale EXPLICIT_ROUTE-Objekt (ERO), mit dem die explizite Route angegeben wird, der der LSP-Tunnel folgen soll;
- das optionale SESSION_ATTRIBUTE-Objekt, mit dem Sitzungsrichtlinieninformationen (z. B. Priorität und Preempt-Attribute des LSP-Tunnels) transportiert werden;
- das optionale RECORD_ROUTE-Objekt (RRO) zum Aufzeichnen des tatsächlichen Pfads;
- die Standard-RSVP-Senderdeskriptor- und Verkehrsspezifikationsobjekte.
Die Path-Nachricht wird hopsweise entlang des Pfads zum Egress-LSR (bzw. bei Vorhandensein eines ERO entlang des vom ERO angegebenen Pfads) weitergeleitet. Jeder LSR richtet beim Empfang einer Path-Nachricht einen „Path-Zustand“ für seinen Upstream-Nachbarn (d. h. den Nachbarn in Herkunftsrichtung der Path-Nachricht) ein.
Wenn der Egress-LSR die Path-Nachricht empfängt, sendet er eine Resv-Nachricht entlang des umgekehrten Pfads (d. h. in Richtung des Ingress-LSR). Die Resv-Nachricht transportiert:
- das LABEL-Objekt, das das vom Egress-LSR für den LSP-Tunnel zugewiesene Label enthält (das Label wird von Downstream nach Upstream des LSP zugewiesen);
- das optionale RECORD_ROUTE-Objekt (RRO);
- das Style-Objekt und den Flow-Deskriptor.
Die Resv-Nachricht wird hopsweise entlang des umgekehrten Pfads des Path-Zustands weitergeleitet. Jeder LSR richtet beim Empfang einer Resv-Nachricht einen „Resv-Zustand“ für seinen Downstream-Nachbarn (d. h. den Nachbarn in Herkunftsrichtung der Resv-Nachricht) ein und propagiert das von ihm seinem Downstream-Nachbarn zugewiesene Label im LABEL-Objekt nach Upstream.
Wenn der Ingress-LSR die Resv-Nachricht empfängt, ist die Einrichtung des LSP-Tunnels abgeschlossen. Zu diesem Zeitpunkt kann der Ingress-LSR beginnen, Pakete über den LSP-Tunnel weiterzuleiten.
2.2 Rerouting eines LSP-Tunnels
Während der Lebensdauer eines LSP-Tunnels kann es erforderlich werden, seinen Pfad zu ändern (z. B. als Reaktion auf Topologieänderungen im Netzwerk, zur Lastverteilung oder zur Optimierung der Ressourcennutzung). Dieses Dokument unterstützt das Rerouting eines LSP-Tunnels, ohne den vom LSP-Tunnel transportierten Verkehr zu unterbrechen. Eine empfohlene Methode ist „make-before-break“ (Aufbau vor Abbruch), d. h.: Zuerst wird ein neuer LSP (mit einer anderen LSP-ID) parallel zum alten eingerichtet, dann, nachdem der Verkehr auf den neuen LSP umgeschaltet wurde, wird der alte LSP abgebaut. Mit dem Shared-Explicit (SE)-Reservierungsstil können alte und neue LSPs auf den gemeinsam genutzten Link-Ressourcen koexistieren, ohne eine doppelte Bandbreitenbelegung zu verursachen.
2.3 Preemption eines LSP-Tunnels
LSP-Tunneln kann eine Priorität zugewiesen werden. Wenn die Netzwerkressourcen nicht ausreichen, um alle eingerichteten LSP-Tunnel gleichzeitig aufzunehmen, kann ein LSP-Tunnel mit höherer Priorität einen LSP-Tunnel mit niedrigerer Priorität preempten (d. h. abbauen und neu einrichten). Dieses Dokument unterstützt Preemption über die Felder „Setup Priority“ (Einrichtungspriorität) und „Holding Priority“ (Haltepriorität) im SESSION_ATTRIBUTE-Objekt.
2.4 Ressourcen-Reservierungsstile
RSVP unterstützt mehrere Ressourcen-Reservierungsstile, darunter:
- Fixed Filter (FF)-Stil: Erstellt eine unabhängige Reservierung für jeden (Sender, Empfänger)-Flow;
- Wildcard Filter (WF)-Stil: Eine einzelne Reservierung wird von einer Gruppe (möglicherweise unbekannter) Sender geteilt;
- Shared Explicit (SE)-Stil: Eine einzelne Reservierung wird von einer explizit aufgeführten Gruppe von Sendern geteilt.
Für LSP-Tunnel wird normalerweise der SE-Stil verwendet, da er es alten und neuen LSPs ermöglicht, die Ressourcenreservierung während eines Reroutings (make-before-break) gemeinsam zu nutzen.
3. RSVP-Nachrichtenformate zum Einrichten von LSP-Tunneln
3.1 Path-Nachricht
Die Path-Nachricht wird vom Ingress-LSR initiiert, um einen LSP-Tunnel einzurichten. Das RSVP-Nachrichtenformat der Path-Nachricht lautet wie folgt:
<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> ]
LABEL_REQUEST und EXPLICIT_ROUTE sind in diesem Dokument neu eingeführte Objekte. Auch SESSION_ATTRIBUTE ist ein in diesem Dokument neu eingeführtes Objekt. RECORD_ROUTE ist in [RFC 2205] definiert, dieses Dokument legt jedoch dessen Verwendung beim Einrichten von LSP-Tunneln fest.
3.2 Resv-Nachricht
Die Resv-Nachricht wird vom Egress-LSR initiiert und entlang des umgekehrten Pfads des Path-Zustands gesendet, um die Einrichtung des LSP-Tunnels abzuschließen. Das RSVP-Nachrichtenformat der Resv-Nachricht lautet wie folgt:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ]
[ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor list>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOW_SPEC> ] <FILTER_SPEC> <LABEL>
<SE flow descriptor list> ::= <SE flow descriptor>
| <SE flow descriptor list> <SE flow descriptor>
<SE flow descriptor> ::= [ <FLOW_SPEC> ] <SE filter spec list>
<SE filter spec list> ::= <FILTER_SPEC> <LABEL>
| <SE filter spec list> <FILTER_SPEC> <LABEL>
LABEL ist ein in diesem Dokument neu eingeführtes Objekt, das das für den LSP-Tunnel zugewiesene Label transportiert.
4. Objekte zum Einrichten von LSP-Tunneln
Dieser Abschnitt beschreibt die erweiterten RSVP-Objekte zum Einrichten von LSP-Tunneln. Jedes Objekt besteht aus einem „Objektkopf“ und einem „Objektrumpf“, wobei der Objektkopf in [RFC 2205] definiert ist.
4.1 LABEL-Objekt
Das LABEL-Objekt wird verwendet, um den für den LSP-Tunnel zugewiesenen Label-Wert zu transportieren. Das LABEL-Objekt wird in der Resv-Nachricht transportiert.
Das Format des LABEL-Objekts lautet wie folgt:
Class = 16, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 16 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Feld Label Value ist ein 20-Bit-Label-Wert (für einen LSR mit Packet-Switching-Fähigkeit). Für einen LSR mit ATM- oder Frame-Relay-Fähigkeit unterscheidet sich die Kodierung des Label-Werts; Details hierzu siehe Anhang B.
4.1.1 Behandlung des LABEL-Objekts in der Resv-Nachricht
Wenn ein LSR eine Resv-Nachricht mit dem LABEL-Objekt empfängt, verwendet er den Label-Wert aus dem LABEL-Objekt für die Label-Bindung seiner Upstream-Schnittstelle (d. h., der Upstream-LSR wird diesen Label-Wert als Ausgangs-Label verwenden, wenn er Pakete an diesen LSR sendet).
4.1.2 Nichtunterstützung des LABEL-Objekts
Wenn ein LSR das LABEL-Objekt nicht unterstützt, muss er beim Empfang einer Resv-Nachricht mit dem LABEL-Objekt eine ResvErr-Nachricht mit dem Fehlercode „Unbekannte Objektklasse“ erzeugen. Das LABEL-Objekt gehört zur Objektklasse „erkennbar“ (zwei höchstwertige Bits der Klasse = 0b10), daher muss bei Unbekanntheit ein Fehler zurückgegeben werden.
4.2 LABEL_REQUEST-Objekt
Das LABEL_REQUEST-Objekt wird verwendet, um beim Einrichten eines LSP-Tunnels die Zuweisung eines Labels anzufordern. Es wird in der Path-Nachricht transportiert. Das LABEL_REQUEST-Objekt kann ferner eine Layer-3-Protokollkennung (L3PID) und einen optionalen Label-Bereich (für ATM- oder Frame-Relay-Links) transportieren.
Das Format des LABEL_REQUEST-Objekts lautet wie folgt (Form ohne Label-Bereich):
Class = 19, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Format des LABEL_REQUEST-Objekts mit ATM-Label-Bereich lautet wie folgt:
Class = 19, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI/VCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Format des LABEL_REQUEST-Objekts mit Frame-Relay-Label-Bereich lautet wie folgt:
Class = 19, C-Type = 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Feld L3PID kennzeichnet das vom LSP-Tunnel transportierte Layer-3-Protokoll (z. B. IPv4 = 0x0800, IPv6 = 0x86DD).
4.2.1 Behandlung von LABEL_REQUEST in der Path-Nachricht
Wenn ein LSR eine Path-Nachricht mit LABEL_REQUEST empfängt, muss er (falls unterstützt) ein Label für den LSP-Tunnel zuweisen und dieses im LABEL-Objekt der an Upstream gesendeten Resv-Nachricht bekanntgeben. Wenn der LSR das angeforderte L3PID nicht unterstützt, muss er eine PathErr-Nachricht erzeugen.
4.2.2 Nichtunterstützung des LABEL_REQUEST-Objekts
Wenn ein LSR das LABEL_REQUEST-Objekt nicht unterstützt, muss er beim Empfang einer Path-Nachricht mit LABEL_REQUEST eine PathErr-Nachricht mit dem Fehlercode „Unbekannte Objektklasse“ erzeugen. Das LABEL_REQUEST-Objekt gehört zur Objektklasse „erkennbar“ (zwei höchstwertige Bits der Klasse = 0b10), daher muss bei Unbekanntheit ein Fehler zurückgegeben werden.
4.3 EXPLICIT_ROUTE-Objekt (ERO)
Das EXPLICIT_ROUTE-Objekt (ERO) ermöglicht dem Ingress-LSR, die explizite Route anzugeben, der der LSP-Tunnel während seiner Einrichtung folgen soll. Das ERO erscheint in der Path-Nachricht. Das ERO besteht aus einer geordneten Liste von Subobjekten, von denen jedes vom Typ strict (streng) oder loose (lose) sein kann.
Das Format des ERO-Objekts lautet wie folgt:
Class = 20, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 20 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Format jedes Subobjekts lautet wie folgt:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
wobei das Bit L (Loose-Bit) angibt, ob das Subobjekt vom Typ loose (L=0) oder strict (L=1) ist.
Die im ERO definierten Subobjekttypen umfassen:
- Typ 1: IPv4-Präfix
- Typ 2: IPv6-Präfix
- Typ 3: Autonome System-Nummer (ASN)
- Typ 4: LSPID Version 4 (veraltet)
- Typ 5: Unnummerierte Schnittstelle (Unnumbered Interface)
- Typ 6: IPv4-Präfix (mit Präfix-Flag)
- Typ 7: IPv6-Präfix (mit Präfix-Flag)
- Typ 8: Autonome System-Nummer (4 Oktets)
- Typ 9: LSPID Version 4 (erweitert)
- Typ 10: SRLG (Shared Risk Link Group)
- Typ 11: Knoten- oder Link-Schutztyp
- Typ 12: Bandbreitenschutztyp
4.3.1 IPv4-Präfix-Subobjekt
Das IPv4-Präfix-Subobjekt wird verwendet, um ein IPv4-Adresspräfix als Route-Element anzugeben. Sein Format lautet wie folgt:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 1 | Length | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved (zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2 IPv6-Präfix-Subobjekt
Das IPv6-Präfix-Subobjekt wird verwendet, um ein IPv6-Adresspräfix als Route-Element anzugeben. Sein Format lautet wie folgt:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 2 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| IPv6 address (16 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.3 Autonome-System-Nummer-Subobjekt
Das Autonome-System-Nummer (ASN)-Subobjekt wird verwendet, um ein autonomes System als abstrakten Knoten anzugeben. Sein Format lautet wie folgt (2-Oktett-ASN):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 3 | Length | Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.4 Behandlung des ERO in der Path-Nachricht
Wenn ein LSR eine Path-Nachricht mit einem ERO empfängt, untersucht er das oberste Subobjekt des ERO, um den nächsten Hop zu bestimmen. Bei einem strict-Subobjekt muss der nächste Hop ein direkt angrenzender Knoten sein; bei einem loose-Subobjekt kann der nächste Hop ein über das IGP-Routing erreichbarer Knoten sein. Nach der Verarbeitung des obersten Subobjekts entfernt der LSR es aus dem ERO (pop) und propagiert das geänderte ERO nach Downstream.
4.3.5 Schleifen im ERO
Die ERO-Verarbeitung muss in der Lage sein, Schleifen zu erkennen. Wenn ein LSR erkennt, dass ein ERO zu einer Schleife führt, muss er eine PathErr-Nachricht erzeugen und den LSP-Tunnel ablehnen. Das Record-Route-Objekt (RRO) kann ebenfalls zur Unterstützung der Schleifenerkennung verwendet werden.
4.4 SESSION_ATTRIBUTE-Objekt
Das SESSION_ATTRIBUTE-Objekt wird verwendet, um die Sitzungsattribute des LSP-Tunnels zu transportieren, einschließlich Sitzungsname, Setup- und Haltepriorität, Wunsch nach lokaler Schutz, Wunsch nach Label-Aufzeichnung usw. Sein Format lautet wie folgt:
Class = 207, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=207 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die Bits des Flags-Felds sind wie folgt definiert:
- 0x01: Lokaler Schutz gewünscht (Local protection desired)
- 0x02: Label-Aufzeichnung gewünscht (Label recording desired)
- 0x04: SE-Stil gewünscht (SE Style desired)
- 0x08: Bandbreitenschutz (Bandwidth protection)
- 0x10: Knotenschutz (Node protection)
4.5 RECORD_ROUTE-Objekt (RRO)
Das RECORD_ROUTE-Objekt (RRO) wird verwendet, um den tatsächlichen Pfad des LSP-Tunnels aufzuzeichnen. Das RRO wird sowohl in Path- als auch in Resv-Nachrichten transportiert. Das RRO besteht aus einer Reihe von Subobjekten, von denen jedes einen Knoten oder Link auf dem Pfad aufzeichnet. Das RRO kann für Schleifenerkennung, Pfad-Diversitätsberechnung und Fehlerdiagnose verwendet werden.
4.6 SESSION-Objekt
Das SESSION-Objekt wird verwendet, um die Sitzung des LSP-Tunnels zu identifizieren. Für einen LSP-Tunnel wird die „Tunnel Endpoint Address“ (Tunnel-Endpunktadresse) im SESSION-Objekt auf die Adresse des Egress-LSR gesetzt, die „Tunnel ID“ wird vom Ingress-LSR zugewiesen, und die „Extended Tunnel ID“ wird normalerweise auf die Adresse des Ingress-LSR gesetzt.
4.7 SENDER_TEMPLATE-Objekt
Das SENDER_TEMPLATE-Objekt wird verwendet, um den Sender (d. h. den Ingress-LSR) des LSP-Tunnels zu identifizieren. Für einen LSP-Tunnel transportiert das SENDER_TEMPLATE-Objekt die „Tunnel ID“ und die „LSP ID“. Die LSP ID wird verwendet, um beim Rerouting (make-before-break) alte und neue LSPs zu unterscheiden.
5. Hello-Erweiterung
Dieses Dokument definiert die RSVP-„Hello“-Erweiterung zum Testen der Erreichbarkeit zwischen RSVP-Nachbarn. Der Hello-Mechanismus ergänzt den auf weichem Zustand (soft state) basierenden Aktualisierungsmechanismus und kann einen Nachbardefektnachweis schneller auslösen als der IGP-Defektnachweis, wodurch ein schnellerer Schutz oder ein Rerouting von LSP-Tunneln unterstützt wird.
Das RSVP-Nachrichtenformat der Hello-Nachricht lautet wie folgt:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
Das Format des HELLO-Objekts lautet wie folgt:
Class = 8, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 8 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Instance | Destination Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hello-Nachrichten werden periodisch zwischen benachbarten RSVP-Nachbarn ausgetauscht. Wenn innerhalb eines konfigurierbaren Intervalls keine Hello-Nachricht vom Gegenüber empfangen wird, gilt der Nachbar als nicht erreichbar, und es wird die entsprechende Fehlerbehandlung ausgelöst (z. B. Widerruf aller Path- und Resv-Zustände, die über diesen Nachbarn verlaufen, sowie Auslösung eines Reroutings des LSP-Tunnels).
6. Sicherheitsüberlegungen
RSVP-Nachrichten werden zum Einrichten und Warten von LSP-Tunneln verwendet und beeinflussen den Weiterleitungszustand und die Netzwerkressourcen direkt. Daher sieht sich die RSVP-TE-Steuerungsebene mehreren Sicherheitsbedrohungen gegenüber, darunter:
- gefälschte Path- oder Resv-Nachrichten, die zu falscher Label-Bindung oder Ressourcenerschöpfung führen;
- nicht autorisierte explizite Routen, die Verkehr über sensible Links leiten;
- Aktualisierungs- oder Zustandsangriffe, die zur Erschöpfung der CPU der Steuerungsebene führen;
- Leckage von Netzwerktopologieinformationen über das RECORD_ROUTE-Objekt.
Um diese Bedrohungen abzumildern, SOLLTE (sollte) der Einsatz RSVP-Authentifizierung (z. B. RSVP-INTEGRITY-Objekt oder IPsec) verwenden, die Steuerungsebenen-Peers filtern (z. B. durch Einschränkung der RSVP-Nachbarn über ACLs) und die Offenlegung der Traffic-Engineering-Datenbank einschränken. Darüber hinaus SOLLTE eine Ratenbegrenzung implementiert werden, um Denial-of-Service-Angriffen zu widerstehen. Für das detaillierte Bedrohungsmodell und Abmilderungsmaßnahmen siehe die entsprechenden Sicherheitsdokumente und nachfolgenden BCPs.
7. RSVP-Nachrichtenverarbeitung durch Label-Switching-Router (LSR)
Dieser Abschnitt beschreibt die detaillierten Regeln der RSVP-Nachrichtenverarbeitung durch einen MPLS-fähigen LSR zum Einrichten von LSP-Tunneln.
7.1 Path-Nachrichtenverarbeitung
Wenn ein LSR eine Path-Nachricht empfängt, führt er folgende Operationen aus:
- Wenn die Path-Nachricht das LABEL_REQUEST-Objekt enthält, muss der LSR ein Label für den LSP-Tunnel zuweisen (es sei denn, er ist der Egress-LSR, in welchem Fall das Label vom Egress basierend auf dem L3PID bestimmt wird).
- Wenn die Path-Nachricht das EXPLICIT_ROUTE-Objekt enthält, wählt der LSR den nächsten Hop gemäß den ERO-Regeln aus.
- Wenn die Path-Nachricht das RECORD_ROUTE-Objekt enthält, fügt der LSR seine eigene Adresse oder Schnittstellenkennung zum RRO hinzu.
- Der LSR leitet die geänderte Path-Nachricht (mit dem gepoppten/aktualisierten ERO und dem um diesen Knoten ergänzten RRO) nach Downstream weiter.
7.2 Resv-Nachrichtenverarbeitung
Wenn ein LSR eine Resv-Nachricht empfängt, führt er folgende Operationen aus:
- Der LSR extrahiert aus dem LABEL-Objekt der Resv-Nachricht das von seinem Downstream-Nachbarn zugewiesene Label.
- Der LSR weist sich selbst ein Label (für seinen Upstream-Nachbarn) zu und platziert es zur Weiterleitung nach Upstream in das LABEL-Objekt.
- Wenn die Resv-Nachricht das RECORD_ROUTE-Objekt enthält, fügt der LSR seinen eigenen Label-Eintrag zum RRO hinzu (wenn das Flag „Label-Aufzeichnung gewünscht“ in SESSION_ATTRIBUTE gesetzt ist).
- Der LSR sendet die Resv-Nachricht entlang des umgekehrten Pfads des Path-Zustands nach Upstream.
7.3 Abbau eines LSP-Tunnels
Ein LSP-Tunnel kann durch Senden einer PathTear- oder ResvTear-Nachricht abgebaut werden. Die PathTear-Nachricht wird in Richtung des Path-Zustands gesendet und entfernt alle Path-Zustände entlang des Pfads. Die ResvTear-Nachricht wird in Richtung des Resv-Zustands gesendet und entfernt alle Resv-Zustände entlang des Pfads. Wenn der Ingress-LSR den LSP-Tunnel nicht mehr benötigt, sendet er eine PathTear-Nachricht; wenn der Egress-LSR beschließt, den LSP-Tunnel zu beenden, sendet er eine ResvTear-Nachricht.
7.4 Fehlerbehandlung
Wenn ein LSR bei der Verarbeitung einer RSVP-Nachricht auf einen Fehler stößt (z. B. ERO nicht erfüllbar, Label-Zuweisung fehlgeschlagen, Ressourcen unzureichend oder unbekanntes Objekt), muss er eine entsprechende Fehlernachricht (PathErr oder ResvErr) erzeugen und den Fehlercode sowie Informationen über den Fehlerknoten transportieren. Der Ingress-LSR kann diese Informationen nutzen, um einen alternativen Pfad auszuwählen oder andere Korrekturmaßnahmen zu ergreifen. Detaillierte Fehlerbehandlungsregeln sind in Anhang A enthalten.
8. Optionen zur Signalisierung von LSP-Tunneln
Dieser Abschnitt beschreibt einige optionale Mechanismen, die zur Verbesserung der Signalisierungsfähigkeiten von LSP-Tunneln verwendet werden können, darunter:
- Preemption (Verdrängung) und Prioritätsbehandlung;
- Resource-Class-Affinität (Administrative Gruppen und Ausschluss administrativer Gruppen);
- DiffServ-empfindliches Traffic Engineering;
- Point-to-Multipoint (P2MP) LSP-Signalisierung (in nachfolgenden Dokumenten definiert).
Diese Optionen werden durch Setzen der entsprechenden Flags und Felder im SESSION_ATTRIBUTE-Objekt und anderen erweiterten Objekten realisiert.
9. Abwärtskompatibilität mit RSVP
Die in diesem Dokument definierten RSVP-Erweiterungen sind so konzipiert, dass sie abwärtskompatibel zu vorhandenen RSVP-Implementierungen sind. Ein RSVP-Knoten, der die LSP-Tunnel-Erweiterungen nicht unterstützt, verarbeitet die neuen Objekte gemäß der Semantik der zwei höchstwertigen Bits der Objektklasse (class-num):
- Wenn die zwei höchstwertigen Bits 0b01 (ignorierbar) sind, kann der Knoten das unbekannte Objekt ignorieren und die Verarbeitung der Nachricht fortsetzen;
- Wenn die zwei höchstwertigen Bits 0b10 (erkennbar) sind, muss der Knoten einen Fehler (PathErr oder ResvErr) zurückgeben, da das unbekannte Objekt die korrekte Funktion beeinträchtigen kann.
LABEL_REQUEST, LABEL und EXPLICIT_ROUTE gehören alle zur Klasse „erkennbar“ (0b10), daher geben nicht unterstützende Knoten einen Fehler zurück und verhindern so die Einrichtung eines unvollständigen LSP-Tunnels.
10. Zukünftige Richtungen
Diese Spezifikation könnte in folgenden Bereichen erweitert werden:
- Unterstützung von Point-to-Multipoint (P2MP) und Multipoint-to-Multipoint (MP2MP) LSPs;
- Unterstützung von Generalized MPLS (GMPLS), einschließlich Time-Division-Multiplexing (TDM)-, Wellenlängen-Switching- und Glasfaser-Switching-Links;
- verbesserte Fast-Reroute (FRR)-Mechanismen;
- engere Integration mit Differentiated Services (DiffServ) und Traffic Engineering.
11. Referenzen
11.1 Normative Referenzen
- [RFC 2119] Bradner, S., „Key words for use in RFCs to Indicate Requirement Levels“, BCP 14, RFC 2119, März 1997.
- [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. und S. Jamin, „Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification“, RFC 2205, September 1997.
- [RFC 2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. und J. McManus, „Requirements for Traffic Engineering Over MPLS“, RFC 2702, September 1999.
- [RFC 3031] Rosen, E., Viswanathan, A. und R. Callon, „Multiprotocol Label Switching Architecture“, RFC 3031, Januar 2001.
11.2 Referenzen
- [RFC 3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. und A. Conta, „MPLS Label Stack Encoding“, RFC 3032, Januar 2001.
- [RFC 3212] Jamoussi, B. et al., „Constraint-Based LSP Setup using LDP“, RFC 3212, Januar 2002.
- weitere nachfolgende RFCs (Dokumente, die Fast Reroute, GMPLS, P2MP usw. definieren).
Anhang A. Fehlerbehandlung
Dieser Anhang beschreibt die Fehlerbehandlungsregeln beim Einrichten eines LSP-Tunnels.
A.1 PathErr-Nachricht
Wenn ein LSR bei der Verarbeitung einer Path-Nachricht auf einen Fehler stößt, erzeugt er eine PathErr-Nachricht mit:
- dem Fehlercode (z. B. unbekannte Objektklasse, ERO nicht erfüllbar, Ressourcen unzureichend, Label-Zuweisung fehlgeschlagen);
- dem Fehler-Subcode (der detailliertere Informationen liefert);
- der Kennung des Fehlerknotens (normalerweise die Adresse des den Fehler erzeugenden LSR).
Die PathErr-Nachricht wird entlang des umgekehrten Pfads der Path-Nachricht gesendet und erreicht schließlich den Ingress-LSR.
A.2 ResvErr-Nachricht
Wenn ein LSR bei der Verarbeitung einer Resv-Nachricht auf einen Fehler stößt, erzeugt er eine ResvErr-Nachricht mit ähnlichen Fehlercodes, Subcodes und Fehlerknoteninformationen. Die ResvErr-Nachricht wird entlang des umgekehrten Pfads der Resv-Nachricht gesendet und erreicht schließlich den Egress-LSR.
A.3 Häufige Fehlercodes
Die folgende Tabelle listet häufige Fehlercodes beim Einrichten eines LSP-Tunnels auf.
| Fehlercode | Bedeutung |
|---|---|
| Unbekannte Objektklasse | Empfang eines unbekannten erkennbaren Objekts |
| ERO nicht erfüllbar | LSP kann nicht gemäß der vom ERO angegebenen Route eingerichtet werden |
| Ressourcen unzureichend | Unzureichende Bandbreite oder Label-Ressourcen |
| Label-Zuweisung fehlgeschlagen | Angefordertes Label kann nicht zugewiesen werden |
| Nicht unterstütztes L3PID | Angefordertes L3-Protokoll wird nicht unterstützt |
Anhang B. RSVP-Nachrichtenverarbeitung in LSRs mit Mehrprotokollunterstützung
Dieser Anhang beschreibt besondere Überlegungen zur RSVP-Nachrichtenverarbeitung in LSRs, die sowohl Packet-Switching-Fähigkeit (PSC) als auch Circuit-Switching-Fähigkeit (z. B. ATM, Frame Relay) besitzen.
B.1 Label-Kodierung auf ATM-Schnittstellen
Auf einer ATM-Schnittstelle wird der Label-Wert des LABEL-Objekts als VPI/VCI-Paar kodiert. Das LABEL_REQUEST-Objekt verwendet C-Type = 2 und transportiert den VPI/VCI-Bereich.
B.2 Label-Kodierung auf Frame-Relay-Schnittstellen
Auf einer Frame-Relay-Schnittstelle wird der Label-Wert des LABEL-Objekts als DLCI kodiert. Das LABEL_REQUEST-Objekt verwendet C-Type = 3 und transportiert den DLCI-Bereich.
B.3 Unnummerierte Schnittstellen
Für unnummerierte (Unnumbered) Schnittstellen wird ein spezielles Subobjekt (Typ 5) im ERO und RRO verwendet, um die Schnittstelle zu identifizieren. Eine unnummerierte Schnittstelle wird durch ihre „Router ID“ und ihren „Interface Index“ identifiziert.
12. Danksagung
Die Autoren danken den zahlreichen Gutachtern für ihre Beiträge und Rückmeldungen zu diesem Dokument, einschließlich mehrerer Mitglieder der MPLS Working Group.
13. Adressen der Autoren
Daniel O. Awduche
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Lou Berger
MPLS Network Working Group
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
Tony Li
Procket Networks
1100 Cadillac Court
Milpitas, CA 95035
Vijay Srinivasan
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
14. Urheberrechtshinweis
Copyright (C) The Internet Society (2001). Alle Rechte vorbehalten.
Dieses Dokument und seine Übersetzungen können kopiert und anderen Personen zur Verfügung gestellt werden und gelten beim Kopieren, Darstellen, Zitieren oder anderweitigen Verwenden als gebührenfrei, sofern alle oben genannten Kopien und abgeleiteten Werke diesen Urheberrechtshinweis sowie die in diesem Dokument genannten Rechte, Einschränkungen und Haftungsausschlüsse enthalten. Das Dokument selbst darf jedoch in keiner Weise verändert werden, beispielsweise durch Entfernen des Urheberrechtshinweises oder der Verweise auf die Internet Society oder andere Internet-Organisationen, außer wenn dies für die Zwecke des Internet-Standardisierungsprozesses erforderlich ist, in welchem Fall die in den Internet-Standards definierten Urheberrechtsverfahren befolgt werden müssen, oder wenn dies erforderlich ist, um es in eine andere Sprache als Englisch zu übersetzen.
Die oben gewährten eingeschränkten Genehmigungen sind dauerhaft und werden von der Internet Society oder ihren Rechtsnachfolgern oder Abtretungsempfängern nicht widerrufen.
Dieses Dokument und die darin enthaltenen Informationen werden „WIE BESEHEN“ (AS IS) zur Verfügung gestellt, und DIE INTERNET SOCIETY UND DIE INTERNET ENGINEERING TASK FORCE LEHNEN ALLE AUSDRÜCKLICHEN ODER STILLSCHWEIGENDEN GARANTIEN AB, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF, JEGLICHE GEWÄHRLEISTUNG DASS DIE NUTZUNG DER HIERIN ENTHALTENEN INFORMATIONEN KEINE RECHTE VERLETZT ODER STILLSCHWEIGENDE GARANTIEN DER MARKTGÄNGIGKEIT ODER DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.
Danksagung
Die Finanzierung der RFC-Editor-Funktion wird derzeit von der Internet Society bereitgestellt.