Übersicht über Remote Device Services Manager (RDSM)

Remote-Services

Die MX BNG stellt eine zentrale Verwaltungsstelle für externe Autoritäten für alle Teilnehmerdienste dar, sowohl lokal als auch remote. Die Remote-Services werden auch durch lokal konfigurierte dynamische Serviceprofile dargestellt, auf die von externen Autoritäten auf die gleiche Weise verwiesen wird wie auf lokale Services auf der BNG. Folglich gibt es für alle Serviceaktionen eine konsistente Schnittstelle zwischen externer Instanz und der BNG. Das NETCONF XML Management Protocol wird für die Bereitstellung und Aufhebung der Bereitstellung der Remotedienste verwendet.

Lokale Abonnentendienste werden durch dynamische Dienstprofile mit null oder mehr Argumenten definiert, um abonnentenspezifische Richtlinien zu erfüllen. Externe Behörden, wie z. B. PCRF, verwenden in der Regel ein Referenzmodell zur Erbringung von Dienstleistungen. Die PCRF-Abrechnungsregel gibt den Namen des dynamischen Dienstprofils und die Argumentwerte an, die während der Abonnentenaushandlung für die Dienstbereitstellung (Aktivierung) oder als Update angewendet werden, nachdem der Abonnent aktiv ist. Der Dienst wird dem Remote-Gerät durch das RDSM-XML-Wörterbuch angezeigt, 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 Remote-Gerät übergeben werden kann. Das Remotedienstprofil kann eine oder mehrere Variablen zum Definieren von Dienstparametern enthalten.

Remotedienste können jedoch auch nicht-referenziell angewendet werden. In diesem Fall spezifiziert die externe Autorität den Remotedienst referenziell, wie sie es für einen lokalen Dienst tun würde. Das Remote-Service-Profil enthält eine oder mehrere Variablen zum Definieren von Service-Parametern. Das RDSM verwendet dann das Datenwörterbuch, das dem Remotegerät zugewiesen ist, 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 Dienstanbieter die referenzielle oder nicht-referenzielle Methode verwendet.

Das dynamische Remotedienstprofil ist im Vergleich zu einem lokalen Dienstprofil, das eine große Anzahl von Konfigurationszeilen enthalten kann, sehr leichtgewichtig. Ein dynamisches Remotedienstprofil enthält nur zwei Dinge:

• Sie müssen angeben, dass der dynamische Profiltyp . remote-device-service Diese Konfiguration verhindert, dass das Profil als lokales Dienstprofil verwendet wird. Dies bedeutet, dass Sie ein dynamisches Dienstprofil nicht so konfigurieren können, dass es einen doppelten Zweck erfüllt (sowohl lokal als auch remote).

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

Jede zusätzliche Konfiguration schlägt bei der Commit-Prüfung fehl. Da das Remotedienstprofil so spezifisch ist, ist für jeden Remotedienst ein dediziertes Dienstprofil erforderlich. Für die externe Behörde bedeutet dies, dass jeder Remote-Service eine eigene PCRF-Abrechnungsregel benötigt.

Prozessabläufe für RDSM-Provisioning und -Deprovisioning

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

• Wird während der Abonnentenanmeldung bereitgestellt. Die Services können vom PCRF als Reaktion auf die Initiierung mit Gx CCR-I/CCR-A-Nachrichtenaustausch bezogen werden.

• Die Bereitstellung wurde während der Abmeldung vom Abonnenten aufgehoben.

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

Abbildung 2 zeigt den Prozessablauf, wenn RDSM durch Instanziierung des Upstream-BW-Dienstprofils erfolgreich Services auf drei berechtigten Remote-Geräten, OLT1, OLT2 und OLT3, bereitstellt.

1. Die Dienstbereitstellung beginnt, wenn sich ein Abonnent anmeldet und authd eine Anforderung an RDSM sendet, um das Remotedienstprofil während der Aushandlung auf berechtigten Remotegeräten zu instanziieren.

2. RDSM erstellt eine Liste von Remote-Geräten, die für die Bereitstellung des Dienstes in Frage kommen:

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

   • Die NETCONF-TCP-Verbindung zum Gerät muss aktiv sein. Obwohl ein Gerät im inaktiven Zustand nicht für die Bereitstellung in Frage kommt, steht es möglicherweise für eine Neukonfiguration zur Verfügung, 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 ist, sendet RDSM eine ausstehende ACK-Antwort für die Dienstprofilinstanziierung an authd. Die Servicebereitstellung steht jetzt noch aus.

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

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

   • Kein Remotegerät verfügt über einen Abonnentenstandort, 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 Dienstvariablen bereitzustellen und den Dienst zu installieren.

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

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 erfolgt parallel für die berechtigten Geräte. Die Bereitstellung für ein Gerät schlägt fehl, wenn einer der folgenden Fälle eintritt:

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

   • Zeitüberschreitung der Antwort.

   In beiden Fällen wird das folgende ERRMSG-Ereignis protokolliert:

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

6. Remote-Gerä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 für die Aufhebung der Bereitstellung des Dienstes angegeben.

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

   • Wenn die Bereitstellung für alle Remotegeräte erfolgreich ist, sendet RDSM eine vollständige Antwort auf die Dienstbereitstellung 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 die Abonnentendienste auf drei berechtigten Remotegeräten, OLT1, OLT2 und OLT3, erfolgreich aktualisiert, indem das UpstreamBW-Dienstprofil mit anderen Parameterwerten instanziiert wird, als bei der Anmeldung verwendet wurden.

Die Aktualisierung der Abonnentendienste beginnt, wenn authd eine Anforderung an RDSM sendet, um das Remotedienstprofil zu instanziieren und den Dienst zu aktualisieren. Der Prozessablauf ist derselbe wie für den Abonnentenanmeldeablauf, mit der Ausnahme, dass RDSM erst dann auf die Instanziierungsanforderung reagiert, wenn die gesamte für die Bereitstellung des Dienstes erforderliche Verarbeitung abgeschlossen ist. Das bedeutet, dass RDSM nach Bestehen der Validierungsprüfung keine Dienstprofilinstanziierung mit ausstehender ACK-Antwort an authd sendet. Wenn die Validierung fehlschlägt, gibt RDSM eine NAC-Antwort an authd zurück und bricht die Aufhebung der Dienstbereitstellung ab.

Abbildung 4 zeigt den Prozessablauf, wenn RDSM die Bereitstellung von Diensten zum Aktualisieren der drei berechtigten Remotegeräte OLT1, OLT2 und OLT3 durch Deinstanziierung des Upstream-BW-Dienstprofils erfolgreich aufhebt.

Der Ablauf des Aufhebens der Bereitstellung ist sowohl für eine Abonnentenabmeldung als auch für eine Aktualisierungsanforderung von authd gleich.

RDSM reagiert erst dann auf authd, wenn alle erforderlichen Verarbeitungsschritte zum Aufheben der Bereitstellung des Dienstes abgeschlossen sind (einschließlich aller Wiederholungsversuche von Fehlern). Auf diese Weise kann die Abmeldung des Abonnenten unabhängig vom Ergebnis der Aufhebung der Bereitstellung fortgesetzt werden.

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

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

   • Ein Abonnent 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 berechtigten Remotegeräten zu deinstanziieren.

2. RDSM verwaltet eine Liste der Remote-Geräte, die mit dem Dienst bereitgestellt werden. Wenn die NETCONF-TCP-Verbindung zum 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 und einer nachfolgenden vom Betreiber initiierten Neukonfiguration durch die BNG für alle aktiven Abonnentendienste neu konfiguriert worden sein.

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

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

   • Wenn die Validierung fehlschlägt, gibt RDSM eine NAC-Antwort an authd zurück und bricht die Aufhebung der Dienstbereitstellung ab. Es gibt unter anderem folgende Gründe für einen Validierungsfehler:

     • Kein konfiguriertes Remote-Gerät befindet sich im Status "Aktiv".

     • Das Wörterbuch auf der BNG enthält keinen Eintrag für das angeforderte Remotedienstprofil oder die Aktion zum Aufheben der Bereitstellung. Folglich gibt es keine RPCs, um die Dienstvariablen bereitzustellen und den Dienst zu entfernen.

   Die von RDSM durchgeführten Validierungsprüfungen schlagen in der Regel bei aktiven Abonnentensitzungen nicht fehl.

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

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 angegeben, um die Bereitstellung des Dienstes aufzuheben. Die Aufhebung der Dienstbereitstellung erfolgt parallel für die berechtigten Geräte. Die Aufhebung der Bereitstellung schlägt für ein Gerät fehl, wenn einer der folgenden Fälle eintritt:

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

   • Zeitüberschreitung der Antwort.

   In beiden Fällen wiederholt RDSM die Aufhebung der Bereitstellung 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 Remotediensts auf den Remotegeräten aufgehoben wurde.

   • Wenn das Aufheben der Bereitstellung erfolgreich ist, sendet RDSM eine vollständige Antwort zum Aufheben der Bereitstellung des Dienstes an authd, das dann die Abmeldung des Abonnenten abschließt.

     Im Falle einer Aktualisierungsanforderung anstelle einer Abonnentenabmeldung sendet RDSM eine vollständige Antwort auf die Instanziierung von Dienstprofilen an authd, wodurch die Bereinigung der Dienstsitzung abgeschlossen wird.

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

RDSM-Wörterbuch zur Implementierung von Serviceaktionen

Ein XML-Wörterbuch, das lokal auf der BNG gespeichert wird, ist ein integraler Bestandteil der Verwaltung von Remote Device Services. Jeder Remotedienst, der von der externen Autorität bereitgestellt wird, muss einen Eintrag in einem RDSM-Wörterbuch auf der BNG haben. Das Wörterbuch übersetzt die PCRF-basierte Abrechnungsregel in eine Reihe von herstellerspezifischen Remote Procedure Calls (RPCs) in dem Eintrag, der dem Dienst zugeordnet ist. Die RPCs stellen dann den Dienst bereit oder heben die Bereitstellung auf. Da die RPCs herstellerspezifisch sind, gilt dies auch für das Wörterbuch. Dies bedeutet, dass für das Remote-Gerät jedes Anbieters separate Wörterbücher erforderlich sind. Für die Geräte eines bestimmten Herstellers 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 Services zu unterstützen, wobei:

• Ein referenzieller Dienst bedeutet, dass der gesamte Dienst, einschließlich der Argumente, dem Remote-Gerät undurchsichtig so dargestellt wird, wie er von einer externen Autorität über das RDSM-Wörterbuch empfangen wurde. Das dynamische Serviceprofil kann eine Variablengruppe 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 die BNG sie interpretiert oder analysiert.

• Ein nicht referenzieller Dienst bedeutet, dass alle von der externen Autorität bereitgestellten Argumente aufgelöst und dem Remotegerät einzeln von einem oder mehreren RPCs bereitgestellt werden müssen. In diesem Fall kann für das dynamische Dienstprofil eine Variablengruppe erforderlich sein, die vom Wörterbuch während der Übersetzung der Argumente verwendet wird.

In beiden Fällen muss das Wörterbuch die Mittel angeben – in der Regel einen Layer-2-Standort –, um den für das Remotegerät geeigneten Teilnehmer zu identifizieren und einen Abonnenten 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 Dienst konfiguriert wird.
junos-rdm-parameter	Individuelle Parameter.
junos-rdm-name	Im Parameterblock identifiziert dieses Element den Teilnehmer auf dem Remote-Gerät oder das PCRF-Argument. Verwenden Sie die Abonnement-ID für den Abonnenten und den Namen des Arguments für ein beliebiges Argument, das in der PCRF angegeben ist.
junos-rdm-source	Quelle des Parameterwerts: subscriber-session, wenn der Wert aus der SDB-Sitzung stammt. service-profile, wenn der Wert aus dem Serviceprofil-Argument stammt.
junos-rdm-index	Index, z. B. ein Enumerationstypwert, der den Parameter aus der angegebenen Quelle auflöst. Die Abonnentensitzungsquelle benötigt dies, um den Parameter einem SDB-Attribut zuzuordnen, das zum Auflösen des Parameterwerts verwendet wird. In einigen Anwendungsfällen wird z. B. die PCRF-Abonnement-ID im SDB-Eintrag des Abonnenten gespeichert, auf den von einem Index (Attributtyp) verwiesen wird, um diesen Parameter aufzulösen.
junos-rdm-services	Serviceblock, der einen oder mehrere Remote-Services auflistet, die vom Gerät unterstützt werden.
junos-rdm-service	Individueller Remotedienst, definiert durch Dienstname, Bereitstellungskonfiguration und Konfiguration für die Aufhebung der Bereitstellung.
junos-rdm-name	Im Serviceblock ist dieses Element der Name des Service. Es handelt sich um den Basisdienstnamen ohne Argumente des Diensts, der aus dem PCRF stammt.
Junos-RDM-Bereitstellung	Bereitstellungsblock, der die Bereitstellungskonfiguration enthält.
junos-rdm-deprovision	Deprovisioning-Block, der die Deprovisioning-Konfiguration enthält.
junos-rdm-service-configuration	Dienstkonfiguration, die einen oder mehrere RPCs zum Bereitstellen oder Aufheben der Bereitstellung des Diensts enthält. Wenn im PCRF-Dienst Argumente für die Bereitstellung angegeben werden, enthalten die RPCs diese Argumente.
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 zum Bearbeiten der Konfiguration und zum Anwenden von Aktionen zur Dienstbereitstellung oder -aufhebung auf das Gerät in großen Mengen enthält, indem auf den Block junos-rdm-provision oder junos-rdm-deprovision für den angegebenen Dienst verwiesen wird. Die Konfiguration für jeden Dienst, der Teil der Massenaktualisierung des Remotegeräts ist, ist enthalten.
junos-rdm-commit-configuration	Block, der null oder mehr RPCs enthält, um die Änderungen auf das Remotegerät zu übertragen.
junos-rdm-close-configuration	Block, der null oder mehr RPCs enthält, um die Konfiguration des Remotegeräts zu beenden.
junos-rdm-rpc	Individueller RPC zur Konfiguration des Remotegeräts.

Bei der Remotegerätekonfiguration ist die Bearbeitungskonfiguration immer erforderlich, um den Dienst bereitzustellen oder die Bereitstellung aufzuheben. In einigen Anwendungsfällen können die Konfigurationsblöcke "Öffnen", "Bestätigen" und "Schließen" optional sein.

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

Die Funktionen 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 bei Interaktionen mit einer externen Autorität verwendet, um dynamische VLAN-, DHCPv4- und DHCPv6-Abonnenten zu authentifizieren. In der Regel werden Abonnenten-VLAN-Tags in den Benutzernamen aufgenommen, indem die interface-name Option für die username-include Anweisung konfiguriert wird.

In ähnlicher Weise werden Abonnenten-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:

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

Um das Format username 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 VLAN-Schnittstellen-Benutzernameninformationen für die AAA-Authentifizierung und Erstellen eindeutiger Benutzernamen für DHCP-Clients.

Um das Abonnement-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 das BNG der MX-Serie für jeden Fall mit demselben PCRF-Back-End interagiert. In diesem Fall müssen Sie möglicherweise zwischen den Anwendungsfällen für die PCRF unterscheiden.

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

Antwort an die externe Autorität von 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 Abonnentenanmeldung im Vergleich zur Aktualisierung einer vorhandenen Abonnentensitzung.

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

Tabelle 2 beschreibt, wie die authd-Antwort variiert, wenn die Aktionen zum Bereitstellen oder Aufheben der Bereitstellung von Diensten erfolgreich sind.

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

Operation	Gx
Einloggen	authd initiiert den CCR-I/CCA-I-Nachrichtenaustausch, um die Abonnentensitzung bereitzustellen. Wenn alle Dienste im CCA-I bereitgestellt sind, sendet authd eine CCR-U-Nachricht, die angibt, dass der Dienst für jede Laderegel im CCA-I aktiv ist. Die Statusberichterstellung für lokale dynamische Services wird verzögert, bis die Bereitstellung von Remoteservices abgeschlossen ist.
Aktualisieren	Die Aufhebung der Bereitstellung wird vor der Bereitstellung für Dienste angewendet, die in derselben PCRF-RAR-Nachricht enthalten sind. Wenn die Aufhebung der Bereitstellung und die Bereitstellung für alle Serviceaktionen abgeschlossen ist, die in der PCRF RAA enthalten sind, sendet authd eine RAA-Antwort mit einem Rule-Report, der den inaktiven/aktiven Status des Dienstes für jede in der RAR angegebene Laderegel angibt. Die Statusberichterstellung für lokale dynamische Services wird verzögert, bis die Verarbeitung von Remote-Services abgeschlossen ist.
Abmeldung	authd initiiert einen CCR-T/CCA-T-Nachrichtenaustausch, um PCRF über die Beendigung des Teilnehmers zu informieren. authd initiiert die Aufhebung der Bereitstellung für alle Dienste, die für die Abonnentensitzung konfiguriert sind.
Servicegerät im Up-Zustand, nachdem der reconfigure Befehl ausgegeben wurde	authd führt keine weitere Aktion aus, wenn es eine Out-of-Band-Benachrichtigung von RDSM erhält, dass die Dienstaktion erfolgreich war. Beispielsweise wird keine CCR-U-Meldung gesendet, die angibt, dass der Dienst für die entsprechende Laderegel aktiv ist.

Tabelle 3 beschreibt, wie die authd-Antwort variiert, wenn die Aktionen zum Bereitstellen oder Aufheben der Bereitstellung von Diensten fehlschlagen.

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

Operation	Gx
Einloggen	authd initiiert einen CCR-I/CCA-I-Austausch, um die Abonnentensitzung bereitzustellen. 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 Dienste. authd sendet eine CCR-U-Nachricht, die Folgendes meldet: Der Service ist für jede Laderegel im CCA-I aktiv, die erfolgreich bereitgestellt wurde Der Dienst ist für die Abrechnungsregel im CCA-I, für die die Bereitstellung fehlgeschlagen ist, inaktiv. Der Dienst ist für alle Laderegeln, die aufgrund des Fehlers nicht verarbeitet wurden, inaktiv. authd ermöglicht den Abschluss der Abonnentensitzungsaushandlung und das Erreichen des aktiven Zustands.
Aktualisieren	Die Aufhebung der Bereitstellung wird vor der Bereitstellung für Dienste angewendet, die in derselben PCRF-RAR-Nachricht enthalten sind. Der Prozess variiert je nach den Aktionen, die fehlschlagen. Wenn authd eine Benachrichtigung über einen Fehler in der Antwort auf die Deinstanziierung des Dienstprofils erhält, was bedeutet, dass RDSM alle Wiederholungsversuche erfolglos ausgeführt hat, fährt authd mit der Verarbeitung der nächsten Dienstaktion fort. Dies bedeutet, dass das Update fortgesetzt und abgeschlossen wird, wenn nur die Aufhebung der Dienstbereitstellung fehlschlägt. Wenn authd eine Fehlerbenachrichtigung in der Instanziierungsantwort des Dienstprofils erhält, beendet authd die Verarbeitung aller verbleibenden Dienste. Für alle bereitgestellten und aufgehobenen Dienste in der Anforderung wird ein Rollback ausgeführt. Das bedeutet, dass die Bereitstellung von Diensten, die erfolgreich bereitgestellt wurden, jetzt aufgehoben wird. Services, deren Bereitstellung erfolgreich aufgehoben wurde, werden nun 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 im RAR angegebene Laderegel angibt. Das bedeutet, dass neu bereitgestellte Laderegeln als aktiv und nicht bereitgestellte Laderegeln als inaktiv gemeldet werden.
Abmeldung	authd initiiert einen CCR-T/CCA-T-Nachrichtenaustausch, um PCRF über die Beendigung des Teilnehmers zu informieren. authd initiiert die Aufhebung der Bereitstellung für alle Dienste, die für die Abonnentensitzung 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 Dienste.
Letztes Servicegerät im ausgefallenen Zustand, nachdem der reconfigure Befehl ausgegeben wurde	authd führt keine weitere Aktion aus, wenn es eine Out-of-Band-Benachrichtigung von RDSM erhält, dass die Dienstaktion fehlgeschlagen ist. Beispielsweise wird kein CCR-U gesendet, das angibt, dass der Dienst für die entsprechende Abrechnungsregel inaktiv ist. Betroffene Abonnentensitzungen werden beibehalten.

Rekonfiguration von Remote-Geräten durch den Bediener

Unter bestimmten Umständen müssen Sie möglicherweise manuell Dienste auf einem Remotegerät bereitstellen, um das Gerät erneut mit allen übereinstimmenden Abonnentendiensten zu synchronisieren, die auf mindestens einem anderen Remotegerät aktiv und konfiguriert sind. In den folgenden Szenarien ist eine manuelle Bereitstellung erforderlich:

• Ein neues Remote-Gerät wird mit dem BNG verbunden, nachdem eine oder mehrere Teilnehmersitzungen auf anderen Remote-Geräten ausgehandelt wurden und Remote-Services auf diesen Geräten bereitgestellt wurden.

• Die NETCONF-Sitzung mit einem Remotegerät mit einem oder mehreren bereitgestellten Remotediensten wechselt in den inaktiven Zustand, wird später wiederhergestellt und kehrt in den aktiven Zustand zurück. Dies ist im Grunde dasselbe wie ein neues Gerät, das an das BNG angeschlossen wird.

Nachdem die NETCONF-Sitzung mit dem 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 von Abonnenten-Remotediensten, die auf dem Gerät bereitgestellt werden können. Diese Services müssen entweder aktiv sein oder gerade bereitgestellt werden. Es wird ein separates ERRMSG-Ereignis protokolliert, das darauf hinweist, dass die Neukonfiguration der Services noch aussteht:

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

Mit dem request services remote-device-management reconfigure service-device Befehl stellen Sie alle aktiven (oder in Bearbeitung) Abonnentendienste bereit, 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 Diensts fehlschlägt, wird die gesamte Massenbereitstellung als Fehler betrachtet, und für alle erfolgreich bereitgestellten Dienste wird ein Rollback ausgeführt. 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 steuern können, indem Sie ein Massenlimit festlegen.

Anmerkung:

Das Remotegerät kann bei Teilnehmeranmeldungen, die nach dem Einrichten der NETCONF-Sitzung erfolgen, automatisch und ohne Bedienereingriff mit Abonnentendiensten bereitgestellt werden.

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 Abonnenten oder der Aktualisierung oder Abmeldung eines vorhandenen Abonnenten 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 sein kann und die Bereitstellung neuer Abonnentendienste akzeptiert, bevor vorhandene Abonnenten durch die Neukonfigurationsanforderung bereitgestellt werden.

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

1. RDSM verwaltet eine Liste der Remote-Geräte, die mit dem Dienst bereitgestellt werden. Wenn die NETCONF-TCP-Verbindung zum 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 und einer nachfolgenden vom Betreiber initiierten Neukonfiguration durch die BNG für alle aktiven Abonnentendienste neu konfiguriert worden sein.

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

   1. Überprüft den Dienst, bevor er auf die Neukonfigurationsanforderung antwortet. Die Validierung schlägt z. B. fehl, wenn das Wörterbuch auf der BNG keinen Eintrag für das angeforderte Remotedienstprofil oder die angeforderte Bereitstellungsaktion enthält, da keine RPCs zum Bereitstellen der Dienstvariablen und zum Hinzufügen des Diensts vorhanden sind.

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

   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:

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

      • Zeitüberschreitung der Antwort.

      In beiden Fällen setzt RDSM alle Dienste zurück, die durch den Massenvorgang erfolgreich 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 Abonnentendienste auf dem Remotegerät abgeschlossen ist, protokolliert RDSM das folgende ERRMSG-Ereignis:

   remote device device-name ip-address reconfiguration succeeded

Externe Meldung zur Serviceabwicklung ERRMSG-Ereignisse

Tabelle 4 listet die ERRMSG-Ereignisse auf, die authd an externe Managementsysteme übermitteln kann, sowie die Informationen, die in den Meldungen enthalten sind. Erfolgreiche Remote-Service-Aktionen werden nur an eine externe Instanz gemeldet und erzeugen kein ERRMSG-Protokoll.

Tabelle 4: Informationen in externen Meldungen zu ERRMSG-Ereignissen

ERRMSG-Veranstaltung	Gerätename	IP-Adresse	Aktueller Stand	Anzahl der Dienste, die zur Neukonfiguration anstehen	Name des Dienstes	Abonnenten-Kennung
Änderung des Remote-Gerätestatus von oben nach unten oder von unten nach oben	✓	✓	✓	–	–	–
Auf dem Remote-Gerät stehen Dienste zur Neukonfiguration an	✓	✓	–	✓	–	–
Abschluss der Remote-Geräteneukonfiguration (erfolgreich oder fehlgeschlagen)	✓	✓	✓	–	–	–
Fehler bei der Bereitstellung des Abonnenten-Remotediensts	✓	✓	–	–	✓	✓
Fehler beim Aufheben der Bereitstellung des Abonnenten-Remotediensts	✓	✓	–	–	✓	✓

Vorteile der Verwaltung von Remote Device Services

• Ermöglicht Topologien, in denen sich die Teilnehmerdienste sowohl über das BNG der MX-Serie als auch über seine Zugriffsknoten erstrecken, zu einem einzigen, logischen System.

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

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