UNION INTERNATIONALE DES TÉLÉCOMMUNICATIONS

Transcription

1 UNION INTERNATIONALE DES TÉLÉCOMMUNICATIONS UIT-T Y.1713 SECTEUR DE LA NORMALISATION DES TÉLÉCOMMUNICATIONS DE L'UIT (03/2004) SÉRIE Y: INFRASTRUCTURE MONDIALE DE L'INFORMATION, PROTOCOLE INTERNET ET RÉSEAUX DE NOUVELLE GÉNÉRATION Aspects relatifs au protocole Internet Gestion, exploitation et maintenance Détection de mauvais branchements dans les réseaux MPLS Recommandation UIT-T Y.1713

2 RECOMMANDATIONS UIT-T DE LA SÉRIE Y INFRASTRUCTURE MONDIALE DE L'INFORMATION, PROTOCOLE INTERNET ET RÉSEAUX DE NOUVELLE GÉNÉRATION INFRASTRUCTURE MONDIALE DE L'INFORMATION Généralités Services, applications et intergiciels Aspects réseau Interfaces et protocoles Numérotage, adressage et dénomination Gestion, exploitation et maintenance Sécurité Performances ASPECTS RELATIFS AU PROTOCOLE INTERNET Généralités Services et applications Architecture, accès, capacités de réseau et gestion des ressources Transport Interfonctionnement Qualité de service et performances de réseau Signalisation Gestion, exploitation et maintenance Taxation RÉSEAUX DE LA PROCHAINE GÉNÉRATION Cadre général et modèles architecturaux fonctionnels Qualité de service et performances Aspects relatifs aux services: capacités et architecture des services Aspects relatifs aux services: interopérabilité des services et réseaux dans les réseaux de nouvelle génération Numérotage, nommage et adressage Gestion de réseau Architectures et protocoles de commande de réseau Sécurité Mobilité généralisée Y.100 Y.199 Y.200 Y.299 Y.300 Y.399 Y.400 Y.499 Y.500 Y.599 Y.600 Y.699 Y.700 Y.799 Y.800 Y.899 Y.1000 Y.1099 Y.1100 Y.1199 Y.1200 Y.1299 Y.1300 Y.1399 Y.1400 Y.1499 Y.1500 Y.1599 Y.1600 Y.1699 Y.1700 Y.1799 Y.1800 Y.1899 Y.2000 Y.2099 Y.2100 Y.2199 Y.2200 Y.2249 Y.2250 Y.2299 Y.2300 Y.2399 Y.2400 Y.2499 Y.2500 Y.2599 Y.2700 Y.2799 Y.2800 Y.2899 Pour plus de détails, voir la Liste des Recommandations de l'uit-t.

3 Recommandation UIT-T Y.1713 Détection de mauvais branchements dans les réseaux MPLS Résumé La présente Recommandation décrit des mécanismes relatifs à la fonctionnalité OAM (exploitation et maintenance) de plan d'utilisateur dans les réseaux MPLS afin de compléter les prescriptions figurant dans la Rec. UIT-T Y.1711 conformément aux conditions et principes énoncés dans la Rec. UIT-T Y La version actuelle de la présente Recommandation se rapporte principalement à la prise en charge des conduits LSP point à point ou multipoint à point indépendamment de la méthode d'établissement considérée. Source La Recommandation Y.1713 de l'uit-t a été approuvée le 15 mars 2004 par la Commission d'études 13 ( ) de l'uit-t selon la procédure définie dans la Recommandation UIT-T A.8. Mots clés Défaillance, dérangement, MPLS, OAM. Rec. UIT-T Y.1713 (03/2004) i

4 AVANT-PROPOS L'UIT (Union internationale des télécommunications) est une institution spécialisée des Nations Unies dans le domaine des télécommunications. L'UIT-T (Secteur de la normalisation des télécommunications) est un organe permanent de l'uit. Il est chargé de l'étude des questions techniques, d'exploitation et de tarification, et émet à ce sujet des Recommandations en vue de la normalisation des télécommunications à l'échelle mondiale. L'Assemblée mondiale de normalisation des télécommunications (AMNT), qui se réunit tous les quatre ans, détermine les thèmes d'étude à traiter par les Commissions d'études de l'uit-t, lesquelles élaborent en retour des Recommandations sur ces thèmes. L'approbation des Recommandations par les Membres de l'uit-t s'effectue selon la procédure définie dans la Résolution 1 de l'amnt. Dans certains secteurs des technologies de l'information qui correspondent à la sphère de compétence de l'uit-t, les normes nécessaires se préparent en collaboration avec l'iso et la CEI. NOTE Dans la présente Recommandation, l'expression "Administration" est utilisée pour désigner de façon abrégée aussi bien une administration de télécommunications qu'une exploitation reconnue. Le respect de cette Recommandation se fait à titre volontaire. Cependant, il se peut que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, l'interopérabilité et l'applicabilité) et considère que la Recommandation est respectée lorsque toutes ces dispositions sont observées. Le futur d'obligation et les autres moyens d'expression de l'obligation comme le verbe "devoir" ainsi que leurs formes négatives servent à énoncer des prescriptions. L'utilisation de ces formes ne signifie pas qu'il est obligatoire de respecter la Recommandation. DROITS DE PROPRIÉTÉ INTELLECTUELLE L'UIT attire l'attention sur la possibilité que l'application ou la mise en œuvre de la présente Recommandation puisse donner lieu à l'utilisation d'un droit de propriété intellectuelle. L'UIT ne prend pas position en ce qui concerne l'existence, la validité ou l'applicabilité des droits de propriété intellectuelle, qu'ils soient revendiqués par un Membre de l'uit ou par une tierce partie étrangère à la procédure d'élaboration des Recommandations. A la date d'approbation de la présente Recommandation, l'uit n'avait pas été avisée de l'existence d'une propriété intellectuelle protégée par des brevets à acquérir pour mettre en œuvre la présente Recommandation. Toutefois, comme il ne s'agit peut-être pas de renseignements les plus récents, il est vivement recommandé aux responsables de la mise en œuvre de consulter la base de données des brevets du TSB. UIT 2004 Tous droits réservés. Aucune partie de cette publication ne peut être reproduite, par quelque procédé que ce soit, sans l'accord écrit préalable de l'uit. ii Rec. UIT-T Y.1713 (03/2004)

5 TABLE DES MATIÈRES Page 1 Domaine d'application Références normatives Bibliographie Définitions Abréviations Applicabilité et aperçu de la fonctionnalité Identification des paquets OAM dans le trafic normal de plan d'utilisateur Capacité utile OAM Traitement des paquets OAM erronés Vérification de la connectivité FEC Codes de type dérangement Génération de paquets CV et FEC-CV par la source et traitement par le puits Traitement des paquets FEC-CV au niveau des routeurs LSR intermédiaires Règles communes de codage Traitement de sortie Règles de codage et de traitement applicables aux conduits LSP de type RFC 3036 (LDP) Règles de codage et de traitement applicables aux conduits LSP de type RFC 3209 (RSVP-TE) Règles de codage et de traitement applicables aux conduits LSP de type RFC 3212 (CR-LDP) Spécifications relatives aux polynômes Critères d'entrée/de sortie et actions résultantes Considérations liées à la sécurité Appendice I Règles de codage et de traitement applicables aux conduits LSP de type RFC 2547 (BGP/VPN) I.1 Scénario 1: conduit à étiquettes regroupées I.2 Scénario 2: conduits à étiquettes non regroupées Appendice II Utilisation de la fonction FEC-CV pour vérifier la connectivité et mesurer la disponibilité de route Appendice III Etablissement de la valeur T FEC-CV Appendice IV Questions relatives au mécanisme ECMP Appendice V Questions relatives au mécanisme de suppression PHP Rec. UIT-T Y.1713 (03/2004) iii

6

7 Recommandation UIT-T Y.1713 Détection de mauvais branchements dans les réseaux MPLS 1 Domaine d'application La présente Recommandation décrit des mécanismes relatifs à la fonctionnalité OAM (exploitation et maintenance) de plan d'utilisateur dans les réseaux MPLS conformément aux conditions et principes énoncés dans la Rec. UIT-T Y La version actuelle de la présente Recommandation se rapporte principalement à la prise en charge des conduits LSP point à point ou multipoint à point indépendamment de la méthode d'établissement considérée. Le mécanisme de détection fait intervenir un nouveau type de paquets OAM (appelé FEC-CV) qui utilise les conventions de protocole décrites dans la Rec. UIT-T Y.1711 (utilisation de l'étiquette d'alerte OAM, de l'unité PDU administrée de la Rec. UIT-T Y.1711 et de codes). Son utilisation et ses conditions d'application sont décrites au 6. 2 Références normatives La présente Recommandation se réfère à certaines dispositions des Recommandations UIT-T et textes suivant qui, de ce fait, en sont partie intégrante. Les versions indiquées étaient en vigueur au moment de la publication de la présente Recommandation. Toute Recommandation ou tout texte étant sujet à révision, les utilisateurs de la présente Recommandation sont invités à se reporter, si possible, aux versions les plus récentes des références normatives suivantes. La liste des Recommandations de l'uit-t en vigueur est régulièrement publiée. La référence à un document figurant dans la présente Recommandation ne donne pas à ce document en tant que tel le statut d'une Recommandation. [1] Recommandation UIT-T Y.1711 (2004), Mécanisme d'exploitation et de maintenance pour les réseaux MPLS. [2] Recommandation UIT-T G.805 (2000), Architecture fonctionnelle générique des réseaux de transport. [3] Recommandation UIT-T M.20 (1992), Philosophie de maintenance pour les réseaux de télécommunication. [4] Recommandation UIT-T Y.1710 (2002), Prescriptions relatives à la fonctionnalité d'exploitation et de maintenance pour les réseaux MPLS. [5] IETF RFC 3036 (2001), LDP Specification. Category: Standards Track. [6] IETF RFC 3209 (2001), RSVP-TE: Extensions to RSVP for LSP Tunnels. Category: Standards Track. [7] IETF RFC 3212 (2002), Constraint-Based LSP Setup using LDP. Category: Standards Track. [8] IETF RFC 3429 (2002), Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. Category: Informational. 3 Bibliographie [9] IETF RFC 2547 (1999), BGP/MPLS VPNs. Category: Informational. Rec. UIT-T Y.1713 (03/2004) 1

8 4 Définitions La terminologie introduite dans la présente Recommandation, nécessaire à la description des composants de réseau fonctionnels associés à la fonctionnalité OAM, est cohérente avec la terminologie utilisée dans la Rec. UIT-T G vers l'arrière: sens opposé au sens vers l'avant. 4.2 client/serveur (relation entre deux couches de réseau): [2] terme désignant le transport transparent d'une connexion de couche liaison cliente (c'est-à-dire supérieure) par un chemin de couche Réseau serveuse (c'est-à-dire inférieure). 4.3 dérangement: [3] interruption de la capacité d'une entité de transport (par exemple une connexion de réseau) à transférer des informations d'utilisateur ou OAM. La présente Recommandation définit deux types de dérangement et reprend les dérangements de référence définis dans la Rec. UIT-T Y.1711 (les spécifications détaillées sont données plus loin): dlocv: perte de vérification de connectivité (CV); dexcess: fréquence de paquets CV reçus trop élevée; dserver: dérangement dans la couche serveuse. Tout dérangement se produisant dans la couche serveuse au-dessous de la couche MPLS. dfecfilter_mismatch: non-concordance de filtres FEC; dfecfilter_mismerge: erreur d'association de filtres FEC; dtssi_mismatch: non-concordance d'identificateurs de source de chemin; dttsi_mismerge: erreur d'association d'identificateurs de source de chemin; dunknown: dérangement inconnu dans le réseau MPLS; dpeerme: défaillance non spécifiée dans une entité de maintenance homologue. 4.4 défaillance: [3] interruption permanente de la capacité d'une entité de transport à transférer des informations d'utilisateur ou OAM. Une défaillance peut être causée par un dérangement persistant. 4.5 vers l'avant: sens de circulation du trafic et des paquets OAM CV sur un conduit LSP. 4.6 connexion de liaison: subdivision d'un chemin de couche N entre deux points de commutation adjacents sur le plan logique dans cette couche. 4.7 sous-réseau: [2] région topologique d'un réseau délimitée par un ensemble de points d'accès périphériques et caractérisée par un routage possible dans le sous-réseau entre ces points d'accès. Un réseau correspond au plus grand sous-réseau et un nœud correspond au plus petit sousréseau (au moins en termes physiques dans la pratique, même s'il existe des sous-réseaux plus petits à l'intérieur des nœuds). 4.8 chemin: [2] entité de transport générique de couche N, composée d'un champ capacité utile (pouvant acheminer un paquet émanant d'une entité de chemin de couche supérieure cliente N 1) auquel un préfixe spécifique est ajouté afin de garantir l'intégrité de transmission de l'entité de transport chemin de couche N. 4.9 terminaison de chemin: [2] point (source ou puits) d'un chemin dans la couche N; c'est en ce point que le préfixe de chemin est ajouté ou retranché, selon le cas. Une terminaison de chemin doit avoir un moyen unique d'identification dans la couche plan d'utilisateur: désigne l'ensemble des composants de transmission de trafic acheminant le flux de trafic. Des paquets OAM CV ou FEC-CV sont insérés périodiquement dans ce flux de trafic afin de contrôler le bon fonctionnement de ces composants de transmission. Le plan d'utilisateur est aussi appelé parfois plan de données (notamment à l'ietf). Il est à noter que les 2 Rec. UIT-T Y.1713 (03/2004)

9 protocoles du plan de commande (par exemple pour la signalisation ou le routage) et les protocoles du plan de gestion nécessiteront leur propre plan d'utilisateur, qui pourra être congruent (à divers degrés), mais pas nécessairement, au plan d'utilisateur prenant en charge le trafic. 5 Abréviations La présente Recommandation utilise les abréviations suivantes: BDI indication de dérangement vers l'arrière (backward defect indication) BIP parité avec entrelacement de bits (bit interleaved parity) CR-LDP protocole de distribution avec étiquette d'acheminement basé sur les contraintes (constraint-based routing using label distribution protocol) CV vérification de connectivité (connectivity verification) CV Packet paquet de vérification de connectivité (connectivity verification packet) DL localisation de dérangement (defect location) DoS déni de service (denial of service) DT type de dérangement (defect type) ECMP conduits de coût égal (equal cost multi-path) FDI indication de dérangement vers l'avant (forward defect indication) FEC classe d'équivalence de réacheminement (forwarding equivalence class) FFD détection rapide de défaillance (fast failure detection) LSP conduit commuté avec étiquette (label switched path) LSR routeur à commutation par étiquette (label switching router) MPLS commutation multiprotocolaire avec étiquette (multi-protocol label switching) NMS système de gestion de réseau (network management system) OAM exploitation et maintenance (operations and maintenance) PHP suppression d'étiquette à l'avant-dernier saut (penultimate hop popping) RSVP protocole de réservation de ressources (resource reservation protocol) TTL durée de vie (time to live) TTSI identificateur de source de chemin (trail termination source identifier) 6 Applicabilité et aperçu de la fonctionnalité La commutation MPLS offre la possibilité de définir une hiérarchie arbitraire, mais, outre le risque de propager des problèmes d'indirection de trafic au sein d'un niveau MPLS particulier, elle ne prend pas nécessairement en charge des mécanismes de synchronisation permettant de garantir que toutes les dépendances hiérarchiques sont satisfaites avant une insertion de trafic dans un conduit LSP. On peut citer l'exemple courant de toute surcouche d'un réseau protocole de distribution avec étiquette (LDP, label distribution protocol) [5] utilisant un mode indépendant de distribution d'étiquettes. Dans un tel mode, un routeur LSR dans le centre du réseau peut annoncer un rattachement d'étiquette pour une classe FEC immédiatement après avoir pris connaissance de cette classe par un moyen quelconque (généralement via une annonce protocole de passerelle intérieur) (IGP, internal gateway protocol), ce qui peut être préalable à l'obtention d'un rattachement d'étiquette fiable vers l'aval ou d'un protocole LDP convenablement configuré sur toutes les liaisons par lesquelles devraient passer le conduit LSP. Cela signifie que la connectivité vers la sortie de Rec. UIT-T Y.1713 (03/2004) 3

10 réseau pour la classe FEC dont peuvent dépendre les applications de niveau MPLS n'existe pas nécessairement. Il en résulte que l'étiquette LDP est dépilée dans le centre du réseau et que le routeur LSR de dépilement peut tenter de transmettre l'étiquette d'application. Cette situation peut être transitoire mais elle est révélatrice du type de problème que l'on peut rencontrer. Pour pouvoir détecter tous les problèmes dans un réseau, il faut donc pouvoir détecter les branchements incorrects indépendamment de l'application considérée. Actuellement, l'unité Y.1711 CV PDU [1] permet de réaliser ceci pour des conduits LSP point à point lorsque l'entrée est connue, et les unités PDU FEC-CV offrent cette possibilité pour des conduits point à point et multipoint à point lorsque l'ensemble des entrées n'est pas nécessairement connu. En résumé, un flux FEC-CV est généré au niveau d'un routeur LSR d'entrée de conduit LSP non surveillé suivant une fréquence nominale de 1 sur T FEC-CV secondes (où T FEC-CV est une valeur configurée pour l'ensemble d'un sous-réseau). L'unité PDU FEC-CV contient un identificateur de point d'accès unique au réseau (TTSI) qui identifie le point d'insertion de l'unité, ainsi qu'un codage de longueur fixe de la fonction LSP que l'on désigne par filtre FEC. La sortie de conduit LSP peut ainsi vérifier la transmission correcte (pas d'acheminement erroné) des points d'entrée LSP (routeurs LSP d'entrée) conformément à la fonction LSP. La détection de branchements incorrects et d'erreurs d'association indiquée dans la Rec. UIT-T Y.1711 est ainsi élargie aux: i) conduits LSP MPLS lorsque, du point de vue du plan de contrôle, il n'y a pas de rattachement strict entre les points d'accès et les sorties de conduit LSP; ii) conduits LSP non surveillés lorsque la sortie n'a pas connaissance de l'identificateur TTSI du point d'accès d'entrée. L'usage courant est de rattacher un seul élément FEC par conduit LSP même si une unité PDU FEC-CV pourra prendre en charge plusieurs éléments FEC dans le cas d'opérateurs choisissant d'utiliser plusieurs éléments FEC par conduit LSP. Le codage de longueur fixe présente des limites pratiques en ce qui concerne le nombre d'éléments FEC qui peuvent être codés dans une seule sonde (éléments qui sont décrits dans les paragraphes de la présente Recommandation relatifs aux règles de codage et de traitement). On suppose qu'un routeur LSR proposant plusieurs classes FEC par rattachement d'étiquette utilisera plusieurs étiquettes lorsqu'il lui faudra proposer un nombre de classes FEC plus grand que celui qui peut normalement être codé dans une seule unité PDU FEC-CV. 7 Identification des paquets OAM dans le trafic normal de plan d'utilisateur On utilise dans la présente Recommandation la valeur d'étiquette réservée globalement, que l'on désigne ici par "étiquette d'alerte OAM" définie dans le document [8] et la Rec. UIT-T Y Capacité utile OAM La capacité utile OAM est conforme aux prescriptions indiquées dans la Rec. UIT-T Y Traitement des paquets OAM erronés Le traitement des paquets OAM erronés est conforme aux prescriptions indiquées dans la Rec. UIT-T Y Vérification de la connectivité FEC La fonction de vérification de connectivité pour la classe FEC (FEC-CV) peut être utilisée à la place de la fonction CV lorsqu'une capacité de détection de dérangement additionnelle ou alternative est nécessaire, en particulier pour détecter des problèmes relatifs à l'élément FTN d'entrée ou d'autres informations de configuration liées au conduit LSP. A cet égard, la fonction FEC-CV peut être utilisée sur des conduits LSP uniquement pour détecter des problèmes FTN/de configuration ou 4 Rec. UIT-T Y.1713 (03/2004)

11 peut être associée à d'autres fonctions de traitement puits afin d'ajouter des dérangements FTN et/ou de configuration à l'ensemble des dérangements qui font l'objet d'une surveillance. Les fonctions FEC-CV et CV ne sont pas interchangeables, une entrée de conduit LSP étant configurée pour utiliser l'une OU l'autre d'entre elles, mais pas les deux. La sortie de conduit LSP traitera la réception d'un type de fonction non prévu comme un dérangement de type dttsi/fec_mismerge ou dttsi/fec_mismatch, suivant la fonction de traitement d'extrémité proche considérée. La structure de la capacité utile FEC-CV est semblable à celle de la capacité utile CV avec l'inclusion du filtre Bloom appelé "filtre FEC". Le filtre FEC est un tableau d'octets non structuré. Type de fonction (08 hex) Réservé (tout à 00 hex) Identificateur de source de chemin LSP (TTSI), 16 octets v6 pour l'identificateur LSN + 4 octets pour l'identificateur de tunnel LSP Filtre FEC Remplissage (tout à 00 hex) BIP-16 1 octet 3 octets 20 octets 16 octets 2 octets 2 octets Figure 1/Y.1713 Structure de la capacité utile FEC-CV Les sondes FEC-CV sont insérées dans des conduits LSP suivant un débit configurable (T FEC-CV ). Leurs implémentations devraient autoriser, au minimum, des fréquences d'insertion comprises entre une insertion par seconde et une insertion par minute, et peuvent donner lieu à des intervalles d'insertion plus longs. 11 Codes de type dérangement Type de dérangement Code DT (hex) Signification dfecfilter_mismatch Le dérangement dfecfilter_mismatch est dû à la présence d'un filtre FEC inattendu dans les paquets OAM FEC-CV OU à la présence d'un paquet OAM Y.1711 CV ou FFD inattendu. Il est à noter que le dérangement dfecfilter_mismatch a priorité sur la condition de dérangement dlocv qui est également présente. dfecfilter_mismerge Le dérangement dfecfilter_mismerge est dû au fait que le paquet OAM FEC-CV entrant comporte un filtre FEC attendu et un filtre FEC inattendu OU parce qu'un paquet OAM Y.1711 CV ou FFD inattendu est reçu avec un paquet OAM FEC-CV attendu. 12 Génération de paquets CV et FEC-CV par la source et traitement par le puits La génération de paquets CV, FFD_CV et FEC-CV par la source et leur traitement par le puits devraient être considérés comme des fonctions indépendantes. Ce découplage fonctionnel permet aux opérateurs d'utiliser différentes catégories de contrôle des conduits LSP en fonction du conduit LSP, par exemple la différentiation entre des conduits LSP considérés comme ''importants'' et des conduits LSP considérés comme ''moins importants'', ou entre des conduits LSP qui peuvent être l'objet d'un traitement des dérangements et de mesures de disponibilité complets et ceux pour lesquels seule la détection d'un sous-ensemble de dérangements peut être implémenté en raison du plan de commande utilisé (LDP par exemple). Rec. UIT-T Y.1713 (03/2004) 5

12 La génération de paquets CV et FEC-CV est une fonction relativement simple (car elle ne varie jamais), beaucoup plus simple que le traitement de ces paquets par le puits. Chaque forme de paquet CV a ses caractéristiques d'application spécifiques et son utilisation dans le réseau peut être configurée de manière complémentaire. Il est prévu (en mode d'utilisation habituelle) que les paquets CV soient générés pour des conduits LSP point à point auxquels n'est associée aucun exigence de vérification FTN, et d'utiliser les paquets FEC-CV pour les conduits LSP point à point nécessitant une vérification FTN avec une signalisation des conduits via le protocole LDP. La génération de paquets CV OU FEC-CV pourrait donc être activée sur la totalité (ou la plupart) des conduits LSP. Le traitement par le puits des paquets CV pourrait être décomposé en plusieurs ''classes'' selon le conduit LSP considéré: 1) pas de traitement des paquets CV. Par conséquent, pas de traitement des dérangements, pas de mesure de disponibilité et pas de mesure de la qualité de service; 2) un contrôle simple de l'arrivée des paquets CV afin de détecter un type de fonction inattendu (par exemple FEC_CV) sans examen de l'identificateur TTSI (bien que l'on suppose que l'identificateur TTSI continue à être généré). Ce mécanisme ne permet pas d'assurer une vérification de connectivité totalement fiable puisqu'il ne permet pas de détecter certains dérangements et n'offre qu'une détection partielle des dérangements d-mismerge/d-mismatch; 3) un contrôle très simple de l'arrivée des paquets CV comportant un identificateur TTSI inattendu ou un type de fonction inattendu (FEC-CV). Il pourrait être appliqué aux conduits LSP moins importants en tant que méthode simple de détection de fuite de trafic depuis des conduits LSP importants (vers des conduits LSP moins importants). Toutefois, il se pourrait qu'aucun autre traitement des dérangements ne soit appliqué (par exemple dlocv) et qu'aucune mesure de disponibilité ne soit faite; 4) un traitement complet des dérangements mais pas de mesure de disponibilité. Il est à noter que si aucune mesure de disponibilité n'est faite, les mesures de la qualité de service sont également strictement impossibles (étant donné que celles-ci ne devraient être faites que lorsque les conduits LSP sont dans l'état disponible); 5) un traitement complet des dérangements et des mesures de disponibilité (qui permet alors de procéder également à des mesures de la qualité de service). De la même façon, le traitement par le puits des paquets FEC-CV pourrait être décomposé en plusieurs ''classes'' selon le conduit LSP considéré: 1) pas de traitement des paquets FEC-CV. Par conséquent, pas de traitement des dérangements, pas de mesure de disponibilité et pas de mesure de la qualité de service; 2) un contrôle simple de l'arrivée des paquets FEC-CV comportant un type de fonction inattendu (CV par exemple) sans examen du filtre FEC ou de l'identificateur TTSI (bien que l'on suppose qu'ils continuent tous deux à être générés). Ce contrôle ne permet pas d'assurer une vérification de connectivité totalement fiable car il ne permet pas de détecter certains dérangements et n'offre qu'une détection partielle des dérangements dmismerge/dmismatch; 3) un contrôle très simple de l'arrivée des paquets FEC-CV comportant un type de fonction inattendu ou un filtre FEC inattendu 1. Ce contrôle pourrait être appliqué aux conduits LSP de protocole LDP en tant que méthode simple de détection de fuite de trafic ou de mauvaise configuration FTN; 1 Il convient de noter que pour les conduits LDP-LSP, l'identificateur TTSI ne constitue une information utile pour l'établissement d'un diagnostic que lorsqu'un dérangement dmismatch/dmismerge a été détecté. 6 Rec. UIT-T Y.1713 (03/2004)

13 4) un traitement complet des dérangements (notamment la vérification du filtre FEC et de l'identificateur TTSI ) mais pas de mesure de disponibilité. Il est à noter que si aucune mesure de disponibilité n'est faite, les mesures de la qualité de service sont également strictement impossibles (étant donné que celles-ci ne devraient être faites que lorsque les conduits LSP sont dans l'état disponible); 5) un traitement complet des dérangements (notamment la vérification du filtre FEC et de l'identificateur TTSI ) et des mesures de disponibilité (qui permet alors de procéder également à des mesures de la qualité de service). 13 Traitement des paquets FEC-CV au niveau des routeurs LSR intermédiaires Les unités PDU FEC-CV sont généralement transmises par les routeurs intermédiaires sans inspection. Les routeurs LSR insérant les paquets FEC-CV peuvent choisir de jouer sur les valeurs de la durée de vie TTL pour limiter le nombre de sauts traversés par une sonde FEC-CV, permettant ainsi aux sondes de terminer leurs parcours au niveau de routeurs intermédiaires. Lorsqu'une sonde FEC-CV achève son parcours au niveau d'un routeur intermédiaire LSR en raison de l'expiration de la condition TTL et qu'elle est associée à un conduit LSP valable, le routeur LSR vérifiera uniquement la validité des conditions de dérangement dfecfilter_mismerge ou dfecfilter_mismatch. Lorsqu'un dérangement est détecté au niveau d'un routeur intermédiaire, on considère que l'état de dérangement ne s'applique qu'à la partie du conduit LSP qui se trouve en amont du routeur LSR, ce qui devrait se traduire par la suppression du trafic associé à une entrée particulière du tableau d'étiquettes entrantes (ILM, incoming label map). Lorsqu'il n'y a pas de tableau d'étiquettes entrantes pour le conduit (absence de tableau ILM), le système de gestion est notifié et l'identificateur TTSI peut être conservé en tant qu'aide au diagnostic, mais aucune autre action résultante n'est possible. 14 Règles communes de codage Une entrée de filtre est une représentation via le filtre d'un seul élément d'information. Elle est spécifiée comme étant un nombre de décalages de filtre propre à l'application considérée et qui correspond à des bits particuliers du filtre FEC. Un décalage de filtre est exprimé par valeurs comprises entre 0 et 127. Chaque décalage de filtre représente un seul bit dans le filtre FEC à 16 octets. Les 4 premiers bits du décalage expriment un décalage en octets par rapport au premier octet du filtre, et les 3 derniers bits expriment un décalage en bits dans l'octet, 0 se référant au bit de plus faible poids et 7 au bit de plus fort poids. Un filtre est initialement mis à zéro, et on applique une opération OU entre le bit correspondant à chaque décalage de filtre et le filtre. Codage généralisé Les règles de codage sont principalement fondées sur le nombre maximal d'entrées de filtre que le filtre devrait pouvoir accepter pour une application donnée. Les décalages de filtre sont générés à partir du contrôle de redondance cyclique (CRC, cyclic redundancy check) sur 32 bits CRC-32. Des règles généralisées sont fournies pour la génération de 2, 3, 4 ou 5 décalages de filtre à partir de la séquence CRC-32. Les règles de codage sont (généralement) conçues pour conserver la distance de Hamming du contrôle CRC via l'inclusion de la plus grande partie des informations. Bien qu'elle ne soit pas utilisée dans la présente Recommandation, la spécification de deux ou cinq décalages est mentionnée pour des applications susceptibles de nécessiter soit: 1) plus de 16 entrées de filtre par conduit LSP (deux décalages de filtre) 2) une entrée de filtre par conduit LSP (cinq décalages de filtre) Rec. UIT-T Y.1713 (03/2004) 7

14 Deux décalages Deux décalages de filtre sont générés en effectuant une opération XOR (OU EXCLUSIF) associant les sept derniers bits des paires d'octets de plus fort poids et de plus faible poids. Figure 2/Y.1713 Génération de 2 décalages de filtre à partir de la séquence CRC-32 Trois décalages Trois décalages de filtre sont générés en segmentant la séquence de contrôle CRC-32 en trois entités de 10 bits, puis en associant respectivement par opération XOR les 7 e, 8 e et 9 e bits aux 4 e, 5 e et 6 e bits. Figure 3/Y.1713 Génération de 3 décalages de filtre à partir de la séquence CRC-32 Quatre décalages de filtre Quatre décalages de filtre sont générés en prenant les 7 derniers bits de chaque octet de la séquence CRC-32 et en associant par une opération XOR le 8 e bit de chaque octet au 7 e CRC-32 XOR XOR XOR XOR Y.1713_F04 Figure 4/Y.1713 Génération de 4 décalages de filtre à partir de la séquence CRC-32 8 Rec. UIT-T Y.1713 (03/2004)

15 Cinq décalages de filtre Cinq décalages de filtre sont générés en segmentant la séquence CRC-32 en quatre décalages de 7 bits et en utilisant les 4 derniers bits restant pour former les 4 bits de plus faible poids du 5 e décalage. La séquence CRC-32 est ensuite segmentée en entités de 9 bits sur lesquelles sont réalisées des calculs de parité dont les résultats sont placés dans les trois bits premiers du 5 e décalage. Parité Parité Parité 31 0 CRC Y.1713_F05 Figure 5/Y.1713 Génération de 5 décalages de filtre à partir de la séquence CRC Traitement de sortie Le traitement de sortie se rapporte à l'un des deux cas suivants. 1) sous-ensemble "raisonnable" La sortie effectuera une opération AND (ET logique) entre le filtre d'entrée reçu et l'inverse logique du filtre de sortie. Un résultat non nul indique un dérangement de type dfecfilter_mismatch ou dfecfilter_mismerge. Si elle a extrait un élément FEC, la sortie peut accepter une non-concordance pendant une durée non spécifiée, et PEUT conserver un deuxième filtre comprenant l'ensemble cumulatif des éléments FEC destinés au conduit LSP. Si l'addition logique du filtre reçu et de l'inverse logique du filtre cumulatif conduit à un résultat non nul, cela signifie que la non-concordance n'est pas liée à l'extraction de l'élément FEC et que l'état de dérangement dfecfilter_mismerge/dfecfilter_mismatch peut être immédiatement déclaré. Rec. UIT-T Y.1713 (03/2004) 9

16 2) Correspondance exacte Figure 6/Y.1713 Filtrage par "sous-ensemble raisonnable " La sortie comparera directement le filtre d'entrée reçu au filtre de sortie. Un résultat non nul indique un dérangement dfecfilter_mismatch/dfecfilter ou qu'une modification récente n'a pas été transmise à l'entrée. Si elle a modifié le filtre FEC, la sortie peut tolérer une non-concordance pendant une durée non spécifiée. Elle PEUT poursuivre le test du filtre pour déterminer si le filtre d'entrée est un sous-ensemble du filtre de sortie en cours d'utilisation ou du filtre de sortie cumulatif afin d'estimer plus rapidement s'il s'agit véritablement d'une non-concordance ou simplement d'un artefact d'hystérésis dans le plan de commande. La sortie indique que la non-concordance n'est pas liée à l'extraction de l'élément FEC et que l'état de dérangement dfecfilter_mismerge/mismatch peut être immédiatement déclaré. 10 Rec. UIT-T Y.1713 (03/2004)

17 Figure 7/Y.1713 Filtrage par "correspondance exacte " 16 Règles de codage et de traitement applicables aux conduits LSP de type RFC 3036 (LDP) Règles de codage en entrée Chaque élément FEC (codé conformément à la section de la norme RFC 3036 [5]) instantié dans le tableau FTN pour le conduit LSP est codé pour former une entrée de filtre comprenant trois décalages de filtre. Figure 8/Y.1713 Entrée de filtre pour les conduits LSP de type RFC 3036 Règles de codage en sortie Chaque élément FEC (codé conformément à la section de la norme RFC 3036 [5]) proposé aux homologues LDP du conduit LSP est codé pour former une entrée de filtre comprenant trois décalages de filtre. Traitement en sortie La sortie réalisera un filtrage de type "sous-ensemble raisonnable". Rec. UIT-T Y.1713 (03/2004) 11

18 Limites Sur la base de ces règles de codage, une limite supérieure de 10 éléments FEC est requise dans un filtre FEC pour garantir avec une probabilité strictement supérieure à 99% la détection de tous les dérangements dus à un branchement incorrect dans un réseau prenant en charge l'ensemble des applications décrites dans la présente Recommandation. Lignes directrices relatives à l'insertion Dans un réseau LDP, un routeur LSR peut disposer de plusieurs conduits associés à une classe FEC donnée et certains d'entre eux peuvent ne pas être utilisés à un moment donné car ce sont des entrées vers des conduits non optimaux. On parlera alors de "rétention libérale d'étiquette". La présente Recommandation préconise comme seule spécification relative à l'insertion de paquets FEC-CV qu'au minimum celle-ci soit réalisée sur les entrées LSP en cours d'utilisation. S'il faut mesurer la connectivité et vérifier la disponibilité de route (voir l'appendice II), la génération de paquets FEC-CV ne devrait être permise qu'en présence d'une route valable pour la classe FEC. Le routeur LSR peut être configuré de sorte à insérer des paquets FEC-CV dans tous les conduits afin de tirer pleinement parti de l'ensemble des conduits de secours possibles. Accroître le nombre de points d'entrée injectant des paquets FEC-CV dans le réseau permettrait de diminuer la valeur T FEC-CV, puisque les points de fusion en aval devraient continuer à "concentrer" la fréquence d'arrivée des paquets au niveau des points de sortie FEC. 17 Règles de codage et de traitement applicables aux conduits LSP de type RFC 3209 (RSVP-TE) Règles de codage en entrée L'entité de bord fournisseur (PE, provider edge) d'entrée code l'identificateur de tunnel et l'identificateur du tunnel élargi extraits de l'objet session (section de la norme RFC 3209 [6]) pour former une entrée de filtre, et l'identificateur de conduit LSP extrait de l'objet gabarit d'expéditeur (sender template) (section de la norme RFC 3209) pour former une autre entrée de filtre. Ces deux entrées de filtre sont composées chacune de quatre décalages de filtre. Si l'identificateur de tunnel élargi est nul, l'adresse expéditeur de tunnel de l'objet gabarit d'expéditeur doit être remplacée. Au cours des procédures de réacheminement et d'accroissement de la largeur de bande (section de la norme RFC 3209), le filtre utilisé contient l'entrée de filtre identificateur de tunnel/identificateur de tunnel élargi et l'entrée de filtre de l'ancien identificateur de conduit LSP jusqu'à réception du message RESV confirmant la réception du conduit à l'aide du nouvel identificateur de conduit LSP. L'entrée modifie alors le filtre pour que celui-ci contienne l'entrée de filtre identificateur de tunnel/identificateur de tunnel élargi ainsi que l'entrée de filtre du nouvel identificateur de conduit LSP. Figure 9/Y.1713 Entrées de filtre pour les conduits de type RFC Rec. UIT-T Y.1713 (03/2004)

19 Règles de codage en sortie L'entité PE de sortie code l'identificateur de tunnel et l'identificateur du tunnel élargi extraits de l'objet session pour former une entrée de filtre, et l'identificateur de conduit LSP extrait de l'objet gabarit d'expéditeur pour former une autre entrée de filtre. Si l'identificateur de tunnel élargi est nul, l'adresse expéditeur tunnel de l'objet gabarit d'expéditeur doit être remplacée. Au cours des procédures de réacheminement et d'accroissement de la largeur de bande (section de la norme RFC 3209) et après réception d'un message de conduit comprenant un nouvel identificateur de conduit LSP, l'ancien et le nouvel identificateurs de conduit LSP seront codés comme des entrées de filtre (tout comme l'identificateur de tunnel et l'identificateur du tunnel élargi), de telle sorte que la modification des identificateurs de conduit LSP au niveau de la sonde d'origine ne se traduise pas par une erreur. Après réception du message Path-tear relatif à l'ancien identificateur LSP, le filtre sera modifié pour ne contenir que le nouvel identificateur LSP pour former une entrée de filtre. Traitement de sortie La sortie effectuera un traitement de type "mise en correspondance exacte" en conditions normales d'exploitation et un traitement de type "sous-ensemble raisonnable" au cours des procédures de réacheminement et d'accroissement de la largeur de bande. Limites Sans objet. Le nombre d'entrées de filtre associé à un conduit LSP de type RFC 3209 est déjà limité. Lignes directrices concernant l'insertion Aucune. 18 Règles de codage et de traitement applicables aux conduits LSP de type RFC 3212 (CR-LDP) Règles de codage applicables aux routeurs LSR d'entrée et de sortie Figure 10/Y.1713 Entrées de filtre pour les conduits de type RFC 3212 L'identificateur de conduit LSP (section 4.5 de la norme RFC 3212 [7]), chaque élément FEC CR_LSP (section 4.10 de la norme RFC 3036) et/ou élément FEC LDP (section de la norme RFC 3036) sont codés pour former une entrée de filtre comprenant trois décalages de filtre. Rec. UIT-T Y.1713 (03/2004) 13

20 Limitations Sur la base de ces règles de codage, une limite supérieure de 10 éléments FEC ainsi que l'élément LSP-ID TLV sont requis dans un filtre FEC pour garantir avec une probabilité strictement supérieure à 99% la détection de tous les dérangements dus à un branchement incorrect dans un réseau prenant en charge l'ensemble des applications décrites dans la présente Recommandation. Lignes directrices relatives à l'insertion Aucune. 19 Spécifications relatives aux polynômes Le contrôle de redondance cyclique CRC à 32 bits utilisé pour générer les entrées de filtre FEC-CV est défini par le polynôme générateur suivant: G(x) 2 = x 32 +x 30 +x 28 +x 21 +x 19 +x 15 +x 12 +x 9 +x 8 +x 4 +x 3 +x 2 +x+1 D'un point de vue mathématique, la séquence de contrôle CRC est définie comme la somme (modulo 2): 1) du reste de la division (modulo 2) entre (x 31 + x x + 1)x k et le polynôme générateur, où k est le nombre de bits associés aux données pour lesquelles le calcul de CRC est effectué; et 2) du reste de la division (modulo 2) par le polynôme générateur du produit des données pour lesquelles le calcul de CRC est effectué (données "interprétées" en tant que polynôme) et de x 32. D'un point de vue algorithmique, la séquence CRC est définie par les procédures suivantes: 1) le complément des 32 premiers bits des données est calculé; 2) les k bits des données sont ensuite considérés comme étant les coefficients d'un polynôme M(x) de degré k-1 écrit suivant le format "big-endian"; 3) M(x) est multiplié par x 32 puis divisé par G(x), ce qui génère un reste R(x) de degré au plus égal à 31; 4) On considère les coefficients de R(x) comme une séquence à 4 octets (soit 32 bits). 20 Critères d'entrée/de sortie et actions résultantes Les critères d'entrée/de sortie de dérangement associés au traitement FEC-CV à l'extrémité proche sont les suivants: Critères d'entrée pour le dérangement dserver Le dérangement dserver n'est pas un état de dérangement valable relevant du traitement FEC-CV pour des niveaux de protocoles de type LDP MPLS. Critères d'entrée pour le dérangement dlocv L'entrée dans la condition de dérangement dlocv entraînant le traitement de dérangement à l'extrémité proche lorsque le processus de disponibilité FEC-CV est activé se produit lorsque aucun paquet FEC-CV attendu correspondant à l'association TTSI/FEC voulue n'est observé par le routeur LSR de sortie pendant une période de trois intervalles T FEC-CV consécutifs. 2 G(x) = (x+1)(x+1)(x 10 +x 8 +x 5 +x 4 +1)(x 10 +x 9 +x 8 +x 3 +x 2 +x+1)(x 10 +x 9 +x 8 +x 6 +x 4 +x 2 +1). G(x) can be conveniently represented by the 33-bit hexadecimal integer F. 14 Rec. UIT-T Y.1713 (03/2004)

21 En termes d'actions résultantes: le code dlocv DT est inséré dans tout paquet OAM FDI envoyé vers l'avant. Critères d'entrée pour le dérangement dttsi_mismatch Le dérangement dttsi_mismatch n'est pas un état de dérangement valable relevant du traitement FEC-CV pour des réseaux de type LDP. Critères d'entrée pour le dérangement dttsi_mismerge Le dérangement dttsi_mismerge n'est pas un état de dérangement valable relevant du traitement FEC-CV dans des réseaux de type LDP. Critères d'entrée pour le dérangement dfecfilter_mismatch L'entrée dans la condition de dérangement dfecfilter_mismatch et donc le passage à l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP se produit lorsqu'on observe au moins un paquet OAM au cours d'une période quelconque de trois intervalles T FEC-CV consécutifs comportant un filtre FEC inattendu ou lorsqu'on observe un paquet OAM de type CV et aucun paquet OAM FEC-CV comportant un filtre FEC attendu au cours de cette même période (autrement dit, occurrence d'un dérangement dlocv). Il convient de noter que le dérangement dfecfilter_mismatch annule et remplace le dérangement dlocv (comme ce serait par exemple le cas pour des conduits LSP commutés). Le code de type de dérangement Hex (0x0205) est inséré dans tout paquet OAM FDI envoyé vers l'avant. La localisation du dérangement DL est également insérée dans ces paquets FDI OAM. Une alarme locale relative à la condition de dérangement est déclenchée et l'identificateur TTSI de la sonde OAM FEC-CV ou CV inattendue est saisi localement (il peut par ailleurs être envoyé facultativement au système NMS par exemple dans le cadre d'un compte rendu d'anomalie). Le signal de trafic aval doit par ailleurs être supprimé. Critères d'entrée pour le dérangement dfecfilter_mismerge L'entrée dans la condition de dérangement dfecfilter_mismerge et donc le passage à l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP se produit lorsqu'on observe au moins un paquet OAM FEC-CV comportant un filtre FEC inattendu ou un paquet OAM de type CV ET que l'on observe au moins un paquet OAM FEC-CV comportant un filtre FEC attendu au cours d'une période quelconque de trois intervalles T FEC-CV consécutifs (autrement dit, pas d'occurrence de dérangement dlocv). Le code de type de dérangement Hex est inséré dans tout paquet OAM FDI envoyé vers l'avant. Le code DL est également inséré dans ces paquets OAM FDI. Une alarme locale relative à la condition de dérangement est déclenchée et l'identificateur TTSI du paquet OAM FEC-CV ou CV inattendu est saisi localement (il peut par ailleurs être envoyé facultativement au système NMS par exemple dans le cadre d'un compte rendu d'anomalie). Le signal de trafic aval pourrait être supprimé. Critères d'entrée pour le dérangement dexcess Le dérangement dexcess n'est pas un état de dérangement valable relevant du traitement FEC-CV dans des réseaux de type MPLS LDP. Critères de sortie pour le dérangement dlocv La sortie de la condition dlocv et donc la sortie de l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP aux fins de disponibilité en extrémité proche en utilisant les paquets FEC-CV se produit: lorsque le nombre de paquets OAM FEC-CV observés comportant chacun un identificateur TTSI attendu est supérieur ou égal à 2 mais inférieur ou égal à 4; lorsque aucun paquet FEC-CV observé ne comporte de filtre FEC ou d'identificateur TTSI inattendu; et Rec. UIT-T Y.1713 (03/2004) 15

22 lorsque aucun paquet OAM CV n'est observé; au cours d'une période quelconque de trois intervalles T FEC-CV consécutifs. Toutes les actions résultantes invoquées lors de l'entrée dans l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP (c'est-à-dire l'envoi de paquets OAM FDI et BDI, le déclenchement d'alarmes locales et la suppression de trafic) sont annulées lors de la sortie de cet état. Critères de sortie pour les dérangements dfecfilter_mismatch et dfecfilter_mismerge La sortie de la condition FECfilter_Mismatch ou dfecfilter_mismerge, et donc la sortie de l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP se produit: lorsque aucun paquet OAM FEC-CV observé ne comporte de filtre FEC inattendu; lorsque aucun paquet OAM CV n'est observé; au cours d'une période quelconque de trois intervalles T FEC-CV consécutifs. Toutes les actions résultantes invoquées lors de l'entrée dans l'état de dérangement à l'extrémité proche puits de chemin de conduit LSP (c'est-à-dire l'envoi de paquets OAM FDI et BDI, le déclenchement d'alarmes locales et la suppression de trafic) sont annulées au moment de la sortie de cet état. 21 Considérations liées à la sécurité La présente Recommandation ne traite d'aucune question de sécurité qui ne soit déjà mentionnée dans le cadre de l'architecture MPLS ou de l'architecture de protocole de couche de réseau figurant dans l'encapsulation. L'architecture MPLS suppose des terminaisons de chemin sécurisées au sein d'une couche donnée, et fournit une hiérarchie arbitraire permettant d'isoler les clients non fiables et de les tenir à l'écart du réseau sécurisé. Ce point est critique en termes de fonctionnalité OAM, lorsque des entrées non sécurisées risquent de tirer parti des mécanismes OAM pour effectuer des attaques de déni de service dans l'infrastructure de réseau. La détection de branchement incorrect améliore la sécurité des réseaux MPLS puisque les manquements à la sécurité dus à l'acheminement erroné des données entre clients peuvent être détectés. Appendice I Règles de codage et de traitement applicables aux conduits LSP de type RFC 2547 (BGP/VPN) I.1 Scénario 1: conduit à étiquettes regroupées Règles de codage pour l'entrée Le routeur PE d'entrée code l'information de prochain saut BGP (border gateway protocol, protocole de passerelle limite), les désignateurs de route RD (route distinguisher) associés au conduit LSP (annonce d'étiquette importée par le protocole BGP). L'adresse de prochain saut VPN-IPv4 et le désignateur de route RD sont concaténés puis encodés pour former une entrée de filtre comprenant cinq décalages de filtre. 16 Rec. UIT-T Y.1713 (03/2004)

23 Administrateur = 0 Numéro assigné = 0 Type RD Administrateur Numéro assigné Prochain saut IPv4 VPN BGP Désignateur de route Entrée de filtre (cinq décalages de filtre) Y.1713.APPX.1_F01 Figure I.1/Y.1713 Entrée de filtre pour étiquettes regroupées RFC 2547 Règles de codage pour la sortie Le routeur PE de sortie code l'information de prochain saut BGP et le désignateur de route associés au conduit LSP (annonce d'étiquette exportée par le protocole BGP) pour former une entrée de filtre comprenant cinq décalages de filtre. Traitement de sortie La sortie effectuera un filtrage de type "correspondance exacte". I.2 Scénario 2: conduits à étiquettes non regroupées Règles de codage pour l'entrée Le routeur PE d'entrée code l'information de prochain saut BGP, les désignateurs de route RD associés au conduit LSP (annonce d'étiquette importée par le protocole BGP) et l'information d'accessibilité à la prochaine couche (NLRI next layer reachability information ou route cliente). L'adresse de prochain saut VPN-IPv4, le désignateur de route RD et l'information NLRI pour la route cliente sont concaténés puis encodés pour former une entrée de filtre comprenant cinq décalages de filtre. Type RD = 0 Numéro assigné = 0 Prochain saut BGP Type RD Administrateur Numéro assigné Longueur Préfixe Prochain saut BGP IPv4VPN Désignateur de route NLRI Entrée de filtre (cinq décalages de filtre) Y.1713.APPX.1_F02 Figure I.2/Y.1713 Entrées de filtre pour étiquettes non regroupées RFC 2547 Règles de codage pour la sortie Le routeur PE de sortie code l'information de prochain saut BGP, le désignateur de route et la route associés au conduit LSP (annonce d'étiquette exportée par le protocole BGP) pour former une entrée de filtre comprenant cinq décalages de filtre. Traitement de sortie La sortie effectuera un filtrage de type "correspondance exacte". NOTE Les mécanismes de mise en cascade de couche VPN (une solution applicable au cas de réseaux VPN entre systèmes autonomes) peuvent ne pas transmettre l'adresse du routeur PE de sortie à l'entrée de couche VPN. Ce point fera l'objet d'études ultérieures. Rec. UIT-T Y.1713 (03/2004) 17