Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Auf dieser Seite
 

Unterstützte MPLS-Standards

Unterstützte MPLS-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für MPLS und Traffic Engineering definieren.

  • RFC 2858, Multiprotokoll-Erweiterungen für BGP-4

  • RFC 3031, Multiprotocol Label Switching-Architektur

  • RFC 3032, MPLS Label Stack Encoding

  • RFC 3140, Identifikationscodes für das Verhalten pro Hop

  • RFC 3270, Multi-Protocol Label Switching (MPLS) Unterstützung von differenzierten Diensten

    Es werden nur E-LSPs unterstützt.

  • RFC 3443, TTL-Verarbeitung (Time To Live) in MPLS-Netzwerken (Multi-Protocol Label Switching)

  • RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol (Graceful-Neustart-Mechanismus für das Label Distribution Protocol)

  • RFC 3906, Berechnen von IGP-Routen (Interior Gateway Protocol) über Traffic-Engineering-Tunnel

  • RFC 4090, Fast Reroute Extensions to RSVP-TE für LSP-Tunnel

    Der Knotenschutz in der Sicherung von Einrichtungen wird nicht unterstützt.

  • RFC 4124, Protokollerweiterungen zur Unterstützung von Diffserv-fähigem MPLS Traffic Engineering

  • RFC 4182, Entfernen einer Einschränkung für die Verwendung von MPLS Explicit NULL

  • RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4379, Erkennen von MPLS-Data-Plane-Fehlern (Multi-Protocol Label Switched)

  • RFC 4385, Pseudowire Emulation Edge-to-Edge (PWE3)-Steuerwort zur Verwendung über ein MPLS-PSN.

    Unterstützt auf Routern der MX-Serie mit dem kanalisierten OC3/STM1 (Multi-Rate) Circuit Emulation MIC mit SFP.

  • RFC 4875, Erweiterungen von RSVP-TE für Point-to-Multipoint-TE-LSPs

  • RFC 4950, ICMP-Erweiterungen für Multiprotokoll-Label-Switching

  • RFC 5317, Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile (Bericht des Joint Working Teams on MPLS Architectural Considerations for a Transport Profile)

  • RFC 5586, MPLS Generic Associated Channel

  • RFC 5654, Anforderungen an ein MPLS-Transportprofil

    Die folgenden Funktionen werden in der Junos OS-Implementierung von MPLS Transport Profile (MPLS-TP) unterstützt:

    • MPLS-TP OAM kann Pakete mit GAL und G-Ach ohne IP-Kapselung senden und empfangen.

    • Zwei unidirektionale RSVP-LSPs zwischen einem Routerpaar können einander zugeordnet werden, um einen zugeordneten bidirektionalen LSP für die Bindung eines Pfads für die GAL- und G-Ach OAM-Nachrichten zu erstellen. Für den zugeordneten bidirektionalen LSP wird eine einzelne Bidirectional Forwarding Detection (BFD)-Sitzung eingerichtet.

  • RFC 5712, MPLS Traffic Engineering Soft Preemption

  • RFC 5718, Ein In-Band-Datenkommunikationsnetzwerk für das MPLS-Transportprofil

  • RFC 5860, Anforderungen für Betrieb, Verwaltung und Wartung (OAM) in MPLS-Transportnetzwerken

  • RFC 5884, Bidirectional Forwarding Detection (BFD) für MPLS Label Switched Paths (LSPs)

  • RFC 5921, Ein Framework für MPLS in Transportnetzwerken

  • RFC 5950, Netzwerkmanagement-Framework für MPLS-basierte Transportnetzwerke

  • RFC 5951, Anforderungen an das Netzwerkmanagement für MPLS-basierte Transportnetzwerke

  • RFC 5960, MPLS-Transportprofil-Data-Plane-Architektur

  • RFC 6215, MPLS-Transportprofil Benutzer-zu-Netzwerk- und Netzwerk-zu-Netzwerk-Schnittstellen

  • RFC 6291, Richtlinien für die Verwendung des Akronyms "OAM" in der IETF.

  • RFC 6370, MPLS-Transportprofilbezeichner (MPLS-TP)

  • RFC 6371, Framework für Betrieb, Verwaltung und Wartung von MPLS-basierten Transportnetzwerken.

  • RFC 6372, MPLS-Transportprofil (MPLS-TP) Survivability Framework

  • RFC 6373, MPLS-TP Control Plane Framework

  • RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint und Multipoint-to-Multipoint Label Switched Paths

    Es werden nur Point-to-Multipoint-LSPs unterstützt.

  • RFC 6424, Mechanismus zur Durchführung von Label Switched Path Ping (LSP Ping) über MPLS-Tunnel

  • RFC 6425, Erkennen von Data-Plane-Fehlern in Point-to-Multipoint-MPLS – Erweiterungen für LSP-Ping

  • RFC 6426, MPLS On-Demand-Konnektivitätsüberprüfung und Routenverfolgung

  • RFC 6428, Proaktive Konnektivitätsüberprüfung, Durchgangsprüfung und Remote-Fehleranzeige für das MPLS-Transportprofil

  • RFC 6510, RSVP-Nachrichtenformate (Resource Reservation Protocol) für LSP-Attributobjekte (Label Switched Path)

  • RFC 6790, Die Verwendung von Entropie-Labels in der MPLS-Weiterleitung

  • RFC 7746, Label Switched Path (LSP) Self-Ping

  • Internet-Entwurfs-draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Nicht-PHP-Verhalten und Out-of-Band-Mapping für RSVP-TE-LSPs

Die folgenden RFCs und Internet-Entwürfe definieren keine Standards, sondern geben Auskunft über MPLS, Traffic Engineering und verwandte Technologien. Die IETF klassifiziert sie unterschiedlich als "experimentell", "historisch" oder "informativ".

  • RFC 2547, BGP/MPLS-VPNs

  • RFC 2702, Anforderungen an Traffic Engineering über MPLS

  • RFC 2917, Eine Kern-MPLS-IP-VPN-Architektur

  • RFC 3063, MPLS-Schleifenverhinderungsmechanismus

  • RFC 3208, PGM Reliable Transport Protocol Specification (PGM-Spezifikation für zuverlässiges Transportprotokoll)

    Nur das Netzwerkelement wird unterstützt.

  • RFC 3469, Framework für MPLS-basierte Wiederherstellung (Multi-Protocol Label Switching)

  • RFC 3564, Anforderungen für die Unterstützung von MPLS-Traffic-Engineering mit differenzierten Service-Kenntnissen

  • RFC 4125, Modell für maximale Bandbreitenbeschränkungen für Diffserv-fähiges MPLS Traffic Engineering

  • RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-fähiges MPLS Traffic Engineering

  • Internet-Entwurf draft-martini-l2circuit-encap-mpls-11.txt, Kapselungsmethoden für den Transport von Layer- 2-Frames über IP- und MPLS-Netzwerke

    Junos OS unterscheidet sich in folgenden Punkten vom Internet-Entwurf:

    • Ein Paket mit der Sequenznummer 0 wird als nicht geordnet behandelt.

    • Jedes Paket, das nicht die nächste inkrementelle Sequenznummer hat, gilt als nicht in der richtigen Reihenfolge.

    • Wenn Pakete außerhalb der Sequenz eintreffen, wird die erwartete Sequenznummer für den Nachbarn auf die Sequenznummer im Steuerwort der Layer-2-Schaltung festgelegt.

  • Internet-Entwurfs-draft-martini-l2circuit-trans-mpls-19.txt, Transport von Layer- 2-Frames über MPLS

  • RFC 4875, Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) (Unterstützt einen Pfad pro S2L-Signalisierungsmodus)

Unterstützte RSVP-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für RSVP definieren.

  • RFC 2205, Resource ReSerVation Protocol (RSVP) – Funktionsspezifikation der Version 1

  • RFC 2210, Die Verwendung von RSVP mit IETF Integrated Services

  • RFC 2211, Spezifikation des Controlled-Load Network Element Service

  • RFC 2212, Spezifikation der garantierten Servicequalität

  • RFC 2215, Allgemeine Charakterisierungsparameter für integrierte Servicenetzwerkelemente

  • RFC 2745, RSVP-Diagnosemeldungen

  • RFC 2747, RSVP Cryptographic Authentication (aktualisiert durch RFC 3097)

  • RFC 2750, RSVP Extensions for Policy Control (RFC wird nicht unterstützt. Vollständig kompatibel mit Geräten, die diesen RFC unterstützen).

  • RFC 2961, Erweiterungen zur Reduzierung der Gemeinkosten für RSVP-Aktualisierungen

  • RFC 3097, RSVP Cryptographic Authentication – Aktualisierter Nachrichtentypwert

  • RFC 3209, RSVP-TE: Erweiterungen für RSVP für LSP-Tunnel

    Das NULL-Dienstobjekt für die MTU-Signalisierung (Maximum Transmission Unit) in RSVP wird nicht unterstützt.

  • RFC 3210, Anwendbarkeitserklärung für Erweiterungen von RSVP für LSP-Tunnel

  • RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)-Erweiterungen

    Nur Abschnitt 9 "Fehlerbehandlung" wird unterstützt.

  • RFC 3477, Signalisieren nicht nummerierter Links im Resource ReSerVation Protocol – Traffic Engineering (RSVP-TE)

  • RFC 4090, Fast Reroute Extensions to RSVP-TE für LSP-Tunnel

  • RFC 4203, OSPF-Erweiterungen zur Unterstützung von Generalized Multi-Protocol Label Switching (GMPLS)

    (OSPF-Erweiterungen können Traffic-Engineering-Informationen über nicht nummerierte Links übertragen.)

  • RFC 4558, Node-ID-basiertes Ressourcenreservierungsprotokoll (RSVP) Hallo, Eine klarstellende Erklärung

  • RFC 4561, Definition eines Knoten-ID-Unterobjekts für Datensatz-Routenobjekt (RRO)

    Das Unterobjekt "RRO-Knoten-ID" ist für die Verwendung in Konfigurationen für den Schutz von Verbindungen und Knoten zwischen ASs vorgesehen.

  • RFC 4875, Erweiterungen von RSVP-TE für Point-to-Multipoint-TE-LSPs

  • RFC 5151, Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions

  • RFC 5420, Codierung von Attributen für die MPLS-LSP-Einrichtung mithilfe des Resource Reservation Protocol Traffic Engineering (RSVP-TE)

    Nur das LSP_ATTRIBUTES-Objekt wird unterstützt.

  • RFC 6437, IPv6-Spezifikation für Flussetiketten

  • RFC 6510, RSVP-Nachrichtenformate (Resource Reservation Protocol) für LSP-Attributobjekte (Label Switched Path)

  • RFC 7570, Label Switched Path (LSP)-Attribut im Explicit Route Object (ERO)

  • RFC 8370, Techniken zur Verbesserung der Skalierbarkeit von RSVP-TE-Bereitstellungen

  • RFC 8577, Signalisieren von RSVP-TE-Tunneln auf einer gemeinsam genutzten MPLS-Weiterleitungsebene

  • RFC 8796, RSVP-TE Zusammenfassung Fast Reroute Extensions for Label Switched Path (LSP) Tunnels

  • draft-ietf-mpls-ri-rsvp-frr-05, Unabhängiger FRR-Anlagenschutz für Aktualisierungsintervalle

Die folgenden RFCs definieren keine Standards, sondern informieren über RSVP und verwandte Technologien. Die IETF klassifiziert sie unterschiedlich als "experimentell" oder "informativ".

  • RFC 2209, Resource ReSerVation Protocol (RSVP) – Nachrichtenverarbeitungsregeln der Version 1

  • RFC 2216, Vorlage für die Servicespezifikation für Netzwerkelemente

  • RFC 4125, Modell für maximale Bandbreitenbeschränkungen für Diffserv-fähiges MPLS Traffic Engineering

  • RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-fähiges MPLS Traffic Engineering

  • RFC 8577, Signalisieren von RSVP-TE-Tunneln auf einer gemeinsam genutzten MPLS-Weiterleitungsebene (vollständig konform)

Unterstützte LDP-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für LDP definieren.

  • RFC 3212, Constraint-basiertes LSP-Setup mit LDP

  • RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol (Graceful-Neustart-Mechanismus für das Label Distribution Protocol)

  • RFC 7060, Verwenden von LDP-Multipoint-Erweiterungen für LDP-Zielsitzungen

  • RFC 8661, Segment-Routing MPLS Interworking mit LDP

  • RFC 8077, Einrichtung und Wartung von Pseudodrahten unter Verwendung des Label Distribution Protocol (LDP)

  • Internet-Entwurfs-draft-napierala-mpls-targeted-mldp-01.txt, Verwenden von LDP-Multipoint-Erweiterungen für LDP-Zielsitzungen

Die folgenden RFCs definieren keine Standards, sondern geben Auskunft über LDP. Die IETF stuft sie als "informativ" ein.

  • RFC 3215, LDP-Zustandsautomat

  • RFC 5036, LDP-Spezifikation

    Für die folgenden Funktionen, die in den angegebenen Abschnitten des RFC beschrieben werden, unterstützt Junos OS einen der möglichen Modi, die anderen jedoch nicht:

    • Kontrolle der Etikettenverteilung (Abschnitt 2.6.1): Der geordnete Modus wird unterstützt, nicht jedoch der unabhängige Modus.

    • Beibehaltung von Etiketten (Abschnitt 2.6.2): Der liberale Modus wird unterstützt, aber nicht der konservative Modus.

    • Label-Werbung (Abschnitt 2.6.3): Es werden sowohl der Modus "Downstream Unsolicited" als auch der Downstream-on-Demand-Modus unterstützt.

  • RFC 5283, LDP-Erweiterung für LSPs (Inter-Area Label Switched Paths)

  • RFC 5443, LDP IGP-Synchronisation

  • RFC 5561, LDP-Funktionen

  • RFC 6512, Verwenden von Multipoint-LDP, wenn der Backbone keine Route zum Stamm hat

    Nur der rekursive undurchsichtige Wert wird unterstützt.

  • RFC 6826, Multipoint-LDP-In-Band-Signalisierung für Point-to-Multipoint- und Multipoint-to-Multipoint-Label Switched Paths

    Die Unterstützung von Junos OS ist auf Point-to-Multipoint-Erweiterungen für LDP beschränkt.

DiffServ-fähige Traffic-Engineering-Standards

Die folgenden RFCs enthalten Informationen zu DiffServ-fähigem Traffic Engineering und Multiklassen-LSPs:

  • RFC 3270, Multi-Protocol Label Switching (MPLS) Unterstützung von differenzierten Diensten

  • RFC 3564, Anforderungen für die Unterstützung von MPLS-Traffic-Engineering mit differenzierten Service-Kenntnissen

  • RFC 4124, Protokollerweiterungen zur Unterstützung von differenziertem MPLS-Traffic-Engineering

  • RFC 4125, Modell für Einschränkungen der maximalen Zuordnungsbandbreite für Diff-Serv-fähiges MPLS Traffic Engineering

  • RFC 4127, Russian Dolls Bandwidth Constraints Model for Diff-Serv-fähiges MPLS

Diese RFCs sind auf der IETF-Website unter http://www.ietf.org/verfügbar.

Unterstützte GMPLS-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für Generalized MPLS (GMPLS) definieren.

  • RFC 3471, Generalized Multi-Protocol Label Switching (GMPLS) Signaling – Funktionsbeschreibung

    Es werden nur die folgenden Funktionen unterstützt:

    • Bidirektionale Sprachdienstleister (nur Upstream-Label)

    • Trennung der Steuerkanäle

    • Verallgemeinerte Bezeichnung (nur vorgeschlagene Bezeichnung)

    • Generalisierte Label-Anforderung (nur Bandbreitencodierung)

  • RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)-Erweiterungen

    Nur Abschnitt 9 "Fehlerbehandlung" wird unterstützt.

  • RFC 4202, Routing-Erweiterungen zur Unterstützung von generalisiertem Multi-Protokoll-Label-Switching

    Es wird nur die Schnittstellenumschaltung unterstützt.

  • RFC 4206, Label Switched Paths (LSP)-Hierarchie mit Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

  • Internet-Entwurf draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, Generalized MPLS (GMPLS) RSVP-TE Signalling in Support of Automatically Switched Optical Network (ASON) (läuft im Januar 2005 aus)

  • Internet-Entwurf draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control

    Es werden nur Labels im S-, U-, K-, L- und M-Format und SONET-Datenverkehrsparameter unterstützt.

  • Internet-Entwurf draft-ietf-ccamp-lmp-10.txt, Link Management Protocol (LMP)

  • Internet-Entwurf draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, OSPF-Erweiterungen zur Unterstützung von Generalized Multi-Protocol Label Switching

    Die folgenden untergeordneten TLV-Typen für den TLV (Link Type, Link, Value) werden nicht unterstützt:

    • Link Local/Remote Identifiers (Typ 11)

    • Verbindungsschutzart (Typ 14)

    • Shared Risk Link Group (SRLG) (Typ 16)

    Die in Abschnitt 2 des Entwurfs beschriebenen Features "Auswirkungen auf den ordnungsgemäßen Neustart" werden ebenfalls nicht unterstützt.

    Der Sub-TLV-Typ Interface Switching Capability Descriptor (Typ 15) ist implementiert, jedoch nur für Paketvermittlung.

  • Internet-Entwurf draft-ietf-mpls-bundle-04.txt, Link-Bündelung im MPLS Traffic Engineering

Unterstützte PCEP-Standards

Junos OS unterstützt im Wesentlichen die folgenden RFCs und Internet-Entwürfe, die Standards für PCEP definieren.

  • RFC 5440, Path Computation Element (PCE) Communication Protocol (PCEP) – Stateful PCE

  • RFC 8231, Path Computation Element Communication Protocol (PCEP) – Erweiterungen für Stateful PCE

  • RFC 8281, Path Computation Element Communication Protocol (PCEP) – Erweiterungen PCE-initiierte LSP-Einrichtung in einem zustandsbehafteten PCE-Modell

  • Internet draft-ietf-pce-stateful-pce-07.txt, PCEP-Erweiterungen für Stateful PCE

  • Internet draft-crabbe-pce-pce-initiated-lsp-03.txt, PCEP-Erweiterungen für PCE-initiierte LSP-Einrichtung in einem Stateful PCE-Modell

  • Internet draft-ietf-pce-segment-routing-06.txt, PCEP-Erweiterungen für Segment-Routing

  • Internet draft-ietf-pce-stateful-pce-p2mp-02.txt, PCE-Protokollerweiterungen (Path Computation Element) für zustandsbehaftete PCE-Nutzung für Point-to-Multipoint-Traffic Engineering Label Switched Paths

  • Internet-Entwurf draft-cbrt-pce-stateful-local-protection-01, PCEP-Erweiterungen für RSVP-TE Local-Protection mit PCE-Stateful (ohne Unterstützung für Bypass-LSP-Mapping )

  • Internet-Entwurf draft-ietf-pce-pcep-flowspec-05, PCEP-Erweiterung für Flow-Spezifikation

    Die aktuelle Implementierung dieser Funktion implementiert die folgenden Abschnitte des Entwurfs nicht:

    • Abschnitt 3.1.2 – Werbung für PCE-Fähigkeiten in IGP

    • Abschnitt 3.2 – PCReq- und PCRep-Nachricht

    • Abschnitt 7 – Die meisten Datenstromspezifikationen, mit Ausnahme der Routenunterscheidungs- und IPv4-Multicast-Datenflussspezifikationen, werden nicht unterstützt.

Verwandte Themen