Présentation de Remote Device Services Manager (RDSM)

Services à distance

Le MX BNG représente un point de gestion unique auprès des autorités externes pour tous les services aux abonnés, locaux et distants. Les services distants sont également représentés par des profils de service dynamiques configurés localement qui sont référencés par une autorité externe de la même manière que les services locaux sur le BNG. Par conséquent, il existe une interface cohérente entre l’autorité externe et le BNG pour toutes les actions de service. Le protocole de gestion XML NETCONF est utilisé pour le provisionnement et le déprovisionnement des services distants.

Les services de abonné locaux sont définis par des profils de service dynamiques qui n’ont aucun argument ou plus pour satisfaire des stratégies spécifiques à abonné. Les autorités externes, comme le PCRF, utilisent généralement un modèle référentiel pour fournir des services. La règle de facturation PCRF spécifie le nom du profil de service dynamique et les valeurs d’argument qui sont appliquées lors de la négociation de l’abonné pour le provisionnement de service (activation) ou en tant que mise à jour après que l’abonné est actif. Le service est présenté à l’appareil distant par le dictionnaire XML RDSM pour que cet appareil l’analyse, l’interprète et l’applique, ce qui permet à la règle de facturation ou au service d’une autorité externe d’être transmis de manière opaque à l’appareil distant avec un traitement minimal. Le profil de service distant peut inclure une ou plusieurs variables pour définir les paramètres de service.

Cependant, les services à distance peuvent également être appliqués de manière non référentielle. Dans ce cas, l’autorité externe spécifie le service distant de manière référentielle comme elle le ferait pour un service local. Le profil de service distant inclut une ou plusieurs variables pour définir les paramètres du service. Le RDSM utilise ensuite le dictionnaire de données attribué à l’appareil distant pour configurer le service sur cet appareil. Le contenu du dictionnaire RDSM d’un appareil est différent selon que le fournisseur de services utilise la méthode référentielle ou non référentielle.

Le profil de service dynamique distant est très léger par rapport à un profil de service local, qui peut inclure un grand nombre de strophes de configuration. Un profil de service dynamique distant ne contient que deux éléments :

• Vous devez spécifier que le type de profil dynamique est remote-device-service. Cette configuration empêche l’utilisation du profil en tant que profil de service local. Cela signifie que vous ne pouvez pas configurer un profil de service dynamique pour qu’il ait un double usage (local et distant).

• Le profil de service distant peut éventuellement inclure une strophe variable pour transmettre des valeurs d’argument au périphérique distant. La strophe variable peut être utilisée pour les méthodes référentielles ou non référentielles.

Toute configuration supplémentaire échoue à la vérification de la validation. Le profil de service distant étant très spécifique, un profil de service dédié est nécessaire pour chaque service distant. Pour l’autorité externe, cela signifie que chaque service à distance nécessite une règle de facturation PCRF distincte.

Flux de processus pour le provisionnement et le déprovisionnement du RDSM

Les services d’abonnés sont provisionnés et déprovisionnés comme suit :

• Provisionné lors de la connexion de l’abonné. Les services peuvent être fournis par le PCRF en réponse à l’initiation avec des échanges de messages Gx CCR-I/CCR-A.

• Déprovisionné lors de la déconnexion d’un abonné.

• Provisionné ou déprovisionné pour les sessions d’abonné actives en réponse à une autorité externe, telle que les messages Gx RAR du PCRF.

La figure 2 montre le flux de processus lorsque RDSM provisionne avec succès des services sur trois équipements distants éligibles, OLT1, OLT2 et OLT3, en instanciant le profil de service BW en amont.

1. Le provisionnement du service commence lorsqu’un abonné se connecte et qu’authd envoie une demande à RDSM pour instancier le profil de service distant sur les appareils distants éligibles pendant la négociation.

2. Le RDSM établit une liste des appareils distants éligibles pour le service à provisionner :

   • Le domaine d’accès de couche 2 de l’appareil doit correspondre à l’emplacement de l’abonné. Le domaine d’accès se compose d’une liste configurée de plages de VLAN ou d’ID de VLAN individuels. La balise VLAN externe de l’abonné doit figurer sur cette liste.

   • La connexion TCP NETCONF à l’équipement doit être établie. Bien qu’un appareil à l’état inactif ne soit pas éligible au provisionnement, il peut être disponible pour une reconfiguration s’il passe ultérieurement à l’état actif.

3. RDSM effectue une validation initiale avant de répondre à la demande d’instanciation du profil de service distant :

   • Une fois la validation réussie, RDSM envoie une instanciation de profil de service en attendant la réponse de l’accusé de réception à authd. Le provisionnement des services est maintenant en attente.

   • En cas d’échec de la validation, RDSM renvoie une réponse NACK à authd et abandonne le provisionnement du service.

   Les contrôles de validation effectués par RDSM n’échouent généralement pas pour les sessions d’abonnés actives. Les raisons de l’échec sont les suivantes :

   • Aucun équipement distant n’a un emplacement d’abonné correspondant au domaine d’accès.

   • Le dictionnaire situé sur le BNG n’inclut pas d’entrée pour le profil de service à distance demandé. Par conséquent, il n’y a pas de RPC pour fournir les variables de service et installer le service.

4. Le RDSM résout tous les paramètres requis pour chaque périphérique distant ; Cela inclut au minimum l’identifiant de l’abonné.

5. RDSM utilise ensuite la session NETCONF dédiée à chacun des appareils éligibles pour émettre une série d’appels RPC, comme spécifié dans le dictionnaire pour le provisionnement du service.

   Le provisionnement des services a lieu en parallèle pour les appareils éligibles. Le provisionnement échoue pour un appareil dans l’un des cas suivants :

   • Le RDSM reçoit une erreur explicite pour tout appel RPC.

   • Le délai de réponse expire.

   L’événement ERRMSG suivant est enregistré dans les deux cas :

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

6. Les appareils distants qui sont correctement provisionnés renvoient une réponse ACK au RDSM.

   Si un ou plusieurs appareils distants ne parviennent pas à être provisionnés, RDSM restaure le service sur chaque appareil distant qui a été correctement provisionné. RDSM utilise la session NETCONF dédiée à chacun de ces appareils pour émettre une série d’appels RPC, comme spécifié dans le dictionnaire, pour le déprovisionnement du service.

7. RDSM envoie une notification hors bande à l’authd pour indiquer si le service distant a été provisionné sur les appareils distants.

   • Lorsque le provisionnement est réussi pour tous les appareils distants, RDSM envoie une réponse complète de provisionnement de service à authd.

   • Si un ou plusieurs des appareils distants éligibles ne parviennent pas à être provisionnés, RDSM signale un échec de provisionnement à authd.

La figure 3 montre le flux de processus lorsque RDSM met à jour avec succès les services d’abonnés sur trois appareils distants éligibles, OLT1, OLT2 et OLT3 en instanciant le profil de service BW en amont avec des valeurs de paramètre différentes de celles utilisées lors de la connexion.

La mise à jour des services d’abonnés commence lorsque authd envoie une demande à RDSM pour instancier le profil de service distant afin de mettre à jour le service. Le flux de processus est le même que pour le flux de connexion de l’abonné, sauf que RDSM ne répond pas à la demande d’instanciation tant que tout le traitement requis pour provisionner le service n’est pas terminé. Cela signifie que lorsque la vérification de validation réussit, RDSM n’envoie pas d’instanciation de profil de service en attendant la réponse ACK à authd ; en cas d’échec de la validation, RDSM renvoie une réponse NACK à authd et abandonne le déprovisionnement du service.

La figure 4 montre le flux de processus lorsque RDSM déprovisionne avec succès les services pour mettre à jour les trois équipements distants éligibles, OLT1, OLT2 et OLT3, en instanciant le profil de service BW en amont.

Le flux du processus de déprovisionnement est le même pour une déconnexion d’abonné et une demande de mise à jour d’authd.

RDSM ne répond pas à authd tant que tous les traitements requis pour déprovisionner le service ne sont pas terminés (y compris toute nouvelle tentative d’échec) ; Cela permet à l’abonné de se déconnecter quel que soit le résultat du déprovisionnement.

En général, le déprovisionnement des services n’échoue pas. Si c’est le cas, vous devrez peut-être prendre des mesures correctives sur l’appareil distant pour que le déprovisionnement réussisse.

1. Le déprovisionnement des services commence lorsque l’une des situations suivantes se produit :

   • Un abonné se déconnecte et authd envoie une demande à RDSM pour désinstancier le profil de service à distance sur les appareils distants éligibles.

   • authd envoie une demande de mise à jour au RDSM pour désinstancier le profil de service à distance sur les appareils distants éligibles.

2. RDSM tient à jour une liste des appareils distants provisionnés avec le service. Si la connexion TCP NETCONF à l’appareil est interrompue, le déprovisionnement n’est pas tenté, car il est supposé qu’il s’est produit par d’autres moyens. Par exemple, l’appareil peut avoir été reconfiguré avec une configuration de base par défaut, puis une action de l’opérateur déclenche une reconfiguration par le BNG pour tous les services d’abonnés actifs.

3. RDSM effectue une validation initiale avant de répondre à la demande de désinstanciation du profil de service distant :

   • Lorsque la validation réussit, RDSM n’envoie pas de réponse à authd.

   • En cas d’échec de la validation, RDSM renvoie une réponse NACK à authd et abandonne le déprovisionnement du service. Les raisons d’un échec de validation sont les suivantes :

     • Aucun périphérique distant configuré n’est à l’état actif.

     • Le dictionnaire situé sur le BNG n’inclut pas d’entrée pour le profil de service à distance ou l’action de déprovisionnement demandé. Par conséquent, il n’y a pas de RPC pour fournir les variables de service et supprimer le service.

   Les contrôles de validation effectués par RDSM n’échouent généralement pas pour les sessions d’abonnés actives.

4. Le RDSM résout tous les paramètres requis pour chaque périphérique distant ; Cela inclut au minimum l’identifiant de l’abonné.

5. RDSM utilise ensuite la session NETCONF dédiée à chacun des appareils éligibles pour émettre une série d’appels RPC comme spécifié dans le dictionnaire pour le déprovisionnement du service. Le déprovisionnement des services a lieu en parallèle pour les appareils éligibles. Le déprovisionnement échoue pour un appareil dans l’un des cas suivants :

   • Le RDSM reçoit une erreur explicite pour tout appel RPC.

   • Le délai de réponse expire.

   Dans les deux cas, RDSM retente l’action de déprovisionnement jusqu’à 5 fois, à 5 secondes d’intervalle. Si toutes les tentatives échouent, l’événement ERRMSG suivant est enregistré dans les deux cas :

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

6. Les appareils distants qui sont déprovisionnés avec succès renvoient une réponse ACK au RDSM.

7. RDSM envoie une notification hors bande à authd pour signaler si le service distant a été déprovisionné sur les appareils distants.

   • Lorsque le déprovisionnement réussit, RDSM envoie une réponse complète de déprovisionnement de service à authd, qui termine ensuite la déconnexion de l’abonné.

     Dans le cas d’une demande de mise à jour plutôt que d’une déconnexion d’abonné, RDSM envoie une réponse complète de désinstanciation du profil de service à authd, qui termine le nettoyage de la session de service.

   • Si un ou plusieurs des appareils distants éligibles ne parviennent pas à être déprovisionnés, RDSM signale un échec de déprovisionnement à authd.

Dictionnaire RDSM pour l’implémentation des actions de service

Un dictionnaire XML stocké localement sur le BNG fait partie intégrante de la gestion des services d’équipement distants. Chaque service distant provisionné par l’autorité externe doit avoir une entrée dans un dictionnaire RDSM sur le BNG. Le dictionnaire traduit la règle de facturation provenant de PCRF en un ensemble d’appels de procédure à distance (RPC) spécifiques au fournisseur dans l’entrée associée au service. Les contrôleurs en chef provisionnent ou déprovisionnent ensuite le service. Les codes RPC étant spécifiques à chaque fournisseur, le dictionnaire l’est aussi. Cela signifie que des dictionnaires distincts sont nécessaires pour chaque équipement distant de chaque fournisseur. Pour les appareils d’un fournisseur donné, les différentes versions logicielles des appareils peuvent également nécessiter des dictionnaires différents.

Le format du dictionnaire est suffisamment souple pour prendre en charge à la fois les services de référence et les services non référentiels, lorsque :

• Un service référentiel signifie que l’ensemble du service, y compris les arguments, est présenté de manière opaque à l’équipement distant tel qu’il est reçu d’une autorité externe via le dictionnaire RDSM. Le profil de service dynamique peut inclure une strophe variable qui est utilisée par le dictionnaire lors de la traduction des arguments. L’équipement distant analyse, interprète et applique les arguments de lui-même sans aucune interprétation ou analyse par le BNG.

• Un service non référentiel signifie que tous les arguments fournis par l’autorité externe doivent être résolus et fournis au périphérique distant individuellement par un ou plusieurs RPC. Dans ce cas, le profil de service dynamique peut nécessiter une strophe variable qui est utilisée par le dictionnaire lors de la traduction des arguments.

Dans les deux cas, le dictionnaire doit spécifier les moyens (généralement un emplacement de couche 2) pour identifier l’abonné adapté à l’équipement distant afin de distinguer un abonné d’un autre.

Le dictionnaire XML RDSM a le format général suivant :

Le tableau 1 définit les différents composants du dictionnaire.

Tableau 1 : Définitions des composants du dictionnaire XML

junos-rdm-parameters	Bloc de paramètres qui répertorie les paramètres individuels qui configurent le service.
paramètre junos-rdm	Paramètre individuel.
nom-junos-rdm	Dans le bloc de paramètres, cet élément identifie l’abonné sur l’appareil distant ou l’argument PCRF. Utilisez subscription-id pour l’abonné et le nom de l’argument pour tout argument spécifié dans le PCRF.
junos-rdm-source	Source de la valeur du paramètre : session d’abonné lorsque la valeur provient de la session SDB. service-profile lorsque la valeur provient de l’argument service profile.
junos-rdm-index	Index, tel qu’une valeur de type énumérée, qui résout le paramètre à partir de la source spécifiée. La source de session d’abonné en a besoin pour mapper le paramètre à un attribut SDB utilisé pour résoudre la valeur du paramètre. Par exemple, pour certains cas d’utilisation, l’ID d’abonnement PCRF est stocké dans l’entrée SDB de l’abonné référencée par un index (type d’attribut) pour résoudre ce paramètre.
junos-rdm-services	Bloc de service qui répertorie un ou plusieurs services distants pris en charge par l’appareil.
junos-rdm-service	Service à distance individuel défini par nom de service, configuration de provisionnement et configuration de déprovisionnement.
nom-junos-rdm	Dans le bloc de service, cet élément est le nom du service. Il s’agit du nom de service de base, sans arguments, du service provenant du PCRF.
junos-rdm-provision	Bloc de provisionnement qui inclut la configuration de provisionnement.
junos-rdm-deprovision	Bloc de déprovisionnement qui inclut la configuration de déprovisionnement.
configuration de service junos-rdm	Configuration de service qui inclut un ou plusieurs bacs réutilisables pour provisionner ou déprovisionner le service. Lorsque des arguments sont spécifiés dans le service PCRF pour le provisionnement, les RPC incluent ces arguments.
junos-rdm-open-configuration	Bloc qui inclut zéro ou plusieurs RPC pour commencer la configuration de l’équipement distant.
junos-rdm-edit-configuration	Bloc qui inclut un ou plusieurs RPC pour modifier la configuration et appliquer des actions de provisionnement ou de déprovisionnement de service à l’appareil de manière groupée, en référençant le bloc junos-rdm-provision ou junos-rdm-deprovision pour le service spécifié. La configuration de chaque service faisant partie de la mise à jour groupée de l’appareil distant est incluse.
junos-rdm-commit-configuration	Bloc qui inclut zéro ou plusieurs RPC pour valider les modifications sur l’appareil distant.
junos-rdm-close-configuration	Bloc qui inclut zéro ou plusieurs RPC pour mettre fin à la configuration de l’équipement distant.
junos-rdm-rpc	RPC individuel pour configurer l’équipement distant.

Pour la configuration d’un appareil distant, la configuration de modification est toujours nécessaire pour provisionner ou déprovisionner le service. Dans certains cas d’usage, les blocs de configuration open, commit et close peuvent être facultatifs.

Fonctionnalités supplémentaires à utiliser avec un modèle d’accès RDSM

Les fonctionnalités de cette section ne sont pas obligatoires pour RDSM, mais peuvent être utiles dans certains cas d’utilisation ou topologies.

Un nom d’utilisateur généré localement est utilisé dans les interactions avec une autorité externe pour authentifier les abonnés VLAN dynamiques, DHCPv4 et DHCPv6. En règle générale, les balises VLAN d’abonné sont incluses dans le nom d’utilisateur en configurant l’option interface-name de l’instruction username-include .

De même, les balises VLAN d’abonné sont incluses dans l’identificateur d’abonnement pour les interactions PCRF en configurant l’option interface-name de l’instruction subscription-id-data-include .

Par convention, le nom de l’interface a le format suivant dans les deux cas :

Dans certains cas d’utilisation avec le modèle d’accès RDSM, la balise VLAN externe est unique dans tout le système. Cela signifie que vous pouvez utiliser un format différent qui exclut le nom IFD sous-jacent :

Pour générer le format de nom d’utilisateur sans le nom IFD sous-jacent, vous spécifiez l’option vlan-tags au lieu de l’option avec l’instruction interface-name username-include . Pour plus d’informations, reportez-vous à Configuration des informations de nom d’utilisateur de l’interface VLAN pour l’authentification AAA et Création de noms d’utilisateur uniques pour les clients DHCP.

Pour générer le format d’ID d’abonnement sans le nom IFD sous-jacent, vous spécifiez l’option vlan-tags au lieu de l’option interface-name avec l’instruction subscription-id-data-include . Voir Configuration de la partition PCRF pour plus d’informations.

Certains réseaux clients peuvent avoir plusieurs modèles de déploiement ou cas d’utilisation qui font que le BNG de la MX Series pour chaque cas interagit avec le même back-end PCRF. Dans cette situation, vous devrez peut-être distinguer les cas d’utilisation du PCRF.

Les messages d’échange de capacité Diameter entre pairs portent l’AVP de nom de produit Diameter. Vous pouvez configurer des valeurs autres que celles par défaut pour les cas d’utilisation afin que le PCRF puisse faire la distinction entre les messages. Voir Messages utilisés par les applications Diameter et AVP Diameter et Applications Diameter pour plus d’informations.

Réponse de l’authd à l’autorité externe sur le succès ou l’échec

La façon dont l’authd répond à l’autorité externe dépend des éléments suivants :

• Opération en cours : par exemple, le provisionnement lors de la connexion d’un abonné par rapport à la mise à jour d’une session d’abonné existante.

• L’autorité externe, Gx (PCRF).

Le Tableau 2 décrit comment la réponse authd varie lorsque les actions de provisionnement ou de déprovisionnement du service réussissent.

Tableau 2 : Comment l’authd répond aux autorités externes lorsque les actions de service réussissent

Fonctionnement	Gx
Connectez-vous	L’authd initie l’échange de messages CCR-I/CCA-I pour provisionner la session de l’abonné. Lorsque tous les services du CCA-I sont provisionnés, authd envoie un message CCR-U qui indique que le service est actif pour chaque règle de facturation du CCA-I. Les rapports d’état des services dynamiques locaux sont retardés jusqu’à ce que le provisionnement des services distants soit terminé.
Mettre à jour	Le déprovisionnement est appliqué avant le provisionnement des services inclus dans le même message RAR PCRF. Lorsque le déprovisionnement et le provisionnement sont terminés pour toutes les actions de service incluses dans le RAA PCRF, authd envoie une réponse RAA avec un rapport de règle qui indique l’état inactif/actif du service pour chaque règle de facturation spécifiée dans le RAR. Les rapports d’état pour les services dynamiques locaux sont retardés jusqu’à ce que le traitement des services distants soit terminé.
Déconnexion	L’authd initie un échange de messages CCR-T/CCA-T pour informer PCRF de la résiliation de l’abonné. authd lance le déprovisionnement pour tous les services configurés pour la session d’abonné.
Appareil de service à l’état actif après l’émission de la reconfigure commande	L’authd ne prend aucune autre mesure lorsqu’il reçoit une notification hors bande du RDSM indiquant que l’action de service a réussi. Par exemple, il n’envoie pas de message CCR-U indiquant que le service est actif pour la règle de facturation correspondante.

Le Tableau 3 décrit comment la réponse authd varie lorsque les actions de provisionnement ou de déprovisionnement de service échouent.

Tableau 3 : Comment l’authd répond aux autorités externes en cas d’échec des actions de service

Fonctionnement	Gx
Connectez-vous	L’authd initie un échange CCR-I/CCA-I pour provisionner la session de l’abonné. Lorsque authd reçoit une notification d’échec dans la réponse d’instanciation du profil de service ou hors bande de RDSM, authd arrête de traiter tous les services restants. authd envoie un message CCR-U qui rapporte ce qui suit : Le service est actif pour chaque règle de facturation dans la CCA-I qui a été provisionnée avec succès Le service est inactif pour la règle de facturation dans la CCA-I qui a échoué au provisionnement. Le service est inactif pour toutes les règles de facturation non traitées en raison de l’échec. authd permet à la négociation de la session de l’abonné de se terminer et d’atteindre l’état actif.
Mettre à jour	Le déprovisionnement est appliqué avant le provisionnement des services inclus dans le même message RAR PCRF. Le processus varie en fonction des actions qui échouent. Lorsque authd reçoit une notification d’échec dans la réponse de désinstanciation du profil de service, ce qui signifie que RDSM a effectué toutes les nouvelles tentatives sans succès, authd continue à traiter l’action de service suivante. Cela signifie que lorsque seul le déprovisionnement de service échoue, la mise à jour se poursuit et se termine. Lorsque authd reçoit une notification d’échec dans la réponse d’instanciation du profil de service, authd arrête de traiter tous les services restants. Tous les services provisionnés et déprovisionnés de la demande sont restaurés. Cela signifie que les services qui ont été correctement provisionnés le sont désapprovisionnés. Les services qui ont été déprovisionnés avec succès le sont désormais. Lorsque toutes les actions de restauration sont terminées, authd envoie une réponse RAA avec un rapport de règle qui indique l’état inactif/actif du service pour chaque règle de facturation spécifiée dans le RAR. Cela signifie que les règles de facturation reprovisionnées sont signalées comme actives et que les règles de facturation déprovisionnées sont signalées comme inactives.
Déconnexion	L’authd initie un échange de messages CCR-T/CCA-T pour informer PCRF de la résiliation de l’abonné. authd lance le déprovisionnement pour tous les services configurés pour la session d’abonné. Lorsque authd reçoit une notification d’échec dans la réponse d’instanciation du profil de service ou hors bande du RDSM, authd poursuit la déconnexion, y compris le déprovisionnement de tous les services restants.
Dernier équipement de service à l’état inactif après l’émission de la reconfigure commande	L’authd ne prend aucune autre mesure lorsqu’il reçoit une notification hors bande du RDSM indiquant que l’action du service a échoué. Par exemple, il n’envoie pas de CCR-U indiquant que le service est inactif pour la règle de facturation correspondante. Les sessions d’abonnés concernées sont maintenues.

Reconfiguration des équipements distants par l’opérateur

Dans certaines circonstances, vous devrez peut-être provisionner manuellement des services sur un périphérique distant pour resynchroniser le périphérique avec tous les services d’abonné correspondants qui sont actifs et configurés sur au moins un autre périphérique distant. Un provisionnement manuel est nécessaire dans les scénarios suivants :

• Un nouvel équipement distant est connecté au BNG après qu’une ou plusieurs sessions d’abonné ont été négociées sur d’autres appareils distants et que des services distants ont été provisionnés sur ces appareils.

• La session NETCONF vers un équipement distant avec un ou plusieurs services distants provisionnés passe à l’état inactif, puis récupère et revient à l’état actif. C’est effectivement la même chose qu’un nouvel appareil connecté au BNG.

Une fois la session NETCONF établie sur l’équipement distant dans l’une ou l’autre de ces situations, un événement ERRMSG est enregistré indiquant que l’appareil est opérationnel. Aucun service à distance n’est actuellement provisionné sur l’appareil. RDSM établit une liste des services distants d’abonnés qui peuvent être provisionnés sur l’appareil. Ces services doivent être actifs ou en cours de provisionnement. Un événement ERRMSG distinct est consigné, indiquant que les services sont en attente de reconfiguration :

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

Vous utilisez la request services remote-device-management reconfigure service-device commande pour provisionner tous les services d’abonné actifs (ou en cours) qui sont mappés au domaine d’accès associé à l’appareil. La demande de reconfiguration déclenche le provisionnement en bloc des services sur l’appareil. Si le provisionnement d’un service échoue, l’ensemble du provisionnement en bloc est considéré comme un échec et tous les services correctement provisionnés sont restaurés. Dans ce cas, vous devez émettre à nouveau la commande. La restauration s’applique uniquement à chaque tentative de provisionnement en bloc, vous pouvez donc contrôler les effets d’un échec de provisionnement en bloc en définissant une limite de provisionnement groupé.

Remarque :

L’équipement distant peut être provisionné automatiquement avec des services d’abonné sans intervention de l’opérateur pour les connexions d’abonné qui se produisent après l’établissement de la session NETCONF.

Vous pouvez émettre une demande de reconfiguration à tout moment lorsque l’appareil distant est opérationnel. Lorsque la reconfiguration de l’appareil distant commence, toutes les nouvelles actions de service résultant d’une nouvelle négociation de abonné ou d’une mise à jour ou d’une déconnexion de abonné existantes sont retardées pour l’appareil distant jusqu’à ce que la reconfiguration soit terminée. En outre, une demande de reconfiguration peut être effectuée à tout moment lorsque l’appareil distant est opérationnel. Cela signifie qu’un équipement distant peut être connecté au réseau et accepter le provisionnement de nouveaux services d’abonné avant que les abonnés existants ne soient provisionnés par la demande de reconfiguration.

Les étapes suivantes illustrent le flux de processus RDSM pour les demandes de reconfiguration :

1. RDSM tient à jour une liste des appareils distants provisionnés avec le service. Si la connexion TCP NETCONF à l’appareil est interrompue, le déprovisionnement n’est pas tenté, car il est supposé qu’il s’est produit par d’autres moyens. Par exemple, l’appareil peut avoir été reconfiguré avec une configuration de base par défaut, puis une action de l’opérateur déclenche une reconfiguration par le BNG pour tous les services d’abonnés actifs.

2. RDSM effectue les opérations en bloc suivantes, où la taille en bloc peut atteindre le nombre total de services d’abonnés à provisionner :

   1. Valide le service avant de répondre à la demande de reconfiguration. Par exemple, la validation échoue lorsque le dictionnaire situé sur le BNG n’inclut pas d’entrée pour le profil de service distant ou l’action de provisionnement demandé, car il n’y a pas de RPC pour fournir les variables de service et ajouter le service.

   2. Résout tous les paramètres requis pour chaque périphérique distant ; Cela inclut au minimum l’identifiant de l’abonné.

   3. Utilise la session NETCONF dédiée à l’équipement distant pour émettre une série d’appels RPC, comme spécifié dans le dictionnaire pour le provisionnement du service. Le provisionnement échoue pour un appareil dans l’un des cas suivants :

      • Le RDSM reçoit une erreur explicite pour tout appel RPC.

      • Le délai de réponse expire.

      Dans les deux cas, RDSM annule tous les services qui ont été correctement provisionnés par l’opération en bloc, la reconfiguration est abandonnée et RDSM consigne l’événement ERRMSG suivant :

      remote device device-name ip-address reconfiguration failed

3. Si le provisionnement est terminé pour tous les services d’abonné sur l’équipement distant, RDSM consigne l’événement ERRMSG suivant :

   remote device device-name ip-address reconfiguration succeeded

Notification externe pour le traitement des services Événements ERRMSG

Le Tableau 4 répertorie les événements ERRMSG que l’authd peut communiquer aux systèmes de gestion externes et les informations incluses dans les notifications. Les actions de service à distance réussies sont uniquement signalées à une autorité externe et ne génèrent pas de journal ERRMSG.

Tableau 4 : Informations incluses dans les notifications externes pour les événements ERRMSG

Événement ERRMSG	Nom de l’appareil	Adresse IP	État actuel	Nombre de services en attente de reconfiguration	Nom du service	Identifiant d’abonné
Changement d’état de l’appareil distant de haut en bas ou de bas en haut	✓	✓	✓	–	–	–
L’appareil distant a des services en attente de reconfiguration	✓	✓	–	✓	–	–
Reconfiguration des appareils à distance (réussite ou échec)	✓	✓	✓	–	–	–
Échec du provisionnement du service à distance par l’abonné	✓	✓	–	–	✓	✓
Échec du déprovisionnement du service à distance abonné	✓	✓	–	–	✓	✓

Avantages de la gestion des services d’équipement à distance

• Permet des topologies dans lesquelles les services d’abonné couvrent à la fois le BNG de la MX Series et ses nœuds d’accès pour former un seul système logique.

• Simplifie la configuration et la gestion des BNG et des appareils distants dans les topologies qui utilisent des systèmes de gestion et de provisionnement externes. Les périphériques distants ont généralement des adresses privées inconnues du système externe, de sorte que le système externe s’adresse uniquement au BNG de la MX Series.

• Ajout d’un nouveau type de profil de service pour les services distants afin de différencier facilement les services distants des services locaux.