Modification de LSP en utilisant le CR-LDP

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 (2002). Tous droits réservés.

Résumé

Le présent document présente une approche pour modifier la bande passante et éventuellement d’autres paramètres d’un chemin de commutation d’étiquettes à acheminement fondé sur la contrainte (CR-LSP, Constraint-based Routed Label Switched Path) établi en utilisant le protocole de distribution d’étiquettes à acheminement fondé sur la contrainte (CR-LDP, Constraint-based Routed Label Distribution Protocol) sans interruption de service. Après l’établissement d’un CR-LSP, sa réservation de bande passante peut avoir besoin d’être changée par l’exploitant du réseau du fait des nouvelles exigences pour le trafic porté sur ce CR-LSP. Le dispositif de modification de LSP peut être pris en charge par CR-LDP en utilisant la valeur modifiée pour le fanion indicateur d’action dans le TLV LSPID. Ce dispositif a des applications dans la gestion dynamique des ressources de réseau lorsque le trafic de différentes priorités et classes de service est impliqué.

1. Conventions de notation

L : LSP (Label Switched Path) Chemin de commutation d’étiquettes

L-id : LSPID (LSP Identifier) Identifiant de chemin de commutation d’étiquette

T : Paramètres de trafic

R : LSR (Label Switching Router) Routeur de commutation d’étiquettes

FEC : (Forwarding Equivalence Class) Classe d’équivalence de transmission

NHLFE : (Next Hop Label Forwarding Entry) Entrée de prochain bond de transmission d’étiquette

FTN : (FEC To NHLFE) Classe d’équivalence de transmission pour entrée de prochain bond de transmission d’étiquette

TLV : Type Longueur Valeur

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

2. Introduction

Considérons un LSP L1 qui a été établi avec son ensemble de paramètres de trafic T0. Une certaine quantité de bande passante est réservée le long du chemin de L1. Considérons alors que certains changements soient nécessaires sur L1. Par exemple, la bande passante de L1 doit être augmentée pour s’accommoder de l’augmentation du trafic sur L1. Ou que l’accord de niveau de service (SLA, service level agreement) associé à L1 a besoin d’être modifié parce qu’on désire une classe de service différente. L’exploitant du réseau aimerait, dans ces cas là, modifier les caractéristiques de L1, par exemple, changer son ensemble de paramètres de trafic de T0 en T1, sans libérer le LSP L1 pour ne pas interrompre le service. Dans certains autres cas, les exploitants de réseaux peuvent vouloir réacheminer un CR-LSP sur un chemin différent soit pour améliorer les performances, soit pour une meilleure utilisation des ressources du réseau. Dans tous ces cas, la modification du LSP est nécessaire. Dans la section 3 ci-dessous est présentée une méthode pour modifier un LSP actif en utilisant CR-LDP. Le concept de LSPID dans le CR-LDP est utilisé pour réaliser la modification du LSP, sans libérer le LSP et sans interruption du service, et sans double réservation de la bande passante. Dans la Section 4 est décrit un exemple pour montrer une application de la méthode présentée en gestion dynamique des exigences de bande passante du réseau sans interruption du service. Dans CR-LDP, un fanion indicateur d’action de _modifier_ est utilisé afin de spécifier explicitement le comportement, et permettre au LSPID existant de prendre en charge à l’avenir d’autres capacités de réseautage. La [RFC3212] spécifie le fanion d’indicateur d’action _modifier_ pour CR-LDP.

3. Modification de LSP en utilisant le CR-LDP

3.1 Procédure de base pour la modification de ressources

La modification de LSP ne peut être admise que quant le LSP est déjà établi et actif. C’est-à-dire que la modification n’est ni définie ni admise durant les phases d’établissement du LSP ou de libération/retrait d’étiquette. Seules les modifications demandées par le LSR d’entrée du LSP sont prises en compte dans le présent document pour le CR-LSP. Le LSR d’entrée ne peut pas modifier un LSP avant l’achèvement d’une précédente procédure de modification.

Supposons que le CR-LSP L1 soit établi avec le LSPID L-id1, qui est unique dans le réseau MPLS. Le LSR d’entrée R1 de L1 a dans son tableau de FTN (FEC pour une NHLFE) la transposition FEC1 –> Étiquette A, où A est l’étiquette sortante pour le LSP L1. Pour modifier les caractéristiques de L1, R1 envoie un message Demande d’étiquette. Dans le message, les TLV auront les nouvelles valeurs demandées, et le TLV LSPID sera inclus en indiquant la valeur de L-id1. Le TLV Paramètres de trafic, le TLV ER, le TLV Classe de ressource (couleur) et le TLV Préemption peuvent avoir des valeurs différentes de celles du message Demande d’étiquette d’origine, qui ont été utilisées pour établir L1 précédemment. Donc, L1 peut être changé dans sa demande de bande passante (TLV Paramètres de trafic) sa classe de service de trafic (TLV Paramètres de trafic) le chemin qu’il traverse (TLV ER) et ses priorités d’établissement et de garde (TLV Préemption). Le LSR d’entrée R1 a maintenant encore l’entrée dans sa FTN comme FEC1 –> Étiquette A. R1 attend pour établir une autre entrée pour FEC1.

Lorsque un LSR Ri le long du chemin de L1 reçoit le message Demande d’étiquette, son comportement est le même que lorsque il reçoit n’importe quel message de demande d’étiquette. La seule extension est que Ri examine le LSPID porté dans le message Demande d’étiquette, L-id1, et identifie si il a déjà L-id1. Si Ri n’a pas L-id1, Ri se comporte de la même façon que lorsque il reçoit un nouveau message Demande d’étiquette. Si Ri a déjà L-id1, il prend le TLV Paramètres de trafic nouvellement reçu et calcule la nouvelle bande passante demandée et en déduit la nouvelle classe de service. En comparant avec la bande passante déjà réservée pour L-id1, Ri réserve maintenant seulement la différence des exigences de bande passante. Cela empêche Ri de faire une double réservation de bande passante. Si une nouvelle classe de service est nécessaire, Ri se prépare aussi à recevoir le trafic sur L1 exactement de la même façon qu’il le traite pour un message Demande d’étiquette, en utilisant peut-être un type de file d’attente différent. Ri alloue une nouvelle étiquette pour le message Demande d’étiquette.

Lorsque le message Transposition d’étiquette est reçu, deux ensembles d’étiquettes existent pour le même LSPID. Le LSR d’entrée R1 va alors avoir deux étiquettes sortantes, A et B, associées à la même FEC, où B est la nouvelle étiquette sortante reçue pour le LSP L1. Le LSR d’entrée R1 peut maintenant activer la nouvelle entrée dans sa FTN, FEC1 –> Étiquette B. Cela signifie que R1 passe le trafic sur L1 sous la nouvelle étiquette _B_ (_nouveau_chemin) pour L1. Les paquets peuvent maintenant être envoyés avec la nouvelle étiquette B, avec le nouvel ensemble de paramètres de trafic, s’il en est, sur un nouveau chemin, c’est-à-dire, si un nouveau chemin est demandé dans le message Demande d’étiquette pour la modification. Tous les autres LSR le long du chemin vont commencer à recevoir les paquets entrants avec la nouvelle étiquette. Pour la nouvelle étiquette entrante, le LSR a déjà établi sa transposition en la nouvelle étiquette sortante. Donc, les paquets seront envoyés avec la nouvelle étiquette sortante. Les LSR n’ont pas à mettre en œuvre de nouvelles procédures pour suivre les nouvelles et les anciennes caractéristiques du LSP.

Le LSR d’entrée R1 commence alors à libérer l’étiquette d’origine A pour le LSP L1. Le message Libération d’étiquette est envoyé par R1 vers les LSR en aval. Le message Libération porte le LSPID de L-id1 et le TLV Étiquette pour indiquer quelle étiquette est à libérer. Le message Libération est propagé au LSR de sortie pour libérer les étiquettes d’origine précédemment utilisées pour L1. À réception du message Libération d’étiquette, le LSR Ri examine le LSPID, le L-id1, et découvre que le L- id1 a encore un autre ensemble d’étiquettes (entrantes/sortantes) sous lui. Donc, la vieille étiquette est libérée sans libérer la ressource utilisée. C’est-à-dire que si la bande passante a été diminuée pour L1, la différence de bande passante est libérée. Autrement, aucune bande passante n’est libérée. Cette procédure de modification peut non seulement être appliquée pour modifier les paramètres de trafic et/ou de classe de service d’un LSP actif, mais aussi pour réacheminer un LSP existant (comme décrit au paragraphe 3.2 ci-dessous) et/ou changer sa priorité d’établissement/garde si désiré. Après la procédure de libération, la modification du LSP est achevée.

La méthode décrite ci-dessus suit le comportement normal de la procédure Demande / Transposition / Notification / Libération / Retrait d’étiquette d’un LSR fonctionnant avec CR-LDP avec une action spécifique entreprise sur un LSPID. Si un message Retrait d’étiquette est utilisé pour supprimer une étiquette associée à un LSPID, le TLV Étiquette devrait être inclus pour spécifier quelle étiquette supprimer. Comme le LSPID peut aussi être utilisé pour la prise en charge d'autres caractéristiques, un fanion indicateur d’action de _modifier_ alloué au LSPID va préciser explicitement l’action/sémantique qui devrait être associée à la procédure d’échange de messages. Les détails de ce fanion sont traités dans le document sur le CR-LDP [RFC3212].

3.2 Réacheminement des LSP

La modification de LSP peut aussi être utilisée pour réacheminer un LSP existant. Seules les modifications demandées par le LSR d’entrée du LSP sont examinées dans le présent document pour les CR-LSP. Le LSR d’entrée ne peut pas modifier un LSP avant que soit achevée une précédente procédure de modification.

Comme au paragraphe précédent, on considère un CR-LSP L1 avec le LSPID L-id1. Pour modifier le chemin du LSP, le LSR d’entrée R1 envoie un message Demande d’étiquette. Dans le message, le TLV LSPID indique L-id1 et le TLV Chemin explicite (ER) est spécifié avec des bonds différents de ceux du chemin explicite spécifié dans le message Demande d’étiquette d’origine. Le fanion d’indication d’action a la valeur _modifier_.

À ce moment, le LSR d’entrée R1 a toujours dans la FTN une entrée de FEC1 –> Étiquette A. R1 attend pour établir une autre entrée pour FEC1.

Lorsque un LSR Ri le long du chemin de L1 reçoit le message Demande d’étiquette, son comportement est le même que lorsque il reçoit un message Demande d’étiquette qui modifie d’autres paramètres du LSP. Ri alloue une nouvelle étiquette au message Demande d’étiquette et transmet le message le long du chemin explicite. Il n’alloue pas plus de ressources que ce qui est décrit au paragraphe 3.1.

À un autre LSR Rj plus loin le long du chemin, le chemin explicite diverge du chemin précédent. Rj agit comme Ri, mais transmet le message Demande d’étiquette le long du nouveau chemin. À partir de ce point, le message Demande d’étiquette est traité comme établissant un nouveau LSP par chaque LSR jusqu’à ce que les chemins convergent à un LSR ultérieur Rk. La valeur _modifier_ du fanion d’indication d’action est ignorée.

À Rk et aux LSR suivants, le message Demande d’étiquette est traité comme à Ri.

Sur le chemin de retour, lorsque le message Transposition d’étiquette est reçu, deux ensembles d’étiquettes existent pour le LSPID lorsque le nouveau chemin coïncide avec l’ancien. Un seul ensemble d’étiquettes va exister aux LSR où les chemins divergent.

Lorsque le message Transposition d’étiquette est reçu au LSR d’entrée R1, il a deux étiquettes sortantes, A et B, associées à la même FEC, où B est la nouvelle étiquette sortante reçue pour le LSP L1. R1 peut maintenant activer la nouvelle entrée dans la FTN, FEC1 –> Étiquette B et désactiver l’ancienne entrée FEC1 –> Étiquette A. Cela signifie que R1 passe le trafic de L1 à la nouvelle étiquette B. Les paquets sont maintenant envoyés avec la nouvelle étiquette B, sur le nouveau chemin.

Le LSR d’entrée R1 commence alors à libérer l’étiquette d’origine A pour le LSP L1. Le message Libération d’étiquette est envoyé par R1 aux LSR vers l’aval en suivant le chemin d’origine. Le message Libération porte le LSPID de L-id1 et le TLV Étiquette pour indiquer quelle étiquette est à libérer. À chaque LSR, l’ancienne étiquette est libérée – aucune autre action n’est nécessaire pour changer le chemin des paquets de données qui sont déjà en train de suivre le nouveau chemin programmé par le message Transposition d’étiquette.

À certains LSR, où les chemins ont divergé, il y a seulement une étiquette pour le LSPID. Par exemple, entre Rj et Rk, le Message Libération d’étiquette va suivre l’ancien chemin. À des LSR entre Rj et Rk seules vont exister les étiquettes provenant du chemin d’origine pour le LSPID L-id1. À ces LSR, le TLV LSPID n’a pas besoin d’être examiné pour délivrer l’étiquette correcte, mais il doit quand même être mis à jour et passé au prochain LSR lorsque le message Libération d’étiquette est propagé. De cette façon, à Rk où les chemins convergent, le LSR aval va savoir quelle étiquette libérer et va pouvoir continuer à transmettre le message Libération d’étiquette le long de l’ancien chemin.

3.3 Traitement des priorités

Lors de l’envoi d’un message Demande d’étiquette pour demander qu’un LSP actif L1 change, la priorité d’établissement utilisée dans le message Demande d’étiquette peut être différente de celle utilisée dans le message Demande d’étiquette précédent, indiquant effectivement la priorité de cette demande de modification. Les exploitants de réseau peuvent utiliser ce dispositif pour décider quelle priorité est à allouer à une demande de modification, sur la base de leurs politiques ou algorithmes, et des autres situations de trafic dans le réseau. Par exemple, la priorité pour une modification peut être déterminée par la priorité du consommateur/LSP. Si un consommateur a excédé de beaucoup trop la bande passante réservée de son tunnel VPN LSP, la priorité de la demande de modification peut recevoir une valeur supérieure. Le message Demande d’étiquette pour la modification d’un LSP actif peut aussi être envoyée avec une priorité de garde différente de la précédente. Cela change effectivement la priorité de garde du LSP. À réception d’un message Demande d’étiquette qui requiert une nouvelle priorité de garde, le LSR affecte une nouvelle priorité de garde à la bande passante. C’est-à-dire que la nouvelle priorité de garde est allouée aux deux étiquettes existantes entrante / sortante et les nouvelles étiquettes à établir pour le LSPID en question. De cette façon, l’auto collision est empêchée.

3.4 Traitement du cas d’échec de modification

Une tentative de modification peut échouer à cause de ressources insuffisantes ou d’autres situations. Un message Notification est renvoyé au LSR d’entrée R1 pour indiquer l’échec du message Demande d’étiquette qui entendait modifier le LSP. Un nouvel essai peut être tenté si désiré par l’exploitant de réseau. Si le LSP sur le chemin d’origine a échoué lorsque une tentative de modification est en cours, la tentative devrait être interrompue en utilisant le message Demande d’interruption d’étiquette comme spécifié dans le document de spécification de LDP [RFC3036].

En cas d’échec de la modification, toutes les modifications au LSP, y compris la priorité de garde, doivent être restaurées à leurs valeurs d’origine.

4. Application de la modification de la bande passante du LSP dans la gestion dynamique de ressource

Dans cette section, on donne un exemple de gestion dynamique des ressources du réseau en utilisant la capacité de modification de la bande passante du LSP. Les détails de cet exemple peuvent être trouvés dans un précédent projet internet [TEQSM]. Supposons que les consommateurs ou services soient alloués à certains CR-LSP. Ces consommateurs/services sont affectés à une des trois priorités : clée, normale ou au mieux. L’exploitant de réseau ne veut faire entrer en collision aucun LSP durant un établissement de LSP, de sorte qu’après l’établissement de ces CR-LSP, leurs priorités de garde sont allouées à la plus haute valeur.

L’exploitant de réseau veut contrôler les ressources sur les liaisons avec les LSR, afin que chaque LSR garde l’état d’usage de ses liaisons. Sur la base de cet historique d’usage, chaque liaison est affectée d’une priorité de seuil en cours Pi, qui signifie que la liaison n’a pas de bande passante disponible pour une demande d’étiquette avec une priorité d’établissement inférieure à Pi. Lorsque la bande passante d’un LSP a besoin d’être modifiée, l’opérateur utilise un algorithme fondé sur la politique pour affecter une priorité à ses demandes de modification, disons Mp pour le LSP L2. Le LSR d’entrée envoie alors un message Demande d’étiquette avec la priorité d’établissement égale à Mp. Si il y a suffisamment de bande passante sur la liaison pour la modification, et si la priorité d’établissement dans le message Demande d’étiquette est d’une priorité supérieure (si Mp est numériquement plus petit) que le seuil Pi de la liaison, le message Demande d’étiquette sera accepté par le LSR. Autrement, le message Demande d’étiquette sera rejeté avec un message Notification qui indiquera que les ressources sont insuffisantes. On devrait noter aussi que lorsque OSPF (ou IS-IS) inonde d’informations la bande passante disponible de la liaison, la bande passante disponible associée à une priorité inférieure à Pi (une valeur numérique supérieure) devrait être interprétée comme _0_.

Cet exemple qui s’appuie sur un seuil de priorité Pi est spécifique de la mise en œuvre, et illustre la souplesse de la procédure de modification pour affecter les priorités et le contrôle des ressources du réseau. Le calcul de Mp peut dépendre du réseau et du service, et se fonde sur la politique d’acheminement de l’opérateur. Par exemple, l’opérateur peut allouer une priorité supérieure (une valeur inférieure de Mp) à la modification de la bande passante de L2 si L2 appartient à un consommateur ou à un service avec la priorité "clée". L’opérateur peut aussi collecter l’usage réel de chaque LSP et affecter une priorité inférieure (un Mp plus élevé) à la modification augmentant la bande passante de L2 si, par exemple, dans la dernière semaine L2 a excédé par deux fois sa bande passante moyenne réservée. De plus, un opérateur peut essayer en vain d’augmenter la bande passante de L2 sur son chemin existant si la bande passante disponible sur L2 est insuffisante. Dans ce cas, l’opérateur veut augmenter la bande passante d’un autre LSP, L3, avec les mêmes LSR d’entrée/sortie que L2, afin d’augmenter l’allocation globale de bande passante d’entrée/sortie. Cependant, dans ce cas, la modification de bande passante de L3 est effectuée avec une priorité inférieure (une valeur de Mp supérieure) car L3 est acheminé sur un chemin secondaire, qui résulte en la priorité supérieure d’allocation de bande passante qui est donnée aux n LSP qui sont sur leur chemin principal [TEQSM].

5. Remerciements

Les auteurs tiennent à remercier Adrian Farrel de sa relecture attentive et de ses commentaires.

6. Considérations de propriété intellectuelle

Il a été notifié à l’IETF des droits de propriété intellectuelle revendiqués à l’égard de tout ou partie de la spécification contenue dans le présent document. Pour plus d’informations, consulter la liste en ligne des revendications de droits.

7. Considérations pour la sécurité

La protection contre la modification des LSP par des agents malveillants doit être contrôlée par le domaine MPLS.

8. Références

[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)

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

[RFC2702] D. Awduche et autres, "Exigences d'ingénierie du trafic sur MPLS", septembre 1999. (Information)

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

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

[RFC3212] B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (P.S.)

[RFC3213] J. Ash et autres, "Déclaration d'applicabilité pour CR-LDP", janvier 2002. (Information)

[RFC3219] J. Rosenberg, H. Salama, M. Squire, "Acheminement téléphonique sur IP (TRIP)", janvier 2002. (P.S.)

[TEQSM] Ash, J., "Traffic Engineering & QoS Methods for IP-, ATM-, & TDM-Based Multiservice Networks", Non publié.

9. Adresse des auteurs

Young Lee

Ceterus Networks

mél : ylee@ceterusnetworks.com

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

Copyright (c) The Internet Society (2002). 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 copyright ci-dessus et le présent et 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, 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.