Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Présentation de l’UIT-T Y.1731 Service OAM Ethernet

SUMMARY Cette section décrit l’OAM de service (ITU-TY.1731) et ses deux composants principaux: la gestion des pannes (surveillance, détection et isolation) et la surveillance des performances (mesure des pertes de trames, mesure de la perte de trame synthétique et mesure du délai de trame).

Présentation des mesures du délai de trame Ethernet

Fonctionnalité de mesure du délai de trame ITU-T Y.1731

La norme IEEE 802.3-2005 pour les opérations, l’administration et la maintenance Ethernet (OAM) définit un ensemble de mécanismes de gestion des défaillances de liaisons afin de détecter et de signaler les pannes de liaison sur un seul réseau EThernet point à point.

Junos OS prend en charge les normes OAM clés qui assurent une gestion et une surveillance automatisées de bout en bout du service Ethernet par les fournisseurs de services:

  • IEEE standard 802.1ag,également connu sous le nom de « Gestion des pannes de connectivité (CFM). »

  • Recommandation Y.1731de l’UIT-T, qui utilise une terminologie différente de IEEE 802.1ag et définit les fonctionnalités OAM de service Ethernet pour la surveillance des pannes, des diagnostics et des performances.

Ces fonctionnalités permettent aux opérateurs de proposer des accords de niveau de service (SA) contraignantes et de générer de nouveaux revenus avec des packages de services garantis par le taux et les performances, adaptés aux besoins spécifiques de leurs clients.

ACX Series des modes proactifs et à la demande.

Remarque :

Les routeurs ACX5048 et ACX5096 ne sont pris en charge que l’horodaème logiciel pour la mesure des délais.

Ethernet CFM

La norme IEEE 802.1ag pour 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’agit d’une liaison unique ou de liaisons multiples couvrant 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 pannes à l IEEE de contrôle de continuité OAM Ethernet 802.1ag

  • Détection de chemins et vérification des pannes à l IEEE protocole Ethernet OAM 802.1ag de linktrace

  • Isolation des pannes grâce IEEE protocole de bouclation OAM 802.1ag Ethernet

Dans un environnement CFM, les entités réseau (opérateurs réseau, fournisseurs de services et clients, par exemple) peuvent faire partie de différents domaines administratifs. Chaque domaine administratif est mapé dans un domaine de maintenance. Les domaines de maintenance sont configurés avec différentes valeurs de niveau pour les séparer. Chaque domaine fournit assez d’informations aux entités pour effectuer leur propre gestion et leur propre 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 extrémité des associations de maintenance (MEP) et les points de maintenance intermédiaires (MIM).

Figure 1 : Relation des mep, MIM et des niveaux de domaine de maintenanceRelation des mep, MIM et des niveaux de domaine de maintenance
Remarque :

Sur ACX Series, les points de maintenance intermédiaires (MIP) sont pris en charge uniquement sur les routeurs ACX5048 et ACX5096.

Mesure du délai de trame Ethernet

Deux objectifs clés de la fonctionnalité OAM sont de mesurer les attributs de qualité de service, comme les variations de délai d’image et de délai de trame (également appelées « gigue de trame »). De telles mesures peuvent vous permettre d’identifier les problèmes réseau avant que vos clients ne soient impactés par des défauts de réseau.

Junos OS prend en charge la mesure de délai de trame Ethernet entre les MEP configurés sur des interfaces physiques ou logiques Ethernet sur MX Series routeurs. La mesure de délai de trame Ethernet permet aux opérateurs de déclencher des mesures de délai sur un service donné et peut être utilisée pour surveiller les SA. La mesure des délais de trame Ethernet permet également de recueillir d’autres informations utiles, telles que les retards dans les pires et les meilleurs cas, les délais moyens et les variations de délai moyennes. L’Junos OS de mesure de délai d’trame Ethernet (ETH-DM) est entièrement conforme à la recommandation UIT-T Y.1731, Fonctions et mécanismes OAM pour les réseaux ethernet. Cette recommandation définit les mécanismes OAM d’exploitation et de maintenance du réseau au niveau de la couche de services Ethernet, appelée « couche ETH » dans la terminologie ITU-T.

routeurs MX Series avec concentrateurs de ports modulaires (MPC) et MPC 10 Gigabit Ethernet avec prise en charge SFP+ Fonctionnalité ITU-T Y.1731 sur VPLS pour la variation de délai d’image et de délai.

Remarque :

MX Series Virtual Chassis ne prend pas en charge la mesure de délai de trame Ethernet (DM).

Mesure de délai d’trame Ethernet à sens simple

En mode ETH-DM à sens one-way, une série de valeurs de variation de délai de trame et de délai de trame est calculé en fonction de la durée d’attente entre l’heure d’envoi d’une trame de mesure à partir d’un routeur initiateur et l’heure de réception de la trame au niveau du récepteur MEP de l’autre routeur.

Remarque :

ACX Series routeurs n’offrent pas de prise en charge des mesures de délai de trame Ethernet à sens simple.

Transmission 1DM

Lorsque vous démarrez une mesure de délai d’image à sens simple, le routeur envoie 1DM d’trames (trames qui transportent l’unité de données de protocole (PDU) pour une mesure de délai à sens simple, du meP de l’initiateur au meP récepteur au rythme et au nombre de trames que vous spécifiez. Le routeur marque chaque trame de 1DM comme étant « drop-ineligible » et insère un délai de transmission dans la trame.

Réception en 1DM

Lorsqu’un MEP reçoit une trame de 1DM, le routeur contenant le récepteur MEP mesure le délai à sens simple de cette trame (différence entre la réception de la trame et l’heure d’attente contenue dans le cadre lui-même) et la variation de délai (différence entre les valeurs de délai actuelles et antérieures).

Statistiques ETH-DM à sens automatique

Le routeur qui contient le récepteur MEP stocke chaque ensemble de statistiques de retard à sens unique dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour n’importe quelle session CFM (paire de pairs MEP). Vous pouvez accéder à ces statistiques à tout moment en affichant le contenu de la base de données ETH-DM.

Nombres de trames ETH-DM à sens simple

Chaque routeur compte le nombre d’images ETH-DM directes envoyées et reçues:

  • Pour un meP initiateur, le routeur compte le nombre d’images 1DM envoyées.

  • Pour un récepteur MEP, le routeur compte le nombre d’images 1DM valides reçues et le nombre d’images 1DM non valides reçues.

Chaque routeur stocke les nombres 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 supportent l’ETH-DM, tout nombre de trames ETH-DM. Vous pouvez accéder aux nombres de trames à tout moment en affichant les informations de base de données CFM pour les interfaces Ethernet attribuées aux mégap.

Synchronisation des horloges système

La précision des calculs de délai à sens simple dépend de la synchronisation de près des horloges système au niveau du meP à l’initiative et du récepteur MEP.

La précision de la variation de délai à sens simple ne dépend pas de la synchronisation de l’horloge système. La variation de délai étant simplement la différence entre les valeurs de délai consécutives à sens simple, la période d’hors phase est éliminée des valeurs de gigue de trame.

Remarque :

Pour une mesure de délai d’trame Ethernet dans une direction unique, les valeurs de variation de délai de trame et de délai de trame sont uniquement disponibles sur le routeur qui contient le meP de récepteur.

Mesure du délai d’trame Ethernet à double sens

Dans le mode ETH-DM à double voie, les valeurs de variation de délai de délai de trame et de délai de trame sont basées sur la différence de temps entre lorsque l’initiateur MEP transmet une trame de demande et reçoit une trame de réponse du meP de l’intervenant, pour soustraire la durée écoulé au niveau du MEP de l’intervenant.

DMM Transmission

Lorsque vous démarrez une mesure de délai de trame à double direction, le routeur envoie des trames de message de mesure de retard (DMM), des trames qui transportent le PDU pour une requête ETH-DM à double direction, du MEP de l’initiateur au MEP de l’intervenant au rythme et au nombre de trames que vous spécifiez. Le routeur marque chaque trame DMM comme étant « drop-ineligible » et insère un délai de transmission dans la trame.

DMR Transmission

Lorsqu’un MEP reçoit une trame DMM, le meP répond par une trame de réponse de mesure de retard (DMR), qui transporte les informations de réponse ETH-DM et une copie de l’image d’accès contenue dans la trame DMM.

Réception DMR

Lorsqu’un MEP reçoit un DMR valide, le routeur contenant le MEP mesure le délai à double sens de cette trame en fonction de la séquence d’heures suivante:

  1. TITxDMM

  2. RxDMM TR

  3. TrTxDMR

  4. TIRxDMR

Un délai d’image à double voie est calculé comme suit:

  1. [TIRxDMR – TITxDMM] – [TRTxDMR – TRRxDMM]

Le calcul montre que le délai de trame est la différence entre la période à laquelle l’initiateur MEP envoie une trame DMM et l’heure à laquelle l’initiateur MEP reçoit la trame DMR associée du MEP de l’intervenant, moins le temps écoulé au niveau du meP de l’intervenant.

La variation de délai est la différence entre les valeurs de délai actuelles et précédentes.

Statistiques ETH-DM à double voie

Le routeur contenant l’initiateur MEP stocke chaque ensemble de statistiques de retard dans la base de données ETH-DM. La base de données ETH-DM collecte jusqu’à 100 ensembles de statistiques pour n’importe quelle session CFM (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 de trames ETH-DM à double sens

Chaque routeur compte le nombre d’images ETH-DM doubles 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 d’images DMR non valides reçues.

  • Pour un meP de réponse, le routeur compte le nombre d’images DMR envoyées.

Chaque routeur stocke les nombres 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 supportent l’ETH-DM, tout nombre de trames ETH-DM. Vous pouvez accéder aux nombres de trames à tout moment en affichant les informations de base de données CFM pour les interfaces Ethernet attribuées aux mégap.

Remarque :

Pour une mesure de délai d’trame Ethernet à double direction, les valeurs de variation de délai de trame et de délai de trame sont disponibles uniquement sur le routeur qui contient le MEP de l’initiateur.

Choisir entre etH-DM à double voie

La mesure de délai d’image à sens simple nécessite de synchroniser étroitement les horloges système au niveau du MEP initiateur et du récepteur. La mesure de délai d’trame à double voie ne nécessite pas de synchronisation des deux systèmes. S’il n’est pas pratique de synchroniser les horloges, les mesures de délai à trames doubles sont plus précises.

Lorsque deux systèmes sont physiquement proches les uns des autres, leurs valeurs de délai à sens simple sont très élevées par rapport à leurs valeurs de délai à double sens. La mesure de délai à sens simple nécessite de synchroniser l’heure des deux systèmes à un niveau extrêmement granulaire, et les routeurs MX Series ne sont actuellement pas en mesure de prendre en charge cette synchronisation granulaire.

Restrictions pour la mesure du délai de trame Ethernet

Les restrictions suivantes s’appliquent à la fonctionnalité de mesure du délai de trame Ethernet:

  • La fonctionnalité ETH-DM n’est pas prise en charge sur les pseudowires d’interface de commutage d’étiquettes (LSI).

    La fonctionnalité ETH-DM est prise en charge sur les interfaces Ethernet agrégées.

  • L’heure d’utilisation assistée par matériel des trames ETH-DM dans le chemin de réception n’est prise en charge que pour les interfaces MEP sur les DPC améliorés et les DPC de mise en file d’attente améliorées dans les routeurs MX Series routeurs. Pour plus d’informations sur l’inséguration assistée par le matériel, consultez les directives relatives à la configuration des routeurs pour la prise en charge d’une session ETH-DM et l’activation de l’option d’inséguration assistée par le matériel.

  • Les mesures de délai de trame Ethernet ne peuvent être déclenchées que lorsque le daemon de gestion périodique des paquets distribué ( ppm ) est activé. Pour plus d’informations sur cette limitation, consultez les directives relatives à la configuration des routeurs pour prendre en charge une session ETH-DM et s’assurer que l’ppm distribué n’est pas désactivé.

  • Vous pouvez surveiller uniquement une 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, consultez « Démarrer une session ETH-DM».

  • Les statistiques ETH-DM sont collectées sur un seul des deux routeurs pairs de la session ETH-DM. Pour une session ETH-DM à usage unique, vous pouvez afficher les statistiques ETH-DM de trame au niveau du récepteur uniquement à l’aide de commandes etH-DM show spécifiques. Pour une session ETH-DM à double direction, vous pouvez afficher uniquement les statistiques sur les délais de trame sur le meP de l’initiateur à l’aide des mêmes commandes spécifiques à ETH-DM. show Pour plus d’informations, consultez le rapport Managing ETH-DM Statistics et ETH-DM Frame Counts.

  • Les nombres de trames ETH-DM sont collectés dans les deux mep et stockés dans les bases de données CFM respectives.

  • En cas moteur de routage basculement GRES, les statistiques ETH-DM collectées sont perdues et les nombres de trames ETH-DM sont réinitialisés dans les zéros. Il est donc important de redémarrer la collecte de statistiques ETH-DM et de compteurs de trames ETH-DM une fois le basculement terminé. GRES permet à un routeur avec deux moteurs de routage de passer d’une moteur de routage principale à une moteur de routage de secours sans interruption du transfert de paquets. Pour plus d’informations, consultez Junos OS Guide de l’utilisateur haute disponibilité.

  • La précision des statistiques sur les délais de trame est compromise lorsque le système change (par exemple à partir de la reconfiguration). Il est recommandé d’effectuer des mesures de délai de trame Ethernet sur un système stable.

Vue d’ensemble des pertes de trames Ethernet

Les principaux objectifs de la fonctionnalité OAM sont de mesurer les attributs de qualité de service tels que le délai de trame, la variation de délai de trame (également appelée « gigue de trame »)et la perte de trame. De telles mesures vous permettent d’identifier les problèmes réseau avant que vos clients ne soient impactés par des défauts de réseau.

Junos OS prend en charge la mesure de perte de trame Ethernet (ETH-LM) entre les points de extrémité de l’association de maintenance (MEP) configurés sur des interfaces physiques ou logiques Ethernet sur les routeurs MX Series et est actuellement prise en charge uniquement pour le service VPWS. EtH-LM est utilisé par les opérateurs pour collecter les valeurs de compteurs applicables aux trames de services d’entrée et de sortie. Ces compteurs conservent un nombre d’images de données transmises et reçues entre deux meps. La mesure de la perte de trame Ethernet est effectuée en envoyant des trames avec des informations ETH-LM à un homologue et en recevant des trames avec des informations ETH-LM du peer MEP. Ce type de mesure de perte de trame est également connu sous le nom de mesure de perte Ethernet unique.

Remarque :

MX Series Virtual Chassis prise en charge de la perte de trame Ethernet (ETH-LM) n’est pas prise en charge.

ETH-LM prend en charge les mesures de perte de trame suivantes:

  • Mesure de perte de trame proche de la fin: mesure de la perte de trame associée aux trames de données d’entrée.

  • Mesure de perte de trames de bout en bout: mesure de la perte de trame associée aux trames de données de sortie.

Remarque :

La fonctionnalité proactive et double de mesure des pertes de l’UIT-T Y1731 n’est pas prise en charge ACX Series routeurs.

La fonctionnalité ETH-LM est prise en charge sur les interfaces Ethernet agrégées.

Remarque :

À partir de Junos OS version 16.1, les résultats de la mesure des pertes Ethernet (ETH-LM) sont inexacts lorsque les PUS de gestion des défaillances 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 comme priorité de perte de paquets (PLP) de moyenne et grande taille. Ce problème de résultats incorrects est spécifique à la mesure des pertes Ethernet lors des sessions CFM des mep en panne. 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 down

  • Les PDUS CFM reçus sur l’interface logique du MEP down sont classés par le classificateur comme PLP jaune ou moyenne-élevée

  • Un paquet est identifié comme jaune lorsque le classificateur d’entrée marque le PLP comme étant de taille moyenne à élevée.

Le problème des anomalies avec les résultats des mesures 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 inexacts de mesure des pertes, provisionnez tous les PDUS locaux de niveau vert ou avec le PLP aussi élevé.

Remarque :

Depuis la version Junos OS 16.1, la surveillance des performances pour la gestion des pannes de connectivité (en incluant l’énoncé et ses sous-déclarations au niveau hiérarchique) n’est pas prise en charge lorsque l’interface réseau vers réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liens membres sur performance-monitoring[edit protocols oam ethernet connectivity-fault-management] des DPC.

Mesure de l’accord de niveau de service

La mesure des accords de niveau de service (SLA) est le processus de surveillance de la bande passante, du délai, de la variation des délais(gigue),de la continuité et de la disponibilité d’un service (E-Line ou E-LAN). Elle vous permet d’identifier les problèmes réseau avant que vos clients ne soient impactés par des défaillances réseau.

Remarque :

Les services VPN Ethernet peuvent être classés dans les catégories:

  • Services E-Line (Peer-to-Peer-Services): les services E-Line sont proposés à l’aide d’MPLS VPN virtuels de couche 2(VPWS).

  • Services multipoint à multipoint (services E-LAN): les services E-LAN sont proposés à l’aide d’MPLS services VPLS (Virtual Private LAN Service).

Pour plus d’informations, consultez le Guide de configuration des VPN Junos.

En Junos OS, les mesures des SLA sont classées dans:

  • Mode à la demande: en mode à la demande, les mesures sont déclenchées via le CLI.

  • Mode proactif: en mode proactif, les mesures sont déclenchées par une application d’itérateur.

Notez que les mesures de délai de trame Ethernet et de perte de trame Ethernet ne sont pas prises en charge sur ae l’interface.

Mode à la demande pour la mesure des SLA

En mode à la demande, les mesures sont déclenchées par l’utilisateur via le CLI.

Lorsque l’utilisateur déclenche la mesure du délai par le biais de l’CLI, la demande de mesure de délai générée est la même que dans les formats de trame spécifiés par la norme ITU-T Y.1731. Pour une mesure de délai dans les deux sens, le traitement côté serveur peut être délégué au moteur de transfert de paquets pour éviter le trop-plein sur le moteur de routage. Pour plus d’informations, consultez le site Configuring Routers to Support an ETH-DM Session. Lorsque le traitement côté serveur est déléguer au moteur de transfert de paquets, les compteurs de trames du message de mesure de retard (DMM) et les compteurs de mesure de retard (DMR) ne sont pas affichés par la receivetransmitshow commande.

Lorsque l’utilisateur déclenche la mesure des pertes via l’CLI, le routeur envoie les paquets au format standard, ainsi que la mesure des pertes au format TLV. Par défaut, l’argument est inclus dans le paquet afin d’autoriser les sessions simultanées de mesure des pertes à partir session-id-tlv du même mep local. Vous pouvez également désactiver l’ID TLV de session en utilisant no-session-id-tlv l’argument.

EtH-LM unique est utilisé à des fins d’exploitation, d’administration et de maintenance à la demande. Un meP envoie des trames avec les informations de demande etH-LM à son pair MEP et reçoit des trames avec les informations de réponse ETH-LM de ses pairs MEP pour réaliser les mesures de perte. L’unité de données de protocole (PDU) utilisée pour une demande etH-LM unique est appelée message de mesure des pertes (LMM) et le PDU utilisé pour une réponse ETH-LM unique est appelé réponse de mesure des pertes (LMR).

Mode proactif pour la mesure des SLA

En mode proactif, les mesures des SLA sont déclenchées par une application d’itérateur. Un iterator est conçu pour transmettre périodiquement des paquets de mesures SLA sous forme de trames conformes à la norme ITU-Y.1731 pour une mesure de délai ou de mesure des pertes sur les routeurs MX Series. Ce mode diffère de la mesure SLA à la demande, qui est lancée par l’utilisateur. L’iterator envoie régulièrement des paquets de demande de délai ou de mesure des pertes pour chacune des connexions 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 le trop-plein du processeur. Junos OS prend en charge le mode proactif pour les VPNWS. Pour qu’un iterator forme une proximité à distance et que son fonctionnement soit opérationnel, le message CCM (Continuity Check message) doit être actif entre les configurations MEP locales et distantes de la gestion des pannes de connectivité (CFM). Tout changement dans les paramètres d’adjacence de l’itérateur réinitialise les statistiques d’itérateur existantes et redémarre l’iterator. Ici, le terme « adjacence » désigne l’appariement de deux points de terminaison (directement ou virtuellement) avec des informations pertinentes pour une compréhension commune, utilisée pour un traitement ultérieur. Par exemple, l’adjacence des itérateurs fait référence à l’association d’itérateurs entre les deux points de terminaison des meps.

Pour chaque DPC MPC, seules 30 instances d’itérateur pour une valeur de 10 millisecondes (ms) sont prise en charge. En Junos OS, 255 configurations de profils d’itérateur et 2 000 associations de mep distants sont pris 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 à l’infini, alors que les itérateurs dont la valeur de cycle est supérieure à 100 ms sont pris en charge pour des itérateurs finites et infinis. Les itérateurs à l’infini sont des itérateurs qui s’exécutent à une infinité jusqu’à ce que l’iterator soit désactivé ou désactivé manuellement.

Remarque :

Les routeurs ACX5048 et ACX5096 n’ont qu’une seconde et plus pour un cycle d’itérateur.

Un service VPWS configuré sur un routeur est surveillé pour suivre les mesures SLA en enregistrant la connexion (ici, il s’agit d’une paire de mep) distants et locaux) sur un iterator, puis en donnez une transmission périodique à trame de mesure SLA sur ces connexions. Le service de bout en bout est identifié via un point de fin d’association de maintenance (MEP) configuré aux deux extrémités.

Pour une mesure de délai et de mesure des pertes dans les deux sens, un itérateur envoie un message de demande de connexion dans la liste (le cas caser), puis envoie un message de demande pour la connexion sondée lors de l’ancien cycle d’itération. Les messages de demande d’arrière en arrière pour les trames de mesure des SLA et leurs réponses contribuent à la mesure de la variation de délai de calcul et de la perte.

La transmission à trames Y.1731 pour un service relié à un itérateur continue sans fin, sauf intervention et arrêt de l’opérateur, ou jusqu’à ce que la condition de compte d’itération 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 deactivate sla-iterator-profile l’instruction au [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id] niveau de la hiérarchie.

  • Fournir une disable déclaration sous le profil de l’itérateur correspondant au niveau de la [edit protocols oam ethernet connectivity-fault-management performance-monitoring sla-iterator-profiles profile-name] hiérarchie.

Mesures des retards et mesures des pertes Ethernet en mode proactif

Dans une mesure de délai à double sens, la trame du message de mesure de retard (DMM) est déclenché par l’intermédiaire d’une application d’itérateur. La trame DMM transporte un type d’itérateur, une longueur et une valeur (TLV) en plus des champs décrits dans le format de trame standard. Le serveur copie alors le TLV de l’itérateur de la trame DMM au cadre de réponse de mesure de retard (DMR).

Dans le cadre d’un calcul de variation de délai à usage one-way, le calcul de la variation de délai est basé sur les délais présents dans la trame DMR (et non sur la trame 1DM). Il n’est donc pas nécessaire que les horloges côté client et côté serveur soient synchronisées. Si la différence entre leurs horloges reste constante, les résultats de la variation de délai doivent être relativement précis. Cette méthode évite également d’envoyer des trames 1DM séparées uniquement pour la mesure de la variation de délai à usage unique.

En mode proactif pour la mesure des pertes, le routeur envoie des paquets au format standard, ainsi que des mesures de perte TLV et TLV de l’itérateur.

Présentation du protocole de notification de défaillance Ethernet

Le protocole FNP (Failure Notification Protocol) est un mécanisme de notification d’échec qui détecte les défaillances dans les réseaux de transport Ethernet point à point sur les routeurs MX Series point à point. En cas de défaillance d’une liaison de nœud, le système FNP détecte la défaillance et envoie des messages FNP aux nœuds adjacents qu’un circuit est en panne. Une fois le message FNP reçu, les nodes peuvent rediriger le trafic vers le circuit de protection.

Remarque :

Le FNP est uniquement pris en charge sur les services E-Line.

Un service E-Line assure une connectivité Ethernet point à point sécurisée entre deux interfaces réseau utilisateur (UNIS). Les services E-Line sont des services protégés et chaque service dispose d’un circuit et d’un circuit de protection en fonctionnement. CFM est utilisé pour surveiller les travail et protéger les chemins. Les intervalles entre les CCM entraînent un délai de ret passation en centaines de millisecondes ou quelques secondes. Le FNP assure la détection et la propagation des circuits de services en moins de 50 ms et offre un échouage 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 ne répondent qu’aux messages FNP générés par les équipements du réseau d’accès Ethernet. Le FNP ne peut être activé que sur les interfaces logiques qui font partie d’une instance de routage VPLS et aucune interface physique dans cette instance de routage VPLS ne doit être configurée par CCM. Le 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 de périphérie. Un VLAN associé au circuit ou circuit de protection en cours d’utilisation doit se trouver sur une interface logique. Aucun port d’accès ou port d’trunk n’est pris en charge sur la liaison ring pour les réseaux VLAN utilisés par les services E-LINE. Le 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 graceful et les fonctionnalités GRES (Graceful moteur de routage Switchover).

Vue d’ensemble des pertes synthétiques Ethernet

La mesure de perte synthétique Ethernet (ETH-SLM) est une application qui permet de calcul de la perte de trame en utilisant des trames synthétiques plutôt que du trafic de données. Ce mécanisme peut être considéré comme un échantillon statistique pour approximative le rapport de perte de trame du trafic de données. Chaque point de extrémité de l’association de maintenance (MEP) réalise 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 d’entrée et une perte de trame de bout en bout spécifie la perte de trame associée aux trames de données de sortie. Les mesures de perte de trames à la fois de bout en bout et de bout en bout contribuent à l’utilisation de secondes graves d’erreurs quasi-finaux et de secondes graves d’erreurs de bout en bout utilisées pour déterminer le temps indisponible. L’etH-SLM est exécuté à l’aide d’images de messages de perte synthétiques (SLM) et de trames de réponse de perte synthétique (SLR). ETH-SLM permet à chaque MEP de réaliser des mesures de perte de trames synthétiques quasiment de bout en bout en utilisant des trames synthétiques, car un service bidirectionnel n’est pas disponible si l’une des deux directions est déterminée à ne pas être disponible.

Il existe les deux types de mesures de perte de trame, définis par les normes UIT-T Y.1731, ETH-LM et ETH-SLM. Junos OS uniquement une etH-SLM unique. Dans une etH-SLM unique, chaque MEP envoie des trames avec les informations de demande ETH-SLM à son pair MEP et reçoit des trames avec les informations de réponse ETH-SLM de son pair MEP afin d’effectuer des mesures de perte synthétiques. EtH-SLM unique sert à la gestion des sinistres à la demande (OAM) en vue d’effectuer des mesures de perte synthétiques pour la connexion Ethernet point à point. Cette méthode permet à un meP d’initier et de signaler des mesures de perte de bout en bout et de quasi-fin associées à une paire de mep qui font partie du même groupe d’entités de maintenance (COMPLET).

Remarque :

MX Series Virtual Chassis mesure de perte synthétique Ethernet (ETH-SLM) n’est pas prise en charge.

L’etH-SLM unique est utilisée pour effectuer des tests à la demande ou proactifs en insitpant un volume fini de trames ETH-SLM à un ou plusieurs pairs MEP et en recevant la réponse ETH-SLM de leurs pairs. Les trames ETH-SLM contiennent les informations de l’ETH-SLM qui sont utilisées pour mesurer et fournir des rapports sur les pertes synthétiques de près ou de loin. La mesure des accords de niveau de service (SLA) est le processus de surveillance de la bande passante, des délais, des variations de délai(gigue),de la continuité et de la disponibilité d’un service. Elle vous permet d’identifier les problèmes réseau avant que vos clients ne soient impactés par des défaillances réseau. En mode proactif, les mesures des SLA sont déclenchées par une application d’itérateur. Un iterator est conçu pour transmettre périodiquement des paquets de mesures SLA sous la forme de trames conformes ITU-Y.1731 pour la mesure de perte de trame synthétique. Ce mode diffère de la mesure SLA à la demande, qui est lancée par l’utilisateur. En mode à la demande, les mesures sont déclenchées par l’utilisateur via le CLI. Lorsque l’utilisateur déclenche l’ETH-SLM via le CLI, la demande de SLM générée est la même que celle générée selon les formats de trame spécifiés par la norme UIT-T Y.1731.

Remarque :

Les routeurs ACX5048 et ACX5096 offrent une prise en charge de l’ETH-SLM pour les services de couche 2.

Scénarios de configuration d’ETH-SLM

L’ETH-SLM mesure la perte de trames en fin de vie et de bout en bout entre deux meps faisant partie du même niveau AUDSE. Vous pouvez configurer etH-SLM pour mesurer les pertes synthétiques pour les meP ascendantes ou en amont et les MEP en baisse ou en aval. Cette section décrit les scénarios suivants pour le fonctionnement d’ETH-SLM:

MeP en amont dans MPLS tunnels

Prenons 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 la direction en amont. Les appareils MX1 et MX2 sont connectés MPLS réseau central. Des mesures ETH-SLM sont réalisées entre le MEP en amont sur le chemin reliant les deux routeurs. Les deux modèles MX1 et MX2 peuvent lancer des services ETH-SLM à la demande ou proactifs, ce qui permet de mesurer respectivement les pertes de bout en bout et de quasi-fin aux niveaux MX1 et MX2. Les deux UNI sont connectés via MPLS VPN de couche 2 virtual private wire service(VPWS).

MeP en aval dans les réseaux Ethernet

Prenons un scénario dans lequel un MEP est configuré entre deux routeurs MX Series, MX1 et MX2, sur les interfaces Ethernet dans la direction en aval. Les MX1 et MX2 sont connectés dans une topologie Ethernet et un MEP en aval est configuré en direction du réseau Ethernet. Des mesures ETH-SLM sont réalisées entre le MEP en aval sur le chemin reliant les deux routeurs. EtH-SLM peut être mesuré dans le chemin entre ces deux routeurs.

Prenons un autre scénario dans lequel un MEP est configuré dans la direction en aval et la protection des services d’un VPNWS sur MPLS est activée en spécifiant un chemin de travail ou en protégeant le chemin sur le MEP. La protection du service assure une protection de connexion de bout en bout 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 protéger 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 travaillant ou protégé.

Sur un exemple de topologie, un routeur MX Series, MX1, est connecté à deux autres routeurs MX Series, MX2 et MX3, sur un MPLS central. La session de gestion des défaillances de connectivité (CFM) entre les 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 à MX4 sur les interfaces Ethernet du réseau d’accès. Le MEP en aval est configuré entre les MX1 et MX4 qui passe par MX2 (session CFM en cours) et entre les MX1 et MX4 qui passent par MX3 (session CFM protégée). EtH-SLM est exécuté entre ces meps en aval. Dans les meP en aval, la configuration est exécutée sur les MX1 et MX4 UNIS, à l’identique des MEP en amont.

Format des messages ETH-SLM

Les messages de perte synthétique (SLM) supportent les demandes de mesure de perte synthétique Ethernet (ETH-SLM) uni-clos. Ce sujet contient les sections suivantes qui décrivent les formats des unités de données de protocole SLM, des PDUS ainsi que de la valeur de longueur de l’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 PDUS SLM:

  • ID MEP source: ID MEP source est un champ à 2 octet où les 13 derniers bits les moins importants sont utilisés pour identifier le MEP transmettant la trame SLM. L’ID MEP est unique au sein du SYSTÈME d’IDE (MEP ID) au sein de LAEE.

  • ID de test: l’ID de test est un champ à 4 octet mis en place par le MEP transmetteant et est utilisé pour identifier un test lors de plusieurs tests exécutés simultanément entre les mep (y compris des tests simultanés à la demande et des tests proactifs).

  • TxFCf—TxFCf est un champ à quatre octets qui transporte le nombre de trames SLM transmises par le MEP vers son pair MEP.

Voici les champs d’un PDU SLM:

  • Niveau TORES: niveau de maintenance configuré dans la plage 0 à 7.

  • Version: 0.

  • OpCode: identifie un type de PDU OAM. SLM: 55.

  • Indicateurs: définissez tous les zéros.

  • TLV Offset— 16.

  • ID MEP source: un champ à 2 octet utilisé pour identifier le MEP transmettant la trame SLM. Dans ce champ à 2 octet, les 13 derniers bits les moins importants sont utilisés pour identifier le meP transmettant la trame SLM. L’ID MEP est unique au sein du SYSTÈME d’IDE (MEP ID) au sein de LAEE.

  • RESV: les champs réservés sont placés sur tous les zéros.

  • ID de test: ensemble de champs à 4 octet par le meP transmis et utilisé pour identifier un test si plusieurs tests sont exécutés simultanément entre les mep (y compris des tests simultanés à la demande et des tests proactifs).

  • TxFCf: un champ à 4 octets qui transporte le nombre d’images SLM transmises par le MEP vers son pair MEP.

  • Optionnel TLV: un TLV de données peut être intégré à n’importe quel SLM transmis. Dans le cadre de l’etH-SLM, la valeur de la TLV de données n’est pas spécifiée.

  • Fin du TLV: valeur octet de zéro.

SLR PDU Format

Un meP utilise le format PDU de réponse de perte synthétique (SLR) pour transmettre des informations sur le SLR. Les champs suivants sont dans un PDU SR:

  • NIVEAU TORES: un champ de 3 bits dont la valeur est copiée à partir du dernier PDU SLM reçu.

  • Version: un champ de 5 bits dont la valeur est copiée à partir du dernier PDU SLM reçu.

  • OpCode: identifie un type de PDU OAM. Pour le SR, il est définie comme 54.

  • Flags: un champ à 1 octet copié à partir du PDU SLM.

  • TLV Offset: un champ à 1 octet copié à partir du PDU SLM.

  • ID MEP source: un champ à 2 octet copié à partir du PDU SLM.

  • ID MEP de l’intervenant: un champ à 2 octets utilisé pour identifier le MEP transmettant la trame de SL.

  • ID de test: un champ à 4 octet copié à partir du PDU SLM.

  • TxFCf: un champ à 4 octet copié à partir du PDU SLM.

  • TxFCb: un champ à 4 octets. Cette valeur représente le nombre de trames SR transmises pour cet ID de test.

  • Optionnel TLV: la valeur est copiée à partir du PDU SLM, si besoin.

  • Fin TLV: un champ à 1 octet copié à partir du 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. Le meP utilise un TLV de données lorsque le meP est configuré pour mesurer les variations de délai et de délai pour différentes tailles de trames. Voici les champs d’un TLV de données:

  • 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 De valeur contenant le modèle de données. La valeur maximale du champ Longueur est 1 440.

  • Modèle de données: un noctet(n indique la longueur) un modèle de bit arbitraire. Le récepteur l’ignore.

Transmission de messages ETH-SLM

La fonctionnalité ETH-SLM peut traiter plusieurs demandes de message de perte synthétique (SLM) simultanément entre deux meps. La session peut être une session SLM proactive ou à la demande. Chaque demande de SLM est identifiée de manière unique par un ID de test.

Un MEP peut envoyer des requêtes SLM ou répondre à des demandes SLM. Une réponse à une demande de SLM s’appelle une réponse de perte synthétique (SLR). Une fois qu’un MEP détermine une demande de SLM à l’aide de l’ID de test, le MEP calcule la perte de trames de bout en bout et de près en se base sur les informations du message SLM ou de l’unité de données du protocole SLM (PDU).

Un meP conserve les compteurs locaux suivants pour chaque ID de test et pour chaque pair MEP surveillé au niveau d’une entité de maintenance pour laquelle les mesures de perte doivent être effectuées:

  • TxFCl: nombre de trames synthétiques transmises vers le peer MEP pour un ID de test. Un meP source incréments ce numéro pour la transmission successive de trames synthétiques avec les informations de demande ETH-SLM tandis qu’une destination ou une réception du meP incréments cette valeur pour la transmission successive de trames synthétiques avec les informations slr.

  • RxFCl: nombre de trames synthétiques reçues auprès du pair MEP pour un ID de test. Un meP source incréments ce numéro pour la réception successive de trames synthétiques avec des informations sur le SLR tandis qu’une destination ou une réception du MEP l’incréments pour la réception successive de trames synthétiques avec informations de demande ETH-SLM.

Les sections suivantes décrivent les phases de traitement des PDUS SLM pour déterminer la perte de trame synthétique:

Lancement et transmission des requêtes SLM

Un MEP transmet périodiquement une demande de SLM avec l’ensemble de champ OpCode comme 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 de SLM. Pour chaque PDU SLM transmis pour la session (ID de test), le compteur local TxFCl est envoyé dans le paquet.

Aucune synchronisation de la valeur de l’ID de test n’est requise entre l’ID de test lancé et l’ID de test intervenant, car l’ID de test est configuré sur le MEP initié et le MEP qui répond utilise l’ID de test qu’il reçoit du MEP à l’initiative de l’initiative. Étant donné que l’ETH-SLM est une technique d’échantillonnage, elle est moins précise que de compter les trames de service. En outre, la précision des mesures 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 de SR

Une fois que le MEP de destination reçoit une trame SLM valide du MEP source, une trame SLM est générée et transmise au MEP source ou de demande. La trame SLR est valide si le niveau TOR ET l’adresse MAC de destination correspondent à l’adresse MAC de réception. Tous les champs des PDUs 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 MAC source est l’adresse MAC du MEP.

  • La valeur du champ OpCode est modifiée du SLM au SR (54).

  • L’ID MEP de l’IP de réponse est rempli avec l’ID MEP du MEP.

  • TxFCb est économisé avec la valeur du compteur local RxFCl au moment de la transmission de trames SR.

  • Une trame SLM est générée à chaque fois qu’une trame SLM est reçue. par conséquent, la RxFCl dans le répondeur est égale au nombre de trames SLM reçues et égale au nombre d’images SLM envoyées. Au niveau du répondant ou du mep de réception, RxFCl équivaut à TxFCl.

Réception des SR

Une fois qu’une trame SLM (avec une valeur TxFCf donnée) est transmise, un MEP s’attend à recevoir une trame SLM correspondante (qui porte la même valeur TxTCf) dans la valeur de délai de son pair MEP. Les trames SR reçues après l’écart de la valeur de délai (5 secondes) sont éliminées. Les informations contenues dans les trames SLR déterminent la perte de trame pour la période de mesure spécifiée. La période de mesure est un intervalle dans lequel le nombre de trames SLM transmises est statistiquement adapté pour effectuer une mesure à une précision donnée. Un meP utilise les valeurs suivantes pour déterminer la perte de trames de près de bout en bout et de bout en bout pendant la période de mesure:

  • À la fin de la période de mesure, nous avons reçu les valeurs TxFCf et TxFCb de trameSLR et la valeur RxFCl du compteur local. Ces valeurs sont représentées comme TxFCf[tc], TxFCb[tc] et RxFCl[tc], lorsque tc représente la période de fin de la période de mesure.

  • Les valeurs TxFCf et TxFCb de trame SLR de la première trame SLR 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 sous les nom de 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 de l’envoi ou du meP source.

Calcul de la perte de trame

La perte de trame synthétique est calculé à la fin de la période de mesure en fonction de la valeur des compteurs locaux et des informations provenant de la dernière trame reçue. Les dernières trames reçues contiennent les valeurs TxFCf et TxFCb. Le compteur local contient la valeur RxFCl. L’utilisation de ces valeurs permet de déterminer la perte de trame à l’aide de la formule suivante:

Perte de trame (en bout) = TxFCf – TxFCb

Perte de trame (fin de trame) = TxFCb – RxFCl

Tableau de l'historique des versions
Version
Description
16.1
À partir de Junos OS version 16.1, les résultats de la mesure des pertes Ethernet (ETH-LM) sont inexacts lorsque les PUS de gestion des défaillances 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 comme priorité de perte de paquets (PLP) de moyenne et grande taille.
16.1
Depuis la version Junos OS 16.1, la surveillance des performances pour la gestion des pannes de connectivité (en incluant l’énoncé et ses sous-déclarations au niveau hiérarchique) n’est pas prise en charge lorsque l’interface réseau vers réseau (NNI) ou l’interface de sortie est une interface Ethernet agrégée avec des liens membres sur performance-monitoring[edit protocols oam ethernet connectivity-fault-management] des DPC.