Présentation OAM du service Ethernet UIT-T Y.1731
SUMMARY La présente section décrit le service OAM (ITU-TY.1731) et ses deux composants principaux : la gestion des défaillances (surveillance, détection et isolation) et la surveillance des performances (mesure de perte de trame, mesure de perte de trame synthétique et mesure du retard de trame).
Présentation des mesures de retard de trame Ethernet
- ITU-T Y.1731 Fonction de mesure du retard de trame
- Mesure du retard de trame Ethernet unidirectionnel
- Mesure du retard de trame Ethernet bidirectionnel
- Choisir entre l’ETH-DM unidirectionnel et bidirectionnel
- Restrictions relatives à la mesure des retards de trame Ethernet
ITU-T Y.1731 Fonction de mesure du retard de trame
La norme IEEE 802.3-2005 relative aux 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 un réseau local Ethernet point à point unique.
Junos OS prend en charge les principales normes OAM qui permettent aux fournisseurs de services d’automatiser de bout en bout la gestion et la surveillance du service Ethernet :
Norme IEEE 802.1ag, également connue sous le nom de « gestion des défauts de connectivité (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 fonctionnalité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 à tarifs et performances garantis, adaptés aux besoins spécifiques de leurs clients.
Les routeurs ACX Series prennent en charge les modes proactif et à la demande.
Vous pouvez configurer les fonctions de mesure des pertes Ethernet (ETH-LM), de mesure des pertes synthétiques Ethernet (ETH-SLM) et de mesure des retards Ethernet (ETH-DM) conformes à la norme UIT-T Y.1731 sur les cartes de ligne MPC10 et MPC11 sur les versions 20.2R2-S3 uniquement et 20.4R1 et ultérieures.
Les routeurs ACX5048 et ACX5096 ne prennent en charge que l’horodatage logiciel pour la mesure des retards.
Ethernet CFM
La norme IEEE 802.1ag relative à la gestion des défaillances de connectivité (CFM) définit des mécanismes permettant d’assurer un service Ethernet de bout en bout sur n’importe quel chemin, qu’il s’agisse d’une ou de plusieurs liaisons s’étendant sur des réseaux composés de plusieurs réseaux locaux.
Pour les interfaces Ethernet sur les routeurs M320, MX Series et T Series, Junos OS prend en charge les éléments clés suivants de la norme Ethernet CFM :
Surveillance des défaillances à l’aide du protocole IEEE 802.1ag Ethernet OAM Continuity Check
Découverte de chemin et vérification des pannes à l’aide du protocole Linktrace Ethernet IEEE 802.1ag
Isolation des pannes à l’aide du protocole IEEE 802.1ag Ethernet OAM Loopback
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 différents domaines administratifs. Chaque domaine administratif est mappé à un domaine de maintenance. Les domaines de maintenance sont configurés avec des valeurs de niveau différentes pour les séparer. 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é.
Figure 1 montre les relations entre les ponts Ethernet du client, du fournisseur et de l’opérateur, les domaines de maintenance, les points de terminaison d’association de maintenance (MEP) et les points intermédiaires de maintenance (MIP).
Sur les routeurs ACX Series, les points intermédiaires de maintenance (MIP) sont pris en charge uniquement sur les routeurs ACX5048 et ACX5096.
Mesure du retard de trame Ethernet
Les deux objectifs principaux de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le retard de trame et la variation de retard de trame (également connu sous le nom de « gigue de trame »). Ces mesures vous permettent d’identifier les problèmes réseau avant que les clients ne soient affectés par des défaillances du réseau.
Junos OS prend en charge la mesure des retards de trame Ethernet entre les MEP configurés sur des interfaces physiques ou logiques Ethernet sur des routeurs MX Series. La mesure de retard de trame Ethernet permet aux opérateurs de contrôler précisément le déclenchement de la mesure de retard sur un service donné et peut être utilisée pour surveiller les SLA. La mesure du retard de trame Ethernet recueille également d’autres informations utiles, telles que les retards dans le pire et le meilleur des cas, le délai moyen et la variation de délai moyen. L’implémentation de 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 réseaux basés sur Ethernet. La recommandation définit les 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 MX Series avec concentrateurs de ports modulaires (MPC) et les MPC Ethernet 10 Gigabit avec SFP+ prennent en charge la fonctionnalité UIT-T Y.1731 sur VPLS pour le retard de trame et la variation de délai.
MX Series Virtual Chassis ne prend pas en charge la mesure du retard de trame (DM) Ethernet.
Mesure du retard de trame Ethernet unidirectionnel
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 sur un routeur et le moment où la trame est reçue par le MEP récepteur sur l’autre routeur.
Les routeurs ACX Series ne prennent pas en charge la mesure unidirectionnelle du retard de trame Ethernet.
- Transmission 1DM
- Réception 1DM
- Statistiques à sens unique sur l’ETH-DM
- 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 portent l’unité de données de protocole (PDU) pour une mesure de retard unidirectionnelle) du MEP initiateur au MEP récepteur à la vitesse et au nombre de trames que vous spécifiez. Le routeur marque chaque trame 1DM comme inéligible 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 de 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 de retard (la différence entre les valeurs de retard actuelles et précédentes).
Statistiques à sens unique sur l’ETH-DM
Le routeur qui contient le MEP récepteur stocke chaque ensemble de statistiques de retard unidirectionnel dans la base de données ETH-DM. La base de données de l’ETH-DM recueille 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 récepteur, le routeur compte le nombre de trames 1DM valides reçues et le nombre de trames 1DM non valides 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, le nombre de trames ETH-DM. 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 du système au niveau du MEP de l’initiateur et du MEP du récepteur.
La précision de la variation de retard unidirectionnelle ne dépend pas de la synchronisation de l’horloge système. Étant donné que la variation de retard est simplement la différence entre des valeurs de retard unidirectionnelles consécutives, la période de déphasage 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 ne sont disponibles que sur le routeur contenant 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 le moment 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 bidirectionnelles de l’ETH-DM
- Nombre d’images ETH-DM bidirectionnelles
DMM Transmission
Lorsque vous démarrez une mesure de retard de trame bidirectionnelle, le routeur envoie des trames de message de mesure de retard (DMM) (trames qui transportent la PDU pour une requête ETH-DM bidirectionnelle) du MEP initiateur au MEP répondeur au débit et au nombre de trames que vous spécifiez. Le routeur marque chaque trame multimètre numérique comme étant inéligible 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épondant 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’horodatage suivante :
TI TxDMM
TRRxDMM
TRTxDMR
TIRxDMR
Un retard de trame 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 de délai est la différence entre les valeurs de retard actuelles et précédentes.
Statistiques bidirectionnelles de l’ETH-DM
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 de l’ETH-DM recueille 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 bidirectionnelles
Chaque routeur compte le nombre de trames ETH-DM bidirectionnelles envoyées et reçues :
Dans le cas d’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.
Dans le cas d’un MEP répondeur, 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, le nombre de trames ETH-DM. 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 ne sont disponibles que sur le routeur qui contient le MEP initiateur.
Choisir entre l’ETH-DM unidirectionnel et bidirectionnel
La mesure du retard de trame unidirectionnel nécessite que les horloges du système MEP de l’initiateur et du MEP du récepteur soient étroitement synchronisées. La mesure bidirectionnelle du retard de trame ne nécessite pas de synchronisation des deux systèmes. S’il n’est pas pratique de synchroniser les horloges, les mesures de retard de trame 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 de retard unidirectionnel nécessite que la synchronisation des deux systèmes soit très granulaire, et les routeurs MX Series ne prennent actuellement pas en charge cette synchronisation granulaire.
Restrictions relatives à la mesure des retards de trame Ethernet
Les restrictions suivantes s’appliquent à la fonction de mesure du retard de trame Ethernet :
La fonctionnalité ETH-DM n’est pas prise en charge sur les pseudowires d’interface à commutation d’étiquettes (LSI).
La fonctionnalité ETH-DM est prise en charge sur les interfaces Ethernet agrégées.
L’horodatage assisté par matériel pour les trames ETH-DM dans le chemin de réception est uniquement pris en charge pour les interfaces MEP sur les DPC améliorés et les DPC de file d’attente améliorée dans les routeurs MX Series. Pour plus d’informations sur l’horodatage assisté par matériel, consultez Instructions pour la configuration des routeurs afin de prendre en charge une session ETH-DM et Activation de l’option d’horodatage assisté par matériel.
Les mesures de retard de trame Ethernet ne peuvent être déclenchées que lorsque le démon de gestion de paquets périodiques distribués (
ppm) est activé. Pour plus d’informations sur cette limitation, consultez Instructions pour la configuration des 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 vers la même adresse MAC ou MEP distante. Pour plus d’informations sur le démarrage d’une session ETH-DM, voir 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
showà ETH-DM. Pour une session ETH-DM bidirectionnelle, vous pouvez afficher les statistiques de retard de trame au niveau du MEP de l’initiateur uniquement, en utilisant les mêmes commandes spécifiquesshowà ETH-DM. Pour plus d’informations, consultez Gestion des statistiques ETH-DM et du nombre d’images ETH-DM.Le nombre de trames de l’ETH-DM est collecté dans les deux MEP et est stocké dans les bases de données CFM respectives.
Si le basculement GRES (Graceful Moteur de Routage ) 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 doté de 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, consultez le 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, à la suite d’une reconfiguration). Nous recommandons d’effectuer des mesures de retard de trame Ethernet sur un système stable.
Présentation de la mesure des pertes de trames 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 de retard de trame (également appelé « gigue de trame ») et la perte de trame. Ces mesures vous permettent d’identifier les problèmes de réseau avant que les clients ne soient affectés par des défaillances du réseau.
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 MX Series et est actuellement pris en charge uniquement pour le service VPWS . ETH-LM est utilisé par les opérateurs pour collecter les valeurs de compteur applicables aux trames de service entrantes et sortantes. Ces compteurs tiennent à jour le 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 homologue et en recevant de la même manière des trames avec des informations ETH-LM du MEP pair. Ce type de mesure de perte de trame est également connu sous le nom de mesure de perte Ethernet asymétrique.
MX Series Virtual Chassis ne prend pas en charge la mesure de perte de trame Ethernet (ETH-LM).
L’ETH-LM prend en charge les mesures de perte de trame suivantes :
Near-end frame loss measurement (Mesure de la perte de trame near end) : mesure de la perte de trame associée aux trames de données entrantes.
Mesure de la perte de trame à l’extrémité : mesure de la perte de trame associée aux trames de données de sortie.
La fonctionnalité de mesure des pertes proactive et double de la norme UIT-T Y1731 n’est pas prise en charge sur les routeurs ACX Series.
La fonctionnalité ETH-LM est prise en charge sur les interfaces Ethernet agrégées.
À partir de Junos OS version 16.1, les résultats de la mesure des pertes Ethernet (ETH-LM) sont inexacts lorsque des PDU de gestion des problèmes de connectivité (CFM) et de surveillance des performances (PM) sont reçus localement à un point de terminaison de maintenance (MEP) classé comme appartenant à la classe jaune ou avec une priorité de perte de paquets (PLP) moyenne-élevée. Ce problème de résultats incorrects est spécifique à la mesure de la perte Ethernet pour les sessions CFM des MEP en baisse. Les statistiques de mesure des pertes Ethernet sont inexactes dans les scénarios suivants :
La mesure des pertes Ethernet fonctionne sur une session CFM pour un MEP en état d’arrêt
Les PDU CFM reçues sur l’interface logique du MEP vers le bas sont classées par le classificateur comme jaunes ou PLP moyen-é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 des pertes Ethernet n’est pas observé lorsque vous configurez la mesure des pertes Ethernet en mode incolore. Pour éviter ce problème de résultats de mesure des pertes inexacts, provisionnez toutes les PDU CFM locales en vert ou avec le PLP comme élevé.
À partir de Junos OS version 16.1, la surveillance des performances pour la gestion des erreurs de connectivité (en incluant l’instruction et ses sous-déclarations au niveau hiérarchique[edit protocols oam ethernet connectivity-fault-management]) n’est pas prise en charge lorsque l’interface performance-monitoring réseau à réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liens membres sur les DPC.
Mesure de l’accord de niveau de service
La mesure de l’accord de niveau de service (SLA) est le processus de surveillance de la bande passante, du délai, de la variation du délai (gigue), de la continuité et de la disponibilité d’un service (E-Line ou E-LAN). Elle vous permet d’identifier les problèmes de réseau avant que les clients ne soient affectés par des défauts du réseau.
Les services VPN Ethernet peuvent être classés comme suit :
Services d’égal à égal (services E-Line) : les services E-Line sont proposés à l’aide d’un service de fil privé privé virtuel (VPWS) VPN de couche 2 basé sur MPLS.
Services multipoint à multipoint (services E-LAN) : les services E-LAN sont proposés à l’aide du service de réseau local privé virtuel (VPLS) basé sur MPLS.
Pour plus d’informations, consultez le Guide de configuration des VPN Junos.
Dans Junos OS, les mesures SLA sont classées comme suit :
Mode à la demande : en mode à la demande, les mesures sont déclenchées via l’interface de ligne de commande.
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 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 du retard via l’interface de ligne de commande, la demande de mesure du délai générée est conforme aux formats de trame spécifiés par la norme UIT-T Y.1731. Pour la mesure du délai bidirectionnel, le traitement côté serveur peut être délégué au moteur de transfert de paquets afin d’éviter toute surcharge sur le moteur de routage. Pour plus d’informations, reportez-vous à la section Configuration des routeurs pour la prise en charge d’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 DMM (Delay Measurement Message) et DMR (Delay Measurement Reply) transmit ne sont pas affichés par la show commande.
Lorsque l’utilisateur déclenche la mesure de perte via l’interface de ligne de commande, le routeur envoie les paquets au format standard avec la TLV de mesure de perte. Par défaut, l’argument est inclus dans le paquet pour autoriser des sessions simultanées de mesure des pertes à partir d’un session-id-tlv même MEP local. Vous pouvez également désactiver le TLV de l’ID de session à 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 MEP homologue et reçoit des trames avec des informations de réponse ETH-LM de son MEP homologue 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 de perte (LMM) et la PDU utilisée pour une réponse ETH-LM asymétrique est appelée réponse de mesure de perte (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 la forme de trames conformes à la norme ITU-Y.1731 pour la mesure du retard bidirectionnel ou de la mesure des pertes sur les routeurs MX Series. Ce mode diffère de la mesure des 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 y sont enregistrées. Les itérateurs veillent à ce 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 adjacence distante 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 défauts de connectivité (CFM). Toute modification des paramètres de contiguïté de l’itérateur réinitialise les statistiques de l’itérateur existantes et redémarre l’itérateur. Ici, le terme adjacence fait référence à l’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 le 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 2000 associations MEP distantes sont prises en charge.
Les itérateurs dont la valeur de temps de cycle est inférieure à 100 ms sont pris en charge uniquement 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 en continu jusqu’à ce que l’itérateur soit désactivé ou désactivé manuellement.
Les routeurs ACX5048 et ACX5096 prennent en charge un temps de cycle d’itérateur de seulement 1 seconde et plus.
Un service VPWS configuré sur un routeur est surveillé pour les mesures de SLA en enregistrant la connexion (ici, la connexion est une paire de MEP distants et locaux) sur un itérateur, puis en initiant la transmission périodique de la trame 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 de retard bidirectionnel et la mesure de 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 cadres de mesure SLA et leurs réponses aident à calculer la variation de retard et la mesure de la perte.
La transmission de trames Y.1731 pour un service attaché à un itérateur se poursuit sans fin, à moins qu’un opérateur n’intervienne et ne l’arrête ou que la condition de nombre d’itérations ne soit remplie. Pour empêcher l’itérateur d’envoyer d’autres trames de mesure SLA 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 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 mesure des pertes en mode proactif
Dans la mesure de retard bidirectionnelle, la trame de message de mesure de retard (DMM) est déclenchée par une application itératrice. La trame DMM comporte un type, une longueur et une valeur d’itérateur (TLV) en plus des champs décrits au format de trame standard et le serveur copie le TLV de l’itérateur de la trame DMM vers la trame DMR (Delay Measurement Reply).
Dans le calcul de la variation de retard unidirectionnelle à l’aide de la méthode de mesure du retard bidirectionnel, le calcul de la variation de retard est basé sur les horodatages présents dans la trame DMR (et non sur 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 à des fins de mesure de variation de retard unidirectionnelle.
En mode proactif pour la mesure des pertes, le routeur envoie des paquets au format standard avec la TLV de mesure des pertes et la TLV de l’itérateur.
Présentation du protocole de notification des défaillances Ethernet
Le protocole FNP (Failure Notification Protocol) 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 MX Series. En cas de défaillance d’une liaison de nud, FNP détecte la défaillance et envoie des messages FNP aux nœuds adjacents pour les informer qu’un circuit est en panne. À la réception du message FNP, les noeuds peuvent rediriger le trafic vers le circuit de protection.
FNP n’est pris en charge que sur les services E-Line.
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 les chemins de travail et de protection. Les intervalles CCM entraînent un temps de basculement de quelques centaines de millisecondes ou de quelques secondes. FNP détecte et propage les défaillances des circuits de service en moins de 50 ms et assure un basculement de 50 ms pour les services E-Line.
Le routeur MX 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 MX Series n’initient pas de messages FNP et répondent uniquement aux messages FNP générés par les équipements 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 aucune interface physique de cette instance de routage VPLS ne doit avoir CCM configuré. FNP ne peut être activé que sur une seule interface logique par interface physique.
Tous les services E-Line sont configurés comme des circuits de couche 2 avec protection de périphérie. Un VLAN associé au circuit de fonctionnement 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 n’est pas dans un nœud MX est contrôlé par FNP.
FNP prend en charge le redémarrage progressif et les fonctionnalités GRES ( Graceful Moteur de routage Switchover ).
Voir également
Présentation de la mesure des pertes synthétiques Ethernet
Ethernet synthetic loss measurement (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 d’extrémité d’association de maintenance (MEP) effectue des mesures de perte de trame, ce qui contribue au temps d’indisponibilité.
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 extrême spécifie la perte de trame associée aux trames de données de sortie. Les mesures de perte de trame à l’extrémité proche et à l’extrémité éloignée contribuent toutes deux à des secondes gravement erronées à l’extrémité proche et à des secondes gravement erronées à l’extrémité éloignée qui sont utilisées en combinaison pour déterminer le temps indisponible. L’ETH-SLM est réalisé à l’aide d’un message de perte synthétique (SLM) et d’une réponse de perte synthétique (SLR). L’ETH-SLM permet à chaque MEP d’effectuer des mesures de perte de trame synthétique à l’extrémité proche et à l’extrémité éloignée 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 UIT-T Y.1731, ETH-LM et ETH-SLM. Junos OS prend uniquement en charge l’ETH-SLM asymétrique. Dans le cas de l’ETH-SLM asymétrique, chaque MEP envoie des trames avec les informations de demande ETH-SLM à son MEP homologue et reçoit des trames avec des informations de réponse ETH-SLM de la part de son MEP homologue pour effectuer des mesures de perte synthétiques. L’ETH-SLM asymétrique est utilisé pour l’OAM proactif ou à la demande afin d’effectuer des mesures de perte synthétiques applicables à la connexion Ethernet point à point. Cette méthode permet à un MEP d’initier et de signaler des mesures de pertes à long terme et à proximité de l’extrémité associées à une paire de MEP qui font partie du même groupe d’entités de maintenance (MEG).
MX Series Virtual Chassis ne prend pas en charge la mesure des pertes synthétiques Ethernet (ETH-SLM).
L’ETH-SLM asymétrique est utilisé pour effectuer des tests à la demande ou proactifs en initiant un nombre fini de trames ETH-SLM à un ou plusieurs pairs 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 perte synthétique à l’extrémité proche et à l’extrémité éloignée. La mesure de l’accord de niveau de service (SLA) est le processus de surveillance de la bande passante, du délai, de la variation du délai (gigue), de la continuité et de la disponibilité d’un service. Elle vous permet d’identifier les problèmes de réseau avant que les clients ne soient affectés par des défauts du réseau. 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 ITU-Y.1731 pour la mesure de perte de trame synthétique. Ce mode diffère de la mesure des 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 l’interface de ligne de commande, la demande SLM générée est conforme aux formats de trame spécifiés par la norme UIT-T Y.1731.
Les routeurs ACX5048 et ACX5096 prennent en charge ETH-SLM pour les services de couche 2.
Scénarios de configuration de l’ETH-SLM
L’ETH-SLM mesure la perte de trame à l’extrémité proche et à l’extrémité éloignée entre deux MEP qui font partie du même niveau MEG. Vous pouvez configurer l’ETH-SLM pour mesurer la perte synthétique à la fois pour la MEP orientée vers le haut ou en amont et la MEP orientée vers le bas ou en aval. Cette section décrit les scénarios suivants pour le fonctionnement de l’ETH-SLM :
MEP amont dans les tunnels MPLS
Imaginons un scénario dans lequel un MEP est configuré entre les interfaces réseau utilisateur (UNI) de deux routeurs MX Series, MX1 et MX2, dans le sens amont. Les réseaux MX1 et MX2 sont connectés via un réseau central MPLS. Les mesures de l’ETH-SLM sont effectuées entre le MEP en amont dans le chemin reliant les deux routeurs. MX1 et MX2 peuvent tous deux lancer un ETH-SLM à la demande ou proactif, qui peut mesurer à la fois la perte à l’extrémité et à l’extrémité proche de MX1 et MX2, respectivement. Les deux UNI sont connectés à l’aide d’un service filaire privé virtuel (VPWS) VPN de couche 2 basé sur MPLS.
MEP en aval dans les réseaux Ethernet
Imaginons un scénario dans lequel un MEP est configuré entre deux routeurs MX Series, MX1 et MX2, sur les interfaces Ethernet en aval. Les protocoles 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é dans le chemin entre ces deux routeurs.
Prenons un autre scénario dans lequel un MEP est configuré en aval et 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 assure une protection de bout en bout de la connexion du chemin de travail 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, via un cur MPLS. La session CFM (connectivity fault management) entre MX1 et MX2 constitue 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 via des interfaces Ethernet à MX4 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 réalisée entre ces eurodéputés en aval. Dans les deux MEP en aval, la configuration est effectuée sur les UNIT MX1 et MX4, de la même manière que dans les MEP en amont.
Format des messages ETH-SLM
Les messages de perte synthétique (SLM) prennent en charge les demandes de mesure de perte synthétique Ethernet asymétrique (ETH-SLM). Cette rubrique contient les sections suivantes qui décrivent les formats des unités de données de protocole (PDU) SLM, des PDU SLR et de la valeur de longueur de type itérateur de données (TLV).
SLM PDU Format
Le format PDU SLM est utilisé par un MEP pour transmettre des informations SLM. Les PDU SLM contiennent les composants suivants :
Source MEP ID : l’ID MEP source est un champ de 2 octets dans lequel les 13 derniers bits les moins significatifs 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 à son homologue MEP.
Les champs suivants sont les suivants dans une PDU SLM :
MEG Level (Niveau MEG) : niveau de domaine de maintenance configuré compris entre 0 et 7.
Version—0.
OpCode : identifie un type de PDU OAM. Pour SLM, c’est 55.
Flags (Indicateurs) : défini sur tous les zéros.
Décalage TLV : 16.
ID MEP source : champ de 2 octets utilisé pour identifier le MEP qui transmet la trame SLM. Dans ce champ de 2 octets, 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.
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 sont exécutés 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 à son homologue MEP.
TLV facultatif : un TLV de données peut être inclus dans n’importe quel SLM transmis. Aux fins de l’ETH-SLM, la partie valeur de la TLV des données n’est pas spécifiée.
End TLV : valeur octet de tous les zéros.
SLR PDU Format
Le format PDU à 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 :
MEG Level (Niveau MEG) : champ 3 bits dont la valeur est copiée à partir de la dernière PDU SLM reçue.
Version : champ de 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 le reflex, il est défini sur 54.
Flags : champ de 1 octet copié à partir de la PDU SLM.
TLV Offset : champ de 1 octet copié à partir de la PDU SLM.
Source MEP ID : champ de 2 octets copié à partir de la PDU SLM.
Responder MEP ID : champ de 2 octets utilisé pour identifier le MEP qui transmet 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 : champ de 4 octets. Cette valeur représente le nombre de trames reflex transmises pour cet ID de test.
TLV facultatif : la valeur est copiée à partir de la PDU SLM, si elle est présente.
End TLV : champ de 1 octet copié à partir de la PDU SLM.
Format TLV de l’itérateur de données
Le TLV de l’itérateur de données spécifie la partie TLV des données de la trame de données Y.1731. Le MEP utilise un TLV de données lorsqu’il est configuré pour mesurer le délai et la variation du délai pour différentes tailles de trame. Voici les champs d’une TLV de données :
Type : identifie le type TLV ; la valeur de ce type de TLV est Data (3).
Length (Longueur) : identifie la taille, en octets, du champ Value (Valeur) contenant le modèle de données. La valeur maximale du champ Longueur est 1440.
Modèle de données : nmodèle de bits arbitraire -octet (n indique la longueur). Le destinataire l’ignore.
Transmission de messages ETH-SLM
La fonctionnalité ETH-SLM peut traiter plusieurs demandes de messages de perte synthétique (SLM) simultanément entre une paire de MEP. Il peut s’agir d’une session SLM en amont ou à la demande. Chaque demande SLM est identifiée de manière unique par un ID de test.
Un député européen peut envoyer des demandes de GDT ou répondre à des demandes de GDT. 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 à l’extrémité et à l’extrémité proche sur la base des informations contenues dans le message SLM ou dans l’unité de données du protocole SLM (PDU).
Un MEP gère les compteurs locaux suivants pour chaque ID de test et pour chaque MEP pair surveillé dans une entité de maintenance pour laquelle des mesures de perte doivent être effectuées :
TxFCl : nombre d’images synthétiques transmises vers le MEP homologue pour un ID de test. Un MEP source incrémente ce nombre pour la transmission successive d’images 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 d’images synthétiques avec les informations SLR.
RxFCl : nombre d’images synthétiques reçues du MEP homologue pour un ID de test. Un MEP source incrémente ce nombre pour la réception successive d’images synthétiques avec des informations SLR, tandis qu’un MEP de destination ou de réception l’incrémente pour la réception successive d’images synthétiques avec des informations de demande ETH-SLM.
Les sections suivantes décrivent les phases de traitement des PDU SLM pour déterminer la perte de trame synthétique :
- Initiation et transmission des demandes SLM
- Réception de SLM et transmission de SLR
- Réception des reflex
- Calcul de la perte de trame
Initiation et transmission des demandes SLM
Un MEP transmet périodiquement une demande SLM dont le champ OpCode est 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 transmise 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 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. De plus, 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 de SLM et transmission de SLR
Une fois que le MEP de destination a reçu une trame SLM valide de la 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 récepteur. Tous les champs des PDU SLM sont copiés à partir de la demande SLM, à l’exception des champs suivants :
L’adresse MAC source est copiée vers 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épondant est renseigné avec l’ID MEP du MEP.
TxFCb est sauvegardé 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épondeur 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’expiration de son homologue MEP. Les images reflex reçues après la valeur du délai d’expiration (5 secondes) sont ignorées. À l’aide des informations contenues dans les images reflex, un MEP détermine la perte de trame 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. Une MEP utilise les valeurs suivantes pour déterminer la perte de trame à l’extrémité proche et à l’extrémité éloignée au cours de la période de mesure :
Les valeurs TxFCf et TxFCb de la trame SLR reçue 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.
Les valeurs TxFCf et TxFCb de la première trame reflex reçue après le début du test et le 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 de trame est déterminée à l’aide de la formule suivante :
Perte de trame (extrême) = TxFCf – TxFCb
Perte de trame (près de l’extrémité) = TxFCb – RxFCl
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
[edit protocols oam ethernet connectivity-fault-management]) n’est pas prise en charge lorsque l’interface performance-monitoring réseau à réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liens membres sur les DPC.