Établissement de LSP fondé sur la contrainte avec 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 spécifie les mécanismes et les TLV (Type/Longueur/Valeur) pour la prise en charge des chemins de commutation d’étiquettes fondés sur la contrainte (CR-LSP, constraint-based Label Switched Path) qui utilisent le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol).

Cette spécification propose un mécanisme d’établissement de bout en bout d’un CR-LSP initié par le routeur de commutation d’étiquettes (LSR, Label Switching Router) d’entrée. Elle spécifie aussi les mécanismes qui donnent le moyen de réserver des ressources en utilisant LDP.

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].

1. Introduction

Le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) est défini dans la [RFC3036] pour la distribution d’étiquettes à l’intérieur d’un domaine MPLS. Un des services les plus importants qui peut être offert en utilisant MPLS en général et LDP en particulier est la prise en charge de l’acheminement fondé sur la contrainte du trafic à travers le réseau d’acheminement. L’acheminement fondé sur la contrainte offre l’opportunité d’étendre les informations utilisées pour établir les chemins au delà de ce qui est disponible pour le protocole d’acheminement. Par exemple, un chemin à distribution d’étiquettes (LSP, Label Switching Path) peut être établi sur la base de contraintes explicites d’acheminement, de contraintes de qualité de service (QS) et d’autres contraintes. L’acheminement fondé sur la contrainte (CR, Constraint-based Routing) est un mécanisme utilisé pour satisfaire aux exigences d’ingénierie du trafic qui ont été proposées par la [RFC3031] et la [RFC2702]. Ces exigences peuvent être satisfaites en étendant LDP à la prise en charge de chemins à commutation d’étiquettes acheminés sur la base de la contrainte (CR-LSP). D’autres utilisations pour les CR-LSP incluent les VPN fondés sur MPLS de la [RFC2764]. D’autres informations sur l’applicabilité des CR-LDP se trouvent dans la [RFC3213].

L’utilité d’un acheminement fondé sur la contrainte (CR, constraint-based routing) dans MPLS a été explorée ailleurs [RFC3031], et [RFC2702]. L’acheminement explicite est un sous ensemble de la fonction plus générale d’acheminement fondé sur la contrainte. À la réunion du groupe de travail MPLS tenue pendant la réunion de décembre 1997 de l’IETF à Washington, il y avait consensus sur l’idée que LDP devrait prendre en charge l’acheminement explicite des LSP avec la fourniture de l’indication de la priorité (de transmission) associée. À la réunion de Chicago (août 1998) la décision a été actée que la prise en charge de l’établissement de chemin explicite dans LDP ferait l’objet d’un document distinct. Le présent document fournit cette prise en charge et il a été accepté comme document de travail à la réunion d’Orlando (décembre 1998).

La présente spécification propose un mécanisme d’établissement de bout en bout de LSP acheminé sur la base de la contrainte (CR-LSP) initié par le LSR d’entrée. Elle spécifie aussi les mécanismes pour fournir des moyens de réservation de ressources utilisant LDP.

Le présent document introduit les TLV et les procédures qui pourvoient à la prise en charge de :

- l’acheminement explicite strict et lâche

- la spécification des paramètres de trafic

- l’épinglage de chemins

- la préemption de CR-LSP par des priorités d’établissement/garde

- du traitement des défaillances

- des LSPID

- des classes de ressources

La Section 2 introduit les diverses contraintes définies dans cette spécification. La Section 3 expose la solution CR-LDP. La Section 4 définit les TLV et les procédures utilisées pour établir les chemins de commutation d’étiquettes acheminés sur la base de la contrainte. L’Appendice A donne plusieurs exemples d’établissement de chemins CR-LSP. L’Appendice B donne des exemples de définitions de service.

2. Généralités sur l’acheminement fondé sur la contrainte

L’acheminement fondé sur la contrainte est un mécanisme qui prend en charge les exigences d’ingénierie du trafic définies dans la [RFC2702]. L’acheminement explicite est un sous ensemble de l’acheminement plus général fondé sur la contrainte où la contrainte est le chemin explicite (ER, explicit route). Les autres contraintes sont définies pour fournir à un exploitant de réseau le contrôle sur le chemin pris par un LSP. La présente section présente les généralités sur les diverses contraintes prises en charge par la présente spécification.

Comme tous les autres LSP, un CR-LSP est un chemin à travers un réseau MPLS. La différence est qu’alors que les autres chemins sont établis sur la seule base des informations contenues dans les tableaux d’acheminement, ou à partir d’un système de gestion, l’acheminement fondé sur la contrainte est calculé à un point de la bordure du réseau sur la base de critères qui incluent les informations d’acheminement mais ne s’y limitent pas. L’intention est que cette fonctionnalité donne les caractéristiques particulières désirées au LSP afin de mieux prendre en charge le trafic envoyé sur le LSP. La raison de l’établissement des CR-LSP peut être qu’on veut allouer une certaine bande passante ou d’autres caractéristiques de classe de service au LSP, ou qu’on veut être sûr que des chemins de remplacement utilisent des chemins physiquement distincts à travers le réseau.

2.1 Chemins explicites stricts et lâches

Un chemin explicite est représenté dans un message Demande d’étiquette par une liste de nœuds ou de groupes de nœuds le long du chemin fondé sur la contrainte. Lorsque le CR-LSP est établi, tous les nœuds ou un sous ensemble des nœuds d’un groupe peuvent être traversés par le LSP. Certaines opérations à effectuer le long du chemin peuvent aussi être codées dans le chemin fondé sur la contrainte.

La capacité de spécifier, en plus des nœuds spécifiés, des groupes de nœuds dont un sous ensemble sera traversé par le CR-LSP, permet au système une latitude locale significative pour satisfaire une demande d’un chemin fondé sur la contrainte. Cela permet à celui qui génère le chemin fondé sur la contrainte d’avoir un certain degré d’imperfection dans les informations sur les détails du chemin.

Le chemin fondé sur la contrainte est codé comme une série de bonds d’ER contenus dans un TLV de chemin fondé sur la contrainte. Chaque bond d’ER peut identifier un groupe de nœuds dans le chemin fondé sur la contrainte. Un chemin fondé sur la contrainte est alors un chemin comportant tous les groupes de nœuds identifiés dans l’ordre dans lequel ils apparaissent dans le TLV.

Pour simplifier l’exposé, on appelle chaque groupe de nœuds un "nœud abstrait". Donc, on peut aussi dire qu’un chemin fondé sur la contrainte est un chemin qui inclut tous les nœuds abstraits, avec les opérations spécifiées qui surviennent le long de ce chemin.

2.2 Caractéristiques du trafic

Les caractéristiques de trafic d’un chemin sont décrites dans le TLV Paramètres de trafic en termes de taux de crête, de taux engagé, et de granularité du service. Les taux, de crête et engagé, décrivent les contraintes de bande passante d’un chemin tandis que la granularité du service peut être utilisée pour spécifier une contrainte sur la variation de délai que le domaine MPLS du CR-LDP peut introduire sur le trafic d’un chemin.

2.3 Préemption

Le CR-LDP signale les ressources exigées par un chemin sur chaque bond de la route. Si une route avec des ressources suffisantes ne peut pas être trouvée, les chemins existants peuvent être réacheminés pour réallouer des ressources au nouveau chemin. C’est le processus de préemption de chemin. Des priorités d’établissement et de garde sont utilisées pour classer les chemins existants (priorité de garde) et le nouveau chemin (priorité d’établissement) pour déterminer si le nouveau chemin peut préempter un chemin existant.

Les attributs setupPriority (priorité d’établissement) d’un nouveau CR-LSP et holdingPriority (priorité de garde) du CR-LSP existant sont utilisés pour spécifier les priorités. Signaler un plus forte priorité de garde exprime que le chemin, une fois qu’il a été établi, devrait avoir une plus faible chance d’être préempté. Signaler une plus forte priorité d’établissement exprime la prévision que, dans le cas d’indisponibilité de ressources, le chemin a plus de chances de préempter d’autres chemins. Les règles exactes qui déterminent la conduite à tenir en cas de collision sont un aspect de la politique du réseau.

L’allocation des valeurs de priorité d’établissement et de garde aux chemins est un aspect de la politique du réseau.

Les valeurs de priorité d’établissement et de garde vont de zéro (0) à sept (7). La valeur zéro (0) est la priorité assignée au chemin le plus important. On l’appelle la plus forte priorité. Sept (7) est la priorité pour le chemin le moins important. L’utilisation de valeurs de priorité par défaut est un aspect de la politique du réseau. La valeur par défaut recommandée est quatre (4).

L’attribut setupPriority d’un CR-LSP ne devrait pas être supérieur (numériquement inférieur) à son holdingPriority car il peut entrer en collision avec un LSP et être percuté par la prochaine demande "équivalente".

2.4 Épinglage de chemin

L’épinglage de chemin est applicable aux segments d’un LSP qui sont à acheminement lâche – c’est-à-dire. les segments qui sont spécifiés avec un prochain bond avec le bit "L" établi ou lorsque le prochain bond est un nœud abstrait. Un CR-LSP peut être établi en utilisant l’épinglage de chemin si il n’est pas souhaité changer le chemin utilisé par un LSP même lorsque un meilleur prochain bond devient disponible sur un LSR le long de la portion à acheminement lâche du LSP.

2.5 Classe de ressource

L’exploitant du réseau peut classer les ressources du réseau de diverses façons. Ces classes sont aussi appelées "couleurs" ou "groupes administratifs". Lorsque un CR-LSP est établi, il est nécessaire d’indiquer quelles classes de ressources le CR-LSP peut en tirer.

3. Vue générale de la solution

La spécification de CR-LSP sur LDP est conçue avec les objectifs suivants :

1. Satisfaire aux exigences exposées dans la [RFC2702] pour effectuer l’ingénierie du trafic et fournir un fondement solide à la réalisation d’un acheminement plus général fondé sur la contrainte.

2. Construire une fonctionnalité déjà spécifiée satisfaisant aux exigences chaque fois que possible. Donc, cette spécification se fonde sur la [RFC3036].

3. Que la solution reste simple.

Dans le présent document est spécifiée la prise en charge des CR-LSP unidirectionnels en point à point. La prise en charge du point à multipoint et du multipoint à point fera l’objet d’études complémentaires.

La prise en charge des LSP de chemin fondé sur la contrainte dans la présente spécification dépend des comportements minimums de LDP suivants, tels que spécifiés dans la [RFC3036] ;

- utilisation des mécanismes de découverte de base et/ou étendue ;

- utilisation du message Demande d’étiquette défini dans la [RFC3036] en mode d’annonce d’étiquette vers l’aval à la demande avec contrôle ordonné ;

- utilisation du message Transposition d’étiquette défini dans la [RFC30361] en mode vers l’aval à la demande avec contrôle ordonné ;

- utilisation du message Notification défini dans la [RFC3036] ;

- utilisation des messages Retrait et Libération définis dans la [RFC3036] ;

- utilisation des mécanismes de détection de boucle (dans le cas de segments à acheminement lâche d’un CR-LSP) définis dans la [RFC3036].

De plus, la fonction suivante est ajoutée à ce qui est défini dans la [RFC3036] :

- Le message Demande d‘étiquette utilisé pour établir un CR-LSP comporte un ou plusieurs CR-TLV décrits à la Section 4. Par exemple, le message Demande d’étiquette peut inclure le TLV ER.

- Un LSR déduit implicitement le contrôle ordonné de l’existence d’un ou plusieurs TLV CR dans le message Demande d’étiquette. Cela signifie que le LSR peut encore être configuré en contrôle indépendant pour les LSP établis par suite d’un acheminement dynamique. Cependant, lorsque un message Demande d’étiquette comporte un ou plusieurs TLV CR, le contrôle ordonné est alors utilisé pour établir le CR-LSP. Noter que ceci est aussi vrai pour les parties à acheminement lâche d’un CR-LSP.

- De nouveaux codes d’état sont définis pour traiter la notification d’erreur pour les défaillances de chemins établis spécifiés dans les TLV CR. Tous les nouveaux codes d’état exigent que le bit F soit établi (à 1).

Les TLV facultatifs DOIVENT être mis en œuvre pour être conformes avec le protocole. Cependant, ils sont facultativement portés dans les messages CR-LDP pour signaler certaines caractéristiques du CR-LSP en cours d’établissement ou de modification.

Des exemples d’établissement de CR-LSP sont donnés à l’Appendice A pour illustrer la façon dont fonctionnent les mécanismes décrits dans le présent document.

3.1 Messages et TLV exigés

Tous les messages, TLV, et procédures non définis explicitement dans le présent document sont définis dans la spécification de LDP [RFC3036]. Le lecteur peut utiliser la [RFC3215] comme document d’information sur les transitions d’état, qui se rapportent aux messages CR-LDP.

Les paragraphes qui suivent font référence à la [RFC3036] et donnent des indications sur les fonctionnalités supplémentaires par rapport à celles définies dans la [RFC3036] lorsque nécessaire.

Noter que l’utilisation du TLV d’état n’est pas limitée aux messages Notification comme spécifié au paragraphe 3.4.6 de la [RFC3036]. Un message autre qu’un message Notification peut porter un TLV d’état comme paramètre facultatif. Lorsque un message autre que Notification porte un TLV d’état, le bit U du TLV d’état devrait être établi à 1 pour indiquer que le receveur devrait éliminer en silence le TLV si il n’est pas prêt à le traiter.

3.2 Message Demande d’étiquette

Le message Demande d’étiquette est défini au paragraphe 3.5.8 de la [RFC3036] avec les modifications suivantes (qui ne sont exigées que si un des TLV CR est inclus dans le message Demande d’étiquette) :

- Le message Demande d’étiquette DOIT inclure un seul élément TLV FEC. L’élément TLV FEC de CR-LSP DEVRAIT être utilisé. Cependant, les autres TLV FEC définis dans la [RFC3036] PEUVENT être utilisés à la place pour certaines applications.

- Le TLV Paramètres facultatifs comporte la définition de tout TLV fondé sur la contrainte spécifié à la Section 4.

- Les procédures pour traiter le message Demande d’étiquette sont augmentées des procédures de traitement des TLV CR définis à la Section 4.

Le codage du message Demande d’étiquette CR-LDP est le suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| Demande d’étiquette (0x0401)| Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV FEC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV LSPID (CR-LDP, obligatoire) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV ER (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Trafic (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Épinglage (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Classe de ressource (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Préemption (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3 Message Transposition d’étiquette

Le message Transposition d’étiquette est défini au paragraphe 3.5.7 de la [RFC3036] avec les modifications suivantes :

- Le message Transposition d’étiquette DOIT inclure un seul TLV Étiquette.

- Les procédures de message Transposition d’étiquette sont limitées au mode contrôle ordonnée vers l’aval à la demande.

Un message Transposition est transmis par un LSR aval à un LSR amont sous l’une des conditions suivantes :

1. Le LSR est l’extrémité de sortie du CR-LSP et une transposition amont a été demandée.

2. Le LSR a reçu une transposition de son LSR amont de prochain bond pour un CR-LSP pour lequel une demande amont est toujours en cours.

Le codage du message Transposition d’étiquette CR-LDP est le suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| Transpo d’étiquette (0x0400)| Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV FEC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV ID de message Demande d’étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV LSPID (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Trafic (CR-LDP, facultatif) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.4 Message Notification

Le message Notification est défini au paragraphe 3.5.1 de la [RFC3036] et le codage du TLV d’état est défini au paragraphe 3.4.6 de la [RFC3036]. L’établissement d’un CR-LSP peut échouer pour diverses raisons. Tous ces échecs sont considérés comme des conditions indicatives et elles sont signalées par le message Notification.

Les messages Notification portent un TLV d’état pour spécifier des événements à signaler. Les nouveaux codes d’état sont définis au paragraphe 4.11 pour signaler les notifications d’erreur associées à l’établissement d’un CR-LSP et le traitement du TLV CR. Tous les nouveaux codes d’état exigent que le bit F soit établi.

Le message Notification PEUT porter le TLV LSPID du CR-LSP correspondant.

Les messages Notification DOIVENT être transmis vers le LSR qui génère la demande d'étiquette à chaque bond et à tout moment où les procédures dans la présente spécification - ou dans la [RFC3036] – spécifient l’envoi d’un message Notification en réponse à un message Demande d’étiquette.

Le codage du message Notification est le suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| Notification (0x0001) | Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| État (TLV) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.5 Messages Libération, Retrait, et Abandon

Les messages Libération d’étiquette, Retrait d’étiquette, et Demande d’abandon d’étiquette sont utilisés comme spécifié dans la [RFC3036]. Ces messages PEUVENT aussi porter le TLV LSPID.

4. Spécification du protocole

Le message Demande d’étiquette défini dans la [RFC3036] DOIT porter le TLV LSPID et PEUT porter un ou plusieurs des TLV facultatifs d’acheminement fondé sur la contrainte (TLV CR) définis dans cette section. Si nécessaire, d’autres contraintes pourront être prises en charge ultérieurement par la définition de nouveaux TLV. Dans la présente spécification sont définis les TLV suivants :

- TLV de chemin explicite (ER)

- TLV de bond de chemin explicite

- TLV de paramètres de trafic

- TLV de préemption

- TLV de LSPID

- TLV d’épinglage de chemin

- TLV Classe de ressource

- TLV de FEC CR-LSP

4.1 TLV de chemin explicite (TLV ER)

Le TLV ER est un objet qui spécifie le chemin à prendre par le LSP qu’on établit. Il est composé de un ou plusieurs TLV de bond de chemin explicite (TLV de bond ER) défini au paragraphe 4.2.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0800 | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV de bond ER 1 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV de bond ER 2 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~ ............ ~

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV de bond ER n |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Champ de quatorze bits qui porte la valeur du TLV ER

Type = 0x0800.

Longueur

Spécifie la longueur du champ valeur en octets.

TLV de bond ER

Un ou plusieurs TLV de bond ER défini au paragraphe 4.2.

4.2 TLV de bond explicite de chemin (TLV de bond ER)

Le contenu d’un TLV ER est une série de TLV de bond ER de longueur variable.

Un nœud qui reçoit un message de demande d’étiquette comportant un type de bond ER qui n’est pas pris en charge NE DOIT PAS propager le message de demande d’étiquette au LSR aval et DOIT renvoyer un message Notification "Pas de chemin".

Chaque TLV de bond ER est de la forme :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| Contenu // |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type de bond ER

Champ de quatorze bits qui porte le type de contenu du bond ER. Les valeurs actuellement définies sont :

Valeur Type

0x0801 préfixe IPv4

0x0802 préfixe IPv6

0x0803 numéro de système autonome

0x0804 LSPID

Longueur

Spécifie la longueur du champ valeur en octets.

Bit L

Le bit L dans le bond ER est un attribut d’un bit. Si le bit L est établi, la valeur de l’attribut est alors "lâche". Autrement, la valeur de l’attribut est "strict". Pour faire court, on dit que si la valeur de l’attribut Bond ER est lâche, c’est alors un "bond ER lâche". Autrement, c’est un "bond ER strict". De plus, on dit que le nœud abstrait d’un bond ER strict ou lâche est, respectivement un nœud strict ou lâche. Les nœuds lâches et stricts sont toujours interprétés par rapport à leurs nœuds abstraits antérieurs. Le chemin entre un nœud strict et son nœud antérieur DOIT ne comporter que des nœuds de réseau provenant du nœud strict et son nœud abstrait antérieur.

Le chemin entre un nœud lâche et son nœud antérieur PEUT inclure d’autres nœuds de réseau, qui ne font pas partie du nœud strict ou de son nœud abstrait antérieur.

Contenu

C’est un champ de longueur variable qui contient un nœud ou un nœud abstrait qui est un des nœuds consécutifs qui constituent le LSP à acheminement explicite.

4.3 TLV de paramètres de trafic

Les paragraphes qui suivent décrivent les paramètres de trafic du CR-LSP. Les caractéristiques exigées d’un CR-LSP sont exprimées par les valeurs des paramètres de trafic.

Un TLV de paramètres de trafic est utilisé pour signaler les valeurs des paramètres de trafic. Les paramètres de trafic sont définis dans les paragraphes qui suivent.

Le TLV Paramètres de trafic contient un champ Fanions, Fréquence, Poids, et les cinq paramètres de trafic PDR, PBS, CDR, CBS, EBS.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0810 | Longueur = 24 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Fanions | Fréquence | Réservé | Poids |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Taux de crête de données (PDR) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Taille de salve de crête (PBS) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Taux de données engagé (CDR) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Taille de salve engagée (CBS) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Excès de taille de salve (EBS) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du type de TLV Paramètres de trafic = 0x0810.

Longueur

Spécifie la longueur du champ Valeur en octets = 24.

Fanions

Le champ Fanions est indiqué ci-dessous.

+--+--+--+--+--+--+--+--+

| Res |F6|F5|F4|F3|F2|F1|

+--+--+--+--+--+--+--+--+

Res - ces bits sont réservés. Zéro à l’émission. Ignoré à réception.

F1 – Correspond à PDR.

F2 – Correspond à PBS.

F3 – Correspond à CDR.

F4 - Correspond à CBS.

F5 - Correspond à EBS.

F6 – Correspond à Poids.

Chaque fanion Fi est un fanion négociable correspondant à un paramètre de trafic. La valeur de fanion négociable zéro note Non négociable et la valeur un note Négociable.

Fréquence

Le champ Fréquence est codé comme un entier non signé de 8 bits avec les codets suivants définis :

0- non spécifié

1- fréquent

2- très fréquent

3-255 - réservé

Réservé - zéro à l’émission, ignoré à réception.

Poids

Entier non signé de 8 bits qui indique le poids du CR-LSP. Les valeurs de poids valides sont de 1 à 255. La valeur 0 signifie que le poids n’est pas applicable à ce CR-LSP.

Paramètres de trafic

Chaque paramètre de trafic est codé comme un nombre de 32 bits à virgule flottante à simple précision de l’IEEE. Une valeur d’infini positif est représentée par un nombre à virgule flottante à simple précision de l’IEEE avec un exposant tout de uns (255) et un signe et une mantisse tout de zéros. Les valeurs PDR et CDR sont en unités d’octets par seconde. Les valeurs PBS, CBS et EBS sont en unités d’octets.

La valeur de PDR DOIT être supérieure ou égale à la valeur de CDR dans un TLV Paramètres de trafic correctement codé.

4.3.1 Sémantique

4.3.1.1 Fréquence

La fréquence spécifie à quelle granularité le CDR alloué au CR-LSP est rendu disponible. La valeur Très fréquent signifie que le taux disponible devrait en moyenne être au moins le CDR mesuré sur tout intervalle de temps égal ou supérieur au plus court temps de paquet au CDR. La valeur Fréquent signifie que le taux disponible devrait en moyenne être au moins celui du CDR lorsque mesuré sur tout intervalle de temps égal ou supérieur au petit nombre de plus courts temps de paquet au CDR.

La valeur Non spécifié signifie que le CDR PEUT être fourni à n’importe quelle granularité.

4.3.1.2 Taux de crête

Le taux de crête définit le taux maximum auquel le trafic DEVRAIT être envoyé au CR-LSP. Le taux de crête est utile pour les besoins d’allocation de ressource. Si l’allocation de ressource au sein du domaine MPLS dépend de la valeur du taux de crête, elle devrait alors être appliquée à l’entrée du domaine MPLS.

Le taux de crête est défini par les deux paramètres de trafic PDR et PBS, voir au paragraphe 4.3.1.5 ci-dessous.

4.3.1.3 Taux engagé

Le taux engagé définit le taux auquel le domaine MPLS s’engage à être disponible pour le CR-LSP.

Le taux engagé est défini par les deux paramètres de trafic CDR et CBS, voir le paragraphe 4.3.1.6 ci-dessous.

4.3.1.4 Excès de taille de salve

L’excès de taille de salve peut être utilisé à la bordure d’un domaine MPLS pour les besoins du conditionnement du trafic. L’EBS PEUT être utilisé pour mesurer de combien le trafic envoyé sur un CR-LSP excède le taux engagé.

Les actions possibles de conditionnement de trafic, comme de passer, marquer ou abandonner, sont spécifiques du domaine MPLS.

L’excès de taille de salve est défini avec le taux engagé, voir le paragraphe 4.3.1.6 ci-dessous.

4.3.1.5 Baquet de jetons de taux de crête

Le taux de crête d’un CR-LSP est spécifié selon un baquet de jetons P avec le taux de jetons PDR et la taille maximum de baquet de jetons PBS.

Le baquet de jetons P est plein au départ (au temps 0), c’est-à-dire que le compte de jetons Tp(0) = PBS. Ensuite, le compte de jetons Tp, si il est inférieur au PBS, est incrémenté de un PDR fois par seconde. Lorsque un paquet de taille B octets arrive à l’instant t, il se passe ce qui suit :

- Si Tp(t)-B ≥ 0, le paquet n’est pas en dépassement du taux de crête et Tp est décrémenté de B jusqu’à la valeur minimum de 0, autrement,

- le paquet est en dépassement du taux de crête et Tp n’est pas décrémenté.

Noter que selon la définition ci-dessus, une valeur d’infini positif de PDR ou de PBS implique que les paquets arrivants ne sont jamais en excès du taux de crête.

La mise en œuvre réelle d’un LSR n’a pas besoin d’être modélisée selon la spécification formelle de baquet de jetons ci-dessus.

4.3.1.6 Baquet de jetons de taux de données engagé

Le taux engagé d’un CR-LSP est spécifié par un baquet de jetons C avec un taux CDR. Le dépassement du taux offert sur le taux engagé PEUT être mesuré par un autre baquet de jetons E, qui opère aussi au taux CDR. La taille maximum du baquet de jetons C est CBS et la taille maximum du baquet de jetons E est EBS.

Les baquets de jetons C et E sont initialement (au temps 0) pleins, c’est-à-dire que le compte de jetons Tc(0) = CBS et que le compte de jetons Te(0) = EBS.

Ensuite, les comptes de jetons Tc et Te sont mis à jour CDR fois par seconde comme suit :

- Si Tc est inférieur à CBS, Tc est incrémenté de un, autrement,

- si Te est inférieur à EBS, Te est incrémenté de un, autrement ni Tc ni Te ne sont incrémentés.

Lorsque un paquet de taille B octets arrive à l’instant t, il se passe ce qui suit :

- Si Tc(t)-B ≥ 0, le paquet n’est pas en excès du taux engagé et Tc est décrémenté de B jusqu’à la valeur minimum de 0, autrement,

- si Te(t)-B ≥ 0, le paquet est en excès du taux de crête mais pas en excès de l’EBS et Te est décrémenté de B jusqu’à la valeur minimum de 0, autrement,

- le paquet est en excès à la fois du taux engagé et de l’EBS et ni Tc ni Te ne sont décrémentés.

Noter que selon la spécification ci-dessus, une valeur de CDR d’infini positif implique que les paquets arrivants ne sont jamais en excès ni du taux engagé ni de l’EBS. Une valeur d’infini positif de CBS ou d’EBS implique que les limites respectives ne peuvent être excédées.

La mise en œuvre réelle d’un LSR n’a pas besoin d’être modélisée selon la spécification formelle ci-dessus.

4.3.1.7 Poids

Le poids détermine la part relative du CR-LSP en éventuelle bande passante excédentaire au dessus du taux engagé. La définition de "part relative" est spécifique du domaine MPLS.

4.3.2 Procédures

4.3.2.1 Message Demande d’étiquette

Si un LSR reçoit un TLV Paramètres de trafic incorrectement codé dans lequel la valeur de PDR est inférieure à la valeur de CDR, il DOIT alors envoyer un message Notification incluant le code d’état "Paramètres de trafic indisponibles" au LSR amont d’où il a reçu le message erroné.

Si un paramètre de trafic est indiqué comme négociable dans le message Demande d’étiquette par le fanion Négociable correspondant, un LSR PEUT alors remplacer la valeur du paramètre de trafic par une plus petite valeur.

Si le poids est indiqué comme négociable dans le message Demande d’étiquette par le fanion Négociable correspondant, un LSR peut alors remplacer la valeur de poids par une valeur inférieure (jusqu’à 0).

Si, après une éventuelle négociation de paramètre de trafic, un LSR peut prendre en charge les paramètres de trafic CR-LSP, le LSR DOIT alors réserver les ressources correspondantes pour le CR-LSP.

Si, après une éventuelle négociation de paramètre de trafic, un LSR ne peut pas prendre en charge les paramètres de trafic CR-LSP, le LSR DOIT alors envoyer un message Notification qui contient le code d’état "Ressource indisponible".

4.3.2.2 Message Transposition d’étiquette

Si un LSR reçoit un TLV Paramètres de trafic incorrectement codé dans lequel la valeur de PDR est inférieure à la valeur de CDR, il DOIT alors envoyer un message Libération d’étiquette contenant le code d’état "Paramètres de trafic indisponible" au LSR d’où il a reçu le message erroné. De plus, le LSP devrait envoyer un message Notification en amont avec le code d’état "Abandon de demande d’étiquette".

Si le fanion Négociation a été établi dans le message de demande d’étiquette, le LSR de sortie DOIT inclure les paramètres de trafic et de poids (éventuellement négociés) dans le message Transposition d’étiquette.

Les paramètres de trafic et de poids dans un message Transposition d’étiquette DOIVENT être transmis inchangés.

Un LSR DEVRAIT ajuster les ressources qu’il a réservé pour un CR-LSP lorsque il reçoit un message Transposition d’étiquette si les paramètres de trafic diffèrent de ceux du message Demande d’étiquette correspondant.

4.3.2.3 Message Notification

Si un LSR reçoit un message Notification pour un CR-LSP, il DEVRAIT libérer toutes les ressources qu’il a éventuellement réservées pour le CR-LSP. De plus, à réception d’un message Notification provenant d’un LSR aval qui est associé à une demande d’étiquette provenant du LSR amont, le LSR local DOIT propager le message Notification en utilisant les procédures de la [RFC3036]. De plus, le bit F DOIT être établi.

4.4 TLV de préemption

La valeur par défaut des priorités d’établissement et de garde devrait être en milieu de gamme (par exemple, 4) afin que cette caractéristique puisse être activée de façon graduelle dans un réseau opérationnel en augmentant ou diminuant la priorité en commençant par le milieu de la gamme.

Comme le TLV Préemption est facultatif, les LSP qui sont établis sans un TLV Préemption explicitement signalé DEVRAIENT être traités comme des LSP avec les priorités d’établissement et de garde par défaut (par exemple, 4).

Lorsque un LSP établi est préempté, le LSR qui initie la préemption envoie un message Retrait en amont et un message Libération en aval.

Lorsque un LSP en cours d’établissement (une demande d’étiquette en cours sans avoir eu en retour une transposition d’étiquette) est préempté, le LSR qui initie la préemption envoie un message Notification en amont et un message Interruption en aval.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0820 | Longueur = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| PrioÉtab | PrioGarde | Réservé |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du TLV Préemption

Type = 0x0820.

Longueur

Spécifie la longueur du champ Valeur en octets = 4.

Réservé

Zéro en émission. Ignoré à réception.

PrioÉtab

Une priorité d’établissement de valeur zéro (0) est la priorité allouée au chemin le plus important. On s’y réfère comme à la plus forte priorité. Sept (7) est la priorité du chemin le moins important. Plus la priorité d’établissement est élevée, plus les chemins de CR-LDP peuvent entrer en collision pour établir le chemin. La valeur par défaut devrait être 4.

PrioGardef

Une priorité de garde de valeur zéro (0) est la priorité allouée au chemin le plus important. On s’y réfère comme à la plus forte priorité. Sept (7) est la priorité pour le chemin le moins important. La valeur par défaut devrait être 4. Plus la priorité de garde est élevée, moins il est probable que le CR-LDP va réallouer sa bande passante à un nouveau chemin.

4.5 TLV LSPID

Le LSPID est un identifiant unique d’un CR-LSP au sein d’un réseau MPLS.

Le LSPID se compose de l’identifiant de routeur du LSR d’entrée (ou d’une des ses propres adresses IPv4) et d’un identifiant de CR-LSP localement unique à ce LSR.

Le LSPID est utile pour la gestion de réseau, pour la réparation de CR-LSP, et pour utiliser un CR-LSP déjà établi comme bond dans un TLV ER.

Un "fanion indicateur d’action" est porté dans le TLV LSPID. Ce "fanion indicateur d’action" indique explicitement l’action qui devrait être entreprise si le LSP existe déjà sur le LSR qui reçoit le message.

Après l’établissement d’un CR-LSP, sa réservation de bande passante peut devoir être changée par le gestionnaire du réseau, du fait des nouvelles exigences pour le trafic porté sur ce CR-LSP. Le "fanion indicateur d’action" est utilisé pour indiquer la nécessité de modifier la bande passante et éventuellement d’autres paramètres d’un CR-LSP établi sans interruption de service. Ce dispositif a des applications dans la gestion dynamique des ressources du réseau lorsque le trafic de différentes priorités et classes de service est impliqué.

La procédure pour le codet "modifier" est définie dans la [RFC3214]. Les procédures pour les autres fanions feront l’objet d’études complémentaires.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0821 | Longueur = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé |ActFan | ID de CR-LSP local |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ID de routeur du LSR d’entrée |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du TLV LSPID.

Type = 0x0821.

Longueur

Spécifie la longueur du champ Valeur en octets = 4.

ActFan

Fanion indicateur d’action : c’est un champ de 4 bits qui indique explicitement l’action qui devrait être entreprise si le LSP existe déjà sur le LSR qui reçoit le message. Un ensemble de codets d’indicateur est proposé ci-dessous :

0000 : indique l’établissement initial du LSP

0001 : indique la modification du LSP

Réservé

Zéro à l’émission. Ignoré à réception.

ID de CR-LSP local

L’ID de LSP local est un identifiant localement unique du CR-LSP au sein du LSR d’entrée qui génère le CR-LSP.

ID de routeur du LSR d’entrée

Un LSR peut utiliser n’importe laquelle de ses propres adresses IPv4 dans ce champ.

4.6 TLC de classe de ressource (couleur)

La classe de ressource telle que définie dans la [RFC2702] est utilisée pour spécifier quelles liaisons sont acceptables par ce CR-LSP. Ces informations permettent d’élaguer la topologie du réseau.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0822 | Longueur = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Classe de ressource |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du TLV Classe de ressource.

Type = 0x0822.

Longueur

Spécifie la longueur du champ Valeur en octets = 4.

Classe de ressource

Le gabarit binaire Classe de ressource qui indique lequel des 32 "groupes administratifs" ou "couleurs" des liaisons que le CR-LSP peut traverser.

4.7 Sémantique de bond ER

4.7.1 Bond ER-1 : préfixe IPv4

Le nœud abstrait représenté par ce bond ER est l’ensemble des nœuds qui ont une adresse IP qui se tient dans ce préfixe. Noter qu’une longueur de préfixe de 32 indique un seul nœud IPv4.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0801 | Longueur = 8 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| Réservé | LongPréf |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse IPv4 (4 octets) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du bond ER-1, Adresse IPv4, Type = 0x0801

Longueur

Spécifie la longueur du champ Valeur en octets = 8.

Bit L

Établi, il indique un bond lâche. À zéro, il indique un bond strict.

Réservé

Zéro en émission. Ignoré à réception.

LongPréf

Longueur du préfixe de 1 à 32.

Adresse Ipv4

Champ de quatre octets qui indique l’adresse IPv4.

4.7.2 Bond ER-2 : adresse IPv6

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| 0x0802 | Longueur = 20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| Réservé | LongPréf |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse IPV6 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse IPV6 (suite) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse IPV6 (suite) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse IPV6 (suite) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du bond ER-2, l’adresse IPv6, Type = 0x0802

Longueur

Spécifie la longueur du champ Valeur en octets = 20.

Bit L

Établi à 1 pour indique un bond lâche. À 0 pour indiquer un bond strict.

Réservé

Zéro en émission. Ignoré à réception.

LongPréf

Longueur du préfixe, de 1 à 128

Adresse IPv6

Adresse d’hôte en envoi individuel de 128 bits.

4.7.3 Bond ER-3 : numéro de système autonome

Le nœud abstrait représenté par ce bond ER est l’ensemble des nœuds appartenant au système autonome.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| 0x0803 | Longueur = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| Réservé | Numéro d’AS |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du bond ER-3, le numéro d’AS, Type = 0x0803

Longueur

Spécifie la longueur du champ Valeur en octets = 4.

Bit L

Établi à 1 pour indique un bond lâche. À 0 pour indiquer un bond strict.

Réservé

Zéro en émission. Ignoré à réception.

Numéro d’AS

Numéro du système autonome.

4.7.4 Bond ER-4 : LSPID

Le LSPID est utilisé pour identifier le point d’entrée de tunnel comme prochain bond dans le ER. Ce bond ER permet d’empiler de nouveaux CR-LSP au sein d’un CR-LSP déjà établi. Il permet aussi de greffer le CR-LSP en cours d’établissement sur un CR-LSP existant.

Si un bond LSPID est le dernier bond ER dans un TLV ER, le LSR peut alors empiler le CR-LSP de la demande d’étiquette entrante sur le CR-LSP qui existe actuellement avec ce LSPID. Ceci est utile, par exemple, au point auquel une demande d’étiquette utilisée pour une réparation locale arrive au prochain bond ER après le segment CR-LSP spécifié comme lâche. L’utilisation du bond LSPID dans ce scénario élimine le besoin que les bonds ER conservent le TLV ER entier restant à chaque LSR qui est à l’extrémité (amont ou aval) d’un segment de CR-LSP spécifié comme lâche au titre de ses informations d’état. Cela est dû au fait que le LSR amont a seulement besoin de garder le prochain bond ER et le LSPID, et que le LSR aval a seulement besoin de garder le LSPID afin que chaque extrémité soit capable de reconnaître que c’est le même LSP qui est identifié.

Si le bond LSPID n’est pas le dernier bond dans un TLV ER, le LSR doit retirer le bond LSPID et transmettre le TLV ER restant dans un message Demande d’étiquette en utilisant une session LDP établie avec le LSR qui est la sortie du CR-LSP spécifié. Ce LSR va continuer de traiter le message Demande d’étiquette du CR-LSP. Le résultat est un CR-LSP tunnelé, ou empilé.

Pour prendre en charge les étiquettes négociées pour les segments CR-LSP tunnelés, une session LDP est exigée par la [RFC3036] entre les points d’extrémité du tunnel – éventuellement en utilisant le CR-LSP existant. L’utilisation de l’existence du CR-LSP au lieu d’une session, ou d’autres approches possibles sans session fera l’objet d’études complémentaires.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| 0x0804 | Longueur = 8 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|L| Réservé | LSPID local |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de routeur du LSR d’entrée |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du bond ER-4, le LSPID, Type = 0x0804

Longueur

Spécifie la longueur du champ Valeur en octets = 8.

Bit L

Établi à 1 pour indique un bond lâche. À 0 pour indiquer un bond strict.

Réservé

Zéro en émission. Ignoré à réception.

LSPID local

Champ de 2 octets qui indique le LSPID qui est unique par référence à son LSR d’entrée.

Identifiant de routeur du LSR d’entrée

Un LSR peut utiliser n’importe laquelle de ses propres adresses IPv4 dans ce champ.

4.8 Traitement du TLV de chemin explicite

4.8.1 Choix du prochain bond

Un message Demande d’étiquette contenant un TLV de chemin explicite doit déterminer le prochain bond pour ce chemin. Le choix de ce prochain bond peut impliquer une sélection à partir d’un ensemble de diverses solutions possibles. Le mécanisme pour effectuer un choix dans cet ensemble dépend de la mise en œuvre et sort du domaine d’application de la présente spécification. Le choix des chemins particuliers sort aussi du domaine d’application de la présente spécification, mais on suppose que chaque nœud va faire de son mieux pour déterminer un chemin sans boucle. Noter que ces efforts peuvent être outrepassés par une politique locale.

Pour déterminer le prochain bond pour le chemin, un nœud effectue les étapes suivantes :

1. Le nœud qui reçoit le message Demande d’étiquette doit d’abord évaluer le premier bond ER. Si le bit L n’est pas établi dans le premier bond ER et si le nœud ne fait pas partie du nœud abstrait décrit par le premier bond ER, il a reçu le message par erreur, et devrait retourner un état "Erreur, mauvais premier bond ER". Si le bit L est établi et si le nœud local ne fait pas partie du nœud abstrait décrit par le premier bond ER, le nœud choisit un prochain bond qui est sur le chemin du nœud abstrait décrit par le premier bond ER. Si il n’y a pas de premier bond ER, le message est aussi une erreur et le système devrait retourner un état "Erreur, mauvais TLV d’acheminement explicite" en utilisant un message Notification envoyé en amont.

2. Si il n’y a pas de second bond ER, cela indique la fin du chemin explicite. Le TLV Chemin explicite devrait être retiré du message Demande d’étiquette. Ce nœud peut ou non être la fin du LSP. Le traitement continue au paragraphe 4.8.2, où un nouveau TLV Chemin explicite peut être ajouté au message Demande d’étiquette.

3. Si le nœud fait aussi partie du nœud abstrait décrit par le second bond ER, alors le nœud supprime le premier bond ER et continue le traitement avec l’étape 2, ci-dessus. Noter que cela fait du second bond ER le premier bond ER de la prochaine itération.

4. Le nœud détermine si il est topologiquement adjacent au nœud abstrait décrit par le second bond ER. Si il l’est, il choisit un prochain bond particulier qui est membre du nœud abstrait. Il supprime alors le premier bond ER et continue le traitement indiqué au paragraphe 4.8.2.

5. Ensuite, le nœud choisit un prochain bond au sein du nœud abstrait du premier bond ER qui se trouve sur le chemin vers le nœud abstrait du second bond ER. Si un tel chemin n’existe pas, il y a alors deux cas :

5.a Si le second bond ER est un bond ER strict, il y a une erreur et le nœud devrait retourner un état "Erreur, mauvais nœud strict".

5.b Autrement, si le second bond ER est un bond ER lâche, le nœud choisit alors un prochain bond sur le chemin vers le prochain nœud abstrait. Si il n’existe pas de tel chemin au sein du domaine MPLS, il y a une erreur, et le nœud devrait retourner un état "Erreur, mauvais nœud lâche".

6. Finalement, le nœud remplace le premier bond ER par tout bond ER qui note un nœud abstrait contenant le prochain bond. Ceci est nécessaire afin que lorsque le chemin explicite est reçu par le prochain bond, il soit accepté.

7. Le message Demande d’étiquette est transmis en direction du prochain bond.

4.8.2 Ajout de bonds ER au TLV de chemin explicite

Après avoir choisi un prochain bond, le nœud peut modifier le chemin explicite de la façon suivante.

Si, au titre de l’exécution de l’algorithme du paragraphe 4.8.1, le TLV Chemin explicite est retiré, le nœud peut ajouter un nouveau TLV Chemin explicite.

Autrement, si le nœud est un membre du nœud abstrait pour le premier bond ER, une série de bonds ER peut alors être insérée avant le premier bond ER ou peut remplacer le premier bond ER. Chaque bond ER dans cette série doit noter un nœud abstrait qui soit un sous ensemble du nœud abstrait actuel.

Autrement, si le premier bond ER est un bond ER lâche, une série arbitraire de bonds ER peut être insérée avant le premier bond ER.

4.9 TLV d’épinglage de chemin

Le paragraphe 2.4 décrit l’utilisation de l’épinglage de chemin. Le codage du TLV Épinglage de chemin est le suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0823 | Longueur = 4 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|P| Réservé |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : C’est un champ de quatorze bits qui porte la valeur du type de TLV Épinglage de chemin = 0x0823

Longueur : Spécifie la longueur du champ Valeur en octets = 4.

Bit P

Le bit P est établi à 1 pour indiquer que l’épinglage de chemin est demandé.

Le bit P est réglé à 0 pour indiquer que l’épinglage de chemin n’est pas demandé.

Réservé : Zéro en émission. Ignoré à réception.

4.10 Élément de FEC CR-LSP

Un nouvel élément FEC est introduit dans cette spécification pour prendre en charge les CR-LSP. Un TLV FEC contenant une FEC de type Élément CR-LSP (0x04) est un TLV FEC CR-LSP. L’élément FEC CR-LSP est une FEC opaque à n’utiliser que dans les messages des CR-LSP.

Un seul élément FEC DOIT être inclus dans le message Demande d’étiquette. L’élément FEC DEVRAIT être l’élément FEC CR-LSP. Cependant, un des autres éléments FEC (Type = 0x01, 0x02, 0x03) définis dans la [RFC3036] PEUT être dans les messages CR-LDP au lieu de l’élément FEC CR-LSP pour certaines applications. Un TLV FEC contenant une FEC de type Élément CR-LSP (0x04) est un TLV FEC CR-LSP.

Nom du type d’élément FEC Type Valeur

CR-LSP 0x04 Pas de valeur; c’est-à-dire, 0 octet de valeur ;

Le codage du TLV FEC CR-LSP est le suivant :

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0|0| Type = 0x0100 | Longueur = 1 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| CR-LSP (4) |

+-+-+-+-+-+-+-+-+

Type

Un champ de quatorze bits portant la valeur du type TLV FEC = 0x0100

Longueur

Spécifie la longueur du champ Valeur en octets = 1.

Type d’élément FEC CR-LSP : 0x04

5. Considérations relatives à l’IANA

CR-LDP définit les espaces de noms suivants, qui demandent à être gérés :

- types de TLV.

- types de FEC.

- codes d’état.

Les paragraphes qui suivent donnent des lignes directrices pour la gestion de ces espaces.

5.1 Espace de nom de type de TLV

La [RFC3036] définit l’espace de noms de TLV LDP. Le présent document redivise la gamme de la RFC3036 à partir de cet espace de TLV pour les TLV associés au CR-LDP dans la gamme 0x0800 - 0x08FF.

Suivant les politiques exposées dans la [RFC2434], les types de TLV dans cette gamme sont alloués par action de consensus de l’IETF.

Les valeurs initiales pour cette gamme sont spécifiées dans le tableau suivant :

TLV Type

Chemin explicite 0x0800

Préfixe IPv4 de bond ER 0x0801

Préfixe IPv6 de bond ER 0x0802

N° de système autonome de bond ER 0x0803

LSP-ID de bond ER 0x0804

Paramètres de trafic 0x0810

Préemption 0x0820

LSPID 0x0821

Classe de ressource 0x0822

Épinglage de chemin 0x0823

5.2 Espace de nom de type de FEC

La RFC3036 définit l’espace de nom Type de FEC. De plus, la RFC3036 a alloué les valeurs 0x00 à 0x03. Les types de FEC 0 à 127 sont disponibles pour être alloués par action de consensus IETF. La présente spécification fait les allocations supplémentaires suivantes, en utilisant les politiques exposées dans la [RFC2434] :

Élément de FEC Type

Élément de CR-LSP 0x04

5.3 Espace de code d’état

La RFC3036 définit l’espace de noms Code d’état. Le présent document redivise la gamme de la RFC3036 pour cet espace de TLV pour les TLV associés au CR-LDP dans la gamme 0x04000000 - 0x040000FF.

Suivant les politiques exposées dans la [RFC2434], les types de TLV dans cette gamme sont alloués par action de consensus de l’IETF.

Les valeurs initiales pour cette gamme sont spécifiées dans le tableau suivant :

Code d’état Type

Erreur, mauvais TLV d’acheminement explicite 0x04000001

Erreur, mauvais nœud strict 0x04000002

Erreur, mauvais nœud lâche 0x04000003

Erreur, mauvais bond ER initial 0x04000004

Ressource indisponible 0x04000005

Paramètres de trafic indisponibles 0x04000006

LSP préempté 0x04000007

Modification de demande non acceptée 0x04000008

6. Considérations pour la sécurité

Le CR-LDP hérite du même mécanisme de sécurité que celui décrit à la section 4 de la [RFC3036] pour protéger contre l’introduction de segments TCP falsifiés dans les flux de connexion de session LDP.

7. Remerciements

Les messages utilisés pour signaler l’établissement de CR-LSP sont fondés sur les travaux effectués par l’équipe de conception de LDP [RFC3036].

La liste des auteurs fournie avec le présent document est une réduction de la liste originale. Les auteurs actuellement énumérés souhaitent mentionner qu’une quantité substantielle de travail a résultée de contributions de Osama Aboul-Magd, Peter Ashwood-Smith, Joel Halpern, Fiffi Hellstrand, Kenneth Sundell et Pasi Vaananen.

Les auteurs tiennent aussi à remercier de leur relecture attentive et de leurs commentaires Ken Hayward, Greg Wright, Geetha Brown, Brian Williams, Paul Beaubien, Matthew Yuen, Liam Casey, Ankur Anand et Adrian Farrel.

8. 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.

9. Références

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

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)

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

[RFC2764] B. Gleeson et autres, "Cadre pour les réseaux privés virtuels fondés sur IP", février 2000. (Information)

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

[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. et B. Thomas, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)

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

[RFC3214] J. Ash et autres, "Modification de LSP avec CR-LDP", janvier 2002. (P.S.)

[RFC3215] C. Boscher, P. Cheval, L. Wu, E. Gray, "Automate à états LDP", janvier 2002. (Information)

Appendice A Exemples d’établissement de CR-LSP

A.1 Exemple d’acheminement strict explicite

Le présent appendice fournit un exemple d’établissement de CR-LSP à acheminement strict. Dans cet exemple, un nœud spécifique représente chaque nœud abstrait.

L’échantillon de réseau utilisé ici se compose de quatre nœuds avec deux LSR bordures et deux LSR centraux comme suit :

abc

LSR1------LSR2------LSR3------LSR4

LSR1 génère un message Demande d’étiquette comme décrit au paragraphe 3.1 et l’envoie au LSR2. Ce message comporte le CR-TLV.

Un vecteur de trois TLV de bond ER <a, b, c> compose le TLV ER. Le TLV de bond ER utilisé dans cet exemple est du type 0x0801 (préfixe IPv4) avec une longueur de préfixe de 32. Donc, chaque TLV de bond ER identifie un nœud spécifique et non un groupe de nœuds. Au LSR2 a lieu le traitement suivant du TLV ER selon le paragraphe 4.8.1 :

1. Le nœud LSR2 fait partie du nœud abstrait décrit par le premier bond <a>. Donc, la première étape réussit le test. On passe à l’étape 2.

2. Il y a un second bond ER, <b>. Passer à l’étape 3.

3. LSR2 ne fait pas partie du nœud abstrait décrit par le second bond ER <b>. Passer à l’étape 4.

4. LSR2 détermine qu’il est topologiquement adjacent au nœud abstrait décrit par le second bond ER <b>. Le LSR2 choisit un prochain bond (LSR3) qui soit le nœud abstrait. Le LSR2 supprime le premier bond ER <a> du TLV ER, qui devient maintenant <b, c>. Le traitement continue avec le paragraphe 4.8.2.

Au LSR2 a lieu le traitement suivant découlant du paragraphe 4.8.2 : l’exécution de l’algorithme du 4.8.1 n’a pas résulté en la suppression du TLV ER.

Aussi, le LSR2 n’est pas membre du nœud abstrait décrit par le premier bond ER <b>.

Finalement, le premier bond ER <b> est un bond strict.

Donc, le traitement du paragraphe 4.8.2 ne résulte pas en l’insertion de nouveaux bonds ER. Le choix du prochain bond a été déjà fait à l’étape 4 du paragraphe 4.8.1 et le traitement du TLV ER est achevé au LSR2. Dans ce cas, le message Demande d’étiquette incluant le TLV ER <b, c> est transmis par le LSR2 au LSR3.

Au LSR3 a lieu un traitement similaire à celui du TLV ER sauf que le TLV ER entrant = <b, c> et que le TLV ER sortant est <c>.

Au LSR4 a lieu le traitement suivant selon le paragraphe 4.8.1 :

1. Le nœud LSR4 fait partie du nœud abstrait décrit par le premier bond <c>. Donc, la première étape réussit le test. Passer à l’étape 2.

2. Il n’y a pas de second bond ER, ce qui indique la fin du CR-LSP. Le TLV ER est supprimé du message Demande d’étiquette. Le traitement continue avec le paragraphe 4.8.2.

Au LSR4 a lieu le traitement suivant selon le paragraphe 4.8.2: L’exécution de l’algorithme de 4.8.1 a résulté en la suppression du TLV ER. LSR4 n’ajoute pas un nouveau TLV ER.

Donc, le traitement du paragraphe 4.8.2 ne résulte pas en l’insertion de nouveaux bonds ER. Cela indique la fin du CR-LSP et le traitement du TLV ER est achevé au LSR4.

Au LSR4, le traitement du paragraphe 3.2 est invoqué. La première condition est satisfaite (le LSR4 est l’extrémité de sortie du CR-LSP et la transposition amont a été demandée). Donc, un message Transposition d’étiquette est généré par le LSR4 et envoyé au LSR3.

Au LSR3, le traitement du paragraphe 3.2 est invoqué. La seconde condition est satisfaite (le LSR3 a reçu une transposition de son prochain bond aval LSR4 pour un CR-LSP pour lequel une demande amont est encore en cours). Donc, un message Transposition d’étiquette est généré par le LSR3 et envoyé au LSR2.

Au LSR2 a lieu un traitement similaire à celui du LSR 3 et un message Transposition d’étiquette est renvoyé au LSR1, ce qui achève l’établissement du CR-LSP de bout en bout.

A.2 Exemple de groupes de nœuds et de nœuds spécifiques

Une demande au LSR d’entrée d’établir un CR-LSP peut être générée par un système de gestion ou une application, les détails étant spécifiques de la mise en œuvre.

Le LSR d’entrée utilise les informations fournies par le système de gestion ou l’application et éventuellement aussi les informations provenant de la base de données d’acheminement, pour calculer le chemin explicite et pour créer le message Demande d’étiquette.

Le message Demande d‘étiquette porte, avec d’autres informations nécessaires, un TLV ER qui définit le chemin à acheminement explicite. Dans notre exemple, la liste des bonds dans le TLV de bond ER est supposée contenir un nœud abstrait représentant un groupe de nœuds, un nœud abstrait représentant un nœud spécifique, un autre nœud abstrait représentant un groupe de nœuds, et un nœud abstrait représentant un point de sortie spécifique.

Entrée --{Groupe 1}--{Spécifique A}--{Groupe 2}--{Spécifique sortie : B}

Le TLV ER contient quatre TLV de bond ER :

1. Un TLV de bond ER qui spécifie un groupe de LSR valide pour le premier nœud abstrait représentant un groupe de nœuds (Groupe 1).

2. Un TLV de bond ER qui indique le nœud spécifique (Nœud A).

3. Un TLV de bond ER qui spécifie un groupe de LSR valides pour le second nœud abstrait représentant un groupe de nœuds (Groupe 2).

4. Un TLV de bond ER qui indique le point de sortie spécifique pour le CR-LSP (Nœud B).

Tous les TLV de bond ER sont des nœuds à acheminement strict.

La procédure d’établissement pour ce CR-LSP fonctionne comme suit :

1. Le nœud d’entrée envoie le message Demande d’étiquette à un nœud qui est membre du groupe de nœuds indiqué dans le premier TLV de bond ER, suivant l’acheminement normal pour le nœud spécifique (A).

2. Le nœud qui reçoit le message s’identifie comme membre du groupe indiqué dans le premier TLV de bond ER, et qui n’est pas le nœud spécifique (A) dans le second. De plus, il réalise que le nœud spécifique (A) n’est pas de son prochain bond.

3. Il garde le TLV de bond ER intact et envoie un message Demande d’étiquette à un autre nœud qui est membre du groupe indiqué dans le premier TLV de bond ER (Groupe 1), suivant l’acheminement normal pour le nœud spécifique (A).

4. Le nœud qui reçoit le message s’identifie comme membre du groupe indiqué dans le premier TLV de bond ER, et qui n’est pas le nœud spécifique (A) dans le second TLV de bond ER. De plus, il réalise que le nœud spécifique (A) est un de ses prochains bonds.

5. Il retire le premier TLV de bond ER et envoie un message Demande d’étiquette au nœud spécifique (A).

6. Le nœud spécifique (A) se reconnaît dans le premier TLV de bond ER. Il retire le TLV de bond ER spécifique.

7. Il envoie un message Demande d’étiquette à un nœud qui est membre du groupe (Groupe 2) indiqué dans le TLV de bond ER.

8. Le nœud qui reçoit le message s’identifie comme membre du groupe indiqué dans le premier TLV de bond ER, de plus, il réalise que le nœud de sortie spécifique (B) est un de ses prochains bonds.

9. Il envoie un message Demande d’étiquette au nœud de sortie spécifique (B).

10. Le nœud de sortie spécifique (B) se reconnaît comme la sortie pour le CR-LSP, il retourne un message Transposition d’étiquette, qui va traverser le même chemin que le message Demande d’étiquette dans la direction opposée.

Appendice B Exemples de service de qualité de service

B.1 Exemples de service

La construction d’un service de bout en bout est le résultat des règles mises en application à la bordure et du traitement que reçoivent les paquets reçus aux nœuds du réseau. Les règles qui définissent les actions de conditionnement du trafic sont mises en œuvre à la bordure et elles incluent une régulation avec des capacité de passer, marquer, et abandonner. Les règles de bordures sont supposées être définies par des accords mutuels entre les fournisseurs de service et leurs clients, et elles vont constituer une part essentielle de l’accord de niveau de service (SLA, service level agreement). Donc, les règles de bordure ne sont pas incluses dans le protocole de signalisation.

Le traitement des paquets à un nœud de réseau est habituellement appelé le comportement local. Le comportement local pourrait être spécifié de nombreuses façons. Un exemple de spécification de comportement local est la fréquence de service introduite au paragraphe 4.3.2.1, avec les règles de réservation de ressources mises en œuvre aux nœuds.

Les règles de bordure et le comportement local peuvent être vues comme les principaux blocs de construction pour l’édification du service de bout en bout. Le tableau qui suit illustre l’applicabilité de l’approche des blocs de construction pour monter différents services, y compris ceux définis pour ATM.

S = Spécifié par l’utilisateur

Dans ce tableau, DS se réfère à un service sensible au délai où le réseau s’engage à livrer avec une forte probabilité les datagrammes d’utilisateur à un taux de PDR avec délai minimum et exigences de délai. Les datagrammes en excédent de PDR seront éliminés.

TS se réfère à un service générique sensible au débit où le réseau s’engage à livrer avec une forte probabilité les datagrammes d’utilisateur à un taux d’au moins CDR. L’usager peut transmettre à n’importe quel taux supérieur à CDR mais les datagrammes en excès de CDR auront une plus faible probabilité d’être livrés.

BE (best effort) est le service au mieux et il implique qu’il n’y a pas de garantie de service attendue du réseau.

B.2 Établissement de CR-LSP acceptant des applications en temps réel

Dans ce scénario, le client a besoin d’établir un LSP pour prendre en charge des applications en temps réel comme la voix et la vidéo. Le service sensible au délai (DS, Delay-sensitive) est demandé dans ce cas.

La première étape est la spécification des paramètres de trafic dans le message de signalisation. Les deux paramètres intéressants pour le service DS sont le PDR et le PBS et l’utilisateur spécifie leur valeur sur la base de cette exigence. Comme tous les paramètres de trafic sont inclus dans le message de signalisation, les valeurs appropriées doivent être allouées à chacun d’eux. Pour le service DS, les valeurs de CDR et de CBS sont réglées égales respectivement au PDR et au PBS. Un fanion indique si les valeurs des paramètres sont soumises ou non à négociation.

Les caractéristiques de transport du service DS exigent que la fréquence Fréquent soit demandée pour refléter les exigences de délai du temps réel du service.

En plus des caractéristiques de transport, l’exploitant du réseau et le consommateur doivent se mettre d’accord sur les actions mises en application à la bordure. La spécification de ces actions est supposée faire partie de la négociation de l’accord de niveau de service (SLA) et n’est pas incluse dans le protocole de signalisation . Pour le service DS, l’action de bordure est d’abandonner les paquets qui excèdent la spécification du PDR et du PBS. Le message de signalisation sera envoyé dans la direction du chemin ER et le LSP sera établi en suivant les procédures normales de LDP. Chaque LSR applique ses règles de contrôle d’admission. Si des ressources suffisantes ne sont pas disponibles et si les valeurs des paramètres sont soumises à négociation, le LSR pourrait alors négocier à la baisse le PDR, le PBS, ou les deux.

Les nouvelles valeurs de paramètres sont propagées en amont dans le message Transposition d’étiquette. Les LSR peuvent avoir besoin de réajuster leurs réservations de ressources sur la base des nouvelles valeurs des paramètres de trafic.

B.3 Établissement de CR-LSP acceptant des applications insensibles au retard

Dans cet exemple, on suppose qu’est demandé un service sensible au débit (TS, Throughput Sensitive). Pour l’allocation des ressources, l’utilisateur assigne des valeurs à PDR, PBS, CDR, et CBS. Le fanion de négociation est établi si les paramètres de trafic sont soumis à négociation. Comme le service est par définition insensible au délai, la fréquence Non spécifié est signalée pour indiquer que la fréquence du service n’est pas un problème.

Comme pour l’exemple précédent, les actions de bordure ne sont pas un objet de signalisation et sont spécifiées dans l’accord de niveau de service entre l’utilisateur et l’exploitant de réseau.

Pour le service TS, les règles de bordure peuvent inclure de marquer pour indiquer de fortes valeurs de préséance d’élimination pour tous les paquets qui excèdent le CDR et le CBS. Les règles de bordure vont alors aussi inclure l’abandon des paquets qui ne se conforment ni au PDR ni au PBS.

Chaque LSR du LSP est supposé faire fonctionner ses règles de contrôle d’admission et négocier la diminution de ses paramètres de trafic si des ressources suffisantes n’existent pas. Les nouvelles valeurs de paramètres sont propagées en amont dans le message Transposition d’étiquette. Les LSR peuvent avoir besoin de réajuster leurs ressources sur la base des nouvelles valeurs de paramètres de trafic.

10. Adresse des auteurs

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.