DE202017105825U1 - Netzmanagementschnittstelle - Google Patents

Netzmanagementschnittstelle Download PDF

Info

Publication number
DE202017105825U1
DE202017105825U1 DE202017105825.5U DE202017105825U DE202017105825U1 DE 202017105825 U1 DE202017105825 U1 DE 202017105825U1 DE 202017105825 U DE202017105825 U DE 202017105825U DE 202017105825 U1 DE202017105825 U1 DE 202017105825U1
Authority
DE
Germany
Prior art keywords
data
network device
request
network
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE202017105825.5U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of DE202017105825U1 publication Critical patent/DE202017105825U1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Netzsystem (100) das umfasst: einen Netzmanager (110); eine Netzvorrichtung (120); Datenverarbeitungs-Hardware (700) in Kommunikation mit der Netzvorrichtung (120); und Speicher-Hardware (720) in Kommunikation mit der Datenverarbeitungs-Hardware (700), wobei die Speicher-Hardware Anweisungen speichert, die dann, wenn sie auf der Datenverarbeitungs-Hardware (700) ablaufen, bewirken, dass die Datenverarbeitungs-Hardware (700) Operationen (442) ausführt, die umfassen: Empfangen einer Anforderung (22) von dem Netzmanager (110), die Daten (21) anfordert, die wenigstens eines aus Zustandsinformationen (344), Konfigurationsinformationen (342) oder Betriebsinformationen (346) umfassen, wobei die Anforderung (22) umfasst: eine Get-Anforderung (320), um eine Momentaufnahme der angeforderten Daten (21), die auf der Netzvorrichtung (120) existieren, zu erhalten; oder eine Subscribe-Anforderung (520), um Aktualisierungen für die angeforderten Daten (21), die auf der Netzvorrichtung (120) existieren, zu abonnieren; und Übertragen einer Datenantwort (24) zu dem Netzmanager (110) über Telemetrie, wobei die Datenantwort (24) die angeforderten Daten (21) umfasst, die Datenelemente aufweisen, die durch wenigstens ein Datenschema definiert sind, das durch die Netzvorrichtung (120) unterstützt wird, wobei die Anforderung (22) und die Antwort (24) einem Protokoll folgen, das konfiguriert ist, bidirektionales Streamen zwischen dem Netzmanager (110) und der Netzvorrichtung (120) zu ermöglichen.

Description

  • Technisches Gebiet
  • Diese Offenbarung bezieht sich auf Netzmanagementschnittstellen.
  • Hintergrund
  • Netzmanagementschnittstellen ermöglichen es Netzmanagementsystemen, mit Netzvorrichtungen (z. B. Routern) sowohl zum Bereitstellen von Änderungen an Konfigurationen darauf als auch Abrufen von Daten von Netzvorrichtungen zu interagieren. Ein Netzmanagementsystem kann mehrere Protokolle für die Bereitstellung von Vorrichtungskonfigurationen und den Abruf von Zustandsinformationen erfordern. Beispielsweise ist ein Netzkonfigurationsprotokoll wie NETCONF im Allgemeinen zur Unterstützung der Bereitstellung von Konfigurationsdaten gut geeignet, erfordert jedoch, dass das Abrufen von Zustandsinformationen von einer Netzvorrichtung getrennt abgefragt werden muss. Andererseits ermöglicht das einfache Netzmanagementprotokoll (SNMP) die Übertragung von Zustandsinformationen von einer Netzvorrichtung zu einem Netzmanagementsystem, ist jedoch im Allgemeinen eine schlechte Wahl zum Aktualisieren einer Konfiguration der Netzvorrichtung.
  • Außerdem unterstützen existierende Netzmanagementschnittstellen im Allgemeinen nur die Übertragung von Daten, die einer spezifizierten Schemadefinitionssprache modelliert sind. Beispielsweise überträgt das SNMP-Protokoll nur ASN.1-modellierte Daten, während das NETCONF-Protokoll YANG als die Schemadefinitionssprache zum Modellieren von Konfigurations- und Zustandsdaten und XML als die einzige Datencodierung verwendet. Moderne Netzvorrichtungen, die zu automatisierten Interaktionen für das Bereitstellen von Konfigurationsdaten übergehen, haben sich jedoch weiterentwickelt, um die Übertragung von Daten in mehreren Formaten zu unterstützen, wie z. B. Datenmodelle in einer Standard-Schemadefinitionssprache (z. B. YANG), in einem Industriestandardformat oder einer anderen Struktur.
  • In Übereinstimmung mit den Anforderungen des Gebrauchsmustergesetzes durch das Gebrauchsmuster zu schützen und Gegenstand des Gebrauchsmusters sind nur Vorrichtungen, wie sie in den beigefügten Ansprüchen definiert sind, jedoch keine Verfahren. In dem Fall, in dem sich die Beschreibung auf Verfahren bezieht, dienen diese Bezugnahmen lediglich dazu, die Einrichtung oder die Einrichtungen zu veranschaulichen, für die in den beigefügten Ansprüchen Schutz begehrt wird.
  • Zusammenfassung
  • Ein Aspekt der Offenbarung stellt ein Verfahren zum Kommunizieren über ein spezifiziertes Protokoll durch Ermöglichen von bidirektionalem Streamen zwischen einem Netzmanager und einer Netzvorrichtung bereit. Das Verfahren enthält Empfangen an einer Datenverarbeitungs-Hardware einer Netzvorrichtung einer Anforderung von dem Netzmanager, die Daten anfordert, die Zustandsinformationen und/oder Konfigurationsinformationen enthalten. Die Anforderung enthält eine Get-Anforderung, um eine Momentaufnahme der angeforderten Daten, die auf der Netzvorrichtung existieren, zu erhalten, oder eine Subscribe-Anforderung, um Aktualisierungen für die angeforderten Daten, die auf der Netzvorrichtung existieren, zu abonnieren. Das Verfahren enthält außerdem Übertragen einer Datenantwort von der Datenverarbeitungs-Hardware zu dem Netzmanager über Telemetrie. Die Datenantwort enthält die angeforderten Daten, die Datenelemente aufweisen, die durch wenigstens ein Datenschema definiert sind, das durch die Netzvorrichtung unterstützt wird. Die Fähigkeits- und Datenanforderungen und die Fähigkeits- und Datenantworten folgen einem Protokoll, das konfiguriert ist, bidirektionales Streamen zwischen dem Netzmanager und der Netzvorrichtung zu ermöglichen.
  • Implementierungen der Offenbarung können eines oder mehrere aus den folgenden optionalen Merkmalen enthalten: In einigen Implementierungen enthalten die Verfahren Empfangen in der Datenverarbeitungs-Hardware einer Capability-Anforderung von dem Netzmanager nach Fähigkeitsinformationen über die Netzvorrichtung und Übertragen von der Datenverarbeitungs-Hardware der Netzvorrichtung einer Capability-Antwort, die die Fähigkeitsinformationen enthält, zu dem Netzmanager über Telemetrie. Die Fähigkeitsinformationen können ein oder mehrere Datenschemas, die durch die Netzvorrichtung unterstützt werden, Codierungen, die durch die Netzvorrichtung unterstützt werden, und eine Version eines Netzmanagementschnittstellendienstes, die durch die Netzvorrichtung unterstützt wird, enthalten.
  • In einigen Beispielen spezifiziert die Get-Anforderung eine Menge von Pfaden, die die angeforderten Daten innerhalb eines oder mehrerer Schemadefinitionsmodellen identifiziert, eingeschränkt durch das wenigstens eine aus den Datenschemas, die durch die Netzvorrichtung zum Gebrauch durch die Netzvorrichtung unterstützt werden, wenn die angeforderten Daten zu dem Netzmanager zurückgegeben werden. Die Get-Anforderung kann außerdem wenigstens eine aus den Codierungen spezifizieren, die durch die Netzvorrichtung zum Gebrauch durch die Netzvorrichtung unterstützt werden, wenn die Menge von Pfaden serialisiert wird.
  • Das Übertragen der Datenantwort kann Übertragen einer Get-Anforderung enthalten, die eine entsprechende Meldungsnachricht für jeden Pfad enthält, der durch die Get-Anforderung spezifiziert ist. Jede Meldungsnachricht kann die Momentaufnahme der angeforderten Daten für den entsprechenden Pfad und ein Zeitstempel-Feld, das eine Zeit angibt, zu der die Netzvorrichtung die Momentaufnahme der angeforderten Daten für den entsprechend Pfad genommen hat, enthalten. Die Subscribe-Anforderung kann eine Menge von Pfaden spezifizieren, die die angeforderten Daten innerhalb eines oder mehrerer Schemadefinitionsmodellen, die durch die wenigstens eine Dateneinheit einschränkt ist, die durch die Netzvorrichtung unterstützt wird, identifizieren, und einen Abonnement-Modus, der Trigger für die Netzvorrichtung angibt, um die Aktualisierungen für die angeforderten Daten zu dem Netzmanager zurückzugeben. Das Übertragen der Datenantwort kann Übertragen einer Subscribe-Antwort enthalten, die ein Aktualisieren-Feld enthält, das eine oder mehrere Meldungsnachrichten enthält, von denen jede einen Aktualisierungswert für einen entsprechenden Pfad, der in der Subscribe-Anforderung spezifiziert ist, bereitstellt.
  • Wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein periodisch abgefragtes Abonnement enthält, kann das Verfahren das Abrufen durch die Datenverarbeitungs-Hardware der angeforderten Daten auf einer Basis pro Datenelement von einer Speicher-Hardware in Kommunikation mit der Datenverarbeitungs-Hardware zu einer Übertragungszeit der Subscribe-Anforderung und Einkapseln durch die Datenverarbeitungs-Hardware der angeforderten Daten in die Subscribe-Antwort enthalten. Wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein Ein-Aus-Abonnement enthält, kann das Verfahren Abrufen durch die Datenverarbeitungs-Hardware der angeforderten Daten auf einer Basis pro Datenelement für jeden entsprechenden Pfad, der durch die Subscribe-Anforderung spezifiziert ist, enthalten, ohne dass die gleichzeitige Serialisierung der Pfade, die durch die Subscribe-Anforderung spezifiziert sind, und Einkapseln durch die Datenverarbeitungs-Hardware der angeforderten Daten in die Subscribe-Antwort über mehrere Meldungsnachrichten erforderlich ist. In einigen Beispielen enthält das Übertragen der Subscribe-Antwort, wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein Stream-Abonnement enthält, Übertragen der Subscribe-Antwort jedes Mal, wenn sich der Aktualisierungswert für den entsprechenden Pfad, der durch die Subscribe-Anforderung spezifiziert ist, ändert, oder Übertragen der Subscribe-Antwort während eines Sample-Intervalls, das durch das Stream-Abonnement spezifiziert ist, wobei die Subscribe-Antwort einen Zeitstempel enthält, der eine Zeit angibt, zu der die angeforderten Daten gesampled wurden.
  • Das Verfahren kann außerdem Abrufen an der Datenverarbeitungs-Hardware einer Set-Anforderung von dem Netzmanager und Bestimmen durch die Datenverarbeitungs-Hardware, ob der Netzmanager fähig ist, die spezifizierte(n) eine oder mehreren Operationen zu verarbeiten. Die Set-Anforderung kann eine oder mehrere Operationen, die die Netzvorrichtung verarbeiten soll, spezifizieren. Wenn der Netzmanager fähig ist, die Operationen, die durch den Netzmanager spezifiziert sind, zu verarbeiten, enthält das Verfahren Verarbeiten durch die Datenverarbeitungs-Hardware der Operationen und Übertragen einer Set-Antwort von der Datenverarbeitungs-Hardware zu dem Netzmanager. Die Set-Antwort kann eine entsprechende Aktualisierungsergebnisantwort für jede der verarbeiteten Operationen enthalten. Die Aktualisierungsergebnisnachricht kann einen Wert für die entsprechende verarbeitete Operation und einen Pfad eines Elements der angeforderten Daten, die durch die entsprechende verarbeitete Operation modifiziert worden sind, angeben. Wenn der Netzmanager nicht fähig ist, wenigstens eine aus den Operationen, die durch den Netzmanager spezifiziert sind, zu verarbeiten, kann das Verfahren Übertragen der Set-Antwort von der Datenverarbeitungs-Hardware zu dem Netzmanager enthalten. Die Set-Antwort kann ein Nachricht-Feld enthalten, das eine Fehlernachricht bereitstellt, die angibt, dass der Netzmanager nicht fähig ist, die durch die Set-Anforderung spezifizierten Operationen zu verarbeiten.
  • Eine oder mehrere Operationen, die durch die Set-Anforderung spezifiziert sind, können wenigstens eines aus einer Löschen-Operation, einer Aktualisieren-Operationen oder einer Ersetzen-Operation enthalten. Das Verfahren kann außerdem vor dem Übertragen der Datenantwort zu dem Netzmanager in Reaktion auf das Empfangen der Datenanforderung Authentifizieren des Netzmanagers durch die Datenverarbeitungs-Hardware enthalten. Das Verfahren kann außerdem Bestimmen durch die Datenverarbeitungs-Hardware enthalten, ob der Netzmanager autorisiert ist, auf die Netzvorrichtung für die angeforderten Daten zuzugreifen. Der Netzmanager kann die Datenantwort zu dem Netzmanager übertragen, wenn der Netzmanager autorisiert und authentifiziert ist.
  • Ein weiterer Aspekt der Offenbarung stellt ein Netzsystem zum Kommunizieren über ein spezifiziertes Protokoll, das bidirektionales Streamen zwischen einem Netzmanager und einer Netzvorrichtung ermöglicht, bereit. Das Netzsystem enthält einen Netzmanager, eine Netzvorrichtung, Datenverarbeitungs-Hardware in Kommunikation mit der Netzvorrichtung und Speicher-Hardware in Kommunikation mit der Datenverarbeitungs-Hardware. Die Speicher-Hardware speichert Anweisungen, die dann, wenn sie auf der Datenverarbeitungs-Hardware ausgeführt werden, bewirken, dass die Datenverarbeitungs-Hardware Operationen ausführt. Die Operationen enthalten Empfangen einer Anforderung von dem Netzmanager, die Daten, die wenigstens eines aus Zustandsinformationen, Konfigurationsinformationen oder Betriebsinformationen umfassen, anfordert, und Senden einer Datenantwort zu dem Netzmanager über Telemetrie. Die Anforderung enthält eine Get-Anforderung, um eine Momentaufnahme der angeforderten Daten, die auf der Netzvorrichtung existieren, zu erhalten, oder eine Subscribe-Anforderung, um Aktualisierungen für die angeforderten Daten, die auf der Netzvorrichtung existieren, zu abonnieren. Die Datenantwort enthält die angeforderten Daten, die Datenelemente aufweisen, die durch wenigstens ein Datenschema, das durch die Netzvorrichtung unterstützt wird, definiert sind. Die Fähigkeits- und Datenanforderungen und die Fähigkeits- und Datenantworten können einem Protokoll folgen, das konfiguriert ist, bidirektionales Streamen zwischen dem Netzmanager und der Netzvorrichtung zu ermöglichen.
  • Dieser Aspekt kann eines oder mehrere aus den folgenden optionalen Merkmalen enthalten. In einigen Implementierungen enthalten die Operationen Empfangen einer Capability-Anforderung von dem Netzmanager nach Fähigkeitsinformationen auf der Netzvorrichtung und Übertragen einer Capability-Antwort, die die Fähigkeitsinformationen umfasst, zu dem Netzmanager über Telemetrie. Die Fähigkeitsinformationen können ein oder mehrere Datenschemas, die durch die Netzvorrichtung unterstützt werden, Codierungen, die durch die Netzvorrichtung unterstützt werden, und eine Version eines Netzmanagementschnittstellendienstes, die durch die Netzvorrichtung unterstützt wird, enthalten.
  • Die Get-Anforderung kann eine Menge von Pfaden spezifizieren, die die angeforderten Daten innerhalb eines oder mehrerer Schemadefinitionsmodellen identifiziert, eingeschränkt durch das wenigstens eine aus den Datenschemas, die durch die Netzvorrichtung zum Gebrauch durch die Netzvorrichtung unterstützt werden, wenn die angeforderten Daten zu dem Netzmanager zurückgegeben werden. Die Get-Anforderung kann außerdem wenigstens eine aus den Codierungen spezifizieren, die durch die Netzvorrichtung zum Gebrauch durch die Netzvorrichtung unterstützt werden, wenn die Menge von Pfaden serialisiert wird. Das Übertragen der Datenantwort kann Übertragen einer Get-Anforderung enthalten, die eine entsprechende Meldungsnachricht für jeden Pfad enthält, der durch die Get-Anforderung spezifiziert ist. Jede Meldungsnachricht kann die Momentaufnahme der angeforderten Daten für den entsprechenden Pfad und ein Zeitstempel-Feld, das eine Zeit angibt, zu der die Netzvorrichtung die Momentaufnahme der angeforderten Daten für den entsprechend Pfad aufgenommen hat, enthalten.
  • Die Subscribe-Anforderung kann eine Menge von Pfaden spezifizieren, die zum die angeforderten Daten innerhalb eines oder mehrerer Schemadefinitionsmodellen identifizieren, die durch die wenigstens eine Dateneinheit einschränkt ist, die durch die Netzvorrichtung unterstützt wird, und einen Abonnement-Modus, der Trigger für die Netzvorrichtung angibt, um die Aktualisierungen für die angeforderten Daten zu dem Netzmanager zurückzugeben. Das Übertragen der Datenantwort kann Übertragen einer Subscribe-Antwort umfassen, die ein Aktualisieren-Feld enthält, das eine oder mehrere Meldungsnachrichten enthält, von denen jede einen Aktualisierungswert für einen entsprechenden Pfad, der in der Subscribe-Anforderung spezifiziert ist, bereitstellt.
  • In einigen Beispielen enthalten die Operationen, wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein periodisch abgefragtes Abonnement enthält, Abrufen der angeforderten Daten auf einer Basis pro Element von der Speicher-Hardware zu einer Übertragungszeit des Subscribe-Anforderung und Einkapseln der angeforderten Daten in die Subscribe-Antwort. Die Operationen können außerdem enthalten, wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein Ein-Aus-Abonnement enthält, Abrufen der angeforderten Daten auf einer Basis pro Datenelement für jeden entsprechenden Pfad, der durch die Subscribe-Anforderung spezifiziert ist, ohne die gleichzeitige Serialisierung der Pfade, die durch die Subscribe-Anforderung spezifiziert sind, und Einkapseln der angeforderten Daten in die Subscribe-Antwort über mehrere Meldungsnachrichten zu erfordern. Das Übertragen der Subscribe-Antwort kann, wenn der Abonnements-Modus, der durch die Subscribe-Anforderung spezifiziert ist, ein Stream-Abonnement enthält, Übertragen der Subscribe-Antwort jedes Mal, wenn sich der Aktualisierungswert für den entsprechenden Pfad, der durch die Subscribe-Anforderung spezifiziert ist, ändert, oder Übertragen der Subscribe-Antwort während eines Sample-Intervalls, das durch das Stream-Abonnement spezifiziert ist, enthalten, wobei die Subscribe-Antwort einen Zeitstempel enthält, der eine Zeit angibt, zu der die angeforderten Daten gesampled wurden.
  • Die Operationen können außerdem Empfangen einer Set-Anforderung von dem Netzmanager und Bestimmen, ob der Netzmanager fähig ist, die spezifizierte(n) eine oder mehreren Operationen zu verarbeiten, enthalten. Die Set-Anforderung kann eine oder mehrere Operationen, die die Netzvorrichtung verarbeiten soll, spezifizieren. Wenn der Netzmanager fähig ist, die Operationen, die durch den Netzmanager spezifiziert sind, zu verarbeiten, enthalten die Operationen Verarbeiten der Operationen und Übertragen einer Set-Antwort zu dem Netzmanager. Die Set-Antwort kann eine entsprechende Aktualisierungsergebnisantwort für jede der verarbeiteten Operationen enthalten, wobei die Aktualisierungsergebnisnachricht einen Wert für die entsprechende verarbeitete Operation und einen Pfad eines Elements der angeforderten Daten, die durch die entsprechende verarbeitete Operation modifiziert worden sind, angibt.
  • Die Operationen können außerdem, wenn der Netzmanager nicht fähig ist, wenigstens eine aus den Operationen, die durch den Netzmanager spezifiziert sind, zu verarbeiten, Übertragen der Set-Antwort zu dem Netzmanager enthalten. Die Set-Antwort kann ein Nachricht-Feld enthalten, das eine Fehlernachricht bereitstellt, die angibt, dass der Netzmanager nicht fähig ist, die durch die Set-Anforderung spezifizierten Operationen zu verarbeiten. Die eine oder mehrere Operationen, die durch die Set-Anforderung spezifiziert sind, können wenigstens eines aus einer Löschen-Operation, einer Aktualisieren-Operationen oder einer Ersetzen-Operation enthalten. Die Operationen können ferner vor dem Übertragen der Datenantwort zu dem Netzmanager in Reaktion auf das Empfangen der Datenanforderung Authentifizieren des Netzmanagers und Bestimmen, ob der Netzmanager autorisiert ist, auf die Netzvorrichtung für die angeforderten Daten zuzugreifen, enthalten. Der Netzmanager kann die Datenantwort zu dem Netzmanager übertragen, wenn der Netzmanager autorisiert und authentifiziert ist.
  • Die Einzelheiten einer oder mehrerer Implementierungen der Offenbarung sind in den begleitenden Zeichnungen und der nachstehenden Beschreibung dargelegt. Andere Aspekte, Merkmale und Vorteile werden aus der Beschreibung und den Zeichnungen und aus den Ansprüchen offensichtlich.
  • Beschreibung der Zeichnungen
  • 1A ist eine schematische Ansicht einer Beispiel-Netzvorrichtung, die ein Telemetriesignal zur Übertragung über ein Netz zu einem Netzmanagementsystem erzeugt.
  • 1B ist eine schematische Ansicht eines Netzmanagementsystems, das Kommunikation zu und von mehreren Netzvorrichtungen überträgt und empfängt.
  • 2A ist eine schematische Ansicht einer Beispiel-Netzvorrichtung, die ein Netzmanagementsystem autorisiert und authentifiziert, das Zugriff auf die Netzvorrichtung anfordert.
  • 2B ist eine schematische Ansicht einer Beispiel-Netzvorrichtung, die eine Capability-Antwort, die Fähigkeitsinformationen enthält, zu einem Netzmanagementsystem überträgt.
  • 3 ist eine schematische Ansicht einer Netzvorrichtung, die eine Get-Anforderung von einem Netzmanagementsystem empfängt und eine Get-Antwort zu dem Netzmanagementsystem zurückgibt.
  • 4A ist eine schematische Ansicht einer Beispiel-Netzvorrichtung, die eine Set-Anforderung, die eine oder mehrere Operationen, die die Netzvorrichtung verarbeiten soll, spezifiziert, empfängt.
  • 4B ist eine schematische Ansicht der Netzvorrichtung von 4A, die eine Set-Antwort, die wenigstens eine Aktualisierungsergebnisantwort enthält, nach dem Verarbeiten der einen oder mehreren Operationen überträgt.
  • 5A ist eine schematische Ansicht einer Beispiel-Netzvorrichtung, die eine Subscribe-Anforderung von einem Netzmanagementsystem zum Abonnieren von Aktualisierungen für Daten, die auf der Netzvorrichtung existieren, empfängt.
  • 5B ist eine schematische Ansicht der Netzvorrichtung von 5A, die eine Subscribe-Antwort überträgt, die eine oder mehrere Meldungsnachrichten enthält, von denen jede einen Aktualisierungswert für einen entsprechenden Pfad, der durch die Subscribe-Anforderung spezifiziert ist, bereitstellt.
  • 6 ist eine schematische Ansicht eines Diagramms von Beispieloperationen, die durch ein Netzmanagementsystem und eine Netzvorrichtung ausgeführt werden, wenn das Netzmanagementsystem eine Kommunikation mit der Netzvorrichtung über ein spezifiziertes Protokoll anfordert.
  • 7 ist eine schematische Ansicht einer Beispiel-Computervorrichtung.
  • 8 ist ein Ablaufplan eines Beispielverfahrens zum Kommunizieren zwischen einem Netzmanagementsystem und einem Netzelement.
  • Gleiche Bezugszeichen in den verschiedenen Zeichnungen geben gleiche Elemente an.
  • Ausführliche Beschreibung
  • Schnittstellen, die zum Interagieren mit Netzvorrichtungen verwendet werden, haben sich aus denen entwickelt, die menschliche Interaktion für das Bereitstellen von Konfigurationsdaten auf der Netzvorrichtung erfordern. Die Implementierungen hier richten sich auf eine allgemeine Schnittstelle, die sowohl die effiziente Übertragung von Zustandsinformationen von einer Netzvorrichtung (z. B. einem Router oder einem anderen Zugangspunkt) zu einem Netzmanagementsystem unterstützen als auch es dem Netzmanagementsystem ermöglichen, die Konfiguration auf der Netzvorrichtung zu modifizieren und/oder abzurufen. Dementsprechend kann das Netzmanagementsystem ein spezifiziertes Protokoll verwenden, um sowohl Zustandsinformationen und Konfigurationsinformationen von der Netzvorrichtung abzurufen als auch die Konfigurationsdaten (d. h. Lese-Schreib-Daten) auf der Netzvorrichtung zu modifizieren, ohne zur Bereitstellung der Konfigurationsdaten auf einen Menschen angewiesen zu sein. Die gemeinsame Schnittstelle ermöglicht bidirektionale Telemetrie-Streams zwischen dem Netzmanagementsystem und der Netzvorrichtung, während sie Interaktion mit vielen unterschiedlichen Schemadefinitionssprachen, die auf der Netzvorrichtung modelliert sein können, bereitstellt.
  • Bezug nehmend auf 1A enthält in einigen Implementierungen ein System 100, 100a eine Netzvorrichtung 120, die mit einem entfernten System 140 über ein Netz 130 kommuniziert. Das entfernte System 140 kann ein verteiltes System (z. B. eine Cloud-Umgebung) sein, das skalierbare/elastische Betriebsmittel 142 aufweist. Die Betriebsmittel 142 enthalten Rechenbetriebsmittel 144 und/oder Speicherbetriebsmittel 146. In einigen Implementierungen führt das entfernte System 140 ein Netzmanagementsystem (NMS) 110 aus, das ein Protokoll zum Übertragen und Empfangen von Kommunikation 20 zu und von der Netzvorrichtung 120 spezifiziert. Das spezifizierte Protokoll ermöglicht bidirektionale Kommunikation 20 zwischen den NMS 110 und der Netzvorrichtung 120. Wie hier verwendet bezieht sich eine Kommunikation 20 auf eine Anforderungsnachricht 22, die das NMS 110 über das Netz 130 zu der Netzvorrichtung 120 unter Verwendung von Telemetrie überträgt, oder eine Antwortnachricht 24, die die Netzvorrichtung 120 über das Netz 130 zu den NMS 110 unter Verwendung von Telemetrie überträgt. Wie hier verwendet bezieht sich der Begriff "Telemetrie" auf Streamen von Daten 21, die den Daten 21, die durch das NMS 110 in der Anforderungsnachricht 22 angefordert werden, oder Daten 21, die durch die Netzvorrichtung 120 abgerufen und zu dem NMS 110 in der Antwortnachricht 24 zurückgegeben/übertragen werden, entsprechen. Die Telemetriedaten 21 können Konfigurationsinformationen 342, Zustandsinformationen 344 und/oder Betriebsinformationen 346, die der Netzvorrichtung 120 zugeordnet sind, zum Gebrauch durch das NMS 110 enthalten.
  • Das Protokoll, das durch das NMS 110 zum Kommunizieren mit der Netzvorrichtung 120 spezifiziert ist, ermöglicht dem NMS 110, den Betriebszustand und/oder die Konfiguration der Netzvorrichtung 120 zu sehen. In einigen Implementierungen führt das NMS 110 Änderungen an dem Betriebszustand und/oder der Konfiguration der Netzvorrichtung 120 aus. Dementsprechend kann die Netzvorrichtung 120 Telemetriedaten 21, die die Konfiguration und/oder den Betriebszustand der Netzvorrichtung 120 enthalten, zu einer gegebenen Zeit zu den NMS 110 übertragen, und das NMS 110 kann Konfigurationsdaten 21 für die Netzvorrichtung 120 bei Bedarf bereitstellen, ohne dass die Netzvorrichtung 120 menschliche Interaktion (z. B. einen Netzadministrator) benötigt, um die Konfiguration der Netzvorrichtung 120 bereitzustellen.
  • Die Netzvorrichtung 120 enthält eine Vorrichtung, die mit anderen Vorrichtungen, Systemen und/oder Netzen kommuniziert. Beispielsweise kann die Netzvorrichtung einem Router, einem Verteiler, einem entfernten Knoten, einer Firewall, einer Sicherheitsvorrichtung, einem Zugangspunkt, einem Thermostaten, einem Modem oder irgendeiner anderen Kommunikationsvorrichtung, die Netzverkehr verarbeiten und/oder weiterleiten kann, entsprechen. Die Netzvorrichtung 120 kann eine eigenständige Vorrichtung sein oder kann mit einer Anwendervorrichtung 102 zum Verbinden der Anwendervorrichtung 102 mit dem Netz 130 betriebstechnisch verbunden sein. In einigen Beispielen implementiert die Anwendervorrichtung 102 (z. B. ein Desktop-Computer oder ein Laptop) die Netzvorrichtung 120. Somit kann die Netzvorrichtung 120 anderen Kommunikationsvorrichtungen wie z. B. einer Computervorrichtung, einer mobilen Vorrichtungen oder einem anderen Anwenderendgerät entsprechen.
  • In einigen Implementierungen enthält das spezifizierte Protokoll, das die bidirektionale Telemetriekommunikation 20 ermöglicht, einen Aufruf einer entfernten Prozedur (RPC), der konfiguriert ist, dem NMS 110 zu ermöglichen, sowohl die Konfiguration der Netzvorrichtung 120 abzurufen und zu modifizieren, als auch die Telemetrie-Streams von Daten 21 von der Netzvorrichtung 120 zu den NMS 110 über das Netz 130 zu steuern und zu erzeugen. In einigen Beispielen ist das spezifizierte Protokoll ein gRPC-basiertes Protokoll, das es einer einzigen Implementierung auf sowohl dem NMS 110 als auch der Netzvorrichtung 120 ermöglicht, miteinander über Telemetrie und Konfigurations-RPCs zu interagieren. Alle Nachrichten innerhalb der gRPC-Dienstdefinition sind als Protokollpuffer (z. B. proto3-Protokollpuffer) definiert. Das Protokoll kann Nutzdaten führen, die Dateninstanzen von OpenConfig-YANG-Schemas enthalten, oder irgendwelche Dateninstanzen mit Eigenschaften, die (1) eine Struktur, die durch eine Baumstruktur repräsentiert sein kann, in der Knoten durch einen Pfad, der Knotennamen enthält, oder Knotennamen, die mit Attributen gekoppelt sind, eindeutig identifiziert werden können, und (2) Werte, die in ein skalares Objekt serialisiert werden können, aufweisen. Beispielsweise können Werte in ein skalares Objekt durch Codieren als eine JavaScript-Objektnotations-Zeichenkette (JSON-Zeichenkette), ein Byte-Array, ein serialisiertes Protobuf-Objekt oder eine andere definierte Serialisierung serialisiert werden. Dementsprechend ist Streaming-Telemetrie ein Paradigma zur Netzüberwachung, in der Daten 21 bidirektional zwischen der Netzvorrichtung 120 und den NMS 110 kontinuierlich mit effizienten inkrementellen Aktualisierungen gestreamt werden. In den Beispielen der 5A und 5B abonniert das NMS 110 spezifische Dateninstanzen der Netzvorrichtung 120, die durch Pfadnamen unter Verwendung von Datenmodellen (z. B. Datenschemas), die durch die Netzvorrichtung 120 unterstützt werden, identifiziert werden.
  • 1A zeigt, wie das NMS 110 das spezifizierte Protokoll verwendet, um eine Kommunikation 20 in der Form einer Anforderung 22 über das Netz 130 zu der Netzvorrichtung 120 zu übertragen. Hier überträgt das NMS 110 die Anforderung 22, um Daten 21 auf der Netzvorrichtung abzufragen und/oder zu modifizieren, oder um als ein Kollektor für gestreamte Daten 21, die von der Netzvorrichtung 120 ausgegeben werden, zu arbeiten. Die Anforderung 22 kann Streamen von Telemetriedaten 21, die den folgenden RPCs entsprechen, enthalten: eine Capability-Anforderung ("CapabilityRequest") 220 (2B); eine Get-Anforderung ("GetRequest") 320 (3); eine Set-Anforderung ("SetRequest") 420 (4A); oder eine Subscribe-Anforderung ("SubscribeRequest") 520 (5A).
  • Andererseits zeigt 1A die Netzvorrichtung 120, die das spezifizierte Protokoll (z. B. gRPC) verwendet, um eine Kommunikation 20 in der Form einer Antwort 24 über das Netz 130 zu dem NMS 110 in Reaktion auf das Empfangen der Anforderung 22 zu übertragen. Die Netzvorrichtung 120 überträgt die Antwort 24, um Daten 21 bereitzustellen, die durch das NMS 110 in der Anforderung 22 angefordert wurden, oder um Änderungen bereitzustellen, die an den zugrundeliegenden Daten 21 auf der Netzvorrichtung 120 vorgenommen wurden. Die Antwort 24 kann Streamen von Telemetriedaten 21, die den folgenden RPCs entsprechen, enthalten: eine Capability-Antwort ("CapabilityResponse") 240 (2B); eine Get-Antwort ("GetResponse") 340 (3); eine Set-Antwort ("SetResponse") 440 (4B); oder eine Subscribe-Antwort ("SubscribeResponse") 540 (5B).
  • In einigen Implementierungen führt die Netzvorrichtung 120 einen Telemetrieprozess 150 zum Streamen der Daten in Echtzeit über Telemetrie aus. Der Telemetrieprozess 150 enthält einen Strategie-Definieren-Schritt (152), einen Codierer-Konfigurieren-Schritt 154 und einen Daten-Streamen-Schritt 156 zum Streamen der Daten 21 zu dem NMS 110. An dem Strategie-Definieren-Schritt definiert der Telemetrieprozess 150 eine Streaming-Häufigkeit zum Streamen der Daten 21. Der Strategie-Definieren-Schritt 152 kann einen Schemapfad der Daten 21, die gestreamt werden sollen, bestimmen, eine Strategiedatei erzeugen, die eine Beschreibung, einen Bezeichner und eine Version aufweist, und den Pfad zu einer Strategiedatei zum Codieren in dem Codierer-Konfigurieren-Schritt 154 hinzufügen. Der Pfad kann durch das NMS 110 in der Anforderung 22, die durch die Netzvorrichtung 120 empfangen wird, spezifiziert sein.
  • In dem Codierer-Konfigurieren-Schritt 153 spezifiziert der Telemetrieprozess 150 ein Format für die gesammelten Daten 21 und codiert die Daten 21 unter Verwendung des spezifizierten Schemas. Beispielsweise kann der Telemetrieprozess 150 die Daten 21 unter Verwendung einer Protokollpuffer-Kompaktcodierung codieren, um die Strategiepfade in Proto-Dateien umzusetzen, und danach die Telemetrie zum Streamen der Daten 21 konfigurieren. In anderen Beispielen kann der Telemetrieprozess 150 die Daten 21 unter Verwendung von JSON und Protokollpuffer-Schlüsselwerten codieren, bevor er die Telemetrie zum Streamen der Daten 21 konfiguriert.
  • In einigen Beispielen spezifiziert das NMS 110 das Format für die Netzvorrichtung 120 zum Verwenden in der Anforderung 22. An dem Daten-Streamen-Schritt 156 streamt der Telemetrieprozess 150 die codierten Daten 21 zu den NMS 110. Die codierten Telemetriedaten 21 können die Konfigurationsinformationen 342, die Zustandsinformationen 344 und/oder Betriebsinformationen 346, die der Netzvorrichtung 120 zugeordnet sind, zum Gebrauch durch das NMS 110 enthalten.
  • Bezug nehmend auf 1B enthält in einigen Implementierungen ein System 100, 100b das NMS 110, das das spezifizierte Protokoll (z. B. gRPC-Protokoll) zum Übertragen und Empfangen von Telemetrie-Kommunikation 20 zu und von mehreren Netzvorrichtungen 120, 120a–n verwendet. Hier enthält jede Kommunikation 20, die von dem NMS 110 zu jeder Netzvorrichtung 120 übertragen wird, eine Anforderung 22, um Daten 21 auf der entsprechenden Netzvorrichtung 120 abzurufen und/oder zu modifizieren, oder um als ein Kollektor für gestreamte Daten 21, die von der entsprechenden Netzvorrichtung 120 ausgegeben werden, zu arbeiten. Ähnlich enthält jede Kommunikation 20, die durch das NMS 110 von den Netzvorrichtungen 120 empfangen wird, eine entsprechende Antwort 24, die Daten 21, die durch das NMS 110 angefordert sind, oder Aktualisierungen, die Änderungen angeben, die an den zugrundeliegenden Daten 21 auf der entsprechenden Netzvorrichtung 120 vorgenommen worden sind, enthält.
  • Eine Kommunikationssitzung zwischen dem NMS 110 und der Netzvorrichtung 120 muss verschlüsselt sein, und weder das NMS 110 noch die Netzvorrichtung 120 kann während der Kommunikationssitzung auf unverschlüsselte Kanäle zurückfallen. In einigen Beispielen ist die Kommunikationssitzung unter Verwendung von Transportschichtsicherung (TLS) verschlüsselt, die mehrere Verfahren zum Austauschen von Schlüsseln, Verschlüsseln von Daten 21 und Authentifizieren von Nachrichtenintegrität zwischen dem NMS 110 und der Netzvorrichtung 120 unterstützt. In einigen Beispielen werden Verbindungen für neue Kommunikationssitzungen wechselseitig authentifiziert. Beispielsweise können das NMS 110 und die Netzvorrichtung 120 jeweils digitale Zertifikate von der anderen Entität validieren, um sicherzustellen, dass die entfernte Entität sowohl bekannt als auch autorisiert ist, sich mit der lokalen Entität zu verbinden.
  • In einigen Implementierungen authentifiziert eine Netzvorrichtung 120 eine RPC-Anforderung 22 von dem NMS 110. Bezug nehmend auf 2A zeigt eine schematische Ansicht 200a, wie das NMS 110 eine RPC-Anforderung 22 zu der Netzvorrichtung 120 streamt, die einen Bezeichner 222 und ein Passwort 224 in den Metadaten 21 der RPC-Anforderung 22 enthält (z. B. das CapabilityRequest 220, das GetRequest 320, das SetRequest 420, oder das SubscribeRequest 520). Die Netzvorrichtung 120 kann bestimmen, ob der Bezeichner 222 autorisiert ist, die entsprechende RPC-Operation anzufordern, und bestimmen, ob das Passwort 224 authentifiziert ist, die entsprechende RPC-Operation anzufordern. Falls der Bezeichner 222 autorisiert ist und das Passwort 224 authentifiziert ist, kann die Netzvorrichtung 120 das NMS 110 authentifizieren und autorisieren, auf die Netzvorrichtung 120 zum Ausführen der entsprechenden RPC-Operation, die in der Anforderung 22 spezifiziert ist, zuzugreifen. Andernfalls kann die Netzvorrichtung 120 eine Fehler-Nachricht in einer Antwort 24 bereitstellen, die das NMS 110 informiert, dass der Bezeichner 222 nicht autorisiert ist und/oder das Passwort 224 nicht authentifiziert ist. In Beispielen, in denen das NMS 110 nur den Bezeichner 222 in der RPC-Anforderung 22 bereitstellt, autorisiert die Netzvorrichtung 120 nur die RPC-Anforderung 22, ohne dass es erforderlich ist, dass die Netzvorrichtung 120 ein Passwort 224 authentifiziert.
  • Bezug nehmend auf 2B verwendet das NMS 110 das CapabilityRequest 220, um Fähigkeitsinformationen 230 von der Netzvorrichtung 120 zu erhalten. Das CapabilityRequest 220 ist ein RPC, der durch das NMS 110 und die Netzvorrichtung 120 als ein initialer Handshake verwendet wird, um Fähigkeitsinformationen 230 auszutauschen. In einigen Implementierungen, wenn das NMS 110 das CapabilityRequest 220 zu der Netzvorrichtung 120 überträgt, muss die Netzvorrichtung 120 mit einem CapabilityResponse 240 antworten, das die Fähigkeitsinformationen 230 für die Netzvorrichtung 120 enthält. Die Fähigkeitsinformationen 230 enthalten ein Feld 242 für unterstützte Modelle, ein Feld 244 für unterstützte Codierungen und ein Feld 246 für die Version der Netzmanagementschnittstelle (NMI-Version).
  • Das Feld 242 für unterstützte Modelle enthält eine Menge von Modelldatennachrichten, von denen jede einem spezifischen Datenmodell zugeordnet ist, das durch die Netzvorrichtung 120 unterstützt wird. Wie hier verwendet bezieht sich ein Datenmodell auf ein Datenschema, das eine Datenstruktur (z. B. einen Datenbaum) für Daten 21, die der Netzvorrichtung 120 zugeordnet sind, darlegt. Jedes Modell, das durch eine entsprechende Modelldatennachricht spezifiziert ist, kann sich auf ein spezifisches Datenschema, ein Bündel von Modulen oder eine Erweiterung oder Abweichung beziehen. Dementsprechend enthält jede Modelldatennachricht ein Name-Feld, das dem Namen des Modells zugeordnet ist, ausgedrückt als eine Zeichenkette, ein Organisation-Feld, das der Organisation zugeordnet ist, die das Modell veröffentlicht, ausgedrückt als eine Zeichenkette, und ein Version-Feld, das der unterstützten Version des Modells zugeordnet ist, ausgedrückt als eine Zeichenkette, die eine Semantikversion eines Katalogeintrags repräsentiert. Die Kombination aus Name, Organisation und Version identifiziert einen Eintrag in dem Modellkatalog eindeutig.
  • Der Datenbaum, der durch die Netzvorrichtung 120 unterstützt wird, ist definiert durch eine Menge von Datenschemas, und das NMS 110 kann diese Datenschemas, die durch die Netzvorrichtung 120 unterstützt werden, erhalten, so dass das NMS 110 valide Modifikationen an dem Datenbaum erzeugen kann und die Daten 21, die durch Get- und Subscribe-RPC-Aufrufe zurückgegeben werden, interpretieren kann. In einigen Beispielen erhält das NMS 110 die Menge von Modelldatennachrichten aus dem Feld 242 für unterstützte Modelle zum nachfolgenden Einschränken einer Menge von Datenschemas, die durch die Netzvorrichtung 120 verwendet werden, so dass das NMS 110 die Daten 21, die von der Netzvorrichtung 10 zurückgegeben werden, gegen eine spezifische Menge von Datenschemas validieren kann. Hier kann das NMS 110 die Daten 21 validieren, selbst wenn die Netzvorrichtung 120 neue Werte zu Datenelementen mit eingeschränkten Werten (z. B. denjenigen, die einen Listentyp repräsentieren) hinzufügt oder neue Datenelemente in den Datenbaum erweitert. In einigen Implementierungen spezifiziert das NMS 110 die Schemas/Modelle zum Gebrauch durch die Netzvorrichtung 120 in den nachfolgenden GetRequest- 320 und/oder SubscribeRequest- 520 RPCs, die zu der Netzvorrichtung 120 übertragen werden. In diesen Implementierungen muss die Netzvorrichtung 120 Datenbaumelemente nutzen, die in Datenschemamodellen außerhalb der spezifizierten Menge von Modellen, die durch das NMS 110 spezifiziert sind, definiert sind, wenn sie mit entsprechenden GetResponse- 340 und/oder SubscribeResponse- 540 RPCs, die zu dem NMS 110 zurückgegeben werden, antwortet.
  • Das Feld 244 für unterstützte Codierungen, das in dem CapabilityResponse enthalten ist, 240 enthält ein Liste-Feld, das den Datencodierungen, die durch die Netzvorrichtung 120 unterstützt werden, zugeordnet ist. Beispielsweise kann die Netzvorrichtung 120 JSON-Codierungen unterstützen, so dass in dem Fall, wenn ein Datenelement an einem spezifizierten Pfad ein Blattknoten ist (d. h. keine Nachfolger aufweist), der Wert des Blatts direkt codiert ist, d. h. kein JSON-Objekt ist erforderlich und ein bloßer JSON-wert ist enthalten. Im Gegensatz dazu, wenn das Datenelement Nachfolgerknoten aufweist, enthält das Wert-Feld eine serialisierte JSON-Entität (z. B. ein Objekt oder Array), die dem referenzierten Element entspricht. Das Feld 246 für die NMI-Version kann die Semantikversion der Dienstes, die durch die Netzvorrichtung 120 unterstützt wird, spezifiziert als eine Zeichenkette spezifizieren.
  • Bezug nehmend auf 3 überträgt in einigen Implementierungen das NMS 110 das GetRequest 320 zu der Netzvorrichtung 120, um eine Momentaufnahme von Daten 21 (z. B. Konfiguration oder Zustand), die auf der Netzvorrichtung 120 existieren, zu erhalten. Die Netzvorrichtung 120 kann die Daten 21 sammeln und zu dem NMS 110 in dem GetResponse 340 übertragen. Dementsprechend ermöglicht es das GetRequest 320 dem NMS 110, eine Menge von Pfaden anzufordern, die die Netzvorrichtung 120 serialisieren und zu den NMS 110 übertragen soll. In Reaktion auf das Empfangen des GetRequest 320 serialisiert die Netzvorrichtung 120 die angeforderten Pfade und gibt das GetResponse 340 zurück. Hier muss das GetResponse 340 die Werte der spezifizierten Blätter zu einer speziellen Sammelzeit widerspiegeln, die für jeden Pfad, der in dem GetRequest 320 spezifiziert ist, unterschiedlich sein kann. In einigen Implementierungen schließt die Netzvorrichtung 120 den Kanal, der durch das GetRequest 320 aufgebaut ist, nach dem Übertragen des GetResponse 340 zu den NMS 110.
  • Im Allgemeinen verwendet das NMS 110 den GetRequest-RPC 320, um eine relativ kleine Menge von Daten 21 von der Netzvorrichtung 120 als ein vollständiges Objekt, z. B. als Teil der Konfiguration, abzurufen. Dementsprechend wird nicht erwartet, dass das GetRequest 320 eine signifikante Betriebsmittellast auf der Netzvorrichtung 120 platziert, wenn es die Daten 21 abruft. Da erwartet wird, dass die Netzvorrichtung 120 eine vollständige Momentaufnahme der angeforderten Daten in dem GetResponse-RPC 340 zurückgibt, ist das GetRequest 320 zum Abrufen sehr großer Datenmengen, wie z. B. des vollständigen Inhalts der Routing-Tabelle oder der vollständigen Bestandsliste der Komponenten der Netzvorrichtung 120 nicht gut geeignet. Stattdessen kann das NMS 110 den SubscribeRequest-RPC 520 von 5A verwenden, wenn es erwünscht ist, große Datenmengen von der Netzvorrichtung 120 abzurufen.
  • Das GetRequest 320 kann eine Pfadliste-Feld, ein Typ-Feld, ein Codierung-Feld und ein Datenmodell-Feld enthalten. Das Pfadliste-Feld identifiziert eine Menge von Pfaden, für die das NMS 110 eine Daten-Momentaufnahme von der Netzvorrichtung 120 anfordert. Der Pfad kann Platzhalter verwenden, und in dem Fall, wenn ein spezifizierter Pfad nicht valide ist, muss die Netzvorrichtung 120 ein Fehler-Feld in dem GetResponse 340 füllen, das den nicht validen Pfad angibt. In einigen Beispielen enthält das GetRequest 320 ein Präfix für jeden Pfad innerhalb des GetRequest 320.
  • In einigen Implementierungen sind Pfade gemäß OpenConfig-Pfad-Konventionen, einer vereinfachten Form von XPATH, repräsentiert. Hier ist ein Pfad durch eine geordnete Liste von Zeichenketten repräsentiert, beginnend mit dem Wurzelknoten und endend an dem spezifischsten Pfadelement. Jeder Pfad kann mit einem Element-Feld, das eine Menge von Pfadelementen als Zeichenketten codiert enthält, und einem Ursprung-Feld, das verwendet werden kann, um den Pfad falls nötig eindeutig zu machen (z. B. kann der Ursprung verwendet werden, um anzugeben, welche Organisation das dem Pfad zugeordnete Datenschema definiert hat), präsentiert sein. Dementsprechend sollte jedes Pfadelement einem Knoten in dem Datenbaum (z. B. Datenstruktur) entsprechen. Beispielsweise kann der Pfad /a/b/c/d codiert sein als:
    Figure DE202017105825U1_0002
    Figure DE202017105825U1_0003
  • Außerdem können Attribute neben dem Knotennamen innerhalb des Pfadelements spezifiziert sein. Beispielsweise würde ein Knoten, der durch /a/e[key=k1]/f/g spezifiziert ist, einen Pfad enthalten, der codiert ist als:
    Figure DE202017105825U1_0004
  • Pfade, die mit der Verkettung von Präfix und Pfad definiert sind und innerhalb der RPC-Anforderung (z. B. GetRequest 320, SetRequest 420 oder SubscribeRequest 520) spezifiziert sind, müssen absolut sein, so dass keine RPCs mit relativen Pfaden erzeugt werden. Zusätzlich kann der Wurzelknoten (‘/’) durch Codieren eines einzelnen Pfadelements als eine leere Zeichenkette wie folgt angegeben sein:
    Figure DE202017105825U1_0005
  • Das Typ-Feld gibt den Typ der Daten 21 an, die von der Netzvorrichtung 120 angefordert werden. Der Typ kann Konfigurationsinformationen 342, Zustandsinformationen 344 und/oder Betriebsinformationen 346 für die Netzvorrichtung 120 enthalten. Die Konfigurationsinformationen 342 enthalten lesbare und/oder schreibbare Eigenschaften (z. B. Lese/Schreibdaten 21) auf der Netzvorrichtung 120 und können durch eine spezifische Menge von Schemamodellen, die durch die Netzvorrichtung 120 unterstützt werden, repräsentiert sein. Beispielsweise falls das Datenschema YANG enthält, können die Konfigurationsinformationen 342 einer "config true"-Menge von Blättern auf der Netzvorrichtung 120 entsprechen. Andererseits enthalten die Zustandsinformationen 344 schreibgeschützte Daten auf der Netzvorrichtung 120. In Yang können die Zustandsinformationen 344 einer "config false"-Menge von Blättern auf der Netzvorrichtung 120 entsprechen. Einige Datenschemas können jedoch die Zustandsinformationen 344 als Text (z. B. Ein, Aus, Fehler) ausdrücken, während andere Datenschemas die Zustandsinformationen als Ganzzahlen (z. B. 0, 1, 2) ausdrücken können. Die Zustandsinformationen 344 können auch spezifischer sein, statt einfach Ein/Aus/Fehler-Zustände für die Netzvorrichtung 120 anzugeben. Beispielsweise können die Zustandsinformationen 344 angeben, ob die Netzvorrichtung 120 überträgt/empfängt oder nicht, oder einen Wert für die Signalstärke der Netzvorrichtung 120 bereitstellen. Die Betriebsinformationen 346 enthalten schreibgeschützte Daten 21 auf der Netzvorrichtung 120, die zu Software-Prozessen, die auf der Netzvorrichtung 120 ablaufen, oder zu externen Interaktionen auf der Netzvorrichtung 120 gehören.
  • Für jeden Pfad, der durch das GetRequest 320 spezifiziert ist, stellt das GetResponse 340, das von der Netzvorrichtung 120 zu den NMS 110 zurückgegeben wird, eine entsprechende Meldung-Nachricht bereit, die ein Zeitstempel-Feld 350 enthält, das eine Zeit angibt, zu der die Netzvorrichtung 120 eine Momentaufnahme der Daten 21 für den entsprechenden Pfad aufgenommen hat. Beispielsweise zeigt 3 das GetResponse 340, das eine Meldung-Nachricht zurückgibt, die eine Momentaufnahme von Daten 21 zum Zeitstempel TS 350 für einen ersten Pfad, der in dem GetRequest 320 spezifiziert ist, enthält. Hier können die Daten 21 irgendeines aus den Konfigurationsinformationen 342, den Zustandsinformationen 344 und/oder den Betriebsinformationen 346 enthalten, die in dem Typ-Feld des GetRequest 320 spezifiziert sind. In Szenarios, in denen das GetRequest 320 den Typ der Daten 21 nicht spezifiziert, kann die Netzvorrichtung 120 jede aus den Konfigurationsinformationen 342, den Zustandsinformationen 344 und den Betriebsinformationen 346 in dem Baum, der aus der Abfrage, die dem GetRequest 320 von dem NMS 110 zugeordnet ist, resultiert, zurückgeben. Das GetResponse 340 kann zusätzliche Meldung-Nachrichten für jeden zusätzlichen Pfad enthalten, wenn das GetRequest 320 eine Liste von Pfaden bereitstellt. Die Momentaufnahme der Daten 21 enthält eine Momentaufnahme der Konfigurationsinformationen 342, der Zustandsinformationen 344 und/oder der Betriebsinformationen 346 für die Netzvorrichtung 120. In einigen Implementierungen reduziert das GetResponse 340 Daten aus mehreren Pfaden nicht in eine einzige Meldung innerhalb des GetResponse 340.
  • Der Feld des Zeitstempels TS 350 des GetResponse 340 kann als eine Anzahl von Nanosekunden repräsentiert seit einer Unix-Epoche (z. B. 1. Januar 1970, 00:00:00 UTC) sein und ist im Allgemeinen als eine signierte 64-Bit-Ganzzahl (int64) codiert. Da der in dem GetResponse 340 zurückgegebene Zeitstempel TS 350 einer Gesamtmenge von Daten 21 zugeordnet ist, können einzelne Datenelemente durch die Netzvorrichtung 120 zu unterschiedlichen Zeiten gesampled/abgerufen worden sein. Dementsprechend kann das NMS 110 den SubscribeRequest-RPC 520 von 5A verwenden, um einen Telemetrie-Stream (z. B. SubscribeResponse 540 von 5B) anzufordern, wenn das NMS eine höhere Genauigkeit für einzelne Datenelemente aus der empfangenen Datenmenge erfordert.
  • Das GetResponse 340 kann auch ein Präfix-Feld und/oder ein Alias-Feld enthalten. Das Präfix ist ein Präfix, das auf alle codierten Pfad-Felder, die in dem GetResponse 340 enthalten sind, angewandt wird. Im Allgemeinen geht das Präfix immer den Pfadelementen voran. Beispielsweise können die Pfade, die innerhalb des GetResponse 340 ausgedrückt sind, durch Verkettung von Präfix + Pfad gebildet werden. Das Alias ist eine Zeichenkette, die ein Alias für das innerhalb des GetResponse 340 spezifizierten Präfix bereitstellt. In einigen Szenarios möchte das NMS 110 oder die Netzvorrichtung 120 Aliasse für einen speziellen Pfad verwenden, so dass aufeinanderfolgende RPCs (z. B. GetResponse 340, SetResponse 440 und/oder SubscribeResponse 540) unter Verwendung des Alias komprimiert werden können, anstatt eine vollständige Repräsentation des Pfads zu verwenden. Somit kann das Verwenden des Alias redundante Informationen entfernen, um die Gesamtlänge der Nachricht der aufeinanderfolgenden RRCs zu reduzieren. In Beispielen, wenn die Netzvorrichtung 120 das Unterstützen von Pfad-Aliassen nicht bereitstellen kann, sollte die maximale Länge der aufeinanderfolgenden RPCs berücksichtigt werden, insbesondere hinsichtlich der Bandbreitennutzung und der Effizienz der Nachrichtenerzeugung. Außerdem können die Pfad-Aliasse als eine Zeichenkette codiert sein und einen Namen aufweisen, dem ein #-Zeichen vorangestellt ist, um Kollidieren zwischen validen Datenpfaden und Aliassen zu vermeiden. Die Netzvorrichtung 120 kann die Aliasse als vollständig erweiterte Pfade spezifizieren, so dass ein einziges Nachschlagen eines Alias ausreichend ist, um einen absoluten Pfad aufzulösen.
  • In einigen Implementierungen stellt das GetResponse 340 eine Fehler-Nachricht bereit, um Fehler in dem GetRequest 320, das durch die Netzvorrichtung 120 von den NMS 110 empfangen wird, anzugeben. Die Fehler-Nachrichten werden durch einen kanonischen RPC-(z. B. gRPC-)Fehlercode für eine spezifizierte Programmiersprache (z. B. Java, Golang, C++) repräsentiert. In einigen Beispielen spezifiziert die Netzvorrichtung 120 eine Freitext-Zeichenkette, die den Kontext des Fehlers angibt, um dem NMS 110 zu ermöglichen, Log-Einträge zu erzeugen, die es einem menschlichen Bediener ermöglichen, sowohl den exakten Fehler, der aufgetreten ist, als auch den Kontext des Fehlers zu verstehen. Im Allgemeinen wird die Netzvorrichtung 120 den kanonischen Fehlercode basierend auf einem erwarteten Verhalten des NMS 110 beim dem Empfangen der Fehler-Nachricht in dem GetResponse 340 wählen. Beispielsweise können Fehlercodes, die angeben, dass das NMS 110 das Senden des GetRequest 320 nachfolgend erneut versuchen kann, verwendet werden, wenn erwartetet wird, dass das erneute Versuchen des GetRequest 320 zu einem anderen Ergebnis, d. h. einem validen Ergebnis, führt. Die Fehler-Nachricht kann einen Code, eine Nachricht und Datenfelder enthalten. Der Code entspricht einem unsignierten 32-Bit-Ganzzahlwert, der dem kanonischen gRPC-Code entspricht, und die Nachricht enthält eine durch einen Menschen lesbare Zeichenkette, die den Fehlerzustand genauer beschreibt. Hier ist nicht erwartet, dass die Zeichenkette maschinenanalysierbar ist, sondern vielmehr Kontextinformationen bereitstellt, die zu anderen vorgelagerten Systemen oder Vorrichtungen weitergegeben werden können. Die Daten stellen eine beliebige Folge von Bytes bereit, um weitere Kontextinformationen, die zu dem Fehler gehören, bereitzustellen. Diese beliebige Folge von Bytes kann als proto.Any codiert sein.
  • Bezug nehmend auf die 4A und 4B überträgt in einigen Implementierungen das NMS 110 einen SetRequest-RPC 420 (4A) zu der Netzvorrichtung 120, der eine oder mehrere Operationen 422, die die Netzvorrichtung 120 verarbeiten soll, spezifiziert, und nach der Verarbeitung jeder aus den Operationen 422 gibt die Netzvorrichtung 120 einen entsprechenden SetResponse-RRC 440 zurück (4B), der eine UpdateResult-Nachricht 446 (4B) für jede aus den verarbeiteten Operationen 442 bereitstellt. Das NMS 110 kann das SetRequest 420 zu der Netzvorrichtung 120 übertragen, um den Zustand der Netzvorrichtung 120 zu modifizieren, und die Netzvorrichtung 120 verarbeitet die in dem SetRequest 420 spezifizierten Operationen.
  • 4A zeigt den SetRequest-RPC 420, der zu der Netzvorrichtung 120 übertragen wird, der die Operation-Felder von Löschen 422, Ersetzen 424 und/oder Aktualisieren 426 enthält, um die eine oder mehreren Operationen 422 zum Verarbeiten durch die Netzvorrichtung 120 zu spezifizieren. Das SetRequest 420 kann ein Präfix spezifizieren, das auf alle Pfade angewandt wird, die innerhalb der Felder 422, 424, 426 des SetRequest 420 definiert sind. Das Löschen-Feld 422 spezifiziert eine Menge von Pfaden zum Entfernen aus dem Datenbaum der Netzvorrichtung. Wie für die Menge von Pfaden, die in dem GetRequest-RPC 320 von 3 spezifiziert sind, kann jeder Pfad in dem Löschen-Feld 422 des SetRequest 420 durch eine geordnete Liste von Zeichenketten repräsentiert sein, beginnend mit dem Wurzelknoten und endend mit dem spezifischsten Pfadelement. Jeder Pfad kann mit einem Element-Feld, das eine Menge von Pfadelementen als Zeichenketten codiert enthält, und einem Ursprung-Feld, das verwendet werden kann, um den Pfad falls nötig eindeutig zu machen (z. B. kann der Ursprung verwendet werden, um anzugeben, welche Organisation das dem Pfad zugeordnete Datenschema definiert hat), präsentiert sein. Dementsprechend sollte jedes Pfadelement einem Knoten in dem Datenbaum (z. B. der Datenstruktur) entsprechen.
  • Das Ersetzen-Feld 424 stellt eine Menge von Aktualisieren-Nachrichten bereit, die Elemente/Pfade des Datenbaums spezifizieren, deren Inhalt ersetzt werden soll. Das Aktualisieren-Feld 426 stellt eine Menge von Aktualisieren-Nachrichten bereit, die Elemente/Pfade des Datenbaums angeben, deren Inhalt aktualisiert werden soll. In einigen Beispielen nutzen das Ersetzen-Feld 424 und/oder das Aktualisieren-Feld 426 eine wiederverwendbare Aktualisieren-Nachricht, um Änderungen an Pfaden, wo ein neuer Wert erforderlich ist, anzugeben. Eine Aktualisieren-Nachricht kann ein Pfad-Feld, das einen codierten Pfad bereitstellt, der den Pfad eines Elements angibt, das modifiziert (z. B. ersetzt oder aktualisiert) werden soll, und ein Wert-Feld, das einen codierten Wert bereitstellt, der den Wert angibt, der auf den spezifizierten Knoten angewandt wird, so dass der Knoten basierend auf dem Kontext der Aktualisieren-Nachricht aktualisiert wird, enthalten. Im Allgemeinen spezifizieren die Ersetzen- und Aktualisieren-Felder 424, 426 des SetRequest 420 Änderungen/Modifikationen an Lese-Schreib-Werten (z. B. Konfigurationsinformationen 342) auf der Netzvorrichtung 120. Die Operationen 442, die in dem Ersetzen-Feld 424 spezifiziert sind, müssen das Verhalten bezüglich irgendwelcher weggelassener Datenelemente in dem Aktualisieren-Feld 426 basierend darauf berücksichtigen, ob sich die weggelassenen Datenelemente auf Nicht-Standardwerte (z. B. eingestellt durch ein früheres SetRequest 420) oder auf nicht modifizierte Standardwerte beziehen. Wenn das Ersetzen-Feld 424 früher eingestellte Werte weglässt, müssen diese Werte als aus dem Datenbaum gelöscht behandelt werden. Andernfalls müssen weggelassene Datenelemente mit ihren Standardwerten auf der Netzvorrichtung 120 erzeugt werden. Andererseits behandeln die Operationen 442, die in dem Aktualisieren-Feld 426 spezifiziert sind, nur den Wert derjenigen Datenelemente, die darin explizit als geändert spezifiziert sind.
  • Für sowohl Ersetzen- als auch Aktualisieren-Operationen 442, falls der Pfad, der in dem entsprechenden Pfad-Feld spezifiziert ist, nicht existiert, erzeugt in einigen Implementierungen die Netzvorrichtung 120 ein Datenbaumelement und füllt das Datenbaumelement mit Daten 21, die in der Aktualisierungsnachricht enthalten sind, die in dem entsprechenden Ersetzen-Feld 424 oder dem entsprechenden Aktualisieren-Feld 426 spezifiziert ist, wenn der Pfad nicht existiert. Wenn nicht valide Werte spezifiziert sind, kann die Netzvorrichtung 120 das Verarbeiten von Aktualisierungen innerhalb des SetRequest 420 beenden, den Datenbaum auf den Zustand vor allen Änderungen zurücksetzen und das SetResponse 440 zurückgeben, das den Fehler angibt, der dem nicht validen Wert zugeordnet ist.
  • Die Netzvorrichtung 120 behandelt das empfangene SetRequest 420 als eine Transaktion durch Verarbeiten der Operationen 442 (z. B. Löschen, Ersetzen und/oder Aktualisieren), die darin enthalten sind. In einigen Implementierungen verarbeitet die Netzvorrichtung 120 die gelöschten Pfade (d. h. wie in dem Löschen-Feld 422 spezifiziert ist), gefolgt von den Pfaden, die ersetzt werden sollen (d. h. wie in dem Ersetzen-Feld 424 spezifiziert ist), und zuletzt die Pfade, die aktualisiert werden sollen (d. h. wie in dem Aktualisieren-Feld 426 spezifiziert ist). Die Netzvorrichtung 120 muss die Reihenfolge von Ersetzen- und Aktualisieren-Feldern 424, 426, die in einem einzigen SetRequest 420 enthalten sind, berücksichtigen. Beispielsweise falls ein einziger Pfad mehrmals für eine einzige Operation 442 innerhalb des Ersetzen-Felds 424 oder des Aktualisieren-Felds 426 spezifiziert ist, dann muss der Zustand der Netzvorrichtung 120 die Anwendung aller Operationen 442 in der Reihenfolge widerspiegeln, selbst wenn die Operationen 442 einander überschreiben.
  • Wenn ein Pfad innerhalb des Löschen-Felds 422 des SetRequest 420 enthalten ist, sollte er von dem Datenbaum der Netzvorrichtung 120 entfernt werden. In Beispielen, in denen der spezifizierte Pfad einem Element entspricht, das Nachfolger aufweist, müssen diese Nachfolger rekursiv gelöscht werden. In einigen Implementierungen muss die Verwendung von Platzhalter-Pfaden durch die Netzvorrichtung 120 erweitert und die entsprechenden Elemente des Datenbaums gelöscht werden. In diesen Implementierungen müssen solche Platzhalter Pfade unterstützen, die einen Teilbaum von Attributen spezifizieren, die benötigt werden, um Einträge innerhalb einer Kollektion (z. B. Liste, Array oder Map) des Datenschemas zu identifizieren.
  • Alle Änderungen, die dem Zustand der Netzvorrichtung 120 entsprechen, die in einem individuellen SetRequest 420 enthalten sind, werden als Teil einer Transaktion betrachtet. Mit anderen Worten werden entweder alle Modifikationen mit dem SetRequest 420 durch die Netzvorrichtung 120 verarbeitet, oder die Netzvorrichtung 120 muss die Zustandsänderungen rückabwickeln, um den Zustand der Netzvorrichtung 120 widerzuspiegeln, bevor die Änderungen angewandt wurden. Dementsprechend spiegelt die Netzvorrichtung 120 keine Änderung wider, bevor alle Änderungen akzeptiert und erfolgreich verarbeitet worden sind. Telemetrie-Aktualisierungsnachrichten (z. B. SetResponse 440) dürfen somit keine Änderung des Zustands widerspiegeln, bis zu der Zeit, wenn die beabsichtigten Modifikationen an den zugrundeliegenden Daten 21 durch die Netzvorrichtung 120 akzeptiert worden sind. Dementsprechend bezieht sich eine "Transaktion" auf ein einziges SetRequest 420, das eine Menge von Änderungen spezifiziert, die gemeinsam angewandt werden sollen und innerhalb des einzelnen SetRequest 420 eingekapselt sind.
  • 4B zeigt den SetResponse-RPC 440, der zu dem NMS 110 übertragen wird, nachdem die Netzvorrichtung 120 die Operationen 442, die in dem empfangenen SetRequest 420 von 4A spezifiziert sind, verarbeitet hat. Das SetResponse 440 kann das Präfix spezifizieren, das auf alle Pfade angewandt wird, die innerhalb der Felder 422, 424, 426 des SetRequest 420 definiert sind. In einigen Implementierungen enthält das SetResponse 440 ein Nachricht-Feld 444 und ein UpdateResult-Feld 446.
  • Das Nachricht-Feld 444 gibt im Allgemeinen den Fertigstellungsstatus der gesamten Transaktion an, die durch die Netzvorrichtung 120 verarbeitet wird. Somit gibt das Nachricht-Feld 444 an, ob die Netzvorrichtung 120 alle Operationen 442, die durch das SetRequest 420 spezifiziert sind, erfolgreich verarbeitet hat. Beispielsweise kann das Nachricht-Feld 444 eine Fehler-Nachricht bereitstellen, wenn eine Aktualisierung nicht erfolgreich auf die Inhalte der Daten 21 angewandt wurde. Die Fehler-Nachricht kann den Code, die Nachricht und Datenfelder enthalten, wie sie vorstehend mit Bezug auf die Fehler-Nachricht des GetResponse 340 von 3 beschrieben sind. Die Fehlernachricht kann einen Fehlercode "ok" enthalten, wenn die Modifikationen/Änderungen an den Daten 21 für die gesamte Transaktion erfolgreich waren. In einigen Implementierungen, wenn das NMS 110 das SetRequest 420 überträgt und die Netzvorrichtung 120 nicht fähig ist, irgendeine der spezifizierten Änderungen anzuwenden/zu verarbeiten, berichtet die Netzvorrichtung 120 die Fehler-Nachricht sowohl in dem Nachricht-Feld 444 des SetResponse 440 als auch in dem UpdateResult-Feld 446 unter einem Fehler-Feld 545 für eine einzelne Operation, das dem Fehler zugeordnet ist. Dementsprechend bestimmt die Netzvorrichtung 120, dass eine gesamte Transaktion fehlschlägt, wenn die Netzvorrichtung 120 irgendeine Operation 442, die durch das SetRequest 420 spezifiziert ist, nicht ausführen kann. Hier kann der Fehlercode für das Nachricht-Feld 444 auf Abgebrochen einstellt werden, während der Fehlercode für das Fehler-Feld 454 innerhalb des UpdateResult-Felds 446, das der fehlgeschlagenen Operation 442 zugeordnet ist, auf Fehler eingestellt werden kann.
  • Das UpdateResult-Feld 446 stellt eine Liste von UpdateResult-Antworten 446a–n bereit, von denen jede einer entsprechenden Operation 442 zugeordnet ist, die durch das SetRequest 420 in den Löschen-, Ersetzen- und Aktualisieren-Felder 422, 424 bzw. 464 spezifiziert sind. Beispielsweise enthält eine erste UpdateResult-Antwort 446a ein Feld 450 für den Zeitstempel TS, ein Pfad-Feld 448, die Operation 442 und das Fehler-Feld 454 für die zugrundeliegende Operation 442, die durch das SetRequest 420 spezifiziert ist. Wie für das Feld 350 für den Zeitstempel TS für das GetResponse 340 von 3 enthält das Zeitstempel-Feld 450 einen codierten Zeitstempel, der die Zeit angibt, zu der der SetRequest-RPC 420 durch die Netzvorrichtung 120 akzeptiert wurde. Das Pfad-Feld 448 enthält den Pfad, der durch das SetRequest 420 (z. B. innerhalb eines aus dem Löschen-, Ersetzen- oder Aktualisieren-Feld 422, 424, 426) für die entsprechende Operation 442 spezifiziert ist, und in Szenarios, in denen das SetRequest 420 kein gemeinsames Präfix verwendet, kann die Netzvorrichtung 120 ein Präfix spezifizieren, um die Wiederholungen von Pfadelementen innerhalb anderer aus den UpdateResult-Antworten 446n zu reduzieren. Das Operation-Feld 442 stellt die Operation (z. B. einen Wert gleich einem aus Löschen, Ersetzen oder Aktualisieren) bereit, die dem spezifizierten Pfad in dem Pfad-Feld 448 entspricht.
  • Das Fehler-Feld 454 stellt die Fehler-Nachricht bereit, wenn die Netzvorrichtung 120 die entsprechende Operation 442 nicht ausführen kann oder auf andere Weise dazu nicht fähig ist. Die Fehler-Nachricht kann den Code, die Nachricht und Datenfelder enthalten, wie sie vorstehend mit Bezug auf die Fehler-Nachricht des GetResponse 340 von 3 beschrieben sind. Das Fehler-Feld 454 kann den codierten Fehler auf "ok" einstellen, wenn die Operation 442 erfolgreich ist. In einigen Beispielen wird die Fehler-Nachricht innerhalb des Fehler-Felds 454 auf "nicht autorisiert" eingestellt, wenn das NMS 110 Metadaten in dem SetRequest 420 spezifiziert, die Authentifizierung durch die Netzvorrichtung 120 erfordern, um die entsprechende Operation auszuführen. Andererseits kann das Fehler-Feld 454 auf "PermissionDenied" eingestellt werden, wenn das NMS 110 nicht die Erlaubnis besitzt, den Pfad, der durch die entsprechende Operation 442 spezifiziert ist, zu modifizieren. Außerdem kann dann, wenn die zugrundeliegende Operation 442 einen Pfad spezifiziert, der durch die Netzvorrichtung 120 nicht analysiert werden kann, das Fehler-Feld 454 auf "InvalidArgument" eingestellt werden, so dass das Nachricht-Feld der Fehler-Nachricht durch Menschen lesbaren Text enthält, der angibt, dass der Pfad, der der zugrundeliegenden Operation 422 zugeordnet ist, nicht analysiert werden konnte. In Implementierungen, wenn die Operation 442 eine Aktualisieren- oder Ersetzen-Operation ist, die einen nicht validen Pfad spezifiziert, kann das Fehler-Feld 454 auf "NotFound" eingestellt werden, so dass das Nachricht-Feld der Fehler-Nachricht einen durch einen Menschen lesbaren Text enthält, der angibt, dass der Pfad, der der zugrundeliegenden Operation 442 zugeordnet ist, nicht valide ist. Außerdem kann das Fehler-Feld 454 auf "InvalidArgument" eingestellt werden, wenn die Operation 442 eine Aktualisieren- oder Ersetzen-Operation ist, die einen nicht validen Wert innerhalb der entsprechenden Aktualisieren-Nachricht in dem Ersetzen-Feld 424 oder dem Aktualisieren-Feld 426 des entsprechenden SetRequest 420 enthält Allgemein wird der "InvalidArgument"-Fehlercode in Szenarios, in denen die Nutzdaten skalare Werte spezifizieren, die nicht dem korrekten Schematyp entsprechen, und in Szenarios, in denen mehrere Werte unter Verwendung einer speziellen Codierung (z. B. JSON), die durch die Netzvorrichtung 120 nicht decodiert werden kann, spezifiziert sind, verwendet.
  • Bezug nehmend auf die 5A und 5B überträgt in einigen Implementierungen das NMS 110 einen SubscribeRequest-RPC 520 (5A) zu der Netzvorrichtung 120, der eine oder mehrere Aktualisierungen spezifiziert, die dem Zustand der Daten 21 (z. B. Dateninstanzen) auf der Netzvorrichtung 120 zugeordnet sind, und die Netzvorrichtung 120 gibt fortgesetzt SubscriptionResponse-RPCs 540 zurück (5B), von denen sich jeder auf den Zustand des Datenbaums (z. B. Konfiguration, Zustand und/oder Betrieb) bezieht, der durch das SubscribeRequest 520 spezifiziert ist. Das SubscribeRequest 520 kann einen Abonnement-Modus 532 spezifizieren, der Trigger für Aktualisierungen für Daten 21, die von der Netzvorrichtung 120 in dem SubscribeResponse 540 gesendet werden, angibt. Alle Anforderungen für neuen Abonnements können innerhalb des SubscribeRequest-RPC 520 eingekapselt sein. Das SubscribeRequest 520 kann spezifizieren, dass der Abonnement-Modus 532 eines aus einem ONCE-Abonnement 532a, einem STREAM-Abonnement 532b oder einem POLL-Abonnement 532c enthält. Das ONCE-Abonnement 532a enthält ein Abonnement, das einen dedizierten Stream (z. B. Telemetrie) aufweist, um Ein-Aus-Daten 21 von der Netzvorrichtung 120 zu dem NMS 110 zurückzugeben. Das STREAM-Abonnement 532b entspricht einem langlebigen Abonnement, das Daten 21 bei dem Auftreten von Triggern, die durch das STREAM-Abonnement 532b spezifiziert sind, streamt. Das POLL-Abonnement 532c verwendet einen Stream, um periodisch eine Menge von Daten 21 von der Netzvorrichtung 120 anzufordern.
  • 5A zeigt, wie das NMS 110 ein SubscribeRequest 520 überträgt, um Aktualisierungen von der Netzvorrichtung 120 für eine spezielle Menge von Pfaden anzufordern. Das SubscribeRequest 520 kann ein Abonnieren-Feld 522, ein Abfragen-Feld 524 und ein Aliasse-Feld 526 enthalten. Das Aliasse-Feld 526 ermöglicht dem NMS 110, ein Alias für die Netzvorrichtung 120 zu erzeugen, das für einen spezifizierten Pfad verwendet wird. Das Aliasse-Feld 526 kann eine AliasList-Nachricht, die eine Liste von Aliassen spezifiziert, die durch einen Zielpfad (codierten Pfad) für jedes Alias repräsentiert ist, und das Alias, das durch das NMS 110 für den entsprechenden Pfad definiert ist, enthalten. In Szenarios, in denen die Netzvorrichtung 120 nicht fähig ist, das Alias, das durch das NMS 110 definiert ist, zu unterstützen, kann die Netzvorrichtung 120 ein SubscribeResponse 540 zurückgeben, das das Fehler-Feld 546 auf einem aus einem InvalidArgument-Fehlercode, wenn das spezifizierte Alias für die Netzvorrichtung nicht zulässig ist, einem AlreadyExists-Fehlercode, wenn das Alias ein Duplikat eines existierenden Alias ist, einem ResourceExhausted-Fehlercode, wenn die Netzvorrichtung 120 unzureichenden Speicher oder Verarbeitungsbetriebsmittel besitzt, um das Alias zu unterstützen, oder einem Unknown-Fehlercode in allen anderen Szenarios eingestellt aufweist.
  • Das Abonnieren-Feld 522 enthält eine SubscriptionList-Nachricht 530, die ein Abonnement-Feld 531, ein Modus-Feld 532, ein Prefix-Feld 533, ein Use_aliases-Feld 534, ein qos-Feld 535, ein Allow_aggregation-Feld 536 und ein Use_models-Feld 537 aufweist. Nur das Abonnement-Feld 531 kann durch das NMS 110 in der SubscriptionList-Nachricht 530 erforderlich sein. Die verbleibenden Felder 532–537 können optional sein.
  • Das Abonnement-Feld 531 in der SubscriptionList-Nachricht 530 enthält eine Menge von Abonnement-Nachrichten, die die neue Menge von Pfaden, die das NMS 110 auf der Netzvorrichtung 120 abonniert, angibt. Eine Abonnement-Nachricht beschreibt generisch eine Menge von Daten 21, die durch das NMS 110 abonniert werden sollen, und enthält einen entsprechenden Pfad. Es ist keine Anforderung vorhanden, dass der Pfad, der durch eine Abonnement-Nachricht spezifiziert ist, derzeit innerhalb des Datenbaums auf der Netzvorrichtung 120 existiert, und deshalb wird die Netzvorrichtung 120 den Kanal mit dem NMS 110 nicht schließen und stattdessen fortfahren, auf die Existenz des Pfads zu einer Zeit in der Zukunft zu überwachen. In einigen Beispielen überträgt die Netzvorrichtung 120 ein SubscribeResponse 540, das ein Fehler-Feld 546 füllt (5B), das auf "NotFound" eingestellt ist, um das NMS 110 zu informieren, dass der Pfad zur Zeit der Erzeugung des Abonnements nicht existiert. Für die STREAM- bzw. POLL-Abonnements 532b, 532c kann das NMS 110 optional zusätzliche Parameter innerhalb der Abonnement-Nachricht spezifizieren.
  • Das Modus-Feld 532 stellt den Typ des Abonnements bereit, der eines aus dem ONCE-Abonnement 532a, dem STREAM-Abonnement 532b oder dem POLL-Abonnement 532c enthält. In einigen Beispielen ist der Standardwert für das Modus-Feld 532 das STREAM-Abonnement 532b. Das NMS 110 kann das ONCE-Abonnement 532a durch Einstellen des Modus-Felds 532 auf das ONCE-Abonnement 532a erzeugen. Ein ONCE-Abonnement 532a agiert als ein Einmal-Anforderung/Antwort-Kanal. Beispielsweise kann die Netzvorrichtung 120 ein relevantes SubscribeResponse 540 erzeugen und übertragen und den Kanal schließen, nachdem der SubscribeResponse 540 übertragen worden ist.
  • In einigen Implementierungen erzeugt das NMS 110 das STREAM-Abonnement 532b durch Übertragen des SubscribeRequest 520 zu der Netzvorrichtung 120, wobei das Modus-Feld 532 auf das STREAM-Abonnement 532b eingestellt ist (in 5A gezeigt). Jeder Eintrag innerhalb der Abonnement-Nachricht des Abonnement-Felds 531 kann mit einem On-Change-Modus oder einem Sampled-Modus spezifiziert sein. Ein STREAM-Abonnement 532b, das mit dem "On-Change"-Modus spezifiziert ist, sendet Datenaktualisierungen nur dann, wenn sich der Wert der Daten 21 ändert. Ein Heartbeat-Intervall kann zusammen mit einem "On-Change"-STREAM-Abonnement 532b spezifiziert werden. Hier wird der Wert des/der Datenelement(e) einmal pro Heartbeat-Intervall gesendet, unabhängig davon, ob sich der Wert geändert hat oder nicht. Andererseits enthält ein STREAM-Abonnement 532b, das mit dem "Sampled"-Modus spezifiziert ist, ein Sample-Intervall, das als eine unsignierte 64-Bit-Ganzzahl, die Nanosekunden repräsentiert, codiert ist. Die Netzvorrichtung 120 kann den Wert des/der Datenelement(e) einmal pro Sample-Intervall zu dem NMS 110 senden. Wenn die Netzvorrichtung 120 nicht fähig ist, das Sample-Intervall zu unterstützen, weist die Netzvorrichtung das STREAM-Abonnement zurück durch Zurückgeben des Sub-scribeResponse 540, wobei das Fehler-Feld auf eine Fehler-Nachricht eingestellt ist, die den InvalidArgument-Fehlercode angibt. In Beispielen, in denen das Sample-Intervall auf null eingestellt ist, muss die Netzvorrichtung 120 das Abonnement erzeugen und die Daten 21 über Telemetrie unter Verwendung des kleinsten möglichen Intervalls übertragen.
  • In einigen Beispielen enthält die Abonnement-Nachricht des Abonnement-Felds 531 für das STREAM-Abonnement 532b optional ein suppress_redundant-Flag, dass, wenn es auf wahr gesetzt ist, die Netzvorrichtung 120 keine Telemetrie-Aktualisierungen erzeugen wird, sofern sich der Wert sich des Pfads, der bei Änderungen berichtet wird, seit der letzten Aktualisierung nicht geändert hat. Allgemein müssen Aktualisierungen nur für individuelle Blattknoten in dem Abonnement, die sich geändert haben, erzeugt werden. Beispielsweise muss für ein Abonnement auf /a/b-, wobei die Blätter c und d vorhanden sind, die von dem b-Knoten abzweigen, eine Aktualisierung für c erzeugt werden und eine Aktualisierung für d darf nicht erzeugt werden, falls sich der Wert von c geändert hat, d jedoch unverändert bleibt. Zusätzlich oder alternativ kann ein heartbeat_interval spezifiziert werden, um das Verhalten des suppress-redundant-Felds in einem Sampled-STREAM-Abonnement 532b zu modifizieren. Hier erzeugt die Netzvorrichtung 120 eine Telemetrie-Aktualisierung pro Heartbeat-Intervall, unabhängig davon, ob das suppress_redundant-Flat auf wahr eingestellt ist. Das Heartbeat-Intervall kann einen Wert enthalten, der als eine unsignierte 64-Bit-Ganzzahl in Nanosekunden spezifiziert ist.
  • In einigen Implementierungen erzeugt das NMS 110 ein Abonnement, das einen durch ein Ziel definierten Modus spezifiziert, der es der Netzvorrichtung 120 ermöglicht, den besten Typ des Abonnements, das erzeugt werden soll, auf einer Basis pro Datenelement auszuwählen. Beispielsweise falls sich der Pfad, der innerhalb der Abonnement-Nachricht spezifiziert ist, auf einige Blätter bezieht, die ereignisgesteuert sind (z. B. ändert sich der Zustand der Netzvorrichtung basierend auf einem externen Trigger), dann kann die Netzvorrichtung 120 das "On-Change"-STREAM-Abonnement 532b erzeugen. Andererseits können Daten, die Zählerwerten zugeordnet sind, die Netzvorrichtung 120 veranlassen, das Sampled-STREAM-Abonnement 532b zu erzeugen.
  • In einigen Implementierungen erzeugt das NMS 110 das POLL-Abonnement 532c für Abruf bei Bedarf von Statistikdaten über langlebige Kanäle. Das POLL-Abonnement 532c spezifiziert eine Menge von abonnierten Pfaden und wird durch Übertragen des SubscribeRequest 520 zu der Netzvorrichtung 120 initiiert, so dass die Abonnement-Nachrichten, die in dem Abonnement-Feld 531 des SubscriptionList 530 enthalten sind, die Menge von Pfaden angeben, die für das NMS 110 von Interesse sind. In einigen Beispielen überträgt das NMS 110 das SubscribeRequest 520 mit dem Abfragen-Feld 524, das eine leere Abfragen-Nachricht enthält. In diesen Beispielen erzeugt die Netzvorrichtung Aktualisierungen für alle entsprechenden Pfade in dem SubscriptionList 530 beim Empfangen des SubscribeRequest 520.
  • Das Prefix-Feld 533 stellt ein gemeinsames Präfix bereit, das auf alle Pfade angewandt wird, die in der SubscriptionList-Nachricht 530 spezifiziert sind, und kann ein Standard-Präfix gleich null enthalten. Das Use_aliases-Feld 534 kann ein Boolesches Flag bereitstellen, das angibt, ob das NMS 110 Aliasse akzeptiert, die der Netzvorrichtung 120 über einen Abonnementkanal zugeordnet sind. Wenn das Boolesche Flag auf wahr eingestellt ist, kann die Netzvorrichtung 120 Aliasse für Pfade innerhalb des Abonnements erzeugen. Irgendwelche Aliasse, die durch die Netzvorrichtung definiert sind, müssen getrennt von einer Aktualisierung für die entsprechenden Datenelement(e) erzeugt werden.
  • Das qos-Feld 535 entspricht einer Paketmarkierung, die zum Erzeugen des SubscribeResponse 540 benutzt wird. Das qos-Feld 535 kann eine einzelne Unterwert-Markierung (z. B. Paketkopf) enthalten, die einen Codepunkt-Wert für unterscheidbare Dienste (DSCP-Wert) als eine unsignierte 32-Bit-Ganzzahl angibt. In Szenarios, in denen das qos-Feld 535 nicht spezifiziert ist, kann die Netzvorrichtung 120 Telemetriedaten unter Verwendung einer Standard-DSCP-Markierung für Verkehr auf Managementebene streamen.
  • Das Allow_aggregation-Feld 536 der SubscriptionList-Nachricht 530 kann einen Booleschen Wert zum Gebrauch durch das NMS 110 bereitstellen, um Schemaelemente, die als für Aggregation geeignet markiert sind, fähig zum Kombinieren in einzelne Telemetrie-Aktualisierungsnachrichten (z. B. SubscribeResponse-RPCs 540) zu ermöglichen. In einigen Beispielen wird Aggregation standardmäßig nicht verwendet. Wenn Aggregation durch sowohl das NMS 110 als auch das spezifizierte Datenschema erlaubt, ist, kann jede Aktualisierungsnachricht ein Schlüsselwertpaar enthalten, wobei der Schlüssel der Pfad zu dem Element innerhalb des Datenbaums sein muss, das durch das Datenschema, das es definiert, explizit als für Aggregation geeignet markiert ist. In einigen Beispielen muss der Wert ein Objekt sein, das die Nachfolger des spezifizierten Datenbaumelements codiert. Für JSON ist der Wert deshalb ein JSON-Objekt, und für Protobuf ist es eine Reihe von binär codierten Protobuf.
  • Das Use_models-Feld 537 stellt eine Modelldatennachricht bereit, die das/die Datenschema(s) zum Gebrauch durch die Netzvorrichtung 120, wenn sie ein Abonnement erzeugt, spezifiziert. In einigen Beispielen muss, wenn das Use_model-Feld 537 ein spezifisches Datenschema spezifiziert, die Netzvorrichtung 120 nur Datenelemente innerhalb des spezifizierten Datenschemas berücksichtigen. Andernfalls kann die Netzvorrichtung 120 alle Datenelemente berücksichtigen, die durch jedes Datenschema definiert sind, das durch die Netzvorrichtung 120 unterstützt wird. Das NMS 110 kann die Datenschemas, die durch die Netzvorrichtung 120 unterstützt werden, aus den Feld 242 für unterstützte Modelle (2B) innerhalb des CapabilityResponse 240 (2B), das von der Netzvorrichtung 120 zurückgegeben wird, erhalten. Wie vorstehen dargelegt, kann die Modelldatennachricht das Name-Feld, das dem Namen des Modells entspricht, ausgedrückt als eine Zeichenkette, das Organisation-Feld, das der Organisation zugeordnet ist, die das Modell veröffentlicht hat, ausgedrückt als eine Zeichenkette, und das Version-Feld, das der unterstützten Version des Modells zugeordnet ist, ausgedrückt als eine Zeichenkette enthalten.
  • Die Netzvorrichtung 120 erzeugt Nachrichten basierend auf dem Typ des Abonnements, der in dem empfangenen SubscribeRequest 530 spezifiziert ist, und die durch das NMS 110 angeforderte Häufigkeit. Die Abonnements entsprechen einer Menge von Pfaden (d. h. definiert in dem Abonnieren-Feld 522 des empfangenen SubscribeRequest 520), die über die Lebensdauer des Abonnements nicht modifiziert werden kann. Um ein Abonnement zu beenden, muss das NMS 110 den gRPC-Kanal, über den der SubscribeRequest-RPC 520 initiiert wurde, schließen oder die gesamte gRPC-Sitzung mit der Netzvorrichtung 120 abbrechen. Abonnements sind grundsätzlich eine Menge unabhängiger Aktualisieren-Nachrichten, die in SubscribeResponse-RPCs 540 enthalten sind, die sich auf den Zustand des Datenbaums beziehen. Mit anderen Worten ist es nicht möglich, dass das NMS 110 ein Abonnement anfordert, um anzunehmen, dass die Menge von Aktualisieren-Nachrichten, die mit den SubscribeResponse-RPCs 540 empfangen werden, eine Momentaufnahme des Datenbaums zu einem speziellen Zeitpunkt repräsentieren. Abonnements ermöglichen es deshalb dem NMS 110, (1) fortgesetzte Aktualisierungen (d. h. das STREAM-Abonnement 532b) von der Netzvorrichtung 120 zu empfangen, um Synchronisation zwischen dem NMS 110 und der Netzvorrichtung 120 für den Zustand von Elementen innerhalb des Datenbaums zu ermöglichen, und (2) eine einzelne Ansicht (d. h. das ONCE-Abonnement 532a oder das POLL-Abonnement 532c) für Elemente des Datenbaums auf einer Basis pro Datenelement gemäß dem Zustand der Elemente zu der Zeit, wenn das SubscribeRequest 520 übertragen wird, zu empfangen. In dem Fall des STREAM-Abonnements 532b empfängt das NMS 110 eine initiale Menge von Aktualisierungen, empfängt eine Nachricht, die angibt, dass die initiale Synchronisation vollständig ist, und empfängt nachfolgende Aktualisierungen, die Änderungen an dem initialen Zustand dieser Elemente angeben. In dem Fall von Abonnements für eine einzelne Ansicht (z. B. dem ONCE-Abonnement 532a oder dem POLL-Abonnement 532c) muss die Netzvorrichtung 120 Werte nicht in eine einzige Momentaufnahmenansicht wie mit dem GetResponse 340 zusammenführen oder eine zusätzliche speicherinterne Repräsentation eines Teilbaums zur Zeit der Anforderung erzeugen und nachfolgend die gesamte Ansicht zu dem NMS 110 übertragen.
  • Bezug nehmend auf 5B enthält das SubscribeResponse 540, das von der Netzvorrichtung 120 zu dem NMS 110 über den Kanal, der durch das entsprechende SubscribeRequest 520 aufgebaut ist, zurückgegeben wird, eine Menge von Antwort-Feldern, die ein Aktualisieren-Feld, ein Sync-Antwort-Feld 544 und ein Fehler-Feld 546 enthält. Das Aktualisieren-Feld 542 enthält Meldungsnachrichten, die einen Aktualisierungswert für einen spezifizierten Pfad und ein Feld für einen Zeitstempel 350, das eine Zeit angibt, zu der die Netzvorrichtung 120 den Wert des Pfads, der aktualisiert wird, gesammelt hat, bereitstellen. In einigen Implementierungen muss, wenn sich der Wert eines Blattknotens geändert hat oder ein neuer Knoten erzeugt worden ist, eine Aktualisierungsnachricht, die den Pfad und den Wert für das aktualisierte Datenelement spezifiziert, an das Aktualisieren-Feld 542 des SubscribeResponse 540 angehängt werden. In einigen Beispielen muss, wenn ein Knoten innerhalb der abonnierten Pfade entfernt worden ist, ein Löschen-Feld der Meldungsnachricht einen Pfad des entfernten Knotens aufweisen, der an das Aktualisieren-Feld 542 angehängt ist. Außerdem kann die Meldungsnachricht des Aktualisieren-Felds 542 ein Alias, das durch die Netzvorrichtung 120 definiert ist, und einen Alias-Pfad innerhalb eines Präfix-Felds und ein bei-Null-Alias-Feld spezifizieren.
  • In einigen Implementierungen muss das SubscribeResponse 540, dessen Sync-Antwort-Feld 544 auf wahr eingestellt ist, zu dem NMS 110 übertragen werden, um anzugeben, dass die initiale Übertragung einer initialen Aktualisierung geendet hat, wenn die Netzvorrichtung 120 die Übertragung der initialen Aktualisierungen für alle Pfade, die innerhalb des SubscriptionList 530 des SubscribeRequest 520 spezifiziert sind, fertigstellt. Dadurch wird das NMS 110 informiert, dass alle existierenden Daten für das Abonnement durch die Netzvorrichtung 120 wenigstens einmal übertragen worden sind. In einigen Beispielen muss, nachfolgend der Übertragung aller Aktualisierungen, die den Datenelementen innerhalb der eingestellten Pfade, die innerhalb des SubscriptionList 530 des SubscribeRequest 520 spezifiziert sind, entsprechen, der Kanal, über den der entsprechende SubscribeRequest empfangen wurde, geschlossen werden.
  • 6 ist ein Diagramm 600, das Beispieloperationen darstellt, die durch das NMS 110 und die Netzvorrichtung 120 ausgeführt werden, wenn das NMS 110 eine Kommunikationssitzung mit der Netzvorrichtung 120 anfordert. Bei Operation 602 überträgt das NMS 110 eine Anforderung 22 für die Kommunikationssitzung mit der Netzvorrichtung 120, und bei Operation 604 akzeptiert die Netzvorrichtung 120 die Kommunikationssitzung und stellt eine Antwort 24 bereit, die das NMS 110 informiert, dass die Kommunikationssitzung akzeptiert ist. Ein spezifiziertes Protokoll (z. B. ein gRPC-basiertes Protokoll) ermöglicht bidirektionale Telemetriekommunikation 20 zwischen dem NMS 110 und der Netzvorrichtung 120 für die Kommunikationssitzung. In einigen Beispielen ist die Kommunikationssitzung wechselseitig authentifiziert. Bei Operation 606 kann das NMS 110 das CapabilityRequest 220 zu der Netzvorrichtung 120 übertragen, um Fähigkeitsinformationen 230 von ihr anzufordern. Bei Operation 608 überträgt die Netzvorrichtung 120 das CapabilityResponse 240 zu dem NMS 110. Das CapabilityResponse 240 enthält die angeforderten Fähigkeitsinformationen 230. Die Fähigkeitsinformationen 230 können das Feld 242 für unterstützte Modelle, das Feld 244 für unterstützte Codierungen und das Version-Feld 246 von 2B enthalten.
  • In einigen Implementierungen verwendet das NMS 110 die Fähigkeitsinformationen 230, die von der Netzvorrichtung 120 zurückgegeben werden, wenn es nachfolgende Anforderungen 22 zu der Netzvorrichtung 120 überträgt. Beispielsweise überträgt bei Operation 610 das NMS 110 eine Anforderung 22 zu der Netzvorrichtung 120, die eines aus dem GetRequest 320, dem SetRequest 420 oder dem SubscribeRequest 520 enthält. Jede aus den Anforderungen 420, 420, 520, die durch die Netzvorrichtung 120 bei Operation 612 empfangen werden, kann ein oder mehrere Datenschemas und Codierungen spezifizieren, die durch die Netzvorrichtung 120 zum Gebrauch wenn sie die entsprechenden GetResponse 340, SetResponse 440 oder SubscribeResponse 540 zurückgibt unterstützt werden. In einigen Beispielen erkennt das NMS 110 die Codierungen und/oder Datenschemas, die durch die Netzvorrichtung 120 unterstützt werden, aus dem entsprechenden Feld 242 für unterstützte Modelle und/oder dem entsprechenden Feld 244 für unterstützte Codierungen innerhalb der Fähigkeitsinformationen 230 des CapabilityResponse 240.
  • Das GetRequest 320 spezifiziert eine Menge von Pfaden, die Daten 21 auf der Netzvorrichtung 120 identifizieren, und kann optional einen oder mehrere Typen der Daten 21 spezifizieren. Die Typen können eine oder mehrere aus den Konfigurationsinformationen 342, den Zustandsinformationen 344 oder den Betriebsinformationen 346 enthalten. Falls das GetRequest 320 den einen oder die mehreren Typen der angeforderten Daten 21 nicht spezifiziert, kann die Netzvorrichtung 120 jede aus den Konfigurationsinformationen 342, den Zustandsinformationen 344 und den Betriebsinformationen 346, die auf der Netzvorrichtung 120 existieren, abrufen, wenn das GetRequest 320 empfangen wird.
  • Das SetRequest 420 spezifiziert eine oder mehrere Operationen 442, die die Netzvorrichtung 120 verarbeiten soll. Die Operationen 422 können eine Löschen-Operation, die in einem Löschen-Feld 422 des SetRequest 420 spezifiziert ist, eine Ersetzen-Operation, die in einem Ersetzen-Feld 424 des SetRequest 420 spezifiziert ist, und/oder eine Aktualisieren-Operation, die in einem Aktualisieren-Feld 426 des SetRequest 420 spezifiziert ist, enthalten.
  • Das SubscribeRequest 520 ist konfiguriert, dem NMS 110 zu ermöglichen, Aktualisierungen für angeforderte Daten 21, die auf der Netzvorrichtung 120 existieren, zu abonnieren. Das SubscribeRequest 520 kann einen Menge von Pfaden (z. B. innerhalb des Abonnement-Felds 531 der SubscriptionList-Nachricht 530), die die angeforderten Daten 21 identifizieren, und einen Abonnement-Modus 532, der Trigger für die Netzvorrichtung angibt, die Aktualisierungen für die angeforderten Daten 21 zu dem NMS 110 zurückzugeben, spezifizieren. Der Abonnement-Modus 532 kann auf eines aus einem ONCE-Abonnement 532a, einem STREAM-Abonnement 532b oder einem POLL-Abonnement 532c eingestellt sein.
  • Bei Operation 612 überträgt die Netzvorrichtung 120 das entsprechende GetResponse 340, SetResponse 440 oder SubscribeResponse 540. Das GetResponse 340 enthält eine entsprechende Meldungsnachricht für jeden Pfad, der in dem vorher empfangenen GetRequest 320 spezifiziert ist. Bezug nehmend auf 3 kann jede Meldungsnachricht eine Momentaufnahme der angeforderten Daten 21 für den entsprechenden Pfad und einen Zeitstempel 350, der eine Zeit angibt, zu der die Netzvorrichtung 120 die Momentaufnahme der angeforderten Daten 21 für den entsprechend Pfad genommen hat, enthalten. Bei Operation 612 benutzt das NMS 110 die Daten 21, die in dem entsprechenden GetResponse 340, SetResponse 440 oder SubscribeResponse 540 bereitgestellt sind.
  • Das SetResponse 440 enthält ein Nachricht-Feld 444, das angibt, ob eine gesamte Transaktion die dem SetRequest 420 zugeordnet ist, erfolgreich war oder nicht, und eine UpdateResult-Antwort 446a–n für jede Operation 442, die durch das SetRequest 420 spezifiziert ist. Falls die Netzvorrichtung 120 nicht fähig ist, irgendeine aus den Operationen 442 zu verarbeiten, schlägt die gesamte Transaktion fehl, und das Nachricht-Feld 444 enthält eine Fehlernachricht, die das NMS 110 über die fehlgeschlagene Transaktion informiert. Jede UpdateResult-Antwort 446a–n gibt einen Wert für die entsprechende verarbeitete Operation (z. B. eine Menge gleich einem aus Löschen, Ersetzen oder Aktualisieren) und ein Element der angeforderten Daten 21, das durch die entsprechende verarbeitete Operation 442 modifiziert ist, an. Für die Operation 442, die die Netzvorrichtung 120 nicht verarbeiten kann, kann die entsprechende UpdateResult-Antwort 446a–n eine Fehler-Nachricht innerhalb eines Fehler-Felds 454 bereitstellen, um das NMS 110 zu informieren, dass die Netzvorrichtung 120 nicht fähig ist, die entsprechende Operation 442 zu verarbeiten.
  • Das SubscribeResponse 540 enthält ein Aktualisieren-Feld 542, das eine oder mehrere Meldungsnachrichten aufweist, von denen jede einen Aktualisierungswert für einen entsprechenden Pfad, der durch das SubscribeRequest 520 spezifiziert ist, bereitstellt. Für das ONCE-Abonnement 532a oder das POLL-Abonnement 532c kann die Netzvorrichtung 120 die angeforderten Daten 21 auf einer Basis pro Datenelement zu einer Übertragungszeit des SubscribeRequest 520 abrufen und danach die abgerufenen Daten 21 in den SubscribeResponse 540 zur Übertragung zu dem NMS 110 einkapseln. Für das STREAM-Abonnement 532b, das in dem On-Change-Modus spezifiziert ist, überträgt die Netzvorrichtung 120 das SubscribeResponse 540 jedes Mal, wenn der aktualisierte Wert für den entsprechenden Pfad, der durch das SubscribeRequest 520 spezifiziert ist, aktualisiert wird. Für das STREAM-Abonnement 532b, das in der Sampled-Betriebsart spezifiziert ist, überträgt die Netzvorrichtung 120 das SubscribeResponse 540 während des Sample-Intervalls, das durch das STREAM-Abonnement 532b spezifiziert ist.
  • 7 ist eine schematische Ansicht einer Beispiel-Computervorrichtung 700 (z. B. der Datenverarbeitungs-Hardware), die verwendet werden kann, um die in diesem Dokument beschriebenen Systeme und Verfahren zu implementieren. Die Computervorrichtung 700 ist dafür vorgesehen, verschiedene Formen von digitalen Computern, wie z. B. Laptops, Desktops, Workstations, persönliche digitale Assistenten, Server, Blade-Server, Mainframes und andere geeignete Computer zu repräsentieren. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sind nur als beispielhaft gedacht und sollen nicht bedeuten, die Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen einzuschränken. Die Netzvorrichtung 120 kann die Computervorrichtung 700 implementieren. Zusätzlich oder alternativ kann das Netzmanagementsystem 110 die Computervorrichtung 700 implementieren.
  • Die Computervorrichtung 700 enthält einen Prozessor 710 (z. B. die Datenverarbeitungs-Hardware), einen Speicher 720, eine Speichervorrichtung 730, eine Hochgeschwindigkeitsschnittstelle/steuereinheit 740, die mit dem Speicher 720 und den Hochgeschwindigkeitserweiterungsanschlüsse 750 verbunden ist, und eine Niedergeschwindigkeitsschnittstelle/steuereinheit 760, die mit dem Niedergeschwindigkeitsbus 770 und der Speichervorrichtung 730 verbunden ist. Alle aus den Komponenten 710, 720, 730, 740, 750 und 760 sind unter Verwendung verschiedener Busse miteinander verbunden und können auf einer gemeinsamen Hauptplatine oder auf andere Weise montiert sein, wie jeweils anwendbar. Der Prozessor 710 kann Anweisungen zur Ausführung innerhalb der Computervorrichtung 700 verarbeiten, die Anweisungen enthalten, die in dem Speicher 720 oder der Speichervorrichtung 730 gespeichert sind, um grafische Informationen für eine grafische Anwenderschnittstelle (GUI) auf einer externen Eingabe/Ausgabevorrichtung wie z. B. der Anzeigevorrichtung 780, die mit der Hochgeschwindigkeitsschnittstelle 740 gekoppelt ist, anzuzeigen. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet werden, wie jeweils anwendbar, zusammen mit mehreren Speichern und Speichertypen. Außerdem können mehrere Computervorrichtungen 700 verbunden sein, wobei jede Vorrichtung Teile der notwendigen Operationen bereitstellt (z. B. als eine Server-Bank, eine Gruppe von Blade-Servern oder mein Mehrprozessorsystem).
  • Der Speicher 720 speichert Informationen nicht-transitorisch innerhalb der Computervorrichtung 700. Der Speicher 720 kann ein computerlesbares Medium, eine flüchtige Speichereinheit(en) oder nichtflüchtige Speichereinheit(en) sein. Der nicht-transitorische Speicher 720 kann physikalische Vorrichtungen sein, die verwendet werden, um Programme (z. B. Folgen von Anweisungen) oder Daten (z. B. Programmzustandsinformationen) auf einer temporären oder permanenten Basis zum Gebrauch durch die Computervorrichtung 700 zu speichern. Beispiele für nichtflüchtigen Speicher enthalten, sind jedoch nicht beschränkt auf, Flash-Speicher und Festwertspeicher (ROM) / programmierbaren Festwertspeicher (RPOM) / löschbaren programmierbaren Festwertspeicher (EPROM) / elektronisch löschbaren programmierbaren Festwertspeicher (EEPROM) (z. B. typischerweise verwendet für Firmware wie z. B. Boot-Programme). Beispiele für flüchtigen Speicher enthalten, sind jedoch nicht beschränkt auf, Direktzugriffsspeicher (RAM), dynamischen Direktzugriffsspeicher (DRAM), statischen Direktzugriffsspeicher (SRAM), Phasenwechselspeicher (PCM) und außerdem auch Platten oder Bänder.
  • Die Speichervorrichtung 730 kann Massenspeicher für die Computervorrichtung 700 bereitstellen. In einigen Implementierungen ist die Speichervorrichtung 730 ein computerlesbares Medium. In verschiedenen unterschiedlichen Implementierungen kann die Speichervorrichtung 730 eine Diskettenvorrichtung, eine Festplattenvorrichtung, eine Vorrichtung mit optischer Platte oder eine Bandvorrichtung, ein Flash-Speicher oder eine ähnliche Festkörperspeichervorrichtung oder ein Array aus Vorrichtungen, das Vorrichtungen in einem Speicherbereichsnetz enthält, oder andere Konfigurationen sein. In zusätzlichen Implementierungen ist ein Computerprogrammprodukt materiell in einem Informationsträger integriert. Das Computerprogrammprodukt enthält Anweisungen, die dann, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie z. B. die vorstehend beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium wie z. B. der Speicher 720, die Speichervorrichtung 730 oder der Speicher auf dem Prozessor 710.
  • Die Hochgeschwindigkeitssteuereinheit 740 managt bandbreitenintensive Operationen für die Computervorrichtung 700, während die Niedergeschwindigkeitssteuereinheit 760 weniger bandbreitenintensive Operationen managt. Eine solche Zuweisung von Aufgaben ist nur beispielhaft. In einigen Implementierungen ist die Hochgeschwindigkeitssteuereinheit 740 mit dem Speicher 720, der Anzeigevorrichtung 780 (z. B. über einen Grafikprozessor oder Beschleuniger) und mit den Hochgeschwindigkeitserweiterungsanschlüssen 750, die verschiedene Erweiterungskarten (nicht gezeigt) aufnehmen können, gekoppelt. In einigen Implementierungen ist die Niedergeschwindigkeitssteuereinheit 760 mit der Speichervorrichtung 730 und dem Niedergeschwindigkeitserweiterungsanschluss 770 gekoppelt. Der Niedergeschwindigkeitserweiterungsanschluss 770, der verschiedene Kommunikationsanschlüsse (z. B. USB, Bluetooth, Ethernet, drahtloses Ethernet) enthalten kann, kann mit einer oder mehreren Eingabe/Ausgabevorrichtungen wie z. B. einer Tastatur, einer Zeigevorrichtung, einem Scanner oder einer Vernetzungsvorrichtung wie z. B. einem Verteiler oder einem Router z. B. über einen Netzadapter verbunden sein.
  • Die Computervorrichtung 700 kann in einer Anzahl von unterschiedlichen Formen implementiert sein, wie in der Figur gezeigt ist. Beispielsweise kann sie als ein Standard-Server 700a oder mehrfach in einer Gruppe solcher Server 700a, als ein Laptop-Computer 700b oder als Teil eines Rack-Server-Systems 700c implementiert sein.
  • 8 stellt eine Beispielanordnung von Operationen für ein Verfahren 800 zum Kommunizieren zwischen einem Netzmanagementsystem (NMS) 110 und einer Netzvorrichtung 120 über ein spezifiziertes Protokoll, das bidirektionales Streamen zwischen ihnen ermöglicht, dar. Der Ablaufplan startet bei Operation 802, wenn die Datenverarbeitungs-Hardware 700 der Netzvorrichtung 120 ein CapabilityRequest 220 von dem NMS 110 für Fähigkeitsinformationen 230 auf der Netzvorrichtung 120 empfängt. Bei Operation 804 überträgt die Datenverarbeitungs-Hardware 700 ein CapabilityResponse 240, das die Fähigkeitsinformationen 230 enthält, zu dem NMS 110 über Telemetrie. Die Fähigkeitsinformationen 230 können ein oder mehrere Datenschemas, die durch die Netzvorrichtung 120 unterstützt werden, enthalten.
  • Bei Operation 806 empfängt die Datenverarbeitungs-Hardware 700 eine Datenanforderung 320, 520 von dem NMS 110, die Daten 21 anfordert, die wenigstens eines aus Konfigurationsinformationen 342 oder Zustandsinformationen 344 enthalten. Die Datenanforderung 320, 520 spezifiziert wenigstens eines aus den Datenschemas, die durch die Netzvorrichtung 120 zum Gebrauch durch die Netzvorrichtung 120 unterstützt werden, wenn sie die angeforderten Daten 21 zu dem NMS 110 zurückgibt.
  • Bei Operation 808 überträgt die Datenverarbeitungs-Hardware eine Datenantwort 340, 540 zu dem NMS 110 über Telemetrie. Die Datenantwort 340, 540 enthält die angeforderten Daten 21, die Datenelemente aufweisen, die durch das spezifizierte wenigstens eine Datenschema definiert sind. Die Fähigkeits- und Datenanforderungen 220, 320, 520 und die Fähigkeits- und Datenantworten 240 340, 540 folgen dem spezifizierten Protokoll.
  • Eine Software-Anwendung (d. h. ein Software-Betriebsmittel) kann sich auf Computer-Software beziehen, die bewirkt, dass eine Computervorrichtung eine Aufgabe ausführt. In einigen Beispielen kann eine Software-Anwendung als eine "Anwendung", eine "App" oder ein "Programm" bezeichnet sein. Beispielanwendungen enthalten, sind jedoch nicht beschränkt auf, Systemdiagnoseanwendungen, Systemmanagementanwendungen, Systemwartungsanwendungen, Textverarbeitungsanwendungen, Tabellenkalkulationsanwendungen, Nachrichtenübermittlungsanwendungen, Medien-Streaming-Anwendungen, Anwendungen für soziale Netzwerke und Spiele-Anwendungen.
  • Der nicht-transitorische Speicher kann physikalische Vorrichtungen sein, die verwendet werden, um Programme (z. B. Folgen von Anweisungen) oder Daten (z. B. Programmzustandsinformationen) auf einer temporären oder permanenten Basis zum Gebrauch durch eine Computervorrichtung zu speichern. Der nicht-transitorische Speicher kann flüchtiger und/oder nichtflüchtiger adressierbarer Halbleiterspeicher sein. Beispiele für nichtflüchtigen Speicher enthalten, sind jedoch nicht beschränkt auf, Flash-Speicher und Festwertspeicher (ROM) / programmierbaren Festwertspeicher (RPOM) / löschbaren programmierbaren Festwertspeicher (EPROM) / elektronisch löschbaren programmierbaren Festwertspeicher (EEPROM) (z. B. typischerweise verwendet für Firmware wie z. B. Boot-Programme). Beispiele für flüchtigen Speicher enthalten, sind jedoch nicht beschränkt auf, Direktzugriffsspeicher (RAM), dynamischen Direktzugriffsspeicher (DRAM), statischen Direktzugriffsspeicher (SRAM), Phasenwechselspeicher (PCM) und außerdem auch Platten oder Bänder.
  • Verschiedene Implementierungen des Systems und der Techniken, die hier beschrieben sind, können in digitaler elektronischer und/oder optischer Schaltungsanordnung, integrierter Schaltungsanordnung, speziell konstruierten ASICs (anwendungsspezifischen integrierten Schaltungen), Computer-Hardware, Firmware, Software und/oder Kombinationen daraus realisiert werden. Diese verschiedenem Implementierungen können Implementierungen in einem oder mehreren Computerprogrammen enthalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das wenigstens einen programmierbaren Prozessor, der ein Spezial- oder Allzweck-Prozessor sein kann, der gekoppelt ist, um Daten und Anweisungen von einem Speichersystem zu empfangen oder zu ihm zu übertragen, wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung enthält.
  • Diese Computerprogramme (auch als Programme, Software, Softwareanwendung oder Code bezeichnet) enthalten Maschinenanweisungen für einen programmierbaren Prozessor und können in einer prozeduralen und/oder objektorientierten Programmierhochsprache und/oder ein Assembler-/Maschinensprache implementiert sein. Wie sie hier verwendet sind, können sich die Begriffe "maschinenlesbares Medium" und "computerlesbares Medium" auf irgendein Computerprogrammprodukt, nicht-transitorisches computerlesbares Medium, Einrichtung und/oder Vorrichtung (z. B. magnetische Platten, optische Platten, Speicher, programmierbare Logik-Vorrichtungen (PLDs)) beziehen, die verwendet werden, um Maschinenanweisungen und/oder Daten für einen programmierbaren Prozessor bereitzustellen, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als ein maschinenlesbares Signal empfängt. Der Begriff "maschinenlesbares Signal" bezieht sich auf jedes Signal, das verwendet wird, um maschinenlesbare Anweisungen und/oder Daten für einen programmierbaren Prozessor bereitzustellen.
  • Die Prozesse und Logikabläufe, die in dieser Spezifikation beschrieben sind, können durch einen oder mehrere programmierbare Prozessoren ausgeführt werden, die ein oder mehrere Computerprogramme ablaufen lassen, um Funktionen durch Arbeiten auf Eingabedaten und Erzeugen einer Ausgabe auszuführen. Die Prozesse und Logikabläufe können auch durch eine Spezial-Logikschaltungsanordnung, z. B. ein FGPA (feldprogrammierbares Gatterfeld) oder eine ASIC (anwendungsspezifische integrierte Schaltung) ausgeführt werden. Prozessoren, die für die Ausführung eines Computerprogramms geeignet sind, enthalten als Beispiel sowohl Allzweck- als auch Spezial-Mikroprozessoren und irgendeinen oder mehrere Prozessoren irgendeiner Art eines digitalen Computers. Allgemein wird ein Prozessor Anweisungen und Daten von einem Festwertspeicher oder einem Direktzugriffsspeicher oder beiden empfangen. Die wesentlichen Elemente eines Computers sind ein Prozessor zum Ausführen von Anweisungen und eine oder mehrere Speichervorrichtungen zum Speichern von Anweisungen und Daten. Allgemein wird ein Computer auch eine oder mehrere Massenspeichervorrichtungen zum Speichern von Daten, z. B. magnetische, magneto-optische Platten oder optische Platten, enthalten oder betriebstechnisch damit gekoppelt sein, um Daten von ihnen zu empfangen, zu ihnen zu übertragen oder beides. Ein Computer muss jedoch solche Vorrichtungen nicht aufweisen. Computerlesbare Medien, die zum Speicher von Computerprogrammanweisungen und Daten geeignet sind, enthalten alle Formen von nichtflüchtigem Speicher, Medien und Speichervorrichtungen, die als Beispiel Halbleiterspeichervorrichtungen, z. B. EPROM, EEPROM und Flash-Speichervorrichtungen enthalten; Magnetplatten, z. B. interne Festplatten oder herausnehmbare Platten; magneto-optische Platten; und CD ROM und DVD-ROM-Platten. Der Prozessor und der Speicher können durch eine Spezial-Logikschaltungsanordnung ergänzt oder darin integriert sein.
  • Um die Interaktion mit einem Anwender bereitzustellen, können ein oder mehrere Aspekte der Offenbarung auf einem Computer implementiert sein, der eine Anzeigevorrichtung, z. B. einen CRT-(Kathodenstrahlröhren-), LCD-Monitor (Flüssigkristallanzeige-Monitor) oder einen berührungssensitiven Bildschirm zum Anzeigen von Informationen für den Anwender und optional eine Tastatur und eine Zeigevorrichtung, z. B. eine Maus oder einen Trackball, durch die der Anwender Eingaben für den Computer bereitstellen kann, aufweist. Andere Arten von Vorrichtungen können verwendet werden, um ebenfalls Interaktion mit einem Anwender bereitzustellen; beispielsweise kann eine für den Anwender bereitgestellte Rückmeldung irgendeine Form sensorischer Rückmeldung sein, z. B. visuelle Rückmeldung, hörbare Rückmeldung oder tastbare Rückmeldung; und eine Eingabe von dem Anwender kann in irgendeiner Form empfangen werden, die akustische, Sprach- oder tastbare Eingabe enthält. Zusätzlich kann ein Computer mit einem Anwender durch Senden von Dokumenten zu einer Vorrichtung und Empfangen von Dokumenten von einer Vorrichtung, die durch den Anwender verwendet wird, interagieren; beispielsweise durch Senden von Web-Seiten zu einem Web-Browser auf einer Clientvorrichtung eines Anwenders in Reaktion auf Anforderungen, die von dem Web-Browser empfangen werden.
  • In einer weiteren Implementierung ist ein Verfahren (800) zum Kommunizieren über ein spezifiziertes Protokoll, das bidirektionales Streamen zwischen einem Netzmanager (110) und einer Netzvorrichtung (120) ermöglicht, bereitgestellt. Das Verfahren enthält Empfangen an einer Datenverarbeitungs-Hardware (700) einer Netzvorrichtung einer Anforderung (22) von dem Netzmanager, die Daten (21) anfordert, die Zustandsinformationen (344) und/oder Konfigurationsinformationen (342) enthalten. Die Anforderung enthält eine Get-Anforderung, um eine Momentaufnahme der angeforderten Daten, die auf der Netzvorrichtung existieren, zu erhalten, oder eine Subscribe-Anforderung, um Aktualisierungen für die angeforderten Daten, die auf der Netzvorrichtung existieren, zu abonnieren. Das Verfahren enthält außerdem Übertragen einer Datenantwort (24) von der Datenverarbeitungs-Hardware zu dem Netzmanager über Telemetrie. Die Datenantwort enthält die angeforderten Daten, die Datenelemente aufweisen, die durch wenigstens ein Datenschema definiert sind, das durch die Netzvorrichtung unterstützt wird. Die Anforderung und die Antwort folgen einem Protokoll, das konfiguriert ist, bidirektionales Streamen zwischen dem Netzmanager und der Netzvorrichtung zu ermöglichen.
  • Eine Anzahl von Implementierungen ist beschrieben worden. Nichtsdestotrotz ist zu verstehen, dass verschiedene Modifikationen vorgenommen werden können, ohne vom Geist und Schutzbereich der Offenbarung abzuweichen. Dementsprechend sind andere Implementierungen innerhalb des Schutzbereichs der folgenden Ansprüche.

Claims (14)

  1. Netzsystem (100) das umfasst: einen Netzmanager (110); eine Netzvorrichtung (120); Datenverarbeitungs-Hardware (700) in Kommunikation mit der Netzvorrichtung (120); und Speicher-Hardware (720) in Kommunikation mit der Datenverarbeitungs-Hardware (700), wobei die Speicher-Hardware Anweisungen speichert, die dann, wenn sie auf der Datenverarbeitungs-Hardware (700) ablaufen, bewirken, dass die Datenverarbeitungs-Hardware (700) Operationen (442) ausführt, die umfassen: Empfangen einer Anforderung (22) von dem Netzmanager (110), die Daten (21) anfordert, die wenigstens eines aus Zustandsinformationen (344), Konfigurationsinformationen (342) oder Betriebsinformationen (346) umfassen, wobei die Anforderung (22) umfasst: eine Get-Anforderung (320), um eine Momentaufnahme der angeforderten Daten (21), die auf der Netzvorrichtung (120) existieren, zu erhalten; oder eine Subscribe-Anforderung (520), um Aktualisierungen für die angeforderten Daten (21), die auf der Netzvorrichtung (120) existieren, zu abonnieren; und Übertragen einer Datenantwort (24) zu dem Netzmanager (110) über Telemetrie, wobei die Datenantwort (24) die angeforderten Daten (21) umfasst, die Datenelemente aufweisen, die durch wenigstens ein Datenschema definiert sind, das durch die Netzvorrichtung (120) unterstützt wird, wobei die Anforderung (22) und die Antwort (24) einem Protokoll folgen, das konfiguriert ist, bidirektionales Streamen zwischen dem Netzmanager (110) und der Netzvorrichtung (120) zu ermöglichen.
  2. System (100) nach Anspruch 1, wobei die Operationen (442) ferner umfassen: Empfangen einer Capability-Anforderung (220) von dem Netzmanager (110) für Fähigkeitsinformationen (230) auf der Netzvorrichtung (120); und Übertragen einer Capability-Antwort (240), die die Fähigkeitsinformationen (230) umfasst, zu dem Netzmanager (110) über Telemetrie, wobei die Fähigkeitsinformationen (230) ein oder mehrere Datenschemas (242), die durch die Netzvorrichtung (120) unterstützt werden, Codierungen (244), die durch die Netzvorrichtung (120) unterstützt werden, und eine Version (246) eines Netzmanagementschnittstellendienstes, die durch die Netzvorrichtung (120) unterstützt wird, umfassen.
  3. System (100) nach Anspruch 2, wobei die Get-Anforderung (320) eine Menge von Pfaden spezifiziert, die die angeforderten Daten (21) innerhalb eines oder mehrerer Schemadefinitionsmodelle identifiziert, eingeschränkt durch das wenigstens eine aus den Datenschemas, die durch die Netzvorrichtung (120) zum Gebrauch durch die Netzvorrichtung (120) unterstützt werden, wenn die angeforderten Daten (21) zu dem Netzmanager (110) zurückgegeben werden).
  4. System (100) nach Anspruch 3, wobei die Get-Anforderung (320) außerdem wenigstens eine aus den Codierungen spezifiziert, die durch die Netzvorrichtung (120) zum Gebrauch durch die Netzvorrichtung (120) unterstützt werden, wenn die Menge von Pfaden serialisiert wird.
  5. System (100) nach Anspruch 3, wobei das Übertragen der Datenantwort (24) Übertragen einer Get-Antwort (340) umfasst, die eine entsprechende Meldungsnachricht für jeden Pfad, der durch die Get-Anforderung (320) spezifiziert ist, umfasst, wobei jede Meldungsnachricht eine Momentaufnahme der angeforderten Daten (21) für den entsprechenden Pfad und ein Zeitstempel-Feld (450), das eine Zeit angibt, zu der die Netzvorrichtung (120) die Momentaufnahme der angeforderten Daten (21) für den entsprechenden Pfad aufgenommen hat, umfasst.
  6. System (100) nach Anspruch 2, wobei die Subscribe-Anforderung (520) eine Menge von Pfaden zum Identifizieren der angeforderten Daten (21) innerhalb eines oder mehrerer Schemadefinitionsmodelle, die durch die wenigstens eine Dateneinheit (21) einschränkt ist, die durch die Netzvorrichtung (120) unterstützt werden, und einen Abonnement-Modus (532), der Trigger für die Netzvorrichtung (120) angibt, die Aktualisierungen für die angeforderten Daten (21) zu dem Netzmanager (110) zurückzugeben, spezifiziert.
  7. System (100) nach Anspruch 6, wobei das Übertragen der Datenantwort (24) Übertragen einer Subscribe-Antwort (540) umfasst, die ein Aktualisieren-Feld enthält, das eine oder mehrere Meldungsnachrichten enthält, von denen jede einen Aktualisierungswert für einen entsprechenden Pfad, der in der Subscribe-Anforderung (520) spezifiziert ist, bereitstellt.
  8. System (100) nach Anspruch 7, wobei die Operationen (442) ferner umfassen, wenn der Abonnements-Modus (532), der durch die Subscribe-Anforderung (520) spezifiziert ist, ein periodisch abgefragtes Abonnement umfasst: Abrufen der angeforderten Daten (21) auf einer Basis pro Datenelement aus der Speicher-Hardware zu einer Übertragungszeit der Subscribe-Anforderung (520); und Einkapseln der angeforderten Daten (21) in die Subscribe-Antwort (540).
  9. System (100) nach Anspruch 7, wobei die Operationen (442) umfassen, wenn der Abonnements-Modus (532), der durch die Subscribe-Anforderung (520) spezifiziert ist, ein Ein-Aus-Abonnement umfasst: Abrufen der angeforderten Daten (21) auf einer Basis pro Datenelement für jeden entsprechenden Pfad, der durch die Subscribe-Anforderung (520) spezifiziert ist, ohne gleichzeitiges Serialisieren der Pfade, die durch die Subscribe-Anforderung (520) spezifiziert sind, zu erfordern; und Einkapseln der angeforderten Daten (21) in die Subscribe-Antwort (540) über mehrere Meldungsnachrichten.
  10. System (100) nach Anspruch 7, wobei das Übertragen der Subscribe-Antwort (540) umfasst, wenn der Abonnements-Modus (532), der durch die Subscribe-Anforderung (520) spezifiziert ist, ein Stream-Abonnement umfasst: Übertragen der Subscribe-Antwort (540) jedes Mal, wenn sich der Aktualisierungswert für einen entsprechenden Pfad, der durch die Subscribe-Anforderung (520) spezifiziert ist, ändert; oder Übertragen der Subscribe-Antwort (540) während eines Sample-Intervalls, das durch das Stream-Abonnement spezifiziert ist, wobei die Subscribe-Antwort (540) einen Zeitstempel (350) enthält, der eine Zeit angibt, zu der die angeforderten Daten (21) gesampelt wurden.
  11. System (100) nach einem der Ansprüche 1–10, wobei die Operationen (442) ferner umfassen: Empfangen einer Set-Anforderung (420) von dem Netzmanager (110), wobei die Set-Anforderung (420) eine oder mehrere Operationen (442) spezifiziert, die die Netzvorrichtung (120) verarbeiten soll; Bestimmen, ob der Netzmanager (110) fähig ist, die spezifizierte eine oder mehreren Operationen (442) zu verarbeiten; und wenn der Netzmanager (110) fähig ist, die Operationen (442), die durch den Netzmanager (110) spezifiziert sind, zu verarbeiten: Verarbeiten der Operationen (442); und Übertragen einer Set-Antwort (440) zu dem Netzmanager (110), wobei die Set-Antwort (440) eine entsprechende Aktualisierungsergebnisnachricht (446) für jede aus den verarbeiteten Operationen (442) umfasst, wobei die Aktualisierungsergebnisnachricht (446) einen Wert für die entsprechende verarbeitete Operation (442) und den Pfad eines Elements der angeforderten Daten (21), die durch die entsprechende verarbeitete Operation (442) modifiziert sind, angibt.
  12. System (100) nach Anspruch 11, wobei die Operationen (442), wenn der Netzmanager (110) nicht fähig ist, wenigstens eine aus den Operationen (442), die durch den Netzmanager (110) spezifiziert sind, zu verarbeiten, ferner Übertragen der Set-Antwort (440) zu dem Netzmanager (110) umfassen, wobei die Set-Antwort (440) ein Nachricht-Feld (444) umfasst, das eine Fehler-Nachricht bereitstellt, die angibt, dass der Netzmanager (110) nicht fähig ist, die Operationen (442), die durch die Set-Anforderung (420) spezifiziert sind, zu verarbeiten.
  13. System (100) nach Anspruch 11, wobei die eine oder mehreren Operationen (442), die durch die Set-Anforderung (420) spezifiziert sind, wenigstens eine aus einer Löschen-Operation (422), einer Aktualisieren-Operation (426) oder einer Ersetzen-Operation (424) umfassen.
  14. System (100) nach einem der Ansprüche 1–13, wobei die Operationen (442) vor dem Übertragen der Datenantwort (24) zu dem Netzmanager (110) ferner umfassen: in Reaktion auf Empfangen der Datenanforderung (22), Authentifizieren des Netzmanagers (110); und Bestimmen, ob der Netzmanager (110) autorisiert ist, auf die Netzvorrichtung (120) für die angeforderten Daten (21) zuzugreifen, wobei der Netzmanager (110) die Datenantwort (24) zu dem Netzmanager (110) überträgt, wenn der Netzmanager (110) autorisiert und authentifiziert ist.
DE202017105825.5U 2016-11-04 2017-09-26 Netzmanagementschnittstelle Active DE202017105825U1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/343,876 US10785278B2 (en) 2016-11-04 2016-11-04 Network management interface
US15/343,876 2016-11-04

Publications (1)

Publication Number Publication Date
DE202017105825U1 true DE202017105825U1 (de) 2018-01-18

Family

ID=60037690

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202017105825.5U Active DE202017105825U1 (de) 2016-11-04 2017-09-26 Netzmanagementschnittstelle

Country Status (5)

Country Link
US (2) US10785278B2 (de)
EP (1) EP3526994B1 (de)
DE (1) DE202017105825U1 (de)
DK (1) DK3526994T3 (de)
WO (1) WO2018084947A1 (de)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10785278B2 (en) * 2016-11-04 2020-09-22 Google Llc Network management interface
US10848839B2 (en) * 2017-06-09 2020-11-24 American Megatrends International, Llc Out-of-band telemetry data collection
US10966005B2 (en) * 2018-03-09 2021-03-30 Infinera Corporation Streaming telemetry for optical network devices
US10778517B2 (en) 2018-03-23 2020-09-15 Hewlett Packard Enterprise Development Lp System and method for validating correctness of changes to network device configurations
US10749759B2 (en) * 2018-03-23 2020-08-18 Hewlett Packard Enterprise Development Lp System and method to provide network insights for correct and efficient network configuration
US10887190B2 (en) 2018-03-23 2021-01-05 Hewlett Packard Enterprise Development Lp System for simultaneous viewing and editing of multiple network device configurations
WO2019233616A1 (en) * 2018-06-06 2019-12-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for merging of yang configuration and state data in model-driven applications
CN111355601B (zh) * 2018-12-21 2022-05-10 华为技术有限公司 信息传输方法和装置
KR102025885B1 (ko) * 2018-12-26 2019-09-26 주식회사 파블로항공 군집 무인 항공 시스템 환경을 위한 실시간 통신 장치
EP3921979B1 (de) * 2019-02-08 2023-11-22 Microsoft Technology Licensing, LLC Modellgesteuerter dienst-rollbackmechanismus für datenintegrität
US11579998B2 (en) 2019-03-14 2023-02-14 Nokia Solutions And Networks Oy Device telemetry control
US10896196B2 (en) * 2019-03-14 2021-01-19 Nokia Solutions And Networks Oy Data retrieval flexibility
US20200295997A1 (en) * 2019-03-14 2020-09-17 Nokia Solutions And Networks Oy Device management clustering
US11579949B2 (en) * 2019-03-14 2023-02-14 Nokia Solutions And Networks Oy Device application support
CN112187525B (zh) * 2019-10-31 2021-08-20 华为技术有限公司 设备管理方法、装置、系统、设备及存储介质
CN111130868A (zh) * 2019-12-16 2020-05-08 北京华为数字技术有限公司 一种处理故障信息的方法及相关设备
EP4079009A4 (de) * 2019-12-17 2022-11-23 Telefonaktiebolaget Lm Ericsson (Publ) Beobachtung von ressourcen durch einen coap-client
CN113132127A (zh) * 2019-12-30 2021-07-16 中兴通讯股份有限公司 网络设备管理方法、系统及网络设备
CN111541662B (zh) * 2020-04-15 2022-09-23 赞同科技股份有限公司 一种基于二进制通信协议的通信方法、电子设备及存储介质
US11509543B2 (en) * 2020-05-21 2022-11-22 Charter Communications Operating, Llc Open-source architecture for remote physical or remote physical-media access control device
CN115695134A (zh) * 2021-07-30 2023-02-03 华为技术有限公司 一种查询方法、装置及设备
US20230362078A1 (en) * 2022-05-05 2023-11-09 Juniper Networks, Inc. Simple network management protocol object history collector management information base to curtail management traffic

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002077213A (ja) * 2000-09-05 2002-03-15 Hitachi Kokusai Electric Inc 加入者無線アクセスシステム
KR100357636B1 (ko) * 2000-12-01 2002-10-25 삼성전자 주식회사 망 관리장치에서 경보정보 관리방법
US20020174207A1 (en) * 2001-02-28 2002-11-21 Abdella Battou Self-healing hierarchical network management system, and methods and apparatus therefor
US20030061333A1 (en) 2001-05-04 2003-03-27 Stephen Dean System and method for universal networked device management
US7188160B2 (en) * 2002-01-22 2007-03-06 Ericsson Ab Method and apparatus for updating network device configuration information in a network management system
GB0222549D0 (en) * 2002-09-30 2002-11-06 Marconi Comm Ltd Monitoring telecommunication network elements
KR100453824B1 (ko) * 2002-12-11 2004-10-20 한국전자통신연구원 이기종 네트워크 장비의 구성 관리를 위한 엑스엠엘 기반망 관리 시스템 및 방법
US7826353B2 (en) * 2003-05-05 2010-11-02 Nokia Corporation Method, system and network element for authorizing a data transmission
US7529825B1 (en) * 2003-12-02 2009-05-05 Cisco Technology, Inc. Server-side XML-based development environment for network device management applications
EP1782246B1 (de) * 2004-07-07 2020-02-12 Sciencelogic, LLC Selbstkonfigurierendes netzwerkverwaltungssystem
JP4845467B2 (ja) * 2004-11-08 2011-12-28 株式会社エヌ・ティ・ティ・ドコモ デバイス管理装置、デバイス及びデバイス管理方法
JP4535129B2 (ja) * 2005-04-14 2010-09-01 パナソニック株式会社 サーバ装置、情報通知方法、および情報通知システム
KR101158092B1 (ko) * 2005-09-30 2012-06-22 주식회사 케이티 네트워크 장치 제어 관리 시스템 및 그 방법
US7793615B2 (en) * 2005-11-17 2010-09-14 Robert Rector Cover apparatus
US8745181B2 (en) * 2005-12-21 2014-06-03 Rockstar Consortium Us Lp Generic SNMP information collection
US20160277261A9 (en) * 2006-12-29 2016-09-22 Prodea Systems, Inc. Multi-services application gateway and system employing the same
US8713133B2 (en) 2007-01-04 2014-04-29 At&T Intellectual Property I, L.P. Methods, systems and computer program products for importing data from an edge router to a network management system
US20090063650A1 (en) * 2007-09-05 2009-03-05 International Business Machines Corporation Managing Collections of Appliances
ES2381904T3 (es) * 2007-09-29 2012-06-01 Research In Motion Limited Método para responder a una petición en un entorno de red que incluye IMS y aparato para el mismo
CN101453355A (zh) * 2007-11-30 2009-06-10 华为技术有限公司 一种轮询方法、系统、网管站及被管设备
JP2010226393A (ja) * 2009-03-23 2010-10-07 Nec Corp 自律分散制御によるパス設定方法およびシステム並びに通信装置
US8335171B1 (en) 2009-09-29 2012-12-18 Juniper Networks, Inc. NETCONF-enabled provisioning in rollback agnostic environment
US8248958B1 (en) * 2009-12-09 2012-08-21 Juniper Networks, Inc. Remote validation of network device configuration using a device management protocol for remote packet injection
US8145939B2 (en) * 2009-12-10 2012-03-27 Computer Associates Think, Inc. Detection and reduction of excessive SNMP traffic
KR101732186B1 (ko) * 2010-08-19 2017-05-02 삼성전자주식회사 단말 관리 패키지를 제공하는 장치, 방법 및 상기 단말 관리 패키지를 제공받는 방법
CN102891768A (zh) 2012-10-11 2013-01-23 华为技术有限公司 网络管理的方法和网元
US9094299B1 (en) 2013-01-08 2015-07-28 Juniper Networks, Inc. Auto-generation of platform-independent interface and operational scripts for configuring network devices
US9258132B2 (en) 2013-06-06 2016-02-09 Alcatel Lucent NETCONF SNMP gateway
US9172613B2 (en) * 2013-08-06 2015-10-27 Cisco Technology, Inc. Multiple topology routing architecture in computer networks
US10117085B2 (en) * 2014-05-19 2018-10-30 Aerohive Networks, Inc. Deployment of proximity beacon devices
US9722906B2 (en) * 2015-01-23 2017-08-01 Cisco Technology, Inc. Information reporting for anomaly detection
US10103882B2 (en) * 2016-03-03 2018-10-16 Dell Products, L.P. Encryption key lifecycle management
US10785278B2 (en) * 2016-11-04 2020-09-22 Google Llc Network management interface

Also Published As

Publication number Publication date
US10785278B2 (en) 2020-09-22
US20180131745A1 (en) 2018-05-10
DK3526994T3 (da) 2020-05-18
EP3526994A1 (de) 2019-08-21
WO2018084947A1 (en) 2018-05-11
US11212335B2 (en) 2021-12-28
EP3526994B1 (de) 2020-04-22
US20200374334A1 (en) 2020-11-26

Similar Documents

Publication Publication Date Title
DE202017105825U1 (de) Netzmanagementschnittstelle
DE60318651T2 (de) Verfahren und Vorrichtung zur dynamischen Konfigurationsverwaltung
DE202017106594U1 (de) Bereitstellen von Zugriff auf eine in einem Datenspeichersystem gespeicherte Datei
DE102016222048B4 (de) Dynamisch definierte virtuelle private netzwerktunnel in hybriden cloud-umgebungen
DE60205539T2 (de) Verfahren und Vorrichtung zum Verwalten von mehreren Netzwerkgeräten
DE69720857T2 (de) Systeme und Verfahren zum Betrieb einer Netzwerk-Verwaltungsstation
DE602005002679T2 (de) WEB-Dienst-Anwendungsprotokoll und SOAP-Verarbeitungsmodell
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE60035830T2 (de) Netzwerkgeräteverwaltungsvorrichtung und - verfahren
DE112012000249T5 (de) Bewusstheit der Mehrmandantenprüfung bei der Unterstützung von Cloud-Umgebung
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem
DE102015119890A1 (de) Paralleles Verarbeiten von Service-Funktionen in Service-Funktionsketten
DE202015009311U1 (de) Öffnen lokaler Anwendungen von Browsern
DE202014010945U1 (de) Systeme zur Bereitstellung von Meldungen von Änderungen in einem Cloud-basierten Dateisystem
DE112012002631T5 (de) Stream-Verarbeitung unter Verwendung einer Client-Server-Architektur
DE102012216028A1 (de) Webseiten-skriptverwaltung
DE112012002889T5 (de) Authentifizieren eines Rich Clients aus einer bestehenden Browser-Sitzung heraus
DE69822272T2 (de) Dynamische Ausbreitung von Druckfähigkeiten
DE10120210A1 (de) Drucksteuerverfahren, Druckserver, Client und Aufzeichnungsmedium in einer Netzumgebung
EP3314806A1 (de) Verschlüsselungsfilter
DE112012003778T5 (de) Computernetzwerk-Management-Tools
DE10024715A1 (de) Verfahren und Vorrichtung zum Einrichten einer Zwei-Wege-Übertragung mit einem fernen Drucker
DE202015009292U1 (de) Erzeugung eines Aktivitätsflusses
DE202012013453U1 (de) Gehostete Speichersperrung
DE112018000731T5 (de) IoT-Gerät Fog-Networking-Betrieb

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: BETTEN & RESCH PATENT- UND RECHTSANWAELTE PART, DE

R207 Utility model specification
R150 Utility model maintained after payment of first maintenance fee after three years
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000

R151 Utility model maintained after payment of second maintenance fee after six years