Traitement de la durée de vie (TTL) dans les réseaux de commutation d’étiquette multi protocoles (MPLS)

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2003). Tous droits réservés

Résumé

Le présent document décrit le traitement de la durée de vie (TTL, Time To Live) dans les réseaux à commutation d’étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) hiérarchiques et il est motivé par la nécessité de formaliser un mode de fonctionnement transparent à la TTL pour un chemin de commutation d’étiquettes MPLS. Il met à jour la [RFC3032], "Codage de pile d’étiquettes MPLS". Le traitement de la TTL dans les tunnels hiérarchiques de modèle aussi bien tuyau (pipe) que uniforme est spécifié avec des exemples pour les deux cas "poussé" et "tiré". Le document complète aussi la [RFC3270], "Prise en charge des services différenciés par MPLS" et lie ensemble la terminologie introduite dans ce document avec le traitement de TTL dans les réseaux MPLS hiérarchiques.

Conventions utilisées dans ce document

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119].

1. Introduction et motifs

Le présent document décrit le traitement de Durée de vie (TTL, Time To Live) dans les réseaux MPLS hiérarchiques. On estime que le présent document apporte des détails qui n’ont pas été fournis dans les [RFC3031] et [RFC3032], et que les méthodes présentées dans ce document complètent la [RFC3270].

En particulier, un nouveau mode de fonctionnement (appelé le modèle Pipe) est introduit pour prendre en charge la pratique de la configuration des LSP MPLS de telle façon que les paquets qui transitent par le chemin commuté par étiquettes (LSP, Label Switched Path) voient le tunnel comme un seul bond, sans considération du nombre de routeurs de commutation d’étiquettes (LSR, label switch router) intermédiaires. Le modèle Pipe pour TTL est actuellement utilisé dans plusieurs réseaux et est fourni par plusieurs fabricants comme option configurable par l’opérateur de réseau.

Le présent document formalise le traitement de la TTL dans les réseaux MPLS et le lie à la terminologie introduite dans la [RFC3270].

2. Traitement de la TTL dans les réseaux MPLS

2.1 Changements à la [RFC3032]

a) La [RFC3032] ne couvre que le modèle Uniforme et ne traite PAS le modèle Pipe ni le modèle Short Pipe. Le présent document traite de ces deux modèles et pour être complet traitera aussi du modèle Uniforme.

b) La [RFC3032] ne couvre pas les LSP hiérarchiques. Le présent document traite cette question.

c) La [RFC3032] ne définit pas le traitement de la TTL en présence de saut de l’avant dernier bond (PHP, Penultimate Hop Popping). Le présent document traite cette question.

2.2 Terminologie et fondements

Comme défini dans la [RFC3032], les paquets MPLS utilisent un en-tête de calage MPLS qui indique les informations suivantes sur un paquet :

a) Étiquette MPLS (20 bits)

b) TTL (8 bits)

c) Bas de pile (1 bit)

d) Bits expérimentaux (3 bits)

Les bits expérimentaux ont été redéfinis ultérieurement dans la [RFC3270] pour indiquer le comportement de programmation et de formatage qui pourrait être associé à un paquet MPLS.

La [RFC3270] définissait aussi deux modèles pour le fonctionnement de tunnel MPLS : les modèles Pipe et Uniforme. Dans le modèle Pipe, un réseau MPLS agit comme un circuit lorsque les paquets MPLS traversent le réseau de telle sorte que seuls les points d’entrée et de sortie de LSP soient visibles aux nœuds qui sont en dehors du tunnel. Une variante courte du modèle Pipe est aussi définie dans la [RFC3270] pour différencier les différents traitement de transmission en sortie et de qualité de service. D’un autre côté, le modèle Uniforme rend tous les nœuds que traverse un LSP visibles aux nœuds en dehors du tunnel. On va étendre les modèles Pipe et Uniforme pour inclure le traitement de la TTL dans les paragraphes qui suivent. De plus, le traitement du TTL, lorsque on effectue une PHP, est aussi décrit dans ce document. Pour une description détaillée des modèles Pipe et Uniforme, prière de voir la [RFC3270].

Le traitement de la TTL dans les réseaux MPLS peut être fractionné en deux blocs logiques : (i) la détermination de la TTL entrante pour tenir compte de toute sortie de tunnel due aux opérations Pop MPLS ; (ii) le traitement de paquet des (éventuels) paquets exposés et des TTL sortantes.

On note aussi ici que la signalisation du type de LSP (modèles Pipe, Short Pipe ou Uniforme) sort du domaine d’application du présent document, et qu’elle n’est pas non plus traitée dans les versions actuelles des protocoles de distribution d’étiquettes, par exemple, LDP [RFC3036] et RSVP-TE [RFC3209]. Actuellement, le type de LSP est configuré manuellement par l’opérateur du réseau au moyen soit d’une ligne de commande, soit d’une interface de gestion de réseau.

2.3 Nouvelle terminologie

iTTL : valeur de TTL à utiliser comme TTL entrante. Aucune vérification n’est effectuée sur la iTTL.

oTTL : valeur de TTL utilisée comme valeur de TTL sortante (voir les exceptions au paragraphe 3.5). C’est toujours (iTTL - 1) sauf mention contraire.

Vérification oTTL : vérifie si oTTL est supérieur à 0. Si la vérification oTTL est fausse, le paquet n’est alors pas transmis. Noter que la vérification oTTL n’est effectuée que si tout TTL sortant (IP ou MPLS) est réglé à oTTL (voir les exceptions au paragraphe 3.5).

3. Traitement du TTL dans les différents modèles

Cette section décrit le traitement de la TTL pour les LSP qui se conforment à chacun des trois modèles (Uniforme, Short Pipe et Pipe) en présence/absence de PHP (lorsque applicable).

3.1 Traitement de la TTL pour les LSP de modèle uniforme (avec ou sans PHP)

(cohérent avec la [RFC3032]) :

========== LSP =============================>

+--Troc--(n-2)-...-troc--(n-i)---+

/ (en-tête externe) \

(n-1) (n-i)

/ \

>--(n)--Pousse............(x)..................Saute--(n-i-1)->

(I) (en-tête interne) (E ou P)

(n) représente la valeur de TTL dans l’en-tête correspondant

(x) représente des informations de TTL non significatives

(I) représente le nœud d’entrée du LSP

(P) représente l’avant dernier nœud du LSP

(E) représente le nœud de sortie du LSP

Cette figure montre le traitement de la TTL pour un LSP MPLS de modèle Uniforme. Noter que les TTL interne et externe des paquets sont synchronisés à l’entrée et la sortir du tunnel.

3.2 Traitement de la TTL pour les LSP du modèle Short Pipe

3.2.1 Traitement de la TTL pour les LSP du modèle Short Pipe sans PHP

========== LSP =============================>

+--Troc--(N-1)-...-troc--(N-i)-----+

/ (en-tête externe) \

(N) (N-i)

/ \

>--(n)--Pousse..............(n-1)...................Saute--(n-2)->

(I) (en-tête interne) (E)

(N) représente la valeur de TTL (peut n’avoir pas de relation avec n)

(n) représente la valeur de TTL tunnelée dans l’en-tête encapsulé

(I) représente le nœud d’entrée du LSP

(E) représente le nœud de sortie du LSP

Le modèle Short Pipe a été introduit dans la [RFC3270]. Dans le modèle Short Pipe, le traitement de transmission au LSR de sortie se fonde sur le paquet tunnelé, par opposition au paquet encapsulant.

3.2.2 Traitement de la TTL pour les LSP du modèle Short Pipe avec PHP:

========== LSP =====================================>

+-Troc-(N-1)-...-troc-(N-i)-+

/ (en-tête externe) \

(N) (N-i)

/ \

>--(n)--Pousse...........(n-1)..........Saute-(n-1)-Decr.-(n-2)->

(I) (en-tête interne) (P) (E)

(N) représente la valeur de TTL (peut n’avoir pas de relation avec n).

(n) représente la valeur de TTL tunnelée dans l’en-tête encapsulé.

(I) représente le nœud d’entrée du LSP.

(P) représente l’avant dernier nœud du LSP.

(E) représente le nœud de sortie du LSP.

Comme l’étiquette a déjà été sautée par l’avant dernier nœud du LSP, le nœud de sortie du LSP décrémente juste le TTL d’en-tête.

Noter aussi qu’à la fin du LSP du modèle Short Pipe, le TTL du paquet tunnelé a été décrémenté de deux, avec ou sans PHP.

3.3 Traitement de la TTL pour les LSP du modèle Pipe (seulement sans PHP)

========== LSP =============================>

+--Troc--(N-1)-...-troc--(N-i)-----+

/ (en-tête externe) \

(N) (N-i)

/ \

>--(n)--Pousse..............(n-1)..................Saute--(n-2)->

(I) (en-tête interne) (E)

(N) représente la valeur de TTL (peut n’avoir pas de relation avec n).

(n) représente la valeur de TTL tunnelée dans l’en-tête encapsulé.

(I) représente le nœud d’entrée du LSP.

(E) représente le nœud de sortie du LSP.

Du point de vue de la TTL, le traitement pour un LSP de modèle Pipe est identique au modèle Short Pipe sans PHP.

3.4 Détermination de la TTL entrante (iTTL)

Si le paquet entrant est un paquet IP, la iTTL est alors la valeur de TTL du paquet IP entrant.

Si le paquet entrant est un paquet MPLS et si on effectue un pousse/troc/PHP, la iTTL est alors la TTL de l’étiquette entrante de dessus.

Si le paquet entrant est un paquet MPLS et si on effectue un saut (terminaison de tunnel) la iTTL est fondée sur le type de tunnel (Pipe ou Uniforme) du LSP qui a été sauté. Si l’étiquette sautée appartenait à un LSP de modèle Pipe, la iTTL est alors la valeur du champ TTL de l’en-tête, exposé après que l’étiquette a été sautée (noter que pour les besoins de ce document, l’en-tête exposé peut être soit un en-tête IP, soit une étiquette MPLS). Si l’étiquette sautée appartenait à un LSP de modèle Uniforme, la iTTL est alors égale à la TTL de l’étiquette sautée. Si plusieurs opérations de saut sont effectuées à la suite, la procédure ci-dessus est alors répétée à une exception près : la iTTL calculée durant le saut précédent est utilisée comme TTL des étiquettes qui sont sautées ensuite ; c’est-à-dire que la TTL contenue dans les étiquettes suivantes est essentiellement ignorée et remplacée par la iTTL calculée durant le saut précédent.

3.5 Détermination de la TTL sortante et traitement de paquet

Après que le calcul de la iTTL est réalisé, on effectue la vérification de oTTL. Si la vérification de oTTL réussit, la TTL sortante du paquet (étiqueté/dés-étiqueté) est calculée et les en-têtes de paquet sont mis à jour comme défini ci-dessous.

Si le paquet a été acheminé comme un paquet IP, la valeur de TTL du paquet IP est réglée à oTTL (iTTL - 1). La ou les valeurs de TTL pour toutes les étiquettes poussées est déterminée comme décrit au paragraphe 3.6.

Pour les paquets qui sont acheminés comme MPLS, on a quatre cas :

1) Troc seulement : L’étiquette acheminée est troquée contre une autre étiquette et le champ TTL de l’étiquette sortante est réglé à oTTL.

2) Troc suivi d’un Pousse : l’opération de troc est effectuée comme décrit en (1). La ou les valeurs de TTL de toutes étiquettes poussées sont déterminées comme décrit au paragraphe 3.6.

3) Saut de l’avant dernier bond (PHP, Penultimate Hop Pop) : L’étiquette acheminée est sautée. La vérification d’oTTL devrait être effectuée sans considération de si la oTTL est utilisée pour mettre à jour le champ TTL de l’en-tête sortant. Si l’étiquette sautée par le PHP appartenait à un LSP du modèle Short Pipe, le champ TTL de l’en-tête exposé au PHP n’est alors ni vérifié ni mis à jour. Si l’étiquette sautée par le PHP était un LSP de modèle Uniforme, le champ TTL de l’en-tête exposé au PHP est alors réglé à oTTL. La ou les valeurs de TTL des étiquettes supplémentaires sont déterminées comme décrit au paragraphe 3.6

4) Saut : L’opération de saut se produit avant l’acheminement et n’est donc pas considérée ici.

3.6. Traitement de tunnel entrant (poussé)

Pour chaque étiquette poussée de modèle Uniforme, le TTL est copié de l’étiquette/paquet IP immédiatement en dessous.

Pour chaque étiquette poussée de modèle Pipe ou Short Pipe, le champ TTL est réglé à une valeur configurée par l’opérateur du réseau. Dans la plupart des mises en œuvre, cette valeur est réglée à 255 par défaut.

3.7 Remarques pour la mise en œuvre

1) Bien que iTTL puisse être décrémenté d’une valeur supérieure à 1 alors qu’elle est mise à jour ou que oTTL est en train d’être déterminé, cette caractéristique ne devrait être utilisée que pour compenser les nœuds de réseau qui ne sont pas capables de décrémenter les valeurs de TTL.

2) Chaque fois que iTTL est décrémenté, la mise en œuvre doit s’assurer que la valeur ne devient pas négative.

3) Dans le modèle Short Pipe avec PHP activé, la TTL du paquet tunnelé reste inchangé après l’opération de PHP.

4. Conclusion

Le présent document Internet décrit comment le champ TTL peut être traité dans un réseau MPLS. On précise les diverses méthodes qui sont appliquées en présence de tunnels hiérarchiques et on complète l’intégration des modèles Pipe et Uniforme avec le traitement du TTL.

5. Considérations sur la sécurité

Le présent document n’ajoute aucun nouveau problème de sécurité autre que ceux définis dans les [RFC3031] et [RFC3032]. En particulier, le document ne définit pas un nouveau protocole ni n’en étend un existant et n’introduit pas de problème de sécurité dans les protocoles existants. Les auteurs estiment que cette précision du traitement du TTL dans les réseaux MPLS profite aux fournisseurs de services et à leurs clients car le dépannage set simplifié.

6. Références

6.1 Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

[RFC3032] E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.

[RFC3270] F. Le Faucheur et autres, "Prise en charge des services différenciés par la commutation d'étiquettes multi-protocoles (MPLS)", mai 2002. (P.S.)

6.2 Références pour information

[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)

[RFC3209] D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)

7. Remerciements

Les auteurs tiennent à remercier les membres du groupe de travail MPLS pour leurs réactions. On tient particulièrement à remercier Shahram Davari et Loa Andersson de leur relecture attentive du document et de leurs commentaires.

8. Adresse des auteurs

9. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.