Lorawan-stack: Настройка политик маршрутизации

Созданный на 9 февр. 2021 · 3Комментарии · Источник: TheThingsNetwork/lorawan-stack

Резюме

Настройте политики маршрутизации.

Для перечисления доступных сетей и арендаторов нам понадобится https://github.com/packetbroker/iam/issues/2.

Почему нам это надо?

Для сетей, чтобы настроить политики маршрутизации с другими сетями

Что уже есть? Что ты видишь сейчас?

В настоящее время это должно быть сделано с помощью pbctl , но было бы неплохо иметь возможность настраивать политики маршрутизации через интерфейс командной строки и консоль.

Чего не хватает? Что вы хотите увидеть?

Возможность настройки политик маршрутизации между локальной сетью или арендатором Packet Broker и любой другой сетью или арендатором.

Как вы предлагаете это реализовать?

Добавьте API к агенту брокера пакетов для управления политикой маршрутизации.
Реализовать поддержку командной строки
Реализовать поддержку консоли. Начнем с ручного ввода NetID и идентификатора арендатора. С https://github.com/packetbroker/iam/issues/2 у нас может быть раскрывающийся список общедоступных сетей и арендаторов (но все же должен быть возможен ручной ввод)

Как вы предлагаете это проверить?

Интеграционное тестирование

Можете ли вы сделать это самостоятельно и отправить запрос на слияние?

Может сделать поддержку API и CLI.

@kschiffer, пожалуйста, уже подумайте об UX. См. связанные команды pbctl , чтобы получить представление о том, что можно сделать.

console packet broker agent needux sizlarge ucli uweb

Источник

johanstokking

Самый полезный комментарий

@kschiffer, пожалуйста, начните думать о UX в виде каркасов.

API разработан. См. https://github.com/TheThingsNetwork/lorawan-stack/pull/3912/files#diff -4371dadc483aa14e23af85a7baf0e1d57b6d0c67fcf203b94412e13b224cc541, а затем особенно те rpc s.

Моя идея заключается в следующем:

Администраторы могут управлять пирингом для своей сети. В стеке вещей это для каждого развертывания. В облаке стека вещей это относится к каждому арендатору. То есть никаких настроек уровня приложения или устройства (пока)
Конфигурация технически состоит из двух частей: конфигурация пересылки и домашней сети. У серверов пересылки есть шлюзовая инфраструктура, у домашних сетей есть конечные устройства. Большинство пользователей будут играть любую роль, но технически нам нужно провести здесь различие.

Элементы пользовательского интерфейса:

Пункт меню верхнего уровня для Packet Broker. Мое предложение состояло бы в том, чтобы использовать термин Packet Broker для продвижения этого бренда. Таким образом, пункт меню будет читать Packet Broker , а не пиринг.
На странице обзора консоли покажите статус Packet Broker (подлежит уточнению, но пока есть ли в сети активная регистрация)
Страница настроек Packet Broker. Здесь пользователь может:
- Зарегистрируйтесь и отмените регистрацию в Packet Broker и просмотрите их регистрационную информацию (привязки /pba/registration ). При отсутствии регистрации ( NotFound ) отключить все компоненты на странице
- Управляйте политиками маршрутизации сервера пересылки. Это на двух уровнях: настройки по умолчанию (привязки /pba/forwarder/default-policy ) и настройки для каждой домашней сети (привязки /pba/forwarder/policies ). Чтобы настроить домашнюю сеть, вы можете разрешить пользователю выбирать домашнюю сеть из списка всех доступных сетей (привязка /pba/forwarde/home-networks )
- Просмотр политик маршрутизации, установленных другими серверами пересылки для этой домашней сети (привязка /pba/home-network/policies )

В будущем будет статистика, но пока не беспокойтесь об этом.

johanstokking 12 мар. 2021

👍2

Все 3 Комментарий

@kschiffer, пожалуйста, начните думать о UX в виде каркасов.

Моя идея заключается в следующем:

Администраторы могут управлять пирингом для своей сети. В стеке вещей это для каждого развертывания. В облаке стека вещей это относится к каждому арендатору. То есть никаких настроек уровня приложения или устройства (пока)
Конфигурация технически состоит из двух частей: конфигурация пересылки и домашней сети. У серверов пересылки есть шлюзовая инфраструктура, у домашних сетей есть конечные устройства. Большинство пользователей будут играть любую роль, но технически нам нужно провести здесь различие.

Элементы пользовательского интерфейса:

Пункт меню верхнего уровня для Packet Broker. Мое предложение состояло бы в том, чтобы использовать термин Packet Broker для продвижения этого бренда. Таким образом, пункт меню будет читать Packet Broker , а не пиринг.
На странице обзора консоли покажите статус Packet Broker (подлежит уточнению, но пока есть ли в сети активная регистрация)
Страница настроек Packet Broker. Здесь пользователь может:
- Зарегистрируйтесь и отмените регистрацию в Packet Broker и просмотрите их регистрационную информацию (привязки /pba/registration ). При отсутствии регистрации ( NotFound ) отключить все компоненты на странице
- Управляйте политиками маршрутизации сервера пересылки. Это на двух уровнях: настройки по умолчанию (привязки /pba/forwarder/default-policy ) и настройки для каждой домашней сети (привязки /pba/forwarder/policies ). Чтобы настроить домашнюю сеть, вы можете разрешить пользователю выбирать домашнюю сеть из списка всех доступных сетей (привязка /pba/forwarde/home-networks )
- Просмотр политик маршрутизации, установленных другими серверами пересылки для этой домашней сети (привязка /pba/home-network/policies )