Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM

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

Résumé

L’architecture de commutation d’étiquettes multi protocoles (MPLS, Multiprotocol Label Switching) de la [RFC3031] expose un moyen par lequel les commutateurs en mode de transfert asynchrone (ATM, Asynchronous Transfer Mode) peuvent être utilisés comme routeurs de commutation d’étiquettes (LSR, Label Switching Router). Les commutateurs ATM utilisent des algorithmes d’acheminement de couche réseau (comme celui de l’ouverture du plus court chemin en premier (OSPF, Open Shortest Path First) celui de système intermédiaire à système intermédiaire (IS-IS), etc.) et leur transmission de données se fonde sur les résultats de ces algorithmes d’acheminement. Aucun acheminement ou adressage spécifique d’ATM n’est nécessaire. Les commutateurs ATM utilisés de cette façon sont appelés des LSR ATM.

Le présent document étend et précise les portions pertinentes des [RFC3031] et [RFC3036] en spécifiant plus en détails les procédures à utiliser lors de la distribution des étiquettes entre des LSR ATM, lorsque ces étiquettes représentent des classes d’équivalence de transmission (FEC, Forwarding Equivalence Classe), voir la [RFC3031]) pour lesquelles les chemins sont déterminé bond par bond par les algorithmes d’acheminement de couche réseau.

Le présent document spécifie aussi l’encapsulation MPLS à utiliser lors de l’envoi de paquets étiquetés de ou vers des LSR ATM, et est à cet égard un document d’accompagnement de la [RFC3032].

1. Introduction

L’architecture MPLS [RFC3031] expose la façon dont les commutateurs ATM peuvent être utilisés comme routeurs de commutation d’étiquettes. Les commutateurs ATM utilisent des algorithmes d’acheminement de couche réseau (tels que OSPF, IS-IS, etc.) et leur transmission de données se fonde sur les résultats de ces algorithmes d’acheminement. Aucun acheminement ou adressage spécifique d’ATM n’est nécessaire. Les commutateurs ATM utilisés de cette façon sont appelés des LSR ATM.

Le présent document étend et précise les portions pertinentes des [RFC3031] et [RFC3036] en spécifiant plus en détails les procédures qui sont à utiliser pour distribuer les étiquettes de et vers les LSR ATM, lorsque ces étiquettes représentent des classes d’équivalence de transmission (FEC, Forwarding Equivalence Classes) voir la [RFC3031]) pour lesquelles les chemins sont déterminés bond par bond par les algorithmes d’acheminement de couche réseau. La technique de distribution d’étiquettes décrite ici est appelée dans la [RFC3031] "à la demande vers l’aval". Cette technique de distribution d’étiquettes DOIT être utilisée par les LSR ATM qui ne sont pas capables de "fusion de VC" (définie à la section 3) et est FACULTATIVE pour les LSR ATM qui sont capables de fusion de VC.

Le présent document NE spécifie PAS les techniques de distribution d’étiquettes à utiliser dans les cas suivants :

- les chemins sont choisis explicitement avant le début de la distribution d’étiquettes, au lieu d’être choisis bond par bond comme cela se fait lors de la distribution d’étiquettes,

- les chemins sont destinés à diverger de toutes façons des chemins choisis par l’acheminement bond par bond conventionnel,

- les étiquettes représentent des FEC qui consistent en paquets en diffusion groupée,

- les LSR utilisent la "fusion de VP".

D’autres déclarations faites dans le présent document sur la distribution d’étiquettes par les LSR ATM ne s’appliquent pas nécessairement à ces cas.

Le présent document spécifie aussi l’encapsulation MPLS à utiliser lors de l’envoi de paquets étiquetés de ou vers des LSR ATM, et est à cet égard un document d’accompagnement de la [RFC3032]. L’encapsulation spécifiée est à utiliser aussi pour les paquets étiquetés en diffusion groupée ou à acheminement explicite.

Le présent document utilise la terminologie exposée dans la [RFC3031].

2. Spécification des exigences

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.

3. Définitions

Un routeur de commutation d’étiquettes (LSR) est un appareil qui met en œuvre les composants de contrôle et de transmission de commutation d’étiquettes décrits dans la [RFC3031].

Une interface ATM contrôlée par commutation d’étiquettes (LC-ATM) est une interface ATM contrôlée par le composant de contrôle de commutation d’étiquettes. Lors de la réception d’un paquet qui traverse une telle interface, il est traité comme un paquet étiqueté. L’étiquette de sommet du paquet est déduite du contenu du champ VCI ou du contenu combiné des champs VPI et VCI. Toute paire d’homologues LDP qui sont connectés via une interface LC-ATM va utiliser les négociations de LDP pour déterminer lequel de ces cas est applicable à cette interface.

Un LSR ATM est un LSR avec un certain nombre d’interfaces LC-ATM qui transmettent des cellules entre ces interfaces, en utilisant des étiquettes portées dans le champ VCI ou VPI/VCI, sans ré-assembler les cellules en trames avant la transmission.

Un LSR fondé sur la trame est un LSR qui transmet des trames complètes entre ses interfaces. Noter qu’un tel LSR peut avoir zéro, une ou plusieurs interfaces LC-ATM.

Parfois une seule boîte peut se comporter comme un LSR ATM par rapport à certaines paires d’interfaces, mais peut se comporter comme un LSR fondé sur la trame par rapport à d’autres paires. Par exemple, un commutateur ATM avec une interface ethernet peut fonctionner comme un LSR ATM lors de la transmission de cellules entre ses interfaces LC-ATM, mais peut fonctionner comme un LSR fondé sur la trame lorsque il transmet des trames provenant de son ethernet à une de ses interfaces LC-ATM. Dans de tels cas, on peut considérer les deux fonctions (LSR ATM et LSR fondé sur la trame) comme étant co-résidentes dans une seule boîte.

Il est prévu qu’une interface LC-ATM soit utilisée pour connecter deux LSR ATM, ou pour connecter un LSR ATM à un LSR fondé sur la trame. L’utilisation d’une interface LC-ATM pour connecter deux LSR fondés sur la trame n’est pas prise en compte dans le présent document.

Un domaine de LSR ATM est un ensemble de LSR ATM qui sont mutuellement interconnectés par des interfaces LC-ATM.

L’ensemble bordure d’un domaine de LSR ATM est l’ensemble des LSR fondés sur la trame qui sont connectés aux membres du domaine par des interfaces LC-ATM. Un LSR fondé sur la trame qui est un membre d’un ensemble bordure d’un domaine de LSR ATM peut être appelé un LSR bordure.

La fusion de circuits virtuels est le processus par lequel un commutateur reçoit des cellules sur plusieurs VCI entrants et les transmet sur un seul VCI sortant sans causer l’entrelacement des cellules des différents PDU AAL5.

4. Caractéristiques particulières des commutateurs ATM

Bien que l’architecture MPLS permette une souplesse considérable dans la mise en œuvre de LSR, un LSR ATM est contraint par les capacités (éventuellement pré-existantes) du matériel et des restrictions sur des questions comme le format de cellule imposé par les norme de l’ATM. À cause de ces contraintes, certaines procédures spéciales sont requises pour les LSR ATM.

Certaines des caractéristiques clés des commutateurs ATM qui affectent leur comportement comme LSR sont :

- que la fonction d’échange d’étiquette est effectuée sur les champs (VCI et/ou VPI) dans l’en-tête de la cellule ; cela impose la taille et le placement de la ou des étiquettes dans un paquet ;

- les VC en multipoint à point et en multipoint à multipoint ne sont généralement pas acceptés ; cela signifie que la plupart des commutateurs ne peuvent pas prendre en charge la "fusion de circuits virtuels" comme défini ci-dessus ;

- il n’y a généralement pas de capacité d’effectuer une fonction de diminution de TTL comme celles qui est effectuée sur les en-têtes IP dans les routeurs.

Le présent document décrit les façons d’appliquer la commutation d’étiquettes aux commutateurs ATM qui travaillent avec ces contraintes.

5. Composant de contrôle de commutation d’étiquette pour ATM

Pour prendre en charge la commutation d’étiquettes, un commutateur ATM DOIT mettre en œuvre le composant de contrôle de commutation d’étiquettes. Cela consiste principalement en procédures d’allocation, de distribution, et de maintenance d’étiquettes. Les informations de lien d’étiquettes sont communiquées par plusieurs mécanismes, notamment le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) [RFC3036]. Le présent document impose certaines exigences sur LDP.

Le présent document considère seulement le cas où le composant de contrôle de commutation d’étiquettes utilise les informations apprises directement des protocoles d’acheminement de couche réseau. On présuppose que le commutateur participe comme homologue à ces protocoles (par exemple, OSPF, IS-IS).

Dans certains cas, les LSR font usage d’autres protocoles (par exemple, RSVP, PIM, BGP) pour distribuer les liens d’étiquettes. Dans ce cas, un LSR ATM aura besoin de participer à ces protocoles. Cependant, cela n’est pas explicitement pris en compte dans le présent document.

La prise en charge de la commutation d’étiquettes sur un commutateur ATM N’exige PAS que le commutateur prenne en charge le composant de contrôle ATM défini par l’UIT et le Forum ATM (par exemple, UNI, PNNI). Un LSR ATM peut FACULTATIVEMENT répondre aux cellules OAM.

6. Commutateurs hybrides (vaisseaux dans la nuit)

L’existence du composant de contrôle de commutation d’étiquettes sur un commutateur ATM n’empêche pas la capacité de prendre en charge le composant de contrôle ATM défini par l’UIT et le Forum ATM sur le même commutateur et les mêmes interfaces. Les deux composants de contrôle, de commutation d’étiquettes, et celui défini par l’UIT/ATM Forum, vont fonctionner indépendamment.

La définition de la façon dont un tel appareil fonctionne sort du domaine d’application du présent document. Cependant, seule une petite quantité d’informations a besoin d’être cohérente entre les deux composants de contrôle, comme les portions de l’espace de VPI/VCI qui sont disponibles pour chaque composant.

7. Utilisation des VPI/VCI

La commutation d’étiquettes est accomplie en associant des étiquettes à des classes d’équivalence de transmission, et en utilisant la valeur de l’étiquette pour transmettre les paquets, ce qui inclut de déterminer la valeur de toute étiquette de remplacement. Voir les détails dans la [RFC3031]. Dans un LSR ATM, l’étiquette est portée dans le champ VPI/VCI, ou, quand deux LSR ATM sont connectés via un "chemin virtuel" ATM, dans le champ VCI.

Les paquets étiquetés DOIVENT être transmis en utilisant l’encapsulation nulle, comme défini au paragraphe 6.1 de la [RFC2684].

De plus, si deux homologues LDP sont connectés via une interface LC-ATM, une connexion non MPLS, capable de porter des paquets IP non étiquetés, DOIT être disponible. Cette connexion non MPLS est utilisée pour porter les paquets LDP entre les deux homologues, et PEUT aussi être utilisée (mais il n’est pas obligatoire de l’utiliser) pour d’autres paquets non étiquetés (tels que des paquets OSPF, etc.). L’encapsulation LLC/SNAP de la [RFC2684] DOIT être utilisée sur la connexion non MPLS.

Il DEVRAIT être possible de configurer une interface LC-ATM avec des VPI/VCI supplémentaires qui seront utilisés pour porter des informations de contrôle ou des paquets non étiquetés. Dans ce cas, les valeurs de VCI NE DOIVENT PAS être dans la gamme 0-32. Ces valeurs peuvent utiliser l’encapsulation nulle, comme défini au paragraphe 6.1 de la [RFC2684], ou l’encapsulation LLC/SNAP, comme défini au paragraphe 5.1 de la [RFC2684].

7.1 Connexions directes

On dit que deux LSR sont "directement connectés" sur une interface LC-ATM si toutes les cellules transmises de cette interface par un LSR vont atteindre l’autre, et si il n’y a pas de commutateur ATM entre les deux LSR.

Lorsque deux LSR sont directement connectés via une interface LC-ATM, ils contrôlent conjointement l’allocation des VPI/VCI sur l’interface qui les connecte. Ils peuvent s’accorder pour utiliser le champ VPI/VCI pour coder une seule étiquette.

La valeur de VPI/VCI par défaut pour la connexion non MPLS est VPI 0, VCI 32. D’autres valeurs peuvent être configurées, pour autant que les deux parties connaissent la valeur configurée.

Une valeur de VPI/VCI dont la partie VCI est dans la gamme 0 à 32 inclus NE DOIT PAS être utilisée comme codage d’une étiquette.

À l’exception de ces valeurs réservées, les valeurs de VPI/VCI utilisées dans les deux directions de la liaison PEUVENT être traitées comme des espaces indépendants.

Les gammes admissibles de VCI sont communiquées au moyen de LDP.

7.2 Connexions via un VP ATM

Il peut être utile parfois de traiter deux LSR comme adjacents (dans un certain LSP) à travers une interface LC-ATM, même si la connexion entre eux est faite à travers un "nuage" ATM via un chemin virtuel ATM. Dans ce cas, le champ VPI n’est pas disponible pour MPLS, et l’étiquette DOIT être codée entièrement au sein du champ VCI.

Dans ce cas, la valeur de VCI par défaut de la connexion non MPLS entre les LSR est 32. D’autres valeurs peuvent être configurées, pour autant que les deux parties connaissent la valeur configurée. Le VPI est réglé à ce qui est nécessaire pour utiliser le chemin virtuel.

Une valeur de VPI/VCI dont la partie VCI est dans la gamme 0 à 32 inclus NE DOIT PAS être utilisée comme codage d’une étiquette.

À l’exception de ces valeurs réservées, les valeurs de VPI/VCI utilisées dans les deux directions de la liaison PEUVENT être traitées comme des espaces indépendants.

La gamme admissible des VPI/VCI est communiquée par LDP. Si plus d’un VPI est utilisé pour la commutation d’étiquettes, la gamme admissible des VCI peut être différente pour chaque VPI, et chaque gamme est communiquée au moyen de LDP.

7.3 Connexions via un SVC ATM

Il peut être parfois utile de traiter deux LSR comme adjacents (dans certains LSP) à travers une interface LC-ATM, même si la connexion entre eux est faite à travers un "nuage" ATM via un ensemble de circuits virtuels commutés ATM.

Le présent document ne spécifie pas la procédure pour traiter ce cas. De telles procédures se trouvent dans la [RFC3038]. Les procédures décrites dans la [RFC3038] permettent à un VCID d’être alloué à chacun de ces VC, et de spécifier comment LDP peut être utilisé pour lier un VCID à une FEC. L’étiquette du sommet d’un paquet reçu va alors être déduite (via une transposition biunivoque) du circuit virtuel sur lequel est arrivé le paquet. Il n’y aura pas de valeur de VPI ou de VCI par défaut pour la connexion non MPLS.

8. Procédures de distribution et de maintenance des étiquettes

Le présent document expose l’utilisation de la distribution d’étiquettes "vers l’aval à la demande" (voir la [RFC3031]) par les LSR ATM. Ces procédures de distribution d’étiquettes DOIVENT être utilisées par les LSR ATM qui ne prennent pas en charge la fusion de circuits virtuels, et PEUVENT aussi être utilisées par les LSR ATM qui ne prennent pas en charge la fusion de circuits virtuels. La procédures diffère cependant quelque peu dans les deux cas. On décrira donc tout à tour les deux scénarios. On commence par décrire le comportement des membres de l’ensemble bordure d’un domaine de LSR ATM ; ces "LSR bordures" ne sont pas eux-mêmes des LSR ATM, et leur comportement est le même que le domaine contienne ou non des LSR capables de fusion de circuits virtuels.

8.1 Comportement d’un LSR bordure

Considérons un membre de l’ensemble bordure d’un domaine de LSR ATM. Supposons que, par suite de ses calculs d’acheminement, il choisisse un LSR ATM comme prochain bond d’une certaine FEC, et que le prochain bond soit accessible via une interface LC-ATM. Le LSR bordure utilise LDP pour demander au prochain bond un lien d’étiquette pour cette FEC. Le champ Compte de bonds dans la demande est réglé à 1 (mais voir au paragraphe suivant). Une fois que le LSR bordure a reçu les informations de lien d’étiquette, il peut utiliser les procédures de transmission MPLS pour transmettre les paquets dans la FEC spécifiée, en utilisant l’étiquette spécifiée comme étiquette de sortie. (Ou en utilisant le VPI/VCI qui correspond au VCID spécifié comme étiquette de sortie, si la technique de VCID de la [RFC3038] est utilisée.)

Note : Si le bond précédent du LSR bordure utilise la distribution d’étiquettes vers l’aval à la demande pour demander une étiquette au LSR bordure pour une certaine FEC, et si le LSR bordure ne fusionne pas le LSP provenant de ce bond précédent avec d’autres LSP, et si la demande provenant du bond précédent a un compte de bonds de h, alors le compte de bonds dans la demande produite par le LSR bordure ne devrait pas être réglé à 1, mais plutôt à h+1.

Le lien reçu par le LSR bordure peut contenir un compte de bonds, qui représente le nombre de bonds que va prendre un paquet pour traverser le domaine de LSR ATM quand il utilise cette étiquette. Si il y a un compte de bonds associé au lien, le LSR ATM DEVRAIT ajuster le TTL d’un paquet de données de cette quantité avant de le transmettre. Dans tous les cas, il DOIT ajuster le TTL d’un paquet de données d’au moins un avant de le transmettre. La procédures pour ce faire (dans le cas de paquets IP) est spécifiée à la section 10. La procédure pour encapsuler les paquets est spécifiée à la section 9.

Lorsque un membre de l’ensemble bordure du domaine de LSR ATM reçoit une demande de lien d’étiquette d’un LSR ATM, il alloue une étiquette, et retourne (via LDP) un lien contenant l’étiquette allouée à l’homologue qui a généré la demande. Il règle le compte de bonds dans le lien à 1.

Lorsque un calcul d’acheminement cause le changement du prochain bond d’un LSR bordure pour une certaine FEC, et que l’ancien prochain bond était dans le domaine de LSR ATM, le LSR bordure DEVRAIT notifier à l’ancien prochain bond (via LDP) que le lien d’étiquette associé à la FEC n’est plus nécessaire.

8.2 Commutateurs ATM conventionnels (sans fusion de VC)

Lorsqu’un LSR ATM reçoit (via LDP) une demande de lien d’étiquette pour une certaine FEC de la part d’un homologue connecté au LSR ATM sur une interface LC-ATM, le LSR ATM entreprend les actions suivantes :

- il alloue une étiquette,

- il demande (via LDP) un lien d’étiquette au prochain bond pour cette FEC,

- il retourne (via LDP) un lien contenant l’étiquette entrante allouée à l’homologue qui a généré la demande.

Pour les besoins de cette procédure, on définit une valeur de compte de bonds maximum MAXHOP. MAXHOP a une valeur par défaut de 255, mais peut être configuré à une valeur différente.

Le champ Compte de bonds dans la demande qu’envoie le LSR ATM (au LSR de prochain bond) DOIT être réglé à un de plus que le champ Compte de bonds qui figure dans la demande qu’il a reçue du LSR en amont. Si le compte de bonds résultant excède MAXHOP, la demande NE DOIT PAS être envoyée au prochain bond, et le LSR ATM DOIT notifier au voisin amont que sa demande de lien ne peut pas être satisfaite.

Autrement, une fois que le LSR ATM a reçu le lien du prochain bond, il commence à utiliser cette étiquette.

Le LSR ATM PEUT choisir d’attendre que la demande soit satisfaite par l’aval avant de retourner le lien vers l’amont. C’est une forme de "contrôle ordonné" (comme défini dans la [RFC3031] et la [RFC3036]) en particulier de "contrôle ordonné à l’initiative de l’entrée". Dans ce cas, tant que le LSR ATM reçoit de l’aval un compte de bonds qui est supérieur à 0 et inférieur à MAXHOP, il DOIT incrémenter le compte de bonds qu’il reçoit de l’aval et DOIT inclure le résultat dans le lien qu’il retourne vers l’amont. Cependant, si le compte de bonds excède MAXHOP, un lien d’étiquette NE DOIT PAS être passé en amont. L’homologue LDP amont DOIT plutôt être informé que le lien d’étiquette demandé ne peut pas être satisfait. Si le compte de bonds reçu de l’aval est 0, le compte de bonds passé en amont devrait aussi être 0 ; cela indique que le compte de bonds réel est inconnu.

Autrement, le LSR ATM PEUT retourner le lien en amont sans attendre un lien provenant de l’aval (un contrôle "indépendant", comme défini dans la [RFC3031] et la [RFC3036]). Dans ce cas, il spécifie un compte de bonds de 0 dans le lien, indiquant que le vrai compte de bonds est inconnu. La valeur correcte pour le compte de bonds sera retournée plus tard, comme on le décrit ci-dessous.

Noter qu’un LSR ATM, ou un membre de l’ensemble bordure d’un domaine de LSR ATM, peut recevoir plusieurs demandes de lien pour la même FEC de la part du même LSR ATM. Il DOIT générer un nouveau lien pour chaque demande (en supposant des ressources adéquates pour le faire) et conserver tout lien existant. Pour chaque demande reçue, un LSR ATM DOIT aussi générer une nouvelle demande de lien en direction du prochain bond pour cette FEC.

Lorsque un calcul d’acheminement cause le changement du prochain bond d’un LSR ATM pour une FEC, le LSR ATM DOIT notifier à l’ancien prochain bond (via LDP) que le lien d’étiquette associé à cette FEC n’est plus nécessaire.

Lorsque un LSR reçoit une notification qu’un certain lien d’étiquette n’est plus nécessaire, le LSR PEUT désallouer l’étiquette associée au lien, et détruire le lien. Dans le cas où un LSR ATM reçoit une telle notification et détruit le lien, il DOIT notifier au prochain bond pour la FEC que le lien d’étiquette n’est plus nécessaire. Si un LSR ne détruit pas le lien, il ne peut le réutiliser que si il reçoit une demande pour la même FEC avec le même compte de bonds que la demande qui a causé à l’origine la création du lien.

Quand un chemin change, les liens d’étiquette sont rétablis à partir du point où le chemin diverge du précédent chemin. Les LSR en amont de ce point (à une exception près, indiquée ci-dessous) oublient le changement.

Chaque fois qu’un LSR change son prochain bond pour une certaine FEC, si le prochain bond est accessible via une interface LC-ATM, alors pour chaque étiquette qu’il a lié à cette FEC, et distribué en amont, il DOIT demander un nouveau lien au nouveau prochain bond.

Lorsque un LSR ATM reçoit un lien d’étiquette pour une certaine FEC de la part d’un voisin en aval, il peut avoir déjà fourni un lien d’étiquette correspondant pour cette FEC à un voisin en amont, soit parce qu’il utilise le contrôle indépendant, soit parce que le nouveau lien venant de l’aval est le résultat d’un changement d’acheminement. Dans ce cas, sauf si le compte de bonds est 0, il DOIT extraire le compte de bonds du nouveau lien et l’incrémenter de un. Si le nouveau compte de bonds est différent de celui qu’il avait précédemment convoyé au voisin amont (y compris le cas où le voisin amont avait donné la valeur 'inconnu') le LSR ATM DOIT notifier le changement au voisin amont. Chaque LSR ATM DOIT à son tour incrémenter le compte de bonds et le passer en amont jusqu’à ce qu’il atteigne le LSR bordure d’entrée. Si à un point quelconque la valeur du compte de bonds devient égale à MAXHOP, le LSR ATM DEVRAIT retirer le lien du voisin amont. Un compte de bonds de 0 DOIT être passé inchangé vers l’amont.

Chaque fois qu’un LSR ATM génère une demande de lien d’étiquette à son LSR de prochain bond par suite de la réception d’une demande de lien d’étiquette venant d’un autre LSR (amont) et que la demande au LSR de prochain bond n’est pas satisfaite, le LSR ATM DEVRAIT détruire le lien créé en réponse à la demande reçue, et le notifier au demandeur (via LDP).

Si un LSR ATM reçoit une demande de lien qui contient un compte de bonds qui excède MAXHOP, il DOIT ne pas établir de lien, et il DOIT retourner une erreur au demandeur.

Lorsque un LSR détermine qu’il a perdu sa session LDP avec un autre LSR, les actions suivantes sont entreprises. Toutes les informations de liens apprises via cette connexion DOIVENT être éliminées. Pour tout lien d’étiquette qui a été créé par suite de la réception d’une demande de lien d’étiquette de la part de l’homologue, le LSR PEUT détruire ces liens (et désallouer les étiquettes associées à ces liens).

Un LSR ATM DEVRAIT utiliser "l’horizon partagé" lorsque il satisfait des demandes de lien provenant de ses voisins. C’est-à-dire que si il reçoit une demande de lien pour une certaine FEC et si le LSR qui fait cette demande est, selon ce LSR ATM, le prochain bond pour cette FEC, il ne devrait pas retourner un lien pour ce chemin.

Il est prévu que les LSR ATM sans fusion utilisent généralement le "mode prudent de rétention d’étiquette" [RFC3031].

8.3. Commutateurs ATM à capacité de fusion de VC

Des changements relativement mineurs sont nécessaires pour s’accommoder des LSR ATM qui prennent en charge la fusion de circuits virtuels. La principale différence est que les LSR ATM capables de fusion de circuits virtuels ont seulement besoin d’une étiquette sortante par FEC, même si plusieurs demandes de liens d’étiquettes pour cette FEC sont reçues des voisins en amont.

Lorsque un LSR ATM capable de fusion de circuits virtuels reçoit une demande de lien d’un LSR amont pour une certaine FEC, et qu’il n’a pas déjà un lien d’étiquette sortante pour cette FEC (ou une demande en cours pour un tel lien d’étiquette) il DOIT produire une demande de lien à son prochain bond tout comme il l’aurait fait si il n’était pas capable de fusion. Si, cependant, il a déjà un lien d’étiquette sortante pour cette FEC, il n’a pas besoin de produire une demande de lien vers l’aval. Il peut plutôt simplement allouer une étiquette entrante, et retourner cette étiquette dans un lien au demandeur amont. Lorsque des paquets avec cette étiquette comme étiquette de sommet sont reçus du demandeur, la valeur d’étiquette du sommet sera remplacée par la valeur existante d’étiquette sortante qui correspond à la même FEC.

Si le LSR ATM n’a pas de lien d’étiquette sortante pour la FEC, mais en a une demande en cours, il n’a pas besoin de produire une autre demande.

Lors de l’envoi d’un lien d’étiquette en amont, le compte de bonds associé au lien correspondant qui provient de l’aval DOIT être incrémenté de 1, et le résultat être transmis en amont comme compte de bond associé au nouveau lien. Cependant, il y a deux exceptions : un compte de bonds de 0 DOIT être passé inchangé vers l’amont, et si le compte de bonds est déjà à MAXHOP, le LSR ATM NE DOIT PAS passer de lien en amont, mais DOIT plutôt y envoyer une erreur.

Noter que, tout comme les LSR ATM conventionnels et les membres de l’ensemble bordure du domaine de LSR ATM, un LSR ATM capable de fusion de circuits virtuels DOIT produire un nouveau lien chaque fois qu’il reçoit une demande de l’amont, car il peut y avoir en amont des commutateurs qui ne prennent pas en charge la fusion de circuits virtuels. Cependant, il a seulement besoin de produire une demande de lien correspondante vers l’aval si il n’a pas déjà un lien d’étiquette pour le chemin approprié.

Lorsque un changement dans le tableau d’acheminement d’un LSR ATM capable de fusion de circuits virtuels l’oblige à choisir un nouveau prochain bond pour une de ses FEC, il PEUT facultativement libérer le lien pour ce chemin depuis l’ancien prochain bond. Si il n’a pas déjà un lien correspondant pour le nouveau prochain bond, il doit en demander un. (Le choix entre le mode de rétention d’étiquette prudent et libéral de la [RFC3031] est une option de la mise en œuvre.)

Si un nouveau lien est obtenu, qui contient un compte de bonds qui diffère de celui qui a été reçu dans l’ancien lien, le LSR ATM doit alors prendre le nouveau compte de bonds, l’incrémenter de un, et notifier la nouvelle valeur à tout voisin amont qui a des liens d’étiquettes pour cette FEC. Tout comme avec les LSR ATM conventionnels, cela permet au nouveau compte de bonds d’être propagé jusqu’à l’entrée du domaine de LSR ATM. Si en un point quelconque, le compte de bonds excède MAXHOP, les liens d’étiquette pour ce chemin doivent alors être supprimés de chez tous les voisins amont auxquels le lien a été fourni précédemment. Cela assure que toute boucle causée par des acheminements transitoires sera détectée et cassée.

9. Encapsulation

Les procédures décrites dans cette section n’affectent que les LSR bordures du domaine de LSR ATM. Les LSR ATM eux-mêmes ne modifient en aucune façon l’encapsulation.

Les paquets étiquetés DOIVENT être transmis en utilisant l’encapsulation nulle du paragraphe 6.1 de la [RFC2684].

Excepté dans certaines circonstances spécifiées ci-dessous, lorsque un paquet étiqueté est transmis sur une interface LC-ATM, où le VPI/VCI (ou VCID) est interprété comme l’étiquette du sommet de la pile d’étiquettes, le paquet DOIT aussi contenir un "en-tête de calage" [RFC3032].

Si le paquet a une pile d’étiquettes avec n entrées, il DOIT porter une cale avec n entrées. La valeur réelle de l’étiquette du sommet est codée dans le champ VPI/VCI. La valeur de l’étiquette de l’entrée du sommet dans la cale (qui est juste une entrée "fourre-tout") DOIT être réglée à 0 à l’émission, et DOIT être ignorée à réception. Le TTL sortant du paquet, et son CoS, sont portés respectivement dans les champs TTL et CoS de l’entrée du sommet de la pile dans la cale.

Noter que si un paquet a une pile d’étiquette d’une seule entrée, cela exige qu’il ait une cale d’une seule entrée (quatre octets) même si la valeur réelle de l’étiquette est codée dans le champ VPI/VCI. Cela est fait pour assurer que le paquet a toujours une cale. Autrement, il n’y aurait aucun moyen de déterminer si il en avait une ou non, c’est-à-dire, aucun moyen de déterminer si il y a d’autres entrées de la pile d’étiquettes.

Le seul moyen d’éliminer cette redondance supplémentaire est :

- par une connaissance à priori que les paquets ont seulement une étiquette (par exemple, peut-être que le réseau n’accepte qu’un seul niveau d’étiquette)

- en utilisant deux VC par FEC, un pour les paquets qui n’ont qu’une seule étiquette, et un pour les paquets qui ont plus d’une étiquette.

La seconde technique exigerait qu’il y ait un moyen pour signaler via LDP que le VC ne porte que des paquets à une seule étiquette et ne porte pas de cale. Pour la prise en charge de la fusion de VC, on devrait aussi à veiller à ne pas fusionner un VC sur lequel la cale n’est pas utilisée dans un VC sur lequel elle est utilisée, et vice versa.

Bien que l’une et l’autre de ces techniques soit permise, on doute qu’elles aient quelque utilité pratique. Noter que si l’en-tête de calage n’est pas présent, le TTL sortant est porté dans le champ TTL de l’en-tête de couche réseau.

10. Manipulation du TTL

Les procédures décrites dans la présente section n’affectent que les LSR bordures du domaine de LSR ATM. Les LSR ATM eux-mêmes ne modifient le TTL en aucune façon.

Les détails de la procédure d’ajustement du TTL sont les suivants. Si un paquet a été reçu par le LSR bordure comme paquet non étiqueté, le "TTL entrant" vient de l’en-tête IP. (Les procédures pour les autres protocoles de couche réseau feront l’objet d’études ultérieures.) Si un paquet a été reçu par le LSR bordure comme paquet étiqueté, en utilisant l’encapsulation spécifiée dans la [RFC3032], le "TTL entrant" vient de l’entrée du sommet de la pile d’étiquettes.

Si un compte de bonds a été associé au lien d’étiquette qui est utilisé lorsque le paquet est transmis, le "TTL sortant" est réglé au plus grand de 0 et de la différence entre le TTL entrant et le compte de bonds. Si un compte de bonds n’a pas été associé au lien d’étiquette qui est utilisé lors de la transmission du paquet, le "TTL sortant" est réglé au plus grand de 0 et de un moins le TTL entrant.

Si cela amène le TTL sortant à zéro, le paquet NE DOIT PAS être transmis comme paquet étiqueté en utilisant l’étiquette spécifiée. Le paquet peut être traité d’une des deux façons suivantes :

- comme étant arrivé à expiration ; cela peut causer l’émission d’un message ICMP ;

- être transmis comme paquet non étiqueté, avec un TTL de 1 moins le TTL entrant ; une telle transmission devrait être faite sur une connexion non MPLS.

Bien sûr, si le TTL entrant est 1, seule la première de ces deux options est applicable.

Si le paquet est transmis comme paquet étiqueté, le TTL sortant est porté comme spécifié à la section 9.

Lorsque un LSR bordure reçoit un paquet étiqueté sur une interface LC-ATM, il obtient le TTL entrant de l’entrée du sommet de la pile d’étiquettes de l’encapsulation générique, ou, si cette encapsulation n’est pas présente, de l’en-tête IP.

Si le prochain bond du paquet est un LSR ATM, le TTL sortant est formé en utilisant les procédures décrites dans cette section. Autrement, le TTL sortant est formé en utilisant les procédures décrites dans la [RFC3032].

Les procédures de la présente section sont destinées à s’appliquer aux seuls paquets en envoi individuel.

11. Détection facultative de boucle : distribution des vecteurs de chemin

Chaque LSR ATM DOIT mettre en œuvre, comme option configurable, les procédure suivantes de détection des boucles de transmission. On appelle cela la procédure de détection de boucle par vecteurs de chemins (LDPV, Loop Detection via Path Vectors). Cette procédure n’empêche pas la formation de boucles de transmission, mais assure que toute boucle sera détectée. Si cette option n’est pas activée, les boucles sont détectées par le mécanisme de compte de bonds décrit précédemment. Si cette option est activée, les boucles seront détectées plus rapidement, mais à un coût en redondance plus élevé.

11.1 Quand envoyer les vecteurs de chemin vers l’aval

Supposons qu’un LSR R envoie une demande de lien d’étiquette, pour un certain LSP, à son prochain bond. Si R ne prend pas en charge la fusion de VC, et si R est configuré à utiliser la procédure de LDPV, alors :

- si R envoie la demande parce qu’il est un nœud d’entrée pour ce LSP, ou parce qu’il a acquis un nouveau prochain bond, alors R DOIT inclure un objet Vecteur de chemin avec la demande, et l’objet Vecteur de chemin DOIT contenir seulement la propre adresse de R ;

- si R envoie la demande par suite de la réception d’une demande venant d’un LSR, en amont, alors :

* si la demande reçue a un objet Vecteur de chemin, R DOIT ajouter sa propre adresse à l’objet Vecteur de chemin reçu, et DOIT passer l’objet Vecteur de chemin résultant à son prochain bond ainsi que la demande de lien d’étiquette ;

* si la demande reçue n’a pas d’objet Vecteur de chemin, R DOIT inclure un objet Vecteur de chemin avec la demande qu’il envoie, et l’objet Vecteur de chemin DOIT contenir seulement la propre adresse de R.

Un LSR qui prend en charge la fusion de circuits virtuels NE DEVRAIT PAS inclure d’objet Vecteur de chemin dans les demandes qu’il envoie à son prochain bond.

Si un LSR reçoit une demande de lien d’étiquette dont l’objet Vecteur de chemin contient l’adresse du nœud lui-même, le LSR en conclut que les demandes de liens d’étiquette ont fait une boucle. Le LSR DOIT agir comme il le ferait dans le cas où le compte de bonds excède MAXHOP (voir le paragraphe 8.2).

Cette procédure détecte le cas où les messages de demande font une boucle à travers une séquence de LSR ATM sans fusion.

11.2 Quand envoyer les vecteurs de chemin vers l’amont

Comme spécifié à la section 8, il y a des circonstances dans lesquelles un LSR R doit informer ses voisins amont, via un message de réponse de lien d’étiquette, d’un changement du compte de bonds pour un LSP particulier. Si les conditions suivantes sont toutes satisfaites :

- R est configuré pour la procédure LDPV,

- R prend en charge la fusion de circuits virtuels,

- R n’est pas la sortie de ce LSP, et

- R n’informe pas ses voisins d’une diminution du compte de bonds,

alors R DOIT inclure un objet Vecteur de chemin dans le message de réponse.

Si le changement du compte de bonds résulte de ce que R a été informé par son prochain bond, S, d’un changement du compte de bonds, et si le message de S à R incluait un objet Vecteur de chemin, si les conditions ci-dessus sont satisfaites, R DOIT s’ajouter lui-même à cet objet et passer le résultat en amont. Autrement, si les conditions ci-dessus sont satisfaites, R DOIT créer un nouvel objet avec seulement sa propre adresse.

Si R est configuré pour la procédure LDPV, et si R prend en charge la fusion de VC, il PEUT alors inclure un objet Vecteur de chemin dans tout message de réponse de lien d’étiquette qu’il envoie vers l’amont. En particulier, chaque fois que R reçoit une réponse de lien d’étiquette de son prochain bond, si cette réponse contient un vecteur de chemin, R PEUT (si il est configuré pour la procédure LDPV) envoyer une réponse à ses voisins en amont, contenant l’objet Vecteur de chemin formé en ajoutant sa propre adresse au vecteur de chemin reçu.

Si R ne prend pas en charge la fusion de VC, il NE DEVRAIT PAS envoyer d’objet Vecteur de chemin en amont.

Si un LSR reçoit un message de son prochain bond, avec un objet Vecteur de chemin qui contient sa propre adresse, ce LSR DOIT alors agir comme il l’aurait fait si il avait reçu un message avec un compte de bonds égal à MAXHOP.

Les LSR qui sont configurés pour la procédure de LDPV NE DEVRAIENT PAS mémoriser un vecteur de chemin une fois que l’objet Vecteur de chemin correspondant a été transmis.

Noter que si le domaine de LSR ATM ne comporte que des LSR ATM qui ne font pas la fusion de VC, les vecteurs ne chemin n’ont jamais besoin d’être envoyés en amont car toutes les boucles seront détectées au moyen des vecteurs de chemin qui voyagent vers l’aval.

En n’envoyant les vecteurs de chemin que lorsque le compte de bonds augmente, on évite de les envoyer dans de nombreuses situations où il n’y a pas de boucle. Le prix en est que dans certaines situations où il y a une boucle, le délai de détection de la boucle peut être rallongé.

12. Considérations pour la sécurité

L’encapsulation et les procédures spécifiées dans le présent document n’interfèrent en aucune façon avec l’application de l’authentification et/ou du chiffrement des paquets à la couche réseau (comme l’application de IPsec aux datagrammes IP).

Les procédures décrites dans le présent document ne protègent pas contre l’altération (accidentelle ou malveillante) des étiquettes MPLS. De telles altération pourraient causer de mauvaises transmissions.

Les procédures décrites dans le présent document ne permettent pas à un LSR receveur d’authentifier le LSR émetteur.

Un exposé sur les considérations pour la sécurité applicables au mécanisme de distribution d’étiquettes se trouve dans la [RFC3036].

13. Considérations sur la propriété intellectuelle

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

L’IETF ne prend position sur la validité ou la portée d’aucun droit de propriété intellectuelle ou d’autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou non disponible ; pas plus qu’elle ne prétend qu’elle ait fait aucun effort pour identifier de tels droits. Des informations sur les procédures de l’IETF au sujet des droits dans la documentation en cours de normalisation et en rapport avec les normes peuvent être trouvées dans le BCP-11. Des copies des revendications de droits peuvent être disponibles à la publication et toutes les assurances de licences peuvent être rendues disponibles, ou le résultat de tentatives d’obtention d’une licence ou permission générale pour l’utilisation de tels droits de propriété par les mises en œuvre ou utilisateurs de la présente spécification peuvent être obtenus auprès du secrétariat de l’IETF.

L’IETF invite toute partie intéressée à porter à son attention tous droits de reproduction, brevets ou applications de brevets, ou autres droits de propriété qui pourraient couvrir une technologie qui pourrait être nécessaire pour mettre en pratique la présente norme. Prière d’adresser les information au Directeur Général de l’IETF.

14. Références

[RFC2684] D. Grossman, J. Heinanen, "Encapsulation multiprotocole sur la couche 5 d'adaptation ATM", septembre 1999. (P.S.)

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

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

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

[RFC3038] K. Nagami et autres, "Notification de VCID sur liaison ATM pour LDP", janvier 2001. (P.S.)

15. Remerciements

Des contributions significatives à ce travail ont été faites pas Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood et Dan Tappan. Nous remercions Alex Conta de ses commentaires.

16. Adresse des auteurs

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

Copyright (c) The Internet Society (2001). 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.