RFC 4379 - 1. Introduction
1. Introduction
Ce document décrit un mécanisme simple et efficace permettant de détecter les défaillances du plan de données dans les chemins de commutation d'étiquettes (Label Switched Path, LSP) à commutation multiprotocole par étiquette (Multi-Protocol Label Switching, MPLS). Ce document comporte deux parties : les informations transportées dans un "echo request" et un "echo reply" MPLS, et les mécanismes de transport de l'echo reply. La première partie vise à fournir suffisamment d'informations pour vérifier le bon fonctionnement du plan de données, ainsi qu'un mécanisme pour valider le plan de données par rapport au plan de contrôle et, par là même, localiser les défaillances. La seconde partie propose deux méthodes de canaux de réponse fiables pour le message echo request, afin d'obtenir une isolation des défaillances plus robuste.
Une considération importante dans cette conception est que les MPLS echo request suivent le même chemin de données que les paquets MPLS normaux. Les MPLS echo request sont destinés avant tout à valider le plan de données, et secondairement à valider le plan de données par rapport au plan de contrôle. Les mécanismes de vérification du plan de contrôle sont précieux, mais ne sont pas traités dans ce document.
Ce document fait un usage particulier de la plage d'adresses 127/8. Il s'agit d'une exception au comportement défini dans la RFC 1122 [RFC1122] et d'une mise à jour de cette RFC. La motivation de ce changement et les détails de cet usage exceptionnel sont examinés à la section 2.1 ci-dessous.
1.1. Conventions
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" de ce document doivent être interprétés comme décrit dans la RFC 2119 [KEYWORDS].
Le terme "Must Be Zero" (MBZ) est utilisé dans les descriptions d'objets pour les champs réservés. Ces champs MUST être mis à zéro à l'émission et ignorés à la réception.
La terminologie relative aux réseaux privés virtuels (Virtual Private Network, VPN) de niveau L2 et L3 est définie dans [RFC4026].
Comme ce document fait référence au Time to Live (TTL) MPLS bien plus souvent qu'au TTL IP, les auteurs ont choisi la convention d'utiliser "TTL" sans qualificatif pour désigner le "TTL MPLS", et "IP TTL" pour la valeur TTL de l'en-tête IP.
1.2. Structure de ce document (Structure of This Document)
Le corps de ce mémo comporte quatre parties principales : la motivation, le format des paquets MPLS echo request/reply, le fonctionnement du LSP ping et un chemin de retour fiable. Il est suggéré aux lecteurs qui découvrent le sujet de sauter les formats de paquets proprement dits et de lire d'abord la théorie du fonctionnement (Theory of Operation) ; le document est structuré ainsi pour éviter les références en avant.
1.3. Contributeurs (Contributors)
Les personnes suivantes ont apporté des contributions essentielles à tous les aspects de ce document, et une grande partie du contenu est issue des débats et discussions de ce groupe.
- Ronald P. Bonica, Juniper Networks, Inc.
- Dave Cooper, Global Crossing
- Ping Pan, Hammerhead Systems
- Nischal Sheth, Juniper Networks, Inc.
- Sanjay Wadhwa, Juniper Networks, Inc.