Lorawan-stack: Configurer les politiques de routage

Créé le 9 févr. 2021 · 3Commentaires · Source: TheThingsNetwork/lorawan-stack

Configurez les politiques de routage.

Pour répertorier les réseaux et les locataires disponibles, nous avons besoin de https://github.com/packetbroker/iam/issues/2.

Pour que les réseaux configurent des politiques de routage avec d'autres réseaux

Cela devrait actuellement être fait avec pbctl , mais ce serait bien de pouvoir configurer les politiques de routage via la CLI et la console.

La possibilité de configurer des politiques de routage entre le réseau ou locataire local de Packet Broker et tout autre réseau ou locataire.

Ajouter une API à Packet Broker Agent pour la gestion des politiques de routage
Implémenter la prise en charge de la CLI
Implémenter la prise en charge de la console. Commençons par saisir manuellement le NetID et l'ID de locataire. Avec https://github.com/packetbroker/iam/issues/2 , nous pouvons avoir une liste déroulante des réseaux publics et des locataires (mais la saisie manuelle doit toujours être possible)

Tests d'intégration

Peut prendre en charge l'API et la CLI.

@kschiffer , pensez déjà à UX. Voir les commandes liées pbctl pour avoir une idée de ce qui peut être fait.

console packet broker agent needux sizlarge ucli uweb

Source

johanstokking

Commentaire le plus utile

@kschiffer , s'il vous plaît, commencez à penser à l'UX sous forme de wireframes.

L'API est conçue. Voir https://github.com/TheThingsNetwork/lorawan-stack/pull/3912/files#diff -4371dadc483aa14e23af85a7baf0e1d57b6d0c67fcf203b94412e13b224cc541 et surtout ces rpc s.

Mon idée est la suivante :

Les administrateurs peuvent gérer le peering pour leur réseau. Dans The Things Stack, c'est par déploiement. Dans The Things Stack Cloud, c'est par locataire. Autrement dit, aucun paramètre au niveau de l'application ou de l'appareil (pour l'instant)
La configuration est techniquement double : configuration du transitaire et du réseau domestique. Les transitaires ont une infrastructure de passerelle, les réseaux domestiques ont des terminaux. La plupart des utilisateurs joueront l'un ou l'autre rôle, mais techniquement, nous devons faire une distinction ici

Les éléments de l'interface utilisateur sont :

Élément de menu de niveau supérieur pour Packet Broker. Ma suggestion serait d'utiliser le terme Packet Broker pour promouvoir cette marque. Ainsi, l'élément de menu lirait Packet Broker et non peering
Dans la page de présentation de la console, affichez l'état de Packet Broker (à déterminer, mais pour l'instant si le réseau a une inscription active)
La page des paramètres de Packet Broker. Ici, l'utilisateur peut :
- Enregistrez-vous et désenregistrez-vous auprès de Packet Broker, et consultez leurs informations d'enregistrement ( /pba/registration liaisons). Lorsqu'il n'y a pas d'inscription ( NotFound ), désactivez tous les composants de la page
- Gérer les politiques de routage du redirecteur. Cela se fait à deux niveaux : les paramètres par défaut (liaisons /pba/forwarder/default-policy ) et les paramètres du réseau domestique (liaisons /pba/forwarder/policies ). Pour configurer par réseau domestique, vous pouvez autoriser l'utilisateur à sélectionner un réseau domestique dans une liste de tous les réseaux disponibles (liaison /pba/forwarde/home-networks )
- Afficher les politiques de routage définies par d'autres redirecteurs pour ce réseau domestique (liaison /pba/home-network/policies )

Il y aura des statistiques à l'avenir, mais ne vous en souciez pas pour l'instant.

johanstokking le 12 mars 2021

👍2

@kschiffer , s'il vous plaît, commencez à penser à l'UX sous forme de wireframes.

L'API est conçue. Voir https://github.com/TheThingsNetwork/lorawan-stack/pull/3912/files#diff -4371dadc483aa14e23af85a7baf0e1d57b6d0c67fcf203b94412e13b224cc541 et surtout ces rpc s.

Mon idée est la suivante :

Les administrateurs peuvent gérer le peering pour leur réseau. Dans The Things Stack, c'est par déploiement. Dans The Things Stack Cloud, c'est par locataire. Autrement dit, aucun paramètre au niveau de l'application ou de l'appareil (pour l'instant)
La configuration est techniquement double : configuration du transitaire et du réseau domestique. Les transitaires ont une infrastructure de passerelle, les réseaux domestiques ont des terminaux. La plupart des utilisateurs joueront l'un ou l'autre rôle, mais techniquement, nous devons faire une distinction ici

Les éléments de l'interface utilisateur sont :

Élément de menu de niveau supérieur pour Packet Broker. Ma suggestion serait d'utiliser le terme Packet Broker pour promouvoir cette marque. Ainsi, l'élément de menu lirait Packet Broker et non peering
Dans la page de présentation de la console, affichez l'état de Packet Broker (à déterminer, mais pour l'instant si le réseau a une inscription active)
La page des paramètres de Packet Broker. Ici, l'utilisateur peut :
- Enregistrez-vous et désenregistrez-vous auprès de Packet Broker, et consultez leurs informations d'enregistrement ( /pba/registration liaisons). Lorsqu'il n'y a pas d'inscription ( NotFound ), désactivez tous les composants de la page
- Gérer les politiques de routage du redirecteur. Cela se fait à deux niveaux : les paramètres par défaut (liaisons /pba/forwarder/default-policy ) et les paramètres du réseau domestique (liaisons /pba/forwarder/policies ). Pour configurer par réseau domestique, vous pouvez autoriser l'utilisateur à sélectionner un réseau domestique dans une liste de tous les réseaux disponibles (liaison /pba/forwarde/home-networks )
- Afficher les politiques de routage définies par d'autres redirecteurs pour ce réseau domestique (liaison /pba/home-network/policies )