RFC 3209 - RSVP-TE: Erweiterungen zu RSVP für LSP-Tunnel
- Status: Proposed Standard
- Veröffentlicht: December 2001
- Stream: IETF
- Errata: Keine Errata
Zusammenfassung (Abstract)
Dieses Dokument beschreibt die Verwendung des Resource ReSerVation Protocol (RSVP) zum Aufbau von Label-Switched-Pfaden (LSPs) in Multiprotocol Label Switching (MPLS)-Netzwerken. LSPs, die mit RSVP aufgebaut werden, können mit oder ohne explizite Routing-Fähigkeit verwendet werden. Wenn explizites Routing verwendet wird, ermöglicht RSVP-TE die Instanziierung von LSPs, die von dem durch das Routing-Protokoll der Netzwerkschicht berechneten kürzesten Pfad abweichen. Diese Fähigkeit ist entscheidend für Traffic Engineering und für die Bereitstellung differenzierter Dienste.
1. Einleitung (Introduction)
Multiprotocol Label Switching (MPLS) [2] ist eine Technologie, die Label-Switching-Weiterleitung mit Netzwerkschicht-Routing kombiniert. Eine grundlegende Anwendung von MPLS ist Traffic Engineering (TE) [3]. Traffic Engineering ermöglicht es Netzwerkbetreibern, den Pfad des Verkehrs durch das Netzwerk zu steuern, um die Ressourcennutzung und die Netzwerkleistung zu optimieren.
Um MPLS Traffic Engineering zu unterstützen, ist ein Mechanismus erforderlich, um Label-Switched-Pfade (LSPs) aufzubauen und zu verwalten. RSVP [1] ist ein ausgereiftes Signalisierungsprotokoll, das erweitert wurde, um den Aufbau von LSPs zu unterstützen. Dieses Dokument definiert die Erweiterungen zu RSVP, um den Aufbau von MPLS-LSPs zu unterstützen, insbesondere für Traffic-Engineering-Anwendungen.
Die in diesem Dokument definierten Erweiterungen ermöglichen die Verwendung von RSVP für:
- Den Aufbau von explizit gerouteten LSPs.
- Das Rerouting von LSPs unter Verwendung der "Make-before-break"-Methode.
- Die Unterstützung der LSP-Schleifenerkennung.
- Die Unterstützung der Label-Verteilung während des LSP-Aufbauprozesses.
2. Terminologie (Terminology)
Dieses Dokument verwendet die in RFC 3031 [2] und RFC 2205 [1] definierte Terminologie. Darüber hinaus werden folgende Begriffe verwendet:
- LSP-Tunnel (LSP Tunnel): Ein Tunnel, der durch einen Label-Switched-Pfad in einem MPLS-Netzwerk aufgebaut wird.
- LSP ID: Ein Bezeichner, der zur Identifizierung eines bestimmten LSPs verwendet wird.
- Tunnel ID: Ein Bezeichner, der zur Identifizierung eines Traffic-Engineering-Tunnels verwendet wird, der einen oder mehrere LSPs enthalten kann.
- Extended Tunnel ID: Ein Bezeichner, der zur global eindeutigen Identifizierung eines Tunnels verwendet wird.
3. Überblick über RSVP-Erweiterungen (Overview of RSVP Extensions)
Das RSVP-Protokoll baut Ressourcenreservierungszustände über Path- und Resv-Nachrichten auf und verwaltet diese. Um LSP-Tunnel zu unterstützen, wurden mehrere neue Objekte eingeführt:
- LABEL_REQUEST Objekt: Wird in Path-Nachrichten übertragen und fordert eine Label-Zuweisung von Downstream-Knoten an.
- LABEL Objekt: Wird in Resv-Nachrichten übertragen und verteilt das zugewiesene Label an Upstream-Knoten.
- EXPLICIT_ROUTE Objekt (ERO): Wird in Path-Nachrichten übertragen und gibt den expliziten Pfad an, den der LSP nehmen muss.
- RECORD_ROUTE Objekt (RRO): Wird in Path- und Resv-Nachrichten übertragen und zeichnet den tatsächlichen Pfad und die Labels auf, die der LSP genommen hat.
- SESSION_ATTRIBUTE Objekt: Wird in Path-Nachrichten übertragen und steuert die LSP-Attribute wie Priorität, Preemption und Affinität.
4. Objektdefinitionen (Object Definitions)
4.1. LABEL Objekt
Das LABEL-Objekt wird verwendet, um das zugewiesene Label in Resv-Nachrichten zu übertragen.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. LABEL_REQUEST Objekt
Das LABEL_REQUEST-Objekt wird verwendet, um eine Label-Bindung in Path-Nachrichten anzufordern.
Class = 19, C_Type = 1 (Ohne Label-Bereich)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L3PID identifiziert das Layer-3-Protokoll, das auf diesem Pfad übertragen wird (normalerweise Ethertype).
4.3. EXPLICIT_ROUTE Objekt (ERO)
Das ERO wird verwendet, um explizite Pfade anzugeben. Es enthält eine Reihe von Unterobjekten (Subobjects), die jeweils einen abstrakten Knoten auf dem Pfad darstellen.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zu den Unterobjekttypen gehören:
- Type 1: IPv4-Präfix
- Type 2: IPv6-Präfix
- Type 32: Autonome Systemnummer (AS Number)
Jedes Unterobjekt hat auch ein L-Bit (Loose bit). Wenn L=0, zeigt dies einen strikten Hop (Strict hop) an; wenn L=1, zeigt dies einen lockeren Hop (Loose hop) an.
4.4. RECORD_ROUTE Objekt (RRO)
Das RRO wird verwendet, um den tatsächlich vom LSP genommenen Pfad aufzuzeichnen. Es kann auch Label-Informationen enthalten.
Class = 21, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5. SESSION_ATTRIBUTE Objekt
Dieses Objekt steuert die Sitzungsattribute wie Priorität und Ressourcenaffinität.
Class = 207, C_Type = 7 (LSP_TUNNEL)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Das Flags-Feld definiert folgende Flags:
- 0x01: Local protection desired (Lokaler Schutz/Fast Reroute gewünscht)
- 0x02: Label recording desired (Label-Aufzeichnung gewünscht)
- 0x04: SE Style desired (SE-Stil gewünscht, für Make-before-break)
4.6. SESSION und SENDER_TEMPLATE Objekte
Neue C-Typen sind definiert, um LSP-Tunnel zu unterstützen.
- LSP_TUNNEL_IPv4 Session Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Session Object (C-Type = 8)
Enthält die Tunnel ID und die Extended Tunnel ID.
- LSP_TUNNEL_IPv4 Sender Template Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Sender Template Object (C-Type = 8)
Enthält die LSP ID.
5. Hello-Erweiterung (Hello Extension)
Die RSVP-Hello-Erweiterung ermöglicht es RSVP-Knoten, zu erkennen, wenn ein benachbarter Knoten nicht erreichbar ist. Dies bietet einen Mechanismus zur Erkennung von Knotenausfällen.
Hello-Nachrichtenformat:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
Das HELLO-Objekt (Class 22) hat zwei Typen:
- HELLO REQUEST (C-Type = 1)
- HELLO ACK (C-Type = 2)
Sie enthalten Quellinstanz- (Src_Instance) und Zielinstanz- (Dst_Instance) Werte zur Erkennung von Knotenneustarts oder Kommunikationsverlusten.
6. Sicherheitsüberlegungen (Security Considerations)
Im Prinzip stellen diese Erweiterungen kein höheres Sicherheitsrisiko dar als RFC 2205 [1]. Es gibt jedoch eine leichte Änderung im Vertrauensmodell. Da der Verkehr basierend auf Labels weitergeleitet wird, möchte ein Administrator möglicherweise die Domäne einschränken, über die LSP-Tunnel aufgebaut werden können.
7. IANA-Überlegungen (IANA Considerations)
Dieses Dokument definiert neue Objektklassennummern (Class Numbers) und Typen (C-Types) sowie Fehlercodes.
8. Referenzen (References)
[1] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205. [2] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031. [3] Awduche, D., et al., "Requirements for Traffic Engineering over MPLS", RFC 2702.
Anmerkung des Übersetzers: Dieses Dokument ist eine Referenzübersetzung von RFC 3209 ins Deutsche.