Vue d’ensemble des entités multicouches

Normes d’interface prises en charge

NorthStar prend actuellement en charge les normes d’interface suivantes :

• Open ROADM, utilisé par Juniper proNX Optical Director

  Reportez-vous à https://www.juniper.net/documentation/product/en_US/pronx-optical-director pour Juniper Networks documentation de proNX Optical Director.

• TE, utilisé par ADVA Optical Networking et Coriant

• Prise en charge limitée de T-API 2.1, utilisée par Ciena et Fujitsu Virtuora NC

L’interface utilisateur de NorthStar pour la configuration et l’utilisation des données du domaine de transport et le flux de travail sont les mêmes, quelle que soit la norme d’interface. Il existe cependant quelques différences en termes de fonctionnalités prises en charge, et celles-ci sont notées dans la documentation.

Principales caractéristiques du support multicouche du contrôleur NorthStar

Les fonctionnalités suivantes s’appliquent à la prise en charge multicouche du contrôleur NorthStar NorthStar :

• Une seule instance de contrôleur NorthStar (ou plusieurs instances de contrôleur NorthStar NorthStar déployées en tant que cluster haute disponibilité) peuvent recevoir simultanément des informations topologiques abstraites de plusieurs contrôleurs de transport.

• Vous pouvez configurer plusieurs périphériques associés à un seul contrôleur de transport, et au moins un périphérique est requis. Si plusieurs périphériques sont configurés, le contrôleur NorthStar NorthStar tente de se connecter à eux selon la méthode Round Robin.

• Le contrôleur de transport doit fournir au contrôleur NorthStar les informations d’identification locale et distante pour chaque liaison intercalaire. Si le contrôleur de transport n’est pas en mesure de fournir les identificateurs de liaison intercalaire côté domaine de paquets, il fournit des liaisons intercalaires ouvertes que vous pouvez compléter à l’aide de l’interface utilisateur Web du contrôleur NorthStar.

• Juniper Networks fournit un script open source à utiliser éventuellement pour configurer les liaisons intercouches.

• Les échecs de liaison de transport peuvent être signalés par les contrôleurs de transport et sont affichés dans l’interface utilisateur du contrôleur NorthStar en tant que liaisons de transport ayant échoué. Seules les défaillances signalées dans la base de données d’ingénierie du trafic (TED) sont prises en compte pour le reroutage. Les liaisons IP associées à des échecs de liaison de transport signalés par un contrôleur de transport ne sont pas considérées comme inactives par le contrôleur NorthStar, sauf si elles sont signalées dans le TED.

• La configuration du profil du contrôleur de transport peut être effectuée dans l’interface utilisateur Web du contrôleur NorthStar ou directement via l’API REST vers le nord du contrôleur NorthStar. Vous pouvez afficher et gérer les éléments de la couche de transport à la fois dans l’interface utilisateur Web et dans le planificateur NorthStar NorthStar.

• L’interface utilisateur Web et l’API REST vers le nord offrent des options de conception de chemin haut de gamme liées au délai pour les liaisons de transport. Dans l’interface utilisateur Web, accédez à Applications>Provision LSP, puis cliquez sur l’onglet Design . Ces options sont également disponibles dans le planificateur NorthStar.

  Lorsque le domaine de transport est connu, les informations de retard n’ont pas besoin d’être renseignées manuellement ou importées à partir d’un fichier statique, car elles sont apprises dynamiquement par le contrôleur NorthStar.

• Une fois le mappage des liaisons intercalaires terminé, les données utilisées par les options de conception de chemin (delay, SRLG, Protected) sont renseignées automatiquement et mises à jour dynamiquement via la communication entre les contrôleurs de transport et NorthStar.

Les SRLG

Le contrôleur NorthStar prend en compte les informations du groupe de liaisons de risque partagé de transport (SRLG) chaque fois qu’une optimisation de chemin se produit ou qu’un événement déclenche un réacheminement.

Par défaut, le contrôleur NorthStar associe les SRLG de transport aux liaisons IP en fonction des informations reçues du contrôleur de transport. La connexion du contrôleur NorthStar à plusieurs contrôleurs de transport introduit la possibilité de chevauchement des plages SRLG, ce qui peut ne pas être souhaitable. La configuration des profils de contrôleur de transport dans l’interface utilisateur Web de l’Contrôleur NorthStar permet de spécifier un préfixe TSRLG supplémentaire (une extension de préfixe) pour chaque contrôleur de transport afin d’éviter tout chevauchement involontaire.

La prévention du chevauchement involontaire des plages SRLG nécessite une vigilance particulière lorsque vous avez des plages de contrôleur de transport et que vous affectez manuellement des SRLG aux liaisons IP dans le contrôleur NorthStar.

Événements de maintenance

Les événements de maintenance qui incluent des éléments de couche transport peuvent être planifiés dans l’interface utilisateur du contrôleur NorthStar NorthStar, car les SRLG de transport sont automatiquement détectés par le contrôleur NorthStar. Vous pouvez sélectionner n’importe quel élément de la couche de transport ou une combinaison d’éléments de la couche de transport et de la couche de paquets à inclure dans un événement de maintenance. Parmi les éléments de la couche transport, seuls les SRLG de transport peuvent déclencher le réacheminement des LSP de la couche paquets.

Le contrôleur NorthStar et le planificateur NorthStar NorthStar prennent tous deux en charge la création d’événements de maintenance qui incluent des éléments de couche transport. Le contrôleur de transport n’est pas informé de ces événements de maintenance, car ils n’existent que dans le cadre de NorthStar.

Latence

Le contrôleur NorthStar peut apprendre dynamiquement les informations de latence pour les liaisons de transport et les liaisons intercouches, afin de prendre en charge les contraintes de routage basées sur la latence pour les LSP de paquets. Il existe trois sources possibles pour les valeurs de latence. Toutes les valeurs sont collectées et enregistrées, mais lorsque plusieurs valeurs sont présentes pour le même objet, le contrôleur NorthStar ne peut en accepter qu’une seule. Le contrôleur NorthStar résout les conflits en acceptant les valeurs de latence en fonction de leur source dans l’ordre de préférence suivant :

• Configuration manuelle par l’utilisateur

• Sondes sur les routeurs prenant en charge l’analyse

• Contrôleur de transport

Paires LSP diversifiées SRLG

Dans l’interface utilisateur Web, vous pouvez créer des paires LSP qui sont différentes les unes des autres en termes de SRLG. Utilisez les mêmes processus et fenêtres d’interface utilisateur que ceux que vous utilisez pour créer d’autres paires LSP diversifiées, et spécifiez SRLG pour la diversité. Cette fonctionnalité est également disponible dans le planificateur NorthStar.

Liaisons de transport protégées

NorthStar prend en charge la contrainte de routage des liens protégés préférés pour les LSP de paquets. Lorsque cette contrainte est sélectionnée, NorthStar calcule le chemin qui maximise le nombre de liaisons protégées, et offre donc la meilleure protection globale. Les liens protégés peuvent être implémentés par le biais d’API REST ou à l’aide de l’interface utilisateur web. Dans l’interface utilisateur Web, accédez à Applications > Provision LSP, puis cliquez sur l’onglet Advanced . Par défaut, l’option Route sur le lien IP protégé n’est pas sélectionnée.