Remote Device Services Manager (RDSM) – Überblick

Remote-Services

Die MX BNG stellt einen zentralen Verwaltungspunkt für externe Autoritäten für alle lokalen und Remote-Services für Anwender dar. Die Remotedienste werden auch durch lokal konfigurierte dynamische Dienstprofile dargestellt, auf die von einer externen Autorität auf die gleiche Weise wie auf lokale Dienste auf der BNG verwiesen wird. Folglich gibt es für alle Servicemaßnahmen eine einheitliche Schnittstelle zwischen externer Behörde und BNG. Das NETCONF XML Management Protocol wird für die Bereitstellung und Aufhebung der Bereitstellung der Remotedienste verwendet.

Lokale Anwender-Services werden durch dynamische Serviceprofile mit null oder mehr Argumenten definiert, um Anwender-spezifische Richtlinien zu erfüllen. Externe Behörden, wie z. B. PCRF, verwenden in der Regel ein Referenzmodell, um Dienstleistungen zu erbringen. Die PCRF-Abrechnungsregel gibt den Namen des dynamischen Dienstprofils und die Argumentwerte an, die während der Aushandlung des Anwenders für die Dienstbereitstellung (Aktivierung) oder als Aktualisierung angewendet werden, nachdem der Anwender aktiv ist. Der Dienst wird dem Remotegerät vom RDSM-XML-Wörterbuch präsentiert, damit dieses Gerät analysieren, interpretieren und anwenden kann, sodass die Laderegel oder der Dienst von einer externen Autorität mit minimaler Verarbeitung undurchsichtig an das Remotegerät übergeben werden kann. Das Remotedienstprofil kann eine oder mehrere Variablen zum Definieren von Dienstparametern enthalten.

Remote-Dienste können jedoch auch auf nicht-referenzielle Weise angewendet werden. In diesem Fall spezifiziert die externe Autorität den entfernten Dienst referenziell wie bei einem lokalen Dienst. Das Remote-Serviceprofil enthält eine oder mehrere Variablen zum Definieren von Serviceparametern. Das RDSM verwendet dann das dem Remote-Gerät zugewiesene Datenwörterbuch, um den Dienst auf diesem Gerät zu konfigurieren. Der Inhalt des RDSM-Wörterbuchs für ein Gerät unterscheidet sich, je nachdem, ob der Service Provider die referenzielle oder die nicht-referenzielle Methode verwendet.

Das dynamische Remote-Serviceprofil ist im Vergleich zu einem lokalen Serviceprofil, das eine große Anzahl von Konfigurationszeilengruppen enthalten kann, sehr einfach. Ein dynamisches Remote-Serviceprofil enthält nur zwei Dinge:

• Sie müssen angeben, dass der dynamische Profiltyp remote-device-serviceist. Diese Konfiguration verhindert, dass das Profil als lokales Dienstprofil verwendet wird. Dies bedeutet, dass Sie ein dynamisches Dienstprofil nicht als Zweizweckprofil (sowohl lokal als auch remote) konfigurieren können.

• Das Remotedienstprofil kann optional eine variable Zeilengruppe enthalten, um Argumentwerte an das Remotegerät zu übergeben. Die variable Zeilengruppe kann entweder für die referenzielle oder die nicht-referentielle Methode verwendet werden.

Jede zusätzliche Konfiguration schlägt die Commit-Prüfung fehl. Da das Remoteserviceprofil so spezifisch ist, ist für jeden Remoteservice ein dediziertes Serviceprofil erforderlich. Für die externe Instanz bedeutet dies, dass jeder Remote-Service eine eigene PCRF-Gebührenregel benötigt.

Prozessabläufe für die RDSM-Bereitstellung und -Aufhebung

Die Bereitstellung und Aufhebung der Bereitstellung von Anwenderservices erfolgt wie folgt:

• Wird während der Anmeldung des Anwenders bereitgestellt. Die Dienste können von der PCRF als Reaktion auf die Initiierung mit Gx CCR-I/CCR-A-Nachrichtenaustausch bezogen werden.

• Die Bereitstellung wurde während der Abmeldung des Anwenders aufgehoben.

• Bereitstellung oder Aufhebung der Bereitstellung für aktive Anwender-Sitzungen als Reaktion auf externe Autorität, wie z. B. Gx RAR-Nachrichten von der PCRF.

Abbildung 2 zeigt den Prozessablauf, wenn RDSM erfolgreich Services auf drei berechtigten Remote-Geräten, OLT1, OLT2 und OLT3, bereitstellt, indem das UpstreamBW-Dienstprofil instanziiert wird.

1. Die Servicebereitstellung beginnt, wenn sich ein Anwender anmeldet und authd eine Anforderung an RDSM sendet, um das Remotedienstprofil während der Verhandlung auf geeigneten Remotegeräten zu instanziieren.

2. RDSM erstellt eine Liste der Remote-Geräte, die für den bereitzustellenden Service infrage kommen:

   • Die Layer-2-Zugriffsdomäne für das Gerät muss mit dem Standort des Anwenders übereinstimmen. Die Zugriffsdomäne besteht aus einer konfigurierten Liste von VLAN-Bereichen oder einzelnen VLAN-IDs. Das äußere VLAN-Tag des Anwenders muss in dieser Liste enthalten sein.

   • Die NETCONF-TCP-Verbindung zum Gerät muss bestehen. Obwohl ein Gerät im ausgefallenen Zustand nicht für die Bereitstellung berechtigt ist, kann es erneut konfiguriert werden, wenn es später in den aktiven Zustand übergeht.

3. RDSM führt eine erste Validierung durch, bevor es auf die Instanziierungsanforderung des Remotedienstprofils antwortet:

   • Wenn die Validierung erfolgreich war, sendet RDSM eine Serviceprofilinstanziierung mit ausstehender ACK-Antwort an authd. Die Servicebereitstellung steht jetzt noch aus.

   • Wenn die Validierung fehlschlägt, gibt RDSM eine NACK-Antwort an authd zurück und bricht die Servicebereitstellung ab.

   Die von RDSM durchgeführten Validierungsprüfungen schlagen in der Regel für aktive Anwender-Sitzungen nicht fehl. Zu den Gründen für das Scheitern gehören die folgenden:

   • Kein Remote-Gerät hat einen Anwenderstandort, der mit der Zugriffsdomäne übereinstimmt.

   • Das Wörterbuch auf der BNG enthält keinen Eintrag für das angeforderte Remote-Service-Profil. Folglich gibt es keine RPCs, um die Servicevariablen bereitzustellen und den Service zu installieren.

4. RDSM löst alle erforderlichen Parameter für jedes Remote-Gerät auf; Dazu gehört mindestens die Kennung des Anwenders.

5. RDSM verwendet dann die dedizierte NETCONF-Sitzung für jedes der berechtigten Geräte, um eine Reihe von RPC-Aufrufen auszugeben, wie im Wörterbuch für die Bereitstellung des Dienstes angegeben.

   Die Servicebereitstellung für die berechtigten Geräte erfolgt parallel. Die Bereitstellung für ein Gerät schlägt fehl, wenn einer der folgenden Fälle eintritt:

   • Das RDSM empfängt einen expliziten Fehler für jeden RPC-Aufruf.

   • Bei der Antwort kommt es zu einer Zeitüberschreitung.

   Das folgende ERRMSG-Ereignis wird in beiden Fällen protokolliert:

   remote device device-name ip-address service service-name provisioning failed for subscriber subscriber-id

6. Remotegeräte, die erfolgreich bereitgestellt wurden, geben eine ACK-Antwort an RDSM zurück.

   Wenn ein oder mehrere Remote-Geräte nicht bereitgestellt werden können, setzt RDSM den Dienst auf jedem Remote-Gerät zurück, das erfolgreich bereitgestellt wurde. RDSM verwendet die dedizierte NETCONF-Sitzung für jedes dieser Geräte, um eine Reihe von RPC-Aufrufen auszugeben, wie im Wörterbuch zum Aufheben der Bereitstellung des Dienstes angegeben.

7. RDSM sendet eine Out-of-Band-Benachrichtigung an authd, um zu melden, ob der Remotedienst auf den Remotegeräten bereitgestellt wurde.

   • Wenn die Bereitstellung für alle Remote-Geräte erfolgreich ist, sendet RDSM eine vollständige Antwort auf die Servicebereitstellung an authd.

   • Wenn eines oder mehrere der berechtigten Remote-Geräte nicht bereitgestellt werden können, meldet RDSM einen Bereitstellungsfehler an authd.

Abbildung 3 zeigt den Prozessablauf, wenn RDSM Anwender-Services auf drei berechtigten Remote-Geräten, OLT1, OLT2 und OLT3, erfolgreich aktualisiert, indem das UpstreamBW-Dienstprofil mit anderen Parameterwerten als bei der Anmeldung instanziiert wird.

Das Aktualisieren von Anwender-Services beginnt, wenn authd eine Anforderung an RDSM sendet, um das Remote-Service-Profil zu instanziieren, um den Service zu aktualisieren. Der Prozessablauf ist derselbe wie für den Anmeldeablauf für den Anwender, mit der Ausnahme, dass RDSM erst auf die Instanziierungsanforderung antwortet, wenn alle für die Bereitstellung des Service erforderlichen Verarbeitung abgeschlossen sind. Das bedeutet, dass RDSM keine Dienstprofilinstanziierung sendet, wenn die Validierungsprüfung erfolgreich ist, und keine ausstehende ACK-Antwort an authd sendet. Wenn die Validierung fehlschlägt, gibt RDSM eine NACK-Antwort an authd zurück und bricht die Bereitstellung des Services ab.

Abbildung 4 zeigt den Prozessablauf, wenn RDSM die Bereitstellung von Services erfolgreich aufhebt, um die drei berechtigten Remotegeräte OLT1, OLT2 und OLT3 durch Deinstanziierung des UpstreamBW-Dienstprofils zu aktualisieren.

Der Ablauf des Bereitstellungsaufhebungsprozesses ist für eine Anwender-Abmeldung und eine Aktualisierungsanforderung von authd identisch.

RDSM antwortet erst dann auf authd, wenn alle erforderlichen Verarbeitungen zum Aufheben der Bereitstellung des Dienstes abgeschlossen sind (einschließlich eventueller Wiederholungen von Fehlern). Dadurch kann die Abmeldung des Anwenders unabhängig vom Ergebnis der Aufhebung der Bereitstellung fortgesetzt werden.

Die Aufhebung der Servicebereitstellung schlägt in der Regel nicht fehl. Wenn dies der Fall ist, müssen Sie möglicherweise einige Korrekturmaßnahmen auf dem Remotegerät ergreifen, damit die Bereitstellung aufgehoben werden kann.

1. Die Aufhebung der Servicebereitstellung beginnt, wenn einer der folgenden Fälle eintritt:

   • Ein Anwender meldet sich ab, und authd sendet eine Anforderung an RDSM, um das Remotedienstprofil auf berechtigten Remotegeräten zu deinstanziieren.

   • authd sendet eine Aktualisierungsanforderung an RDSM, um das Remotedienstprofil auf geeigneten Remotegeräten zu deinstanziieren.

2. RDSM verwaltet eine Liste der Remote-Geräte, die mit dem Service bereitgestellt werden. Wenn die NETCONF-TCP-Verbindung mit dem Gerät unterbrochen ist, wird nicht versucht, die Bereitstellung aufzuheben, da davon ausgegangen wird, dass sie auf andere Weise erfolgt ist. Beispielsweise kann das Gerät mit einer Standard-Baseline-Konfiguration neu konfiguriert worden sein, und eine anschließende Operatoraktion initiierte Neukonfiguration durch die BNG für alle aktiven Anwender-Services.

3. RDSM führt eine erste Validierung durch, bevor es auf die Anfrage zur Deinstanziierung des Remote-Serviceprofils antwortet:

   • Wenn die Validierung erfolgreich ist, sendet RDSM keine Antwort an authd.

   • Wenn die Validierung fehlschlägt, gibt RDSM eine NACK-Antwort an authd zurück und bricht die Bereitstellung des Service ab. Zu den Gründen für einen Validierungsfehler gehören die folgenden:

     • Kein konfiguriertes Remote-Gerät befindet sich im Betriebszustand.

     • Das Wörterbuch auf der BNG enthält keinen Eintrag für das angeforderte Remotedienstprofil oder die Aufhebung der Bereitstellung. Folglich gibt es keine RPCs, die die Servicevariablen bereitstellen und den Service entfernen.

   Die von RDSM durchgeführten Validierungsprüfungen schlagen in der Regel für aktive Anwender-Sitzungen nicht fehl.

4. RDSM löst alle erforderlichen Parameter für jedes Remote-Gerät auf; Dazu gehört mindestens die Kennung des Anwenders.

5. RDSM verwendet dann die dedizierte NETCONF-Sitzung für jedes der berechtigten Geräte, um eine Reihe von RPC-Aufrufen auszugeben, wie im Wörterbuch zum Aufheben der Bereitstellung des Dienstes angegeben. Die Aufhebung der Servicebereitstellung für die berechtigten Geräte erfolgt parallel. Die Aufhebung der Bereitstellung für ein Gerät schlägt fehl, wenn einer der folgenden Fälle eintritt:

   • Das RDSM empfängt einen expliziten Fehler für jeden RPC-Aufruf.

   • Bei der Antwort kommt es zu einer Zeitüberschreitung.

   In beiden Fällen wiederholt RDSM die Bereitstellungsaufhebung bis zu 5 Mal in Intervallen von 5 Sekunden. Wenn alle Versuche fehlschlagen, wird in beiden Fällen das folgende ERRMSG-Ereignis protokolliert:

   remote device device-name ip-address service service-name de-provisioning failed for subscriber subscriber-id

6. Remotegeräte, deren Bereitstellung erfolgreich aufgehoben wurde, geben eine ACK-Antwort an RDSM zurück.

7. RDSM sendet eine Out-of-Band-Benachrichtigung an authd, um zu melden, ob die Bereitstellung des Remote-Dienstes auf den Remote-Geräten aufgehoben wurde.

   • Wenn die Aufhebung der Bereitstellung erfolgreich ist, sendet RDSM eine Antwort auf die vollständige Bereitstellung des Dienstes an authd, die dann die Abmeldung des Anwenders abschließt.

     Im Falle einer Aktualisierungsanforderung anstelle einer Abmeldung des Anwenders sendet RDSM eine vollständige Antwort auf die Deinstanziierung des Dienstprofils an authd, wodurch die Bereinigung der Dienstsitzung abgeschlossen ist.

   • Wenn die Bereitstellung eines oder mehrerer der berechtigten Remotegeräte nicht aufgehoben werden kann, meldet RDSM einen Fehler bei der Aufhebung der Bereitstellung an authd.

RDSM-Wörterbuch für die Implementierung von Serviceaktionen

Ein lokal auf dem BNG gespeichertes XML-Wörterbuch ist eine integrale Komponente der Verwaltung von Remote-Gerätediensten. Jeder Remote-Service, der von der externen Stelle bereitgestellt wird, muss einen Eintrag in einem RDSM-Wörterbuch auf der BNG haben. Das Wörterbuch übersetzt die aus PCRF stammende Abrechnungsregel in eine Reihe von anbieterspezifischen Remote Procedure Calls (RPCs) im Eintrag, der dem Dienst zugeordnet ist. Die RPCs Bereitstellung dann den Service oder heben Sie die Bereitstellung auf. Da die RPCs herstellerspezifisch sind, ist es auch das Wörterbuch. Das bedeutet, dass für die Remote-Geräte der einzelnen Anbieter separate Wörterbücher erforderlich sind. Für die Geräte eines bestimmten Anbieters können unterschiedliche Softwareversionen auf den Geräten auch unterschiedliche Wörterbücher erfordern.

Das Wörterbuchformat ist flexibel genug, um sowohl referenzielle als auch nicht-referenzielle Dienste zu unterstützen, wobei:

• Ein referenzieller Dienst bedeutet, dass der gesamte Dienst, einschließlich der Argumente, dem entfernten Gerät undurchsichtig präsentiert wird, wie er von einer externen Autorität über das RDSM-Wörterbuch empfangen wurde. Das dynamische Dienstprofil kann eine variable Zeilengruppe enthalten, die vom Wörterbuch während der Übersetzung der Argumente verwendet wird. Das Remote-Gerät analysiert, interpretiert und wendet die Argumente selbst an, ohne dass eine Interpretation oder Analyse durch die BNG erforderlich ist.

• Ein nicht-referenzieller Dienst bedeutet, dass alle von der externen Autorität gelieferten Argumente gelöst und dem entfernten Gerät einzeln von einem oder mehreren RPCs bereitgestellt werden müssen. In diesem Fall erfordert das dynamische Dienstprofil möglicherweise eine variable Zeilentrennung, die vom Wörterbuch während der Übersetzung der Argumente verwendet wird.

In beiden Fällen muss das Wörterbuch die Mittel – in der Regel ein Layer-2-Standort – zur Identifizierung des für das Remote-Gerät geeigneten Anwenders angeben, um einen Anwender von einem anderen zu unterscheiden.

Das XML-RDSM-Wörterbuch hat das folgende allgemeine Format:

Tabelle 1 definiert die einzelnen Komponenten des Wörterbuchs.

Tabelle 1: Definitionen von XML-Wörterbuchkomponenten

junos-rdm-parameters	Parameterblock, der einzelne Parameter auflistet, mit denen der Service konfiguriert wird.
junos-rdm-parameter	Individueller Parameter.
junos-rdm-name	Im Parameterblock identifiziert dieses Element den Anwender auf dem entfernten Gerät oder das PCRF-Argument. Verwenden Sie die Abonnement-ID für den Anwender und den Namen des Arguments für jedes in der PCRF angegebene Argument.
junos-rdm-source	Quelle des Parameterwerts: Anwender-Sitzung, wenn der Wert aus der SDB-Sitzung stammt. service-profile, wenn der Wert aus dem service-profile-Argument stammt.
junos-rdm-index	Index, z. B. ein Aufzählungstypwert, der den Parameter aus der angegebenen Quelle auflöst. Die Quelle der Anwender-Sitzung erfordert dies, um den Parameter einem SDB-Attribut zuzuordnen, das zum Auflösen des Parameterwerts verwendet wird. In einigen Anwendungsfällen wird beispielsweise die PCRF-Abonnement-ID im SDB-Eintrag des Anwenders gespeichert, auf den von einem Index (Attributtyp) verwiesen wird, um diesen Parameter aufzulösen.
Junos-RDM-Services	Dienstblock, der einen oder mehrere Remotedienste auflistet, die vom Gerät unterstützt werden.
junos-rdm-service	Einzelner Remote-Service, definiert durch Servicename, Bereitstellungskonfiguration und Konfiguration der Aufhebung der Bereitstellung.
junos-rdm-name	Im Service-Baustein ist dieses Element der Name des Service. Es ist der Basisdienstname ohne Argumente des Diensts, der von der PCRF bezogen wird.
junos-rdm-Bereitstellung	Bereitstellungsblock, der die Bereitstellungskonfiguration umfasst.
junos-rdm-deprovision	Block zum Aufheben der Bereitstellung, der die Konfiguration zum Aufheben der Bereitstellung umfasst.
junos-rdm-service-configuration	Dienstkonfiguration, die einen oder mehrere RPCs zur Bereitstellung oder Aufhebung der Bereitstellung des Dienstes umfasst. Wenn Argumente im PCRF-Dienst für die Bereitstellung angegeben werden, schließen die RPCs diese Argumente ein.
junos-rdm-open-configuration	Block, der null oder mehr RPCs enthält, um mit der Konfiguration des Remotegeräts zu beginnen.
junos-rdm-edit-configuration	Block, der einen oder mehrere RPCs enthält, um die Konfiguration zu bearbeiten und Aktionen zur Servicebereitstellung oder -aufhebung auf das Gerät in großen Mengen anzuwenden, indem auf den junos-rdm-Bereitstellung- oder junos-rdm-deprovisioning-Block für den angegebenen Dienst verwiesen wird. Die Konfiguration für jeden Dienst, der Teil der Massenaktualisierung auf dem Remote-Gerät ist, ist enthalten.
junos-rdm-commit-configuration	Block, der null oder mehr RPCs enthält, um die Änderungen auf das Remote-Gerät zu übertragen.
junos-rdm-close-konfiguration	Block, der null oder mehr RPCs enthält, um die Konfiguration des Remote-Geräts zu beenden.
junos-rdm-rpc	Individueller RPC zur Konfiguration des Remote-Geräts.

Bei der Remotegerätekonfiguration ist die Bearbeitungskonfiguration immer erforderlich, um den Dienst zu Bereitstellung oder die Bereitstellung aufzuheben. In einigen Anwendungsfällen können die Konfigurationsblöcke open, commit und close optional sein.

Zusätzliche Funktionen für die Verwendung mit einem RDSM-Zugriffsmodell

Die Features in diesem Abschnitt sind für RDSM nicht erforderlich, können aber in bestimmten Anwendungsfällen oder Topologien nützlich sein.

Ein lokal generierter Benutzername wird in Interaktionen mit einer externen Autorität verwendet, um dynamische VLAN-, DHCPv4- und DHCPv6-Abonnenten zu authentifizieren. In der Regel werden VLAN-Tags des Anwenders in den Benutzernamen aufgenommen, indem die interface-name Option für die username-include Anweisung konfiguriert wird.

Ebenso werden Anwender-VLAN-Tags in die Abonnement-ID für PCRF-Interaktionen aufgenommen, indem die interface-name Option für die subscription-id-data-include Anweisung konfiguriert wird.

Gemäß der Konvention hat der Schnittstellenname in beiden Fällen das folgende Format:

Bei einigen Anwendungsfällen mit dem RDSM-Zugriffsmodell ist das äußere VLAN-Tag im gesamten System eindeutig. Das bedeutet, dass Sie ein anderes Format verwenden können, das den zugrunde liegenden IFD-Namen ausschließt:

Um das Benutzernamenformat ohne den zugrunde liegenden IFD-Namen zu generieren, geben Sie die vlan-tags Option anstelle der interface-name Option mit der username-include Anweisung an. Weitere Informationen finden Sie unter Konfigurieren der Benutzernameninformationen der VLAN-Schnittstelle für die AAA-Authentifizierung und Erstellen eindeutiger Benutzernamen für DHCP-Clients.

Um das Subskriptions-ID-Format ohne den zugrunde liegenden IFD-Namen zu generieren, geben Sie die vlan-tags Option anstelle der interface-name Option mit der subscription-id-data-include Anweisung an. Weitere Informationen finden Sie unter Konfigurieren der PCRF-Partition .

Einige Kundennetzwerke verfügen möglicherweise über mehr als ein Bereitstellungsmodell oder einen Anwendungsfall, der dazu führt, dass die BNG der MX-Serie für jeden Fall mit demselben PCRF-Backend interagiert. In dieser Situation müssen Sie möglicherweise zwischen den Anwendungsfällen für die PCRF unterscheiden.

Die Diameter-Fähigkeit: Austauschnachrichten zwischen Peers tragen den Diameter-Produktnamen AVP. Sie können nicht standardmäßige Werte für die Anwendungsfälle konfigurieren, damit PCRF zwischen den Nachrichten unterscheiden kann. Weitere Informationen finden Sie unter Von Diameter-Anwendungen verwendete Meldungen und Diameter-AVPs und Diameter-Anwendungen .

Antwort auf die externe Autorität durch authd bei Erfolg oder Misserfolg

Wie authd auf die externe Autorität reagiert, hängt von Folgendem ab:

• Der Vorgang, der ausgeführt wird, z. B. die Bereitstellung während der Anmeldung des Anwenders im Vergleich zum Aktualisieren einer vorhandenen Anwendersitzung.

• Die externe Autorität, Gx (PCRF).

In Tabelle 2 wird beschrieben, wie sich die Authentifizierungsantwort ändert, wenn die Servicebereitstellungs- oder -entziehungsaktionen erfolgreich sind.

Tabelle 2: Wie authd auf externe Autorität reagiert, wenn Serviceaktionen erfolgreich sind

Betrieb	Gx
Einloggen	authd initiiert den CCR-I/CCA-I-Nachrichtenaustausch zur Bereitstellung der Anwender-Sitzung. Wenn alle Services im CCA-I bereitgestellt sind, sendet authd eine CCR-U-Nachricht, die angibt, dass der Service für jede Abrechnungsregel im CCA-I aktiv ist. Die Statusmeldung für lokale dynamische Services verzögert sich, bis die Remote-Servicebereitstellung abgeschlossen ist.
Aktualisieren	Die Aufhebung der Bereitstellung wird vor der Bereitstellung für Services angewendet, die in derselben PCRF RAR-Nachricht enthalten sind. Wenn die Aufhebung der Bereitstellung und die Bereitstellung für alle in der PCRF RAA enthaltenen Serviceaktionen abgeschlossen sind, sendet authd eine RAA-Antwort mit einem Regelbericht, der den inaktiven/aktiven Status des Dienstes für jede im RAR angegebene Abrechnungsregel angibt. Die Statusberichterstattung für lokale dynamische Services wird verzögert, bis die Remoteserviceverarbeitung abgeschlossen ist.
Abmelden	authd initiiert einen CCR-T/CCA-T-Nachrichtenaustausch, um PCRF über die Kündigung des Anwenders zu informieren. authd initiiert die Aufhebung der Bereitstellung für alle Services, die für die Anwender-Sitzung konfiguriert sind.
Servicegerät im aktivierten Zustand, nachdem der reconfigure Befehl ausgegeben wurde	authd führt keine weiteren Aktionen durch, wenn es eine Out-of-Band-Benachrichtigung von RDSM erhält, dass die Serviceaktion erfolgreich war. Beispielsweise wird keine CCR-U-Nachricht gesendet, die angibt, dass der Dienst für die entsprechende Abrechnungsregel aktiv ist.

In Tabelle 3 wird beschrieben, wie sich die Authentifizierungsantwort ändert, wenn die Servicebereitstellungs- oder -entziehungsaktionen fehlschlagen.

Tabelle 3: Wie authd auf externe Autorität reagiert, wenn Serviceaktionen fehlschlagen

Betrieb	Gx
Einloggen	authd initiiert einen CCR-I/CCA-I-Austausch zur Bereitstellung der Anwender-Sitzung. Wenn authd eine Benachrichtigung über einen Fehler in der Instanziierungsantwort des Dienstprofils oder Out-of-Band von RDSM erhält, beendet authd die Verarbeitung aller verbleibenden Services. authd sendet eine CCR-U-Nachricht, die Folgendes meldet: Der Service ist für jede Abrechnungsregel im CCA-I aktiv, die erfolgreich bereitgestellt wurde Der Dienst ist für die Abrechnungsregel im CCA-I, bei der die Bereitstellung fehlgeschlagen ist, inaktiv. Der Dienst ist für alle Abrechnungsregeln inaktiv, die aufgrund des Fehlers nicht verarbeitet wurden. Authd ermöglicht es der Aushandlung der Anwender-Sitzung, abgeschlossen zu werden und den aktiven Zustand zu erreichen.
Aktualisieren	Die Aufhebung der Bereitstellung wird vor der Bereitstellung für Services angewendet, die in derselben PCRF RAR-Nachricht enthalten sind. Der Prozess variiert je nach den fehlgeschlagenen Aktionen. Wenn authd eine Benachrichtigung über einen Fehler in der Antwort auf die Deinstanziierung des Dienstprofils erhält, was bedeutet, dass RDSM alle Wiederholungen erfolglos durchgeführt hat, verarbeitet authd die nächste Dienstaktion. Das bedeutet, dass das Update fortgesetzt und abgeschlossen wird, wenn nur die Aufhebung der Bereitstellung des Dienstes fehlschlägt. Wenn authd eine Benachrichtigung über einen Fehler in der Instanziierungsantwort des Dienstprofils erhält, beendet authd die Verarbeitung aller verbleibenden Services. Für alle bereitgestellten und nicht bereitgestellten Services in der Anforderung wird ein Rollback ausgeführt. Das bedeutet, dass die Bereitstellung von Diensten, die erfolgreich bereitgestellt wurden, jetzt aufgehoben wird. Die Bereitstellung von Diensten, deren Bereitstellung erfolgreich aufgehoben wurde, wird jetzt erneut bereitgestellt. Wenn alle Rollback-Aktionen abgeschlossen sind, sendet authd eine RAA-Antwort mit einem Regelbericht, der den inaktiven/aktiven Status des Dienstes für jede in der RAR angegebene Abrechnungsregel angibt. Das bedeutet, dass wiederbereitgestellte Laderegeln als aktiv und nicht bereitgestellte Laderegeln als inaktiv gemeldet werden.
Abmelden	authd initiiert einen CCR-T/CCA-T-Nachrichtenaustausch, um PCRF über die Kündigung des Anwenders zu informieren. authd initiiert die Aufhebung der Bereitstellung für alle Services, die für die Anwender-Sitzung konfiguriert sind. Wenn authd eine Benachrichtigung über einen Fehler in der Instanziierungsantwort des Dienstprofils oder Out-of-Band von RDSM erhält, fährt authd mit der Abmeldung fort, einschließlich der Aufhebung der Bereitstellung aller verbleibenden Services.
Letztes Servicegerät im ausgefallenen Zustand, nachdem der reconfigure Befehl ausgegeben wurde	authd führt keine weiteren Aktionen durch, wenn es eine Out-of-Band-Benachrichtigung von RDSM erhält, dass die Serviceaktion fehlgeschlagen ist. Beispielsweise sendet es keine CCR-U, die angibt, dass der Dienst für die entsprechende Abrechnungsregel inaktiv ist. Betroffene Anwender-Sitzungen werden beibehalten.

Neukonfiguration von Remote-Geräten durch Betreiber

Unter bestimmten Umständen müssen Sie Dienste auf einem Remotegerät manuell Bereitstellung, um das Gerät mit allen übereinstimmenden Anwender Services neu zu synchronisieren, die auf mindestens einem anderen Remotegerät aktiv und konfiguriert sind. Eine manuelle Bereitstellung ist in den folgenden Szenarien erforderlich:

• Ein neues Remotegerät wird mit der BNG verbunden, nachdem eine oder mehrere Anwendersitzungen auf anderen Remotegeräten ausgehandelt wurden und Remotedienste auf diesen Geräten bereitgestellt wurden.

• Die NETCONF-Sitzung zu einem Remotegerät mit einem oder mehreren bereitgestellten Remotediensten wechselt in den inaktiven Zustand, stellt sich später wieder her und wechselt wieder in den aktiven Zustand. Dies ist praktisch dasselbe wie ein neues Gerät, das mit dem BNG verbunden wird.

Nachdem die NETCONF-Sitzung für das Remotegerät in einer dieser Situationen eingerichtet wurde, wird ein ERRMSG-Ereignis protokolliert, dass das Gerät aktiv ist. Derzeit werden keine Remotedienste auf dem Gerät bereitgestellt. RDSM erstellt eine Liste der Remote-Services für Anwender, die auf dem Gerät bereitgestellt werden können. Diese Services müssen entweder aktiv sein oder gerade bereitgestellt werden. Ein separates ERRMSG-Ereignis wird protokolliert, das darauf hinweist, dass eine Neukonfiguration der Services aussteht:

remote device device-name ip-address has number services pending reconfiguration

Sie verwenden den request services remote-device-management reconfigure service-device Befehl zur Bereitstellung aller aktiven (oder in Bearbeitung) Anwender-Services, die der Zugriffsdomäne zugeordnet sind, die dem Gerät zugeordnet ist. Die Neukonfigurationsanforderung löst die Massenbereitstellung von Diensten auf dem Gerät aus. Wenn die Bereitstellung eines Service fehlschlägt, wird die gesamte Massenbereitstellung als fehlgeschlagen betrachtet, und alle erfolgreich bereitgestellten Services werden zurückgesetzt. In diesem Fall müssen Sie den Befehl erneut ausführen. Das Rollback gilt nur für jeden Massenbereitstellungsversuch, sodass Sie die Auswirkungen eines Massenbereitstellungsfehlers kontrollieren können, indem Sie ein Massenlimit festlegen.

Hinweis:

Das Remote-Gerät kann für Anwender-Anmeldungen, die nach dem Aufbau der NETCONF-Sitzung erfolgen, automatisch mit Anwender-Services bereitgestellt werden, ohne dass ein Bediener eingreifen muss.

Sie können jederzeit eine Neukonfigurationsanforderung stellen, wenn das Remote-Gerät aktiv ist. Wenn die Neukonfiguration des Remotegeräts beginnt, werden alle neuen Dienstaktionen, die sich aus der Aushandlung eines neuen Anwenders oder einem vorhandenen Update oder einer Abmeldung des Anwenders ergeben, für das Remotegerät verzögert, bis die Neukonfiguration abgeschlossen ist. Außerdem kann jederzeit eine Neukonfigurationsanforderung ausgeführt werden, wenn das Remote-Gerät aktiv ist. Dies bedeutet, dass ein Remote-Gerät mit dem Netzwerk verbunden werden kann und die Bereitstellung neuer Anwender-Services akzeptiert, bevor bestehende Teilnehmer durch die Neukonfigurationsanforderung bereitgestellt werden.

Die folgenden Schritte zeigen den RDSM-Prozessablauf für Neukonfigurationsanforderungen:

1. RDSM verwaltet eine Liste der Remote-Geräte, die mit dem Service bereitgestellt werden. Wenn die NETCONF-TCP-Verbindung mit dem Gerät unterbrochen ist, wird nicht versucht, die Bereitstellung aufzuheben, da davon ausgegangen wird, dass sie auf andere Weise erfolgt ist. Beispielsweise kann das Gerät mit einer Standard-Baseline-Konfiguration neu konfiguriert worden sein, und eine anschließende Operatoraktion initiierte Neukonfiguration durch die BNG für alle aktiven Anwender-Services.

2. RDSM führt Folgendes als Massenvorgang aus, wobei die Massengröße bis zur Gesamtzahl der bereitzustellenden Anwender-Services reichen kann:

   1. Überprüft den Dienst, bevor er auf die Neukonfigurationsanforderung antwortet. Die Überprüfung schlägt beispielsweise fehl, wenn das Wörterbuch auf der BNG keinen Eintrag für das angeforderte Remotedienstprofil oder die Anforderungsbereitstellungsaktion enthält, da keine RPCs vorhanden sind, um die Dienstvariablen bereitzustellen und den Dienst hinzuzufügen.

   2. Löst alle erforderlichen Parameter für jedes Remote-Gerät auf; Dazu gehört mindestens die Kennung des Anwenders.

   3. Verwendet die dedizierte NETCONF-Sitzung für das Remotegerät, um eine Reihe von RPC-Aufrufen auszugeben, wie im Wörterbuch für die Bereitstellung des Diensts angegeben. Die Bereitstellung für ein Gerät schlägt fehl, wenn einer der folgenden Fälle eintritt:

      • Das RDSM empfängt einen expliziten Fehler für jeden RPC-Aufruf.

      • Bei der Antwort kommt es zu einer Zeitüberschreitung.

      In beiden Fällen rollt RDSM alle Dienste zurück, die erfolgreich durch den Massenvorgang bereitgestellt wurden, die Neukonfiguration wird abgebrochen und RDSM protokolliert das folgende ERRMSG-Ereignis:

      remote device device-name ip-address reconfiguration failed

3. Wenn die Bereitstellung für alle Anwender-Services auf dem Remote-Gerät abgeschlossen ist, protokolliert RDSM das folgende ERRMSG-Ereignis:

   remote device device-name ip-address reconfiguration succeeded

Externe Benachrichtigung für die Service-Verarbeitung von ERRMSG-Ereignissen

Tabelle 4 listet die ERRMSG-Ereignisse auf, die authd an externe Managementsysteme kommunizieren kann, sowie die Informationen, die in den Benachrichtigungen enthalten sind. Erfolgreiche Remote-Service-Aktionen werden nur an eine externe Behörde gemeldet und erzeugen kein ERRMSG-Protokoll.

Tabelle 4: In externen Meldungen für ERRMSG-Ereignisse enthaltene Informationen

ERRMSG-Veranstaltung	Gerätename	IP-Adresse	Aktueller Stand	Anzahl der Services, deren Konfiguration noch aussteht	Service Name	Anwender-ID
Statusänderung des Remote-Geräts von "Up" zu "Down" oder "Down" zu "Up"	✓	✓	✓	–	–	–
Für das Remote-Gerät stehen Services zur Neukonfiguration aus	✓	✓	–	✓	–	–
Abschluss der Neukonfiguration des Remote-Geräts (Erfolg oder Misserfolg)	✓	✓	✓	–	–	–
Fehler bei der Remote-Servicebereitstellung des Anwenders	✓	✓	–	–	✓	✓
Fehler bei der Aufhebung der Bereitstellung des Remote-Services für den Anwender	✓	✓	–	–	✓	✓

Vorteile des Remote Device Service Management

• Ermöglicht Topologien, in denen Anwender-Services sowohl das BNG der MX-Serie als auch seine Zugriffsknoten umfassen, um ein einziges, logisches System zu bilden.

• Vereinfacht die Konfiguration und Verwaltung von BNGs und Remote-Geräten in Topologien, die externe Management- und Bereitstellungssysteme verwenden. Die Remote-Geräte haben in der Regel private Adressen, die dem externen System unbekannt sind, sodass das externe System nur den BNG der MX-Serie adressiert.

• Fügt einen neuen Dienstprofiltyp für Remotedienste hinzu, um Remote- und lokale Dienste einfach zu unterscheiden.