Présentation de l’OAM des services Ethernet ITU-T Y.1731
Cette section décrit le service OAM (ITU-TY.1731) et ses deux composantes principales : la gestion des défaillances (surveillance, détection et isolation) et la surveillance des performances (mesure de la perte de trame, mesure de la perte de trame synthétique et mesure du retard de trame).
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Consultez la section Comportement ITU-T Y.1731 (ETH-DM, ETH-LM et ETH-SLM) spécifique à la plate-forme pour obtenir des notes relatives à votre plate-forme.
Présentation des mesures de retard de trame Ethernet
- Fonction de mesure du retard de trame ITU-T Y.1731
- Mesure unidirectionnelle du retard de trame Ethernet
- Mesure du retard de trame Ethernet bidirectionnel
- Choisir entre ETH-DM unidirectionnel et bidirectionnel
- Restrictions relatives à la mesure du retard de trame Ethernet
Fonction de mesure du retard de trame ITU-T Y.1731
La norme IEEE 802.3-2005 sur les opérations, l’administration et la maintenance Ethernet (OAM) définit un ensemble de mécanismes de gestion des défaillances de liaison permettant de détecter et de signaler les défaillances de liaison sur une seule LAN Ethernet point à point.
Junos OS prend en charge les principales normes OAM qui permettent aux fournisseurs de services de gérer et de surveiller le service Ethernet de bout en bout de bout en bout :
Norme IEEE 802.1ag, également connue sous le nom de « Connectivity Fault Management (CFM) ».
La Recommandation UIT-T Y.1731, qui utilise une terminologie différente de celle de l’IEEE 802.1ag et définit les fonctionnalités OAM des services Ethernet pour la surveillance des pannes, le diagnostic et la surveillance des performances.
Ces capacités permettent aux opérateurs de proposer des accords de niveau de service (SLA) contraignants et de générer de nouveaux revenus grâce à des offres de services avec garantie de débit et de performance et adaptées aux besoins spécifiques de leurs clients.
Vous pouvez configurer les capacités de mesure des pertes Ethernet conformes à la norme ITU-T Y.1731 (ETH-LM), de mesure des pertes synthétiques Ethernet (ETH-SLM) et de mesure des retards Ethernet (ETH-DM) sur les cartes de ligne MPC10 et MPC11.
Ethernet CFM
La norme IEEE 802.1ag pour la gestion des pannes de connectivité (CFM) définit des mécanismes permettant d’assurer le service Ethernet de bout en bout sur n’importe quel chemin, qu’il s’agisse d’une liaison unique ou de plusieurs liaisons couvrant des réseaux composés de plusieurs réseaux locaux.
Junos OS prend en charge les éléments clés suivants de la norme Ethernet CFM :
Surveillance des pannes à l’aide du protocole de contrôle de continuité Ethernet OAM IEEE 802.1ag
Découverte de chemin et vérification des pannes à l’aide du protocole Ethernet OAM Linktrace IEEE 802.1ag
Isolation des pannes à l’aide du protocole Ethernet OAM Loopback IEEE 802.1ag
Dans un environnement CFM, les entités réseau telles que les opérateurs réseau, les fournisseurs de services et les clients peuvent faire partie de domaines administratifs différents. Chaque domaine administratif est mappé dans un domaine de maintenance. Les domaines de maintenance sont configurés avec des valeurs de niveau différentes pour les garder séparés. Chaque domaine fournit suffisamment d’informations pour que les entités puissent effectuer leur propre gestion et surveillance de bout en bout, tout en évitant les failles de sécurité.
La figure 1 illustre les relations entre les clients, les fournisseurs et les opérateurs : ponts Ethernet, domaines de maintenance, points de terminaison d’association de maintenance (MEP) et points intermédiaires de maintenance (MIP).
de domaine de maintenance
Mesure du retard de trame Ethernet
Deux objectifs clés de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le retard d’image et la variation du délai d’image (également appelée « gigue d’image »). Ces mesures peuvent vous permettre d’identifier les problèmes de réseau avant qu’ils n’affectent les clients.
Junos OS prend en charge la mesure du retard de trame Ethernet entre les MEP configurés sur des interfaces physiques ou logiques Ethernet sur les routeurs. La mesure du retard de trame Ethernet offre aux opérateurs un contrôle précis pour déclencher la mesure du retard sur un service donné et peut être utilisée pour surveiller les SLA. La mesure du retard de trame Ethernet collecte également d’autres informations utiles, telles que les retards les plus défavorables et les meilleurs retards, le retard moyen et la variation du retard moyen. L’implémentation par Junos OS de la mesure du retard de trame Ethernet (ETH-DM) est entièrement conforme à la Recommandation UIT-T Y.1731, Fonctions et mécanismes OAM pour les réseaux Ethernet. La recommandation définit des mécanismes OAM pour l’exploitation et la maintenance du réseau au niveau de la couche de service Ethernet, appelée « couche ETH » dans la terminologie de l’UIT-T.
Les routeurs dotés de concentrateurs de ports modulaires (MPC) et de MPC 10 Gigabit Ethernet avec SFP+ prennent en charge la fonctionnalité ITU-T Y.1731 sur VPLS pour la variation du délai de trame et du retard.
Mesure unidirectionnelle du retard de trame Ethernet
En mode ETH-DM unidirectionnel, une série de valeurs de retard de trame et de variation de retard de trame sont calculées en fonction du temps écoulé entre le moment où une trame de mesure est envoyée par le MEP initiateur à un routeur et le moment où la trame est reçue au MEP récepteur de l’autre routeur.
- Transmission 1DM
- Réception 1DM
- Statistiques ETH-DM unidirectionnelles
- Nombre d’images ETH-DM unidirectionnel
- Synchronisation des horloges système
Transmission 1DM
Lorsque vous démarrez une mesure de retard de trame unidirectionnelle, le routeur envoie des trames 1DM (trames qui transportent l’unité de données de protocole) pour une mesure de retard unidirectionnelle de l’initiateur MEP au MEP récepteur au débit et pour le nombre de trames que vous spécifiez. Le routeur marque chaque trame 1DM comme drop-ineligible et insère un horodatage de l’heure de transmission dans la trame.
Réception 1DM
Lorsqu’un MEP reçoit une trame 1DM, le routeur qui contient le MEP récepteur mesure le délai unidirectionnel pour cette trame (la différence entre l’heure à laquelle la trame a été reçue et l’horodatage contenu dans la trame elle-même) et la variation du retard (la différence entre les valeurs de retard actuelles et précédentes).
Statistiques ETH-DM unidirectionnelles
Le routeur qui contient le récepteur MEP stocke chaque ensemble de statistiques de retard unidirectionnel dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour une session CFM donnée (paire de pairs MEP). Vous pouvez accéder à ces statistiques à tout moment en affichant le contenu de la base de données ETH-DM.
Nombre d’images ETH-DM unidirectionnel
Chaque routeur compte le nombre de trames ETH-DM unidirectionnelles envoyées et reçues :
Pour un MEP initiateur, le routeur compte le nombre de trames 1DM envoyées.
Pour un MEP de récepteur, le routeur compte le nombre de trames 1DM valides reçues et le nombre de trames 1DM invalides reçues.
Chaque routeur stocke le nombre de trames ETH-DM dans la base de données CFM. La base de données CFM stocke les statistiques de session CFM et, pour les interfaces qui prennent en charge ETH-DM, toutes les trames ETH-DM comptent. Vous pouvez accéder au nombre de trames à tout moment en affichant les informations de la base de données CFM pour les interfaces Ethernet affectées aux MEP ou pour les MEP dans les sessions CFM.
Synchronisation des horloges système
La précision des calculs de retard unidirectionnel dépend d’une synchronisation étroite des horloges système au niveau du MEP initiateur et du MEP récepteur.
La précision de la variation du retard unidirectionnel ne dépend pas de la synchronisation de l’horloge système. Comme la variation du retard est simplement la différence entre des valeurs de retard unidirectionnelles consécutives, la période hors phase est éliminée des valeurs de gigue de trame.
Pour une mesure de retard de trame Ethernet unidirectionnelle donnée, les valeurs de retard de trame et de variation de retard de trame sont disponibles uniquement sur le routeur qui contient le MEP du récepteur.
Mesure du retard de trame Ethernet bidirectionnel
En mode ETH-DM bidirectionnel, les valeurs de retard de trame et de variation de retard de trame sont basées sur la différence de temps entre le moment où le MEP initiateur transmet une trame de demande et celui où il reçoit une trame de réponse du MEP répondeur, en soustrayant le temps écoulé au MEP répondeur.
- DMM Transmission
- DMR Transmission
- Réception DMR
- Statistiques ETH-DM bidirectionnelles
- Nombre d’images ETH-DM bidirectionnel
DMM Transmission
Lorsque vous démarrez une mesure de retard de trame bidirectionnelle, le routeur envoie des trames de message de mesure de retard (trames qui transportent la PDU pour une requête ETH-DM bidirectionnelle) du MEP initiateur au MEP répondeur au débit et pour le nombre de trames que vous spécifiez. Le routeur marque chaque trame DMM comme drop-ineligible et insère un horodatage de l’heure de transmission dans la trame.
DMR Transmission
Lorsqu’un MEP reçoit une trame DMM, le MEP répondeur répond avec une trame DMR (delay measurement reply), qui contient les informations de réponse ETH-DM et une copie de l’horodatage contenu dans la trame DMM.
Réception DMR
Lorsqu’un MEP reçoit un DMR valide, le routeur qui contient le MEP mesure le délai bidirectionnel pour cette trame en fonction de la séquence d’horodatages suivante :
TITxDMM
TRRxDMM
TRTxDMR
TIRxDMR
Un délai d’image bidirectionnel est calculé comme suit :
[TIRxDMR –TI TxDMM] – [TRTxDMR –TR RxDMM]
Le calcul montre que le délai de trame est la différence entre le moment où le MEP initiateur envoie une trame DMM et le moment où le MEP initiateur reçoit la trame DMR associée du MEP répondeur, moins le temps écoulé au MEP répondeur.
La variation du retard est la différence entre les valeurs de retard actuelles et précédentes.
Statistiques ETH-DM bidirectionnelles
Le routeur qui contient le MEP initiateur stocke chaque ensemble de statistiques de retard bidirectionnel dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour une session CFM donnée (paire de pairs MEP). Vous pouvez accéder à ces statistiques à tout moment en affichant le contenu de la base de données ETH-DM.
Nombre d’images ETH-DM bidirectionnel
Chaque routeur compte le nombre de trames ETH-DM bidirectionnelles envoyées et reçues :
Pour un MEP initiateur, le routeur compte le nombre de trames DMM transmises, le nombre de trames DMR valides reçues et le nombre de trames DMR non valides reçues.
Pour un répondeur MEP, le routeur compte le nombre de trames DMR envoyées.
Chaque routeur stocke le nombre de trames ETH-DM dans la base de données CFM. La base de données CFM stocke les statistiques de session CFM et, pour les interfaces qui prennent en charge ETH-DM, toutes les trames ETH-DM comptent. Vous pouvez accéder au nombre de trames à tout moment en affichant les informations de la base de données CFM pour les interfaces Ethernet affectées aux MEP ou pour les MEP dans les sessions CFM.
Pour une mesure de retard de trame Ethernet bidirectionnelle donnée, les valeurs de retard de trame et de variation de retard de trame sont disponibles uniquement au niveau du routeur qui contient le MEP initiateur.
Choisir entre ETH-DM unidirectionnel et bidirectionnel
La mesure du retard de trame unidirectionnelle nécessite que les horloges système du MEP initiateur et du récepteur MEP soient étroitement synchronisées. La mesure du retard d’image bidirectionnelle ne nécessite pas de synchronisation des deux systèmes. S’il n’est pas pratique de synchroniser les horloges, les mesures de retard d’image bidirectionnelles sont plus précises.
Lorsque deux systèmes sont physiquement proches l’un de l’autre, leurs valeurs de retard unidirectionnel sont très élevées par rapport à leurs valeurs de retard bidirectionnel. La mesure du retard unidirectionnel nécessite que la synchronisation des deux systèmes soit synchronisée à un niveau très granulaire.
Restrictions relatives à la mesure du retard de trame Ethernet
Les restrictions suivantes s’appliquent à la fonctionnalité de mesure du retard de trame Ethernet :
La fonctionnalité ETH-DM n’est pas prise en charge sur les pseudofils d’interface à commutation d’étiquettes (LSI).
La fonctionnalité ETH-DM est prise en charge sur les interfaces Ethernet agrégées.
Les mesures de retard de trame Ethernet ne peuvent être déclenchées que lorsque le démon de gestion périodique distribué des paquets (
ppm) est activé. Pour plus d’informations sur cette limitation, consultez Instructions pour configurer les routeurs afin de prendre en charge une session ETH-DM et s’assurer que le ppm distribué n’est pas désactivé.Vous ne pouvez surveiller qu’une seule session à la fois sur le même MEP ou adresse MAC distant. Pour plus d’informations sur le démarrage d’une session ETH-DM, consultez Démarrage d’une session ETH-DM.
Les statistiques ETH-DM sont collectées sur un seul des deux routeurs homologues de la session ETH-DM. Pour une session ETH-DM unidirectionnelle, vous pouvez afficher les statistiques ETH-DM de trame au niveau du MEP récepteur uniquement, à l’aide de commandes spécifiques à
showETH-DM. Pour une session ETH-DM bidirectionnelle, vous pouvez afficher les statistiques de retard de trame au niveau du MEP initiateur uniquement, en utilisant les mêmes commandes spécifiques àshowETH-DM. Pour plus d’informations, consultez Gestion des statistiques ETH-DM et Nombre de trames ETH-DM.Le nombre de trames ETH-DM est collecté dans les deux PEM et stocké dans les bases de données CFM respectives.
Si le basculement GRES ( graceful moteur de routage switchover ) se produit, toutes les statistiques ETH-DM collectées sont perdues et le nombre de trames ETH-DM est remis à zéro. Par conséquent, la collecte des statistiques ETH-DM et des compteurs de trames ETH-DM doit être redémarrée, une fois le basculement terminé. GRES permet à un routeur avec deux moteurs de routage de passer d’un moteur de routage principal à un moteur de routage de secours sans interruption du transfert de paquets. Pour plus d’informations, reportez-vous au Guide de l’utilisateur de la haute disponibilité de Junos OS.
La précision des statistiques de retard d’image est compromise lorsque le système change (par exemple, lors d’une reconfiguration). Nous vous recommandons d’effectuer des mesures de retard de trame Ethernet sur un système stable.
Présentation de la mesure de la perte de trame Ethernet
Les principaux objectifs de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le retard de trame, la variation du délai de trame (également appelée « gigue de trame ») et la perte de trame. Ces mesures vous permettent d’identifier les problèmes de réseau avant qu’ils n’affectent les clients.
Junos OS prend en charge la mesure de perte de trame Ethernet (ETH-LM) entre les points de terminaison d’association de maintenance (MEP) configurés sur des interfaces physiques ou logiques Ethernet sur les routeurs et n’est actuellement pris en charge que pour le service VPWS . L’ETH-LM est utilisé par les opérateurs pour collecter les valeurs de compteur applicables aux trames de service d’entrée et de sortie. Ces compteurs conservent un nombre de trames de données transmises et reçues entre une paire de MEP. La mesure de la perte de trame Ethernet est effectuée en envoyant des trames avec des informations ETH-LM à un MEP pair et en recevant de la même manière des trames avec des informations ETH-LM de la part du MEP pair. Ce type de mesure de perte de trame est également connu sous le nom de mesure de perte Ethernet asymétrique.
L’ETH-LM prend en charge les mesures de perte de trame suivantes :
Mesure de la perte de trame à proximité de la fin : mesure de la perte de trame associée aux trames de données entrantes.
Mesure de la perte de trame distante : mesure de la perte de trame associée aux trames de sortie.
La fonctionnalité ETH-LM est prise en charge sur les interfaces Ethernet agrégées.
Les résultats de la mesure des pertes Ethernet (ETH-LM) sont inexacts lorsque les PDU de gestion des pannes de connectivité (CFM) et de surveillance des performances (PM) sont reçus localement au niveau d’un point de terminaison de maintenance (MEP) classé comme appartenant à la classe jaune ou à une priorité de perte de paquets (PLP) de moyenne-élevée. Ce problème de résultats incorrects est spécifique à la mesure de perte Ethernet pour les sessions CFM des MEP en panne. Les statistiques de mesure des pertes Ethernet sont inexactes dans les scénarios suivants :
-
La mesure de perte Ethernet fonctionne sur une session CFM pour un MEP à l’état inactif
-
Les PDU CFM reçus sur l’interface logique de la MEP descendante sont classés par le classificateur en PLP jaune ou moyennement élevé
-
Un paquet est identifié comme jaune lorsque le classificateur d’entrée marque le PLP comme moyen-élevé.
Le problème des écarts avec les résultats de mesure de perte Ethernet n’est pas observé lorsque vous configurez la mesure de perte Ethernet en mode incolore. Pour éviter ce problème de résultats de mesure des pertes inexacts, provisionnez tous les PDU CFM locaux en vert ou avec le PLP aussi élevé.
La surveillance des performances pour la gestion des pannes de connectivité (en incluant l’instruction performance-monitoring et ses sous-instructions au niveau de la hiérarchie) n’est [edit protocols oam ethernet connectivity-fault-management] pas prise en charge lorsque l’interface NNI (Network-to-Network) ou de sortie est une interface Ethernet agrégée avec des liens membres sur des DPC.
Mesure de l’accord de niveau de service
La mesure d’un accord de niveau de service (SLA) est le processus de surveillance de la bande passante, du retard, de la variation du délai (gigue), de la continuité et de la disponibilité d’un service (E-Line ou E-LAN). Il vous permet d’identifier les problèmes de réseau avant qu’ils n’affectent les clients.
Les services VPN Ethernet peuvent être classés en :
Services peer-to-peer (services E-Line) : les services E-Line sont proposés à l’aide d’un VPN de couche 2 basé sur MPLS, un service de virement privé virtuel (VPWS).
Services multipoint à multipoint (services E-LAN) : les services E-LAN sont proposés à l’aide du service LAN privé virtuel (VPLS) basé sur le MPLS.
Pour plus d’informations, consultez le Guide de configuration de Junos VPN.
Dans Junos OS, les mesures SLA sont classées en :
Mode à la demande : en mode à la demande, les mesures sont déclenchées via la CLI.
Mode proactif : en mode proactif, les mesures sont déclenchées par une application itératrice.
Notez que la mesure du retard de trame Ethernet et la mesure de la perte de trame Ethernet ne sont pas prises en charge sur l’interface ae .
Mode à la demande pour la mesure des SLA
En mode à la demande, les mesures sont déclenchées par l’utilisateur via la CLI.
Lorsque l’utilisateur déclenche la mesure de retard via la CLI, la demande de mesure de retard générée est conforme aux formats de trame spécifiés par la norme UIT-T Y.1731. Pour la mesure du retard bidirectionnel, le traitement côté serveur peut être délégué au moteur de transfert de paquets pour éviter toute surcharge sur le moteur de routage. Pour plus d’informations, consultez Configuration des routeurs pour prendre en charge une session ETH-DM. Lorsque le traitement côté serveur est délégué au moteur de transfert de paquets, les compteurs de trames receive de messages de mesure de retard (DMM) et les compteurs de trames transmit de réponse de mesure de retard (DMR) ne sont pas affichés par la show commande.
Lorsque l’utilisateur déclenche la mesure de perte via la CLI, le routeur envoie les paquets au format standard avec la mesure de perte TLV. Par défaut, l’argument session-id-tlv est inclus dans le paquet pour autoriser des sessions simultanées de mesure des pertes à partir du même MEP local. Vous pouvez également désactiver l’ID de session TLV à l’aide de l’argument no-session-id-tlv .
L’ETH-LM asymétrique est utilisé à des fins d’exploitation, d’administration et de maintenance à la demande. Un MEP envoie des trames avec des informations de demande ETH-LM à son homologue MEP et reçoit des trames avec des informations de réponse ETH-LM de son homologue MEP pour effectuer des mesures de perte. L’unité de données de protocole (PDU) utilisée pour une demande ETH-LM asymétrique est appelée message de mesure des pertes (LMM) et la PDU utilisée pour une réponse ETH-LM asymétrique est appelée réponse de mesure des pertes (LMR).
Mode proactif pour la mesure des SLA
En mode proactif, les mesures de SLA sont déclenchées par une application itératrice. Un itérateur est conçu pour transmettre périodiquement des paquets de mesure SLA sous forme de trames conformes à la norme ITU-Y.1731 pour la mesure du retard bidirectionnel ou de l’affaiblissement sur les routeurs MX Series. Ce mode diffère de la mesure SLA à la demande, qui est initiée par l’utilisateur. L’itérateur envoie périodiquement des paquets de demande de mesure de retard ou de perte pour chacune des connexions qui lui sont enregistrées. Les itérateurs s’assurent que les cycles de mesure ne se produisent pas en même temps pour la même connexion afin d’éviter une surcharge du processeur. Junos OS prend en charge le mode proactif pour VPWS. Pour qu’un itérateur forme une contiguïté à distance et devienne fonctionnellement opérationnel, le message de contrôle de continuité (CCM) doit être actif entre les configurations MEP locales et distantes de la gestion des pannes de connectivité (CFM). Toute modification des paramètres d’adjacence de l’itérateur réinitialise les statistiques d’itérateur existantes et redémarre l’itérateur. Ici, le terme contiguïté fait référence à un appariement de deux points de terminaison (connectés directement ou virtuellement) avec des informations pertinentes pour la compréhension mutuelle, qui sont utilisées pour un traitement ultérieur. Par exemple, la contiguïté de l’itérateur fait référence à l’association de l’itérateur entre les deux points de terminaison des MEP.
Pour chaque DPC ou MPC, seules 30 instances d’itérateur pour une valeur de temps de cycle de 10 millisecondes (ms) sont prises en charge. Dans Junos OS, 255 configurations de profil d’itérateur et 2 000 associations MEP distantes sont prises en charge.
Les itérateurs dont la valeur de temps de cycle est inférieure à 100 ms ne sont pris en charge que pour les itérateurs infinis, tandis que les itérateurs dont la valeur de temps de cycle est supérieure à 100 ms sont pris en charge pour les itérateurs finis et infinis. Les itérateurs infinis sont des itérateurs qui s’exécutent à l’infini jusqu’à ce que l’itérateur soit désactivé ou désactivé manuellement.
Un service VPWS configuré sur un routeur est surveillé pour les mesures SLA en enregistrant la connexion (ici, la connexion est une paire de MEP distants et locaux) sur un itérateur, puis en initiant une transmission périodique des trames de mesure SLA sur ces connexions. Le service de bout en bout est identifié par le biais d’un point de terminaison d’association de maintenance (MEP) configuré aux deux extrémités.
Pour la mesure du retard bidirectionnel et la mesure de la perte, un itérateur envoie un message de demande pour la connexion de la liste (le cas échéant), puis envoie un message de demande pour la connexion qui a été interrogée lors du cycle d’itération précédent. Les messages de demande consécutifs pour les trames de mesure SLA et leurs réponses aident à calculer la variation de retard et la mesure des pertes.
La transmission de trames Y.1731 pour un service attaché à un itérateur se poursuit indéfiniment, sauf intervention et arrêt d’un opérateur, ou jusqu’à ce que la condition de nombre d’itérations soit remplie. Pour empêcher l’itérateur d’envoyer des trames de mesure SLA plus proactives, l’opérateur doit effectuer l’une des tâches suivantes :
Activez l’instruction
deactivate sla-iterator-profileau niveau de la[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id]hiérarchie.Provisionnez une
disableinstruction sous le profil d’itérateur correspondant au niveau de la[edit protocols oam ethernet connectivity-fault-management performance-monitoring sla-iterator-profiles profile-name]hiérarchie.
Mesures de retard Ethernet et de perte en mode proactif
Dans la mesure de retard bidirectionnelle, la trame du message de mesure de retard (DMM) est déclenchée par une application itératrice. La trame multidisciplinaire comporte un type, une longueur et une valeur d’itérateur (TLV) en plus des champs décrits au format d’image standard et le serveur copie le TLV de l’itérateur TLV de la trame multimètre vers la trame de réponse de mesure de retard (DMR).
Dans le calcul de variation de retard unidirectionnel utilisant la méthode de mesure de retard bidirectionnel, le calcul de variation de retard est basé sur les horodatages présents dans la trame DMR (et non dans la trame 1DM). Par conséquent, il n’est pas nécessaire que les horloges côté client et côté serveur soient synchronisées. En supposant que la différence entre leurs horloges reste constante, les résultats de la variation de retard unidirectionnelle devraient être assez précis. Cette méthode élimine également le besoin d’envoyer des trames 1DM séparées uniquement pour la mesure de la variation de retard unidirectionnelle.
En mode proactif, pour la mesure des pertes, le routeur envoie des paquets au format standard avec le TLV de mesure des pertes et le TLV itérateur.
Présentation du protocole de notification des défaillances Ethernet
Le protocole de notification des défaillances (FNP) est un mécanisme de notification des défaillances qui détecte les défaillances dans les réseaux de transport Ethernet point à point sur les routeurs. Si une liaison de nœud tombe en panne, FNP détecte la défaillance et envoie des messages FNP aux nœuds adjacents indiquant qu’un circuit est en panne. À la réception du message FNP, les nœuds peuvent rediriger le trafic vers le circuit de protection.
FNP est pris en charge sur les services E-Line uniquement.
Un service E-Line fournit une connectivité Ethernet point à point sécurisée entre deux interfaces réseau utilisateur (UNI). Les services E-Line sont des services protégés et chaque service dispose d’un circuit de travail et d’un circuit de protection. Le CFM est utilisé pour surveiller le travail et protéger les chemins. Les intervalles CCM entraînent un basculement de l’ordre de centaines de millisecondes ou de quelques secondes. Le FNP permet de détecter et de propager les défaillances des circuits de services en moins de 50 ms et fournit un basculement de 50 ms pour les services E-Line.
Le routeur agit comme un nœud PE et gère les messages FNP reçus sur le VLAN de gestion et les messages FNP reçus sur les interfaces Ethernet et les PW créés pour le VPLS de gestion. Les routeurs ne lancent pas de messages FNP et répondent uniquement aux messages FNP générés par les périphériques du réseau d’accès Ethernet. FNP ne peut être activé que sur les interfaces logiques qui font partie d’une instance de routage VPLS, et CCM ne doit pas être configuré sur les interfaces physiques de cette instance de routage VPLS. Le protocole FNP ne peut être activé que sur une seule interface logique par interface physique.
Tous les services E-Line sont configurés en tant que circuits de couche 2 avec protection des bords. Un VLAN associé au circuit de travail ou au circuit de protection doit être mappé à une interface logique. Aucun port trunk ou port d’accès n’est pris en charge dans la liaison en anneau pour les VLAN utilisés par les services E-LINE. FNP ne contrôle pas l’interface logique associée au circuit de protection. Seul le service E-Line dont le point de terminaison ne se trouve pas dans un nœud MX est contrôlé par FNP.
Le protocole FNP prend en charge le redémarrage progressif et les fonctionnalités GRES (Graceful moteur de routage switchover ).
Voir aussi
Présentation de la mesure des pertes synthétiques Ethernet
La mesure de perte synthétique Ethernet (ETH-SLM) est une application qui permet de calculer la perte de trame en utilisant des trames synthétiques au lieu du trafic de données. Ce mécanisme peut être considéré comme un échantillon statistique permettant d’estimer le taux de perte de trame du trafic de données. Chaque point de terminaison d’association de maintenance (MEP) effectue des mesures de perte de trame, ce qui contribue à l’indisponibilité du temps.
Une perte de trame proche de la fin spécifie la perte de trame associée aux trames de données entrantes et une perte de trame distante spécifie la perte de trame associée aux trames de données de sortie. Les mesures de perte de trame proche et distante contribuent à l’obtention de secondes et de secondes distantes gravement erronées qui sont utilisées conjointement pour déterminer le temps indisponible. L’ETH-SLM est réalisé à l’aide de trames de message de perte synthétique (SLM) et de réponse de perte synthétique (SLR). L’ETH-SLM permet à chaque MEP d’effectuer des mesures de perte de trame synthétique proche et distante en utilisant des trames synthétiques, car un service bidirectionnel est défini comme indisponible si l’une des deux directions est jugée indisponible.
Il existe deux types de mesure de perte de trame, définis par les normes ITU-T Y.1731, ETH-LM et ETH-SLM. Junos OS ne prend en charge qu’ETH-SLM asymétrique. Dans l’ETH-SLM asymétrique, chaque MEP envoie des trames avec les informations de requête ETH-SLM à son homologue MEP et reçoit des trames avec des informations de réponse ETH-SLM de son homologue MEP pour effectuer des mesures de perte synthétiques. L’ETH-SLM asymétrique est utilisé pour l’OAM proactive ou à la demande afin d’effectuer des mesures d’affaiblissement synthétique applicables à une connexion Ethernet point à point. Cette méthode permet à un MEP d’initier et de signaler des mesures de perte de fin et de proximité associées à une paire de MEP qui font partie du même groupe d’entités de maintenance (MEG).
L’ETH-SLM asymétrique est utilisé pour effectuer des tests à la demande ou proactifs en initiant un nombre fini de trames ETH-SLM vers un ou plusieurs homologues MEP et en recevant la réponse ETH-SLM des pairs. Les trames ETH-SLM contiennent les informations ETH-SLM qui sont utilisées pour mesurer et rapporter les mesures de pertes synthétiques proches et distantes. La mesure d’un accord de niveau de service (SLA) est le processus de surveillance de la bande passante, du délai, de la variation du retard (gigue), de la continuité et de la disponibilité d’un service. Il vous permet d’identifier les problèmes de réseau avant qu’ils n’affectent les clients. En mode proactif, les mesures de SLA sont déclenchées par une application itératrice. Un itérateur est conçu pour transmettre périodiquement des paquets de mesure SLA sous la forme de trames conformes à la norme UIT-Y.1731 pour la mesure de l’affaiblissement de trame synthétique. Ce mode diffère de la mesure SLA à la demande, qui est initiée par l’utilisateur. En mode à la demande, les mesures sont déclenchées par l’utilisateur via la CLI. Lorsque l’utilisateur déclenche l’ETH-SLM via la CLI, la requête SLM générée est conforme aux formats de trame spécifiés par la norme ITU-T Y.1731.
Scénarios de configuration d’ETH-SLM
L’ETH-SLM mesure la perte de trame proche et distante entre deux MEP qui font partie du même niveau MEG. Vous pouvez configurer ETH-SLM pour mesurer l’affaiblissement synthétique pour les MEP orientés vers le haut ou en amont et les MEP orientés vers le bas ou en aval. Cette section décrit les scénarios suivants pour le fonctionnement de l’ETH-SLM :
MEP en amont dans les tunnels MPLS
Imaginez un scénario dans lequel une MEP est configurée entre les interfaces réseau utilisateur (UNI) de deux routeurs MX Series, MX1 et MX2, en amont. Les MX1 et MX2 sont connectés via un réseau central MPLS. Les mesures ETH-SLM sont effectuées entre le MEP en amont dans le chemin reliant les deux routeurs. Les MX1 et MX2 peuvent tous deux initier un ETH-SLM à la demande ou proactif, qui peut mesurer les pertes à distance et à proximité au niveau MX1 et MX2, respectivement. Les deux UNI sont connectés à l’aide d’un VPN de couche 2 basé sur le MPLS, un service de virement privé virtuel (VPWS).
MEP en aval dans les réseaux Ethernet
Prenons le cas d’un MEP configuré entre deux routeurs MX Series, MX1 et MX2, sur les interfaces Ethernet en aval. MX1 et MX2 sont connectés dans une topologie Ethernet et le MEP en aval est configuré vers le réseau Ethernet. Les mesures ETH-SLM sont effectuées entre le MEP en aval dans le chemin reliant les deux routeurs. L’ETH-SLM peut être mesuré sur le chemin entre ces deux routeurs.
Prenons un autre scénario dans lequel un MEP est configuré en aval et où la protection du service pour un VPWS sur MPLS est activée en spécifiant un chemin de travail ou un chemin de protection sur le MEP. La protection des services fournit une protection de bout en bout du chemin de travail par connexion en cas de panne. Pour configurer la protection des services, vous devez créer deux chemins de transport distincts : un chemin de travail et un chemin de protection. Vous pouvez spécifier le chemin de travail et le chemin de protection en créant deux associations de maintenance. Pour associer l’association de maintenance à un chemin, vous devez configurer l’interface MEP dans l’association de maintenance et spécifier le chemin comme étant fonctionnel ou protégé.
Dans un exemple de topologie, un routeur MX Series, MX1, est connecté à deux autres routeurs MX Series, MX2 et MX3, sur un cœur MPLS. La session de gestion des pannes de connectivité (CFM) entre MX1 et MX2 est le chemin de travail sur le MEP et la session CFM entre MX1 et MX3 est le chemin de protection sur le MEP. Les MX2 et MX3 sont, à leur tour, connectés à la MX4 via des interfaces Ethernet dans le réseau d’accès. Le MEP en aval est configuré entre MX1 et MX4 qui passe par MX2 (session CFM de travail) et également entre MX1 et MX4 qui passe par MX3 (session CFM protégée). L’ETH-SLM est effectué entre ces MEP en aval. Dans les deux MEP en aval, la configuration est effectuée sur des UNI MX1 et MX4, de la même manière que pour les MEP en amont.
Format des messages ETH-SLM
Les messages de perte synthétique (SLM) prennent en charge les requêtes de mesure de perte synthétique Ethernet (ETH-SLM) asymétriques. Cette rubrique contient les sections suivantes qui décrivent les formats des unités de données (PDU) du protocole SLM, des PDU SLR et de la valeur de longueur du type d’itérateur de données (TLV).
SLM PDU Format
Le format PDU SLM est utilisé par un MEP pour transmettre des informations SLM. Les composants suivants sont contenus dans les PDU SLM :
ID MEP source : l’ID MEP source est un champ de 2 octets dans lequel les 13 derniers bits de poids faible sont utilisés pour identifier le MEP qui transmet la trame SLM. L’ID MEP est unique au sein du MEG.
ID de test : l’ID de test est un champ de 4 octets défini par le MEP émetteur et est utilisé pour identifier un test lorsque plusieurs tests s’exécutent simultanément entre les MEP (y compris les tests simultanés à la demande et proactifs).
TxFCf : TxFCf est un champ de 4 octets qui transporte le nombre de trames SLM transmises par le MEP vers son homologue MEP.
Les champs d’une PDU SLM sont les suivants :
Niveau MEG : niveau de domaine de maintenance configuré dans la plage de 0 à 7.
Version—0.
OpCode : identifie un type de PDU OAM. Pour SLM, c’est 55.
Indicateurs (Flags) : défini sur tous les zéros.
Décalage TLV—16.
ID MEP source : champ de 2 octets utilisé pour identifier le MEP transmettant la trame SLM. Dans ce champ de 2 octets, les 13 derniers bits les moins significatifs sont utilisés pour identifier le MEP transmettant la trame SLM. L’ID MEP est unique au sein du MEG.
RESV : les champs réservés sont définis sur tous les zéros.
ID de test : champ de 4 octets défini par le MEP émetteur et utilisé pour identifier un test lorsque plusieurs tests s’exécutent simultanément entre MEP (y compris les tests simultanés à la demande et proactifs).
TxFCf : champ de 4 octets qui transporte le nombre de trames SLM transmises par le MEP vers son homologue MEP.
TLV facultatif : un TLV de données peut être inclus dans tout SLM transmis. Aux fins de l’ETH-SLM, la partie valeur des données TLV n’est pas spécifiée.
End TLV : valeur d’octet entièrement zéro.
SLR PDU Format
Le format PDU de réponse de perte synthétique (SLR) est utilisé par un MEP pour transmettre des informations SLR. Les champs d’une PDU SLR sont les suivants :
Niveau MEG : champ 3 bits dont la valeur est copiée à partir de la dernière PDU SLM reçue.
Version : champ 5 bits dont la valeur est copiée à partir de la dernière PDU SLM reçue.
OpCode : identifie un type de PDU OAM. Pour SLR, il est fixé à 54.
Flags : champ de 1 octet copié à partir de la PDU SLM.
Décalage TLV : champ de 1 octet copié à partir de la PDU SLM.
ID MEP source : champ de 2 octets copié à partir de la PDU SLM.
ID MEP du répondeur : champ de 2 octets utilisé pour identifier le MEP transmettant la trame SLR.
ID de test : champ de 4 octets copié à partir de la PDU SLM.
TxFCf : champ de 4 octets copié à partir de la PDU SLM.
TxFCb : un champ de 4 octets. Cette valeur représente le nombre d’images SLR transmises pour cet ID de test.
Facultatif TLV : la valeur est copiée à partir de la PDU SLM, si elle existe.
End TLV : champ de 1 octet copié à partir de la PDU SLM.
Format TLV de l’itérateur de données
L’itérateur de données TLV spécifie la partie TLV de données de la trame de données Y.1731. La MEP utilise une valeur TLV de données lorsqu’elle est configurée pour mesurer le retard et la variation du délai pour différentes tailles de trame. Les champs d’un TLV de données sont les suivants :
Type : identifie le type de TLV ; la valeur de ce type de TLV est Données (3).
Longueur : identifie la taille, en octets, du champ Valeur contenant le modèle de données. La valeur maximale du champ Longueur est 1440.
Modèle de données : un nmodèle de bits arbitraire -octet (n indique la longueur). Le récepteur l’ignore.
Transmission des messages ETH-SLM
La fonctionnalité ETH-SLM peut traiter plusieurs requêtes de messages de perte synthétiques (SLM) simultanément entre une paire de MEP. Il peut s’agir d’une session SLM proactive ou à la demande. Chaque demande SLM est identifiée de manière unique par un ID de test.
Un MEP peut envoyer des demandes SLM ou répondre à des demandes SLM. Une réponse à une demande SLM est appelée réponse de perte synthétique (SLR). Une fois qu’un MEP a déterminé une demande SLM à l’aide de l’ID de test, il calcule la perte de trame à distance et à proximité sur la base des informations contenues dans le message SLM ou l’unité de données de protocole (PDU) SLM.
Un MEP tient à jour les compteurs locaux suivants pour chaque ID de test et pour chaque MEP homologue surveillé dans une entité de maintenance pour laquelle des mesures de perte doivent être effectuées :
TxFCl : nombre de trames synthétiques transmises vers le MEP homologue pour un ID de test. Un MEP source incrémente ce nombre pour la transmission successive de trames synthétiques avec des informations de demande ETH-SLM tandis qu’un MEP de destination ou de réception incrémente cette valeur pour la transmission successive de trames synthétiques avec les informations SLR.
RxFCl : nombre de trames synthétiques reçues du MEP homologue pour un ID de test. Un MEP source incrémente ce nombre pour la réception successive de trames synthétiques avec des informations SLR, tandis qu’un MEP de destination ou de réception l’incrémente pour la réception successive de trames synthétiques avec des informations de requête ETH-SLM.
Les sections suivantes décrivent les phases de traitement des PDU SLM pour déterminer l’affaiblissement de trame synthétique :
- Initiation et transmission des demandes de GDT
- Réception des SLM et transmission des SLR
- Réception des reflex
- Calcul de la perte de trame
Initiation et transmission des demandes de GDT
Un MEP transmet périodiquement une demande SLM avec le champ OpCode défini sur 55. Le MEP génère un ID de test unique pour la session, ajoute l’ID MEP source et initialise les compteurs locaux de la session avant le lancement du SLM. Pour chaque PDU SLM transmis pour la session (ID de test), le compteur local TxFCl est envoyé dans le paquet.
Aucune synchronisation n’est requise de la valeur de l’ID de test entre les MEP initiateurs et les MEP répondants, car l’ID de test est configuré au niveau du MEP initiateur et le MEP répondant utilise l’ID de test qu’il reçoit du MEP initiateur. Étant donné que l’ETH-SLM est une technique d’échantillonnage, elle est moins précise que le comptage des trames de service. En outre, la précision de la mesure dépend du nombre de trames SLM utilisées ou de la période de transmission des trames SLM.
Réception des SLM et transmission des SLR
Une fois que le MEP de destination reçoit une trame SLM valide du MEP source, une trame SLR est générée et transmise au MEP demandeur ou source. La trame SLR est valide si le niveau MEG et l’adresse MAC de destination correspondent à l’adresse MAC du MEP destinataire. Tous les champs des PDU SLM sont copiés à partir de la requête SLM, à l’exception des champs suivants :
L’adresse MAC source est copiée sur l’adresse MAC de destination et l’adresse source contient l’adresse MAC du MEP.
La valeur du champ OpCode passe de SLM à SLR (54).
L’ID MEP du répondeur est renseigné avec l’ID MEP du MEP.
TxFCb est enregistré avec la valeur du compteur local RxFCl au moment de la transmission des trames SLR.
Une trame SLR est générée chaque fois qu’une trame SLM est reçue ; par conséquent, RxFCl dans le répondeur est égal au nombre de trames SLM reçues et également égal au nombre de trames SLR envoyées. Au niveau du répondant ou du MEP récepteur, RxFCl est égal à TxFCl.
Réception des reflex
Après la transmission d’une trame SLM (avec une valeur TxFCf donnée), un MEP s’attend à recevoir une trame SLR correspondante (portant la même valeur TxTCf) dans la valeur de délai d’attente de son homologue MEP. Les images SLR reçues après la valeur du délai d’attente (5 secondes) sont ignorées. Avec les informations contenues dans les images SLR, un MEP détermine la perte d’image pour la période de mesure spécifiée. La période de mesure est un intervalle de temps pendant lequel le nombre de trames SLM transmises est statistiquement suffisant pour effectuer une mesure avec une précision donnée. Un MEP utilise les valeurs suivantes pour déterminer la perte de trame proche et distante pendant la période de mesure :
Dernières valeurs TxFCf et TxFCb de la trame SLR reçues et la valeur RxFCl du compteur local à la fin de la période de mesure. Ces valeurs sont représentées par TxFCf[tc], TxFCb[tc] et RxFCl[tc], où tc est l’heure de fin de la période de mesure.
Valeurs TxFCf et TxFCb de la première trame SLR reçue après le début du test et du compteur local RxFCl au début de la période de mesure. Ces valeurs sont représentées par TxFCf[tp], TxFCb[tp] et RxFCl[tp], où tp est l’heure de début de la période de mesure.
Pour chaque paquet SLR reçu, le compteur RxFCl local est incrémenté au niveau du MEP émetteur ou source.
Calcul de la perte de trame
La perte de trame synthétique est calculée à la fin de la période de mesure sur la base de la valeur des compteurs locaux et des informations de la dernière trame reçue. La dernière trame reçue contient les valeurs TxFCf et TxFCb. Le compteur local contient la valeur RxFCl. À l’aide de ces valeurs, la perte d’image est déterminée à l’aide de la formule suivante :
Perte de trame (extrémité distante) = TxFCf – TxFCb
Perte de trame (proche de la fin) = TxFCb – RxFCl
Comportement de la norme ITU-T Y.1731 spécifique à la plate-forme (ETH-DM, ETH-LM et ETH-SLM)
Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.
| Plate-forme | Différence |
|---|---|
| ACX Series |
|
| MX Series |
|