Aller au contenu principal

RFC 4379 - Détection des défaillances du plan de données MPLS

  • Statut: Proposed Standard
  • Publié: February 2006
  • Stream: IETF
  • Met à jour: RFC1122
  • Remplacé par: RFC8029
  • Errata: Pas d'errata

Résumé

Ce document décrit un mécanisme simple et efficace qui peut être utilisé pour détecter les défaillances du plan de données dans les chemins commutés par étiquette (LSP) Multi-Protocol Label Switching (MPLS). Il y a deux parties dans ce document : les informations transportées dans une "demande d'écho" (echo request) et une "réponse d'écho" (echo reply) MPLS à des fins de détection et d'isolement des pannes, et des mécanismes pour envoyer la réponse d'écho de manière fiable.

1. Introduction

Ce document décrit un mécanisme de détection des défaillances du plan de données des LSP MPLS.

  1. Informations transportées dans les demandes et réponses d'écho MPLS.
  2. Mécanismes de transport de la réponse d'écho.

Les demandes d'écho MPLS suivent le même chemin de données que les paquets MPLS normaux. Ceci est crucial pour valider le plan de données.

1.1 Conventions

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans le RFC 2119.

1.2 Structure de ce document

Le corps de ce mémo contient quatre parties principales : motivation, format des paquets de demande/réponse d'écho MPLS, fonctionnement du ping LSP et chemin de retour fiable.

2. Motivation

Lorsqu'un LSP ne parvient pas à livrer le trafic utilisateur, la défaillance ne peut pas toujours être détectée par le plan de contrôle MPLS. Il est nécessaire de fournir un outil permettant aux utilisateurs de détecter ces "trous noirs" de trafic ou ces erreurs de routage dans un délai raisonnable.

2.1 Utilisation de la plage d'adresses 127/8

Le ping LSP est conçu comme un outil de diagnostic. Il doit acheminer un paquet de demande d'écho MPLS en se basant uniquement sur sa pile d'étiquettes, sans utiliser l'adresse de destination IP pour une décision de transfert. Pour éviter que les paquets de diagnostic ne soient transférés par IP par erreur, ce document spécifie l'utilisation de la plage d'adresses 127/8.

3. Format des paquets (Packet Format)

Les demandes et réponses d'écho MPLS sont des paquets UDP. Ils doivent être encapsulés dans un paquet UDP avec le port source et le port de destination tous deux fixés à 3503.

 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply Mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TLVs |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1 Codes de retour (Return Codes)

ValueMeaning
0No return code
1Malformed echo request received
2One or more of the TLVs was not understood
3Replying router is an egress for the FEC at stack depth
4Replying router has no mapping for the FEC at stack depth
5Downstream Mapping Mismatch
6Upstream Interface Index Unknown
7Reserved
8Label switched at stack-depth
9Label switched but no MPLS forwarding at stack-depth
10Mapping for this FEC is not the given label at stack-depth
11No label entry at stack-depth
12Protocol not associated with interface at label stack-depth
13Premature termination of ping due to label stack shrinking to a single label

4. Théorie de fonctionnement (Theory of Operation)

4.1 Gestion de l'ECMP

Pour tester un chemin ECMP particulier, l'expéditeur peut faire varier les chemins en modifiant l'adresse de destination IP (dans la plage 127/8).


Note: Cette traduction est fournie à titre de référence. Veuillez consulter le RFC 4379 original pour les détails officiels.