<reference title="RSVP-TE: Extensions to RSVP for LSP Tunnels" url="https://www.rfc-editor.org/rfc/rfc3209.txt" rfc="3209" lang="fr" translators="["AI"]" />
RFC 3209
Extensions RSVP pour les tunnels LSP (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Cette traduction est établie à partir du texte original en anglais https://www.rfc-editor.org/rfc/rfc3209.txt, paragraphe par paragraphe, en conservant l'ensemble des sections, des diagrammes binaires, des blocs de code et des tableaux.
Informations métadonnées du texte original
- Titre du document : RSVP-TE: Extensions to RSVP for LSP Tunnels
- Catégorie : Standards Track
- Statut : Proposed Standard
- Auteurs : D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow
- Date : décembre 2001
Groupe de travail réseau
| Groupe de travail réseau | D. Awduche |
| Demande de commentaires (RFC) : 3209 | Movaz Networks |
| Catégorie : Standards Track | L. Berger |
| Groupe de travail réseau MPLS | |
| D. Gan | |
| Juniper Networks, Inc. | |
| T. Li | |
| Procket Networks | |
| V. Srinivasan | |
| G. Swallow | |
| Cisco Systems, Inc. | |
| décembre 2001 |
Extensions RSVP pour les tunnels LSP (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Statut de ce mémoire
Ce mémoire définit un protocole de piste de norme Internet pour la communauté Internet. Sa distribution n'est pas restreinte.
Avis de droit d'auteur
Copyright (C) L'Internet Society (2001). Tous droits réservés.
Le présent document et ses traductions peuvent être copiés et fournis à d'autres personnes, et sont considérés comme ne pas entraîner de frais lorsqu'ils sont copiés, présentés, cités ou utilisés à d'autres fins, à condition que toutes les copies et œuvres dérivées susmentionnées contiennent cet avis de droit d'auteur et les droits, restrictions et clauses de non-responsabilité énoncés dans le présent document. Toutefois, le document lui-même ne peut être modifié de quelque manière que ce soit, par exemple en supprimant l'avis de droit d'auteur ou les références à l'Internet Society ou à d'autres organisations Internet, sauf lorsque cela est nécessaire aux fins du processus des normes Internet, auquel cas les procédures de droit d'auteur définies dans les normes Internet doivent être suivies, ou lorsque cela est requis pour le traduire dans une langue autre que l'anglais.
Les permissions limitées accordées ci-dessus sont permanentes et ne seront pas révoquées par l'Internet Society ou ses successeurs ou ayants droit.
Le présent document et les informations qu'il contient sont fournis « EN L'ÉTAT » (AS IS) et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRESSES OU IMPLICITES, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE SELON LAQUELLE L'UTILISATION DES INFORMATIONS CONTENUES DANS LE PRÉSENT DOCUMENT NE PORTERA ATTEINTE À AUCUN DROIT OU TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.
Remerciements
Le financement de la fonction d'édition des RFC est actuellement assuré par l'Internet Society.
Résumé
Le présent document décrit des extensions au « protocole de réservation de ressources » (RSVP) (version 1) permettant d'établir, dans des réseaux IP et des réseaux à commutation de labels multiprotocoles (MPLS), des chemins de commutation de labels (LSP) qui peuvent suivre un routage explicitement spécifié et être soumis à des contraintes d'ingénierie de trafic. Ces chemins sont appelés « tunnels LSP pour l'ingénierie de trafic », ou simplement « TE LSP ». La capacité pour un chemin de commutation de labels d'être établi en suivant un routage explicite et d'être potentiellement soumis à des contraintes d'ingénierie de trafic est un élément de construction important de nombreuses stratégies d'ingénierie de trafic des fournisseurs de services, et est également requise par l'architecture MPLS. Le présent document propose une extension RSVP pour établir des tunnels LSP à routage explicite soumis à des contraintes d'ingénierie de trafic. Il définit également des objets supplémentaires pour enregistrer et prendre en charge la spécification d'un routage explicite dans les messages RSVP, ainsi que plusieurs objets servant à contrôler davantage la politique d'établissement des tunnels LSP. En outre, le présent document définit un message « Hello » utilisé pour tester l'accessibilité entre des voisins RSVP.
1. Introduction
Le présent document décrit des extensions au protocole de réservation de ressources (RSVP, version 1 [RFC 2205]) permettant de prendre en charge l'établissement de « tunnels LSP pour l'ingénierie de trafic » (ci-après « TE LSP » ou « tunnel LSP ») dans des réseaux IP et MPLS. Pour une vue d'ensemble du MPLS, voir [RFC 3031] ; pour une vue d'ensemble de l'ingénierie de trafic (TE) MPLS, voir [RFC 2702]. La section 2 donne un aperçu. La section 3 décrit les formats des messages RSVP utilisés pour établir des tunnels LSP. La section 4 décrit les objets RSVP étendus servant à établir des tunnels LSP. La section 5 décrit l'extension « Hello ». La section 6 décrit les considérations de sécurité. La section 7 décrit le traitement des messages RSVP par les routeurs de commutation de labels (LSR) MPLS. La section 8 définit les options de signalisation des tunnels LSP. La section 9 décrit la compatibilité ascendante avec RSVP. La section 10 indique les domaines dans lesquels la présente spécification pourrait être étendue à l'avenir. La section 11 donne les références. L'annexe A donne le traitement des erreurs. L'annexe B donne le traitement des messages RSVP dans les LSR à prise en charge multiprotocole. La section 12 est un remerciement. La section 13 donne les adresses des auteurs. La section 14 donne l'avis de droit d'auteur du présent mémoire.
1.1 Terminologie
Les termes et conventions utilisés dans le présent document sont donnés dans [RFC 3031] et [RFC 2702]. Pour la commodité du lecteur, certaines de ces définitions sont répétées ci-dessous.
Routeur de commutation de labels (LSR) : routeur ou commutateur capable de comprendre la commutation de labels et de transférer des paquets en fonction de la valeur du label.
Chemin de commutation de labels (LSP) : pour un ensemble donné de paquets, défini par le chemin emprunté par les paquets et par l'ensemble des LSR sur lesquels le comportement de commutation/transfert de labels a été établi. Le chemin de commutation de labels d'un paquet est identifié par la pile de labels appliquée au paquet au LSR d'entrée. Un LSP utilisé pour l'ingénierie de trafic et suivant un routage explicite est également souvent appelé « tunnel LSP ».
Aval (Downstream) : sur un LSP ou un chemin de commutation de labels, la direction allant de l'entrée vers la sortie.
Amont (Upstream) : sur un LSP ou un chemin de commutation de labels, la direction allant de la sortie vers l'entrée.
Tunnel LSP : chemin de commutation de labels initié par le LSR d'entrée, dont les paquets sont encapsulés d'une manière telle que les LSR le long du LSP n'examinent pas l'en-tête IP des paquets lors du transfert. Autrement dit, les LSR au milieu du tunnel sont « aveuglés » quant aux informations sur les paquets encapsulés à l'intérieur. Dans RSVP-TE, le tunnel LSP est identifié par l'objet SESSION.
LSR d'entrée (Ingress LSR) : LSR qui applique la première couche de label au tunnel LSP. Le LSR d'entrée est également l'initiateur de l'établissement du tunnel LSP.
LSR de sortie (Egress LSR) : LSR qui retire le label de couche la plus externe du tunnel LSP. Le LSR de sortie est le point terminal ultime du tunnel LSP.
Ingénierie de trafic (Traffic Engineering) : processus de mappage du trafic sur la topologie physique du réseau après prise en compte de métriques de contrainte techniques ou commerciales (incluant, sans s'y limiter, la gestion de la bande passante, les métriques d'utilisation, la gestion de la congestion et la satisfaction des exigences de qualité de service).
Routage explicite (Explicit Route) : liste de nœuds ou de nœuds abstraits (par exemple, un système autonome) préspécifiée par le LSR d'entrée lors de l'initiation de l'établissement d'un tunnel LSP. Cette liste spécifie l'ensemble des nœuds et/ou interfaces qu'un tunnel LSP doit traverser lors de son établissement.
Nœud abstrait (Abstract Node) : séquence de zéro ou plusieurs nœuds simples (c'est-à-dire un hôte ou un routeur) sans nœud intermédiaire entre eux.
Objet de routage explicite (ERO) : composé d'une liste ordonnée d'éléments de routage explicite (sous-objets), chacun pouvant être de type strict ou loose, indiquant un routage explicite le long d'une séquence de nœuds abstraits. L'ERO est transporté dans le message Path.
Objet de routage enregistré (RRO) : composé d'une liste ordonnée d'éléments de routage (sous-objets), enregistrant le chemin réel du tunnel LSP. Le RRO est transporté dans les messages Path et Resv.
Tunnel d'ingénierie de trafic : tunnel LSP établi et maintenu à des fins d'ingénierie de trafic. Un tunnel d'ingénierie de trafic n'a pas besoin de suivre le plus court chemin IGP et peut être soumis à plusieurs contraintes.
1.2 Aperçu du document
Le présent document décrit les extensions à RSVP permettant d'établir des tunnels LSP dans des réseaux IP et MPLS. En particulier, le présent document décrit les objets RSVP servant aux fins suivantes :
- demander un label lors de l'établissement d'un tunnel LSP ;
- transporter des informations de routage explicite lors de l'établissement d'un tunnel LSP ;
- transporter des spécifications d'ingénierie de trafic (bande passante, couleur, affinité de classe de ressources, etc.) ;
- transporter des informations de politique et de préemption (priorité, préemptibilité) ;
- transporter les attributs d'identification de la session du tunnel LSP.
En outre, le présent document définit les règles de traitement des messages RSVP pour établir des tunnels LSP soumis à des contraintes d'ingénierie de trafic, incluant l'établissement, le démantèlement, le routage et la préemption.
2. Aperçu
RSVP [RFC 2205] est un protocole utilisé pour établir et maintenir des arbres de distribution dans des réseaux à protocole Internet (IP) pour la transmission de données multicast ou unicast. Les messages RSVP circulent le long de l'arbre de distribution unicast ou multicast, dans le sens du routage du flux de données. Dans le modèle de réservation RSVP initié par le récepteur, le récepteur envoie un message « Resv » à l'émetteur, réservant des ressources le long du chemin. Dans le modèle RSVP initié par l'émetteur, l'émetteur envoie un message « Path » au récepteur pour établir l'état le long du chemin et caractériser le trafic.
Le présent document décrit des extensions à RSVP permettant de prendre en charge l'établissement de chemins de commutation de labels (LSP) sous forme de tunnels. Ces extensions permettent à RSVP d'établir des chemins de commutation de labels dans des réseaux MPLS, et permettent également dans des réseaux IP d'établir des TE LSP « symboliques » (c'est-à-dire que, bien qu'il n'existe pas de véritable commutation de labels dans un réseau IP, RSVP peut néanmoins établir et maintenir un état à routage explicite et contraint dont la sémantique est la même que celle d'un tunnel TE LSP MPLS).
Le présent document définit les extensions suivantes à RSVP :
- transporter une demande de label et une liaison de label dans les messages RSVP ;
- transporter un routage explicite dans les messages RSVP ;
- transporter des spécifications d'ingénierie de trafic dans les messages RSVP ;
- transporter des attributs de session pour le contrôle de politique et la préemption dans les messages RSVP ;
- transporter un message « Hello » entre les voisins RSVP pour tester l'accessibilité.
Les sections suivantes décrivent en détail ces extensions.
2.1 Établissement d'un tunnel LSP
Pour établir un tunnel LSP, le LSR d'entrée envoie un message Path au LSR de sortie. Le message Path transporte :
- l'objet LABEL_REQUEST, utilisé pour demander l'attribution d'un label au tunnel LSP ;
- l'objet EXPLICIT_ROUTE (ERO) (optionnel), utilisé pour spécifier le routage explicite que le tunnel LSP doit suivre ;
- l'objet SESSION_ATTRIBUTE (optionnel), utilisé pour transporter des informations de politique de session (par exemple la priorité et les attributs de préemption du tunnel LSP) ;
- l'objet RECORD_ROUTE (RRO) (optionnel), utilisé pour enregistrer le chemin réel ;
- les objets standard de descripteur d'émetteur et de spécification de trafic RSVP.
Le message Path est propagé saut par saut le long du chemin vers le LSR de sortie (ou, lorsqu'un ERO est présent, le long du chemin spécifié par l'ERO). Chaque LSR, à la réception d'un message Path, établit un « état Path » pour son voisin amont (c'est-à-dire le voisin dans le sens d'origine du message Path).
Lorsque le LSR de sortie reçoit le message Path, il envoie un message Resv le long du chemin inverse (c'est-à-dire vers le LSR d'entrée). Le message Resv transporte :
- l'objet LABEL, contenant le label attribué au tunnel LSP par le LSR de sortie (le label est attribué de l'aval vers l'amont du LSP) ;
- l'objet RECORD_ROUTE (RRO) (optionnel) ;
- l'objet de style et le descripteur de flux.
Le message Resv est propagé saut par saut le long du chemin inverse de l'état Path. Chaque LSR, à la réception d'un message Resv, établit un « état Resv » pour son voisin aval (c'est-à-dire le voisin dans le sens d'origine du message Resv), et propage vers l'amont le label qu'il a attribué à son voisin aval dans l'objet LABEL.
Lorsque le LSR d'entrée reçoit le message Resv, l'établissement du tunnel LSP est terminé. À ce moment, le LSR d'entrée peut commencer à transférer des paquets via le tunnel LSP.
2.2 Routage d'un tunnel LSP
Au cours de la durée de vie d'un tunnel LSP, il peut être nécessaire de modifier son chemin (par exemple, en réponse à des changements de topologie de réseau, pour un équilibrage de charge ou pour optimiser l'utilisation des ressources). Le présent document prend en charge le routage d'un tunnel LSP sans interrompre le trafic qu'il porte. Une méthode recommandée est le « make-before-break » (établir avant de rompre), à savoir : établir d'abord un nouveau LSP (avec un LSP ID différent) en parallèle de l'ancien, puis, après basculement du trafic vers le nouveau LSP, démanteler l'ancien LSP. Avec le style de réservation partagé explicite (SE), les anciens et nouveaux LSP peuvent coexister sur les ressources de liaison partagées sans entraîner une double occupation de la bande passante.
2.3 Préemption d'un tunnel LSP
Les tunnels LSP peuvent se voir attribuer une priorité. Lorsque les ressources du réseau sont insuffisantes pour héberger simultanément tous les tunnels LSP établis, un tunnel LSP de priorité plus élevée peut préempter (c'est-à-dire démanteler et réétablir) un tunnel LSP de priorité inférieure. Le présent document prend en charge la préemption via les champs « priorité d'établissement » (Setup Priority) et « priorité de maintien » (Holding Priority) dans l'objet SESSION_ATTRIBUTE.
2.4 Styles de réservation de ressources
RSVP prend en charge plusieurs styles de réservation de ressources, notamment :
- style Filtre Fixe (FF) : crée une réservation indépendante pour chaque flux (émetteur, récepteur) ;
- style Filtre Générique (WF) : une seule réservation est partagée par un ensemble (éventuellement inconnu) d'émetteurs ;
- style Partagé Explicite (SE) : une seule réservation est partagée par un ensemble d'émetteurs explicitement énumérés.
Pour les tunnels LSP, le style SE est généralement utilisé, car il permet aux anciens et nouveaux LSP de partager la réservation de ressources lors d'un routage (make-before-break).
3. Formats des messages RSVP pour l'établissement de tunnels LSP
3.1 Message Path
Le message Path est utilisé, initié par le LSR d'entrée, pour établir un tunnel LSP. Le format du message RSVP Path est le suivant :
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
[ <LABEL_REQUEST> ]
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
LABEL_REQUEST et EXPLICIT_ROUTE sont des objets nouvellement introduits par le présent document. SESSION_ATTRIBUTE est également un objet nouvellement introduit par le présent document. RECORD_ROUTE est défini dans [RFC 2205], mais le présent document en spécifie l'utilisation dans l'établissement des tunnels LSP.
3.2 Message Resv
Le message Resv est initié par le LSR de sortie, envoyé le long du chemin inverse de l'état Path, pour achever l'établissement du tunnel LSP. Le format du message RSVP Resv est le suivant :
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ]
[ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor list>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOW_SPEC> ] <FILTER_SPEC> <LABEL>
<SE flow descriptor list> ::= <SE flow descriptor>
| <SE flow descriptor list> <SE flow descriptor>
<SE flow descriptor> ::= [ <FLOW_SPEC> ] <SE filter spec list>
<SE filter spec list> ::= <FILTER_SPEC> <LABEL>
| <SE filter spec list> <FILTER_SPEC> <LABEL>
LABEL est un objet nouvellement introduit par le présent document, utilisé pour transporter le label attribué au tunnel LSP.
4. Objets pour l'établissement de tunnels LSP
La présente section décrit les objets RSVP étendus servant à l'établissement de tunnels LSP. Chaque objet est composé d'un « en-tête d'objet » et d'un « corps d'objet », l'en-tête d'objet étant défini dans [RFC 2205].
4.1 Objet LABEL
L'objet LABEL est utilisé pour transporter la valeur de label attribuée au tunnel LSP. L'objet LABEL est transporté dans le message Resv.
Le format de l'objet LABEL est le suivant :
Class = 16, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 16 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le champ Label Value est une valeur de label sur 20 bits (pour un LSR à capacité de commutation de paquets). Pour un LSR à capacité ATM ou Relais de trame, le codage de la valeur de label est différent ; voir l'annexe B pour plus de détails.
4.1.1 Traitement de l'objet LABEL dans le message Resv
Lorsqu'un LSR reçoit un message Resv transportant l'objet LABEL, il utilise la valeur de label de l'objet LABEL pour la liaison de label de son interface amont (c'est-à-dire que le LSR amont utilisera cette valeur de label comme label de sortie lors de l'envoi de paquets vers ce LSR).
4.1.2 Non prise en charge de l'objet LABEL
Si un LSR ne prend pas en charge l'objet LABEL, il doit produire un message ResvErr avec le code d'erreur « classe d'objet inconnue » à la réception d'un message Resv transportant l'objet LABEL. L'objet LABEL appartient à la classe d'objet « reconnaissable » (deux bits de poids fort de la classe à 0b10), il doit donc renvoyer une erreur s'il est inconnu.
4.2 Objet LABEL_REQUEST
L'objet LABEL_REQUEST est utilisé pour demander l'attribution d'un label lors de l'établissement d'un tunnel LSP. Il est transporté dans le message Path. L'objet LABEL_REQUEST peut également transporter un identificateur de protocole de couche 3 (L3PID) et une plage de labels optionnelle (pour les liaisons ATM ou Relais de trame).
Le format de l'objet LABEL_REQUEST est le suivant (forme sans plage de labels) :
Class = 19, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le format de l'objet LABEL_REQUEST avec plage de labels ATM est le suivant :
Class = 19, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI/VCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le format de l'objet LABEL_REQUEST avec plage de labels Relais de trame (Frame Relay) est le suivant :
Class = 19, C-Type = 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le champ L3PID identifie le protocole de couche 3 transporté par le tunnel LSP (par exemple IPv4 = 0x0800, IPv6 = 0x86DD).
4.2.1 Traitement de LABEL_REQUEST dans le message Path
Lorsqu'un LSR reçoit un message Path transportant LABEL_REQUEST, il doit (s'il le prend en charge) attribuer un label pour le tunnel LSP et l'annoncer dans l'objet LABEL du message Resv qu'il envoie vers l'amont. Si le LSR ne prend pas en charge le L3PID demandé, il doit produire un message PathErr.
4.2.2 Non prise en charge de l'objet LABEL_REQUEST
Si un LSR ne prend pas en charge l'objet LABEL_REQUEST, il doit produire un message PathErr avec le code d'erreur « classe d'objet inconnue » à la réception d'un message Path transportant LABEL_REQUEST. L'objet LABEL_REQUEST appartient à la classe d'objet « reconnaissable » (deux bits de poids fort de la classe à 0b10), il doit donc renvoyer une erreur s'il est inconnu.
4.3 Objet EXPLICIT_ROUTE (ERO)
L'objet EXPLICIT_ROUTE (ERO) permet au LSR d'entrée de spécifier le routage explicite que le tunnel LSP doit suivre lors de son établissement. L'ERO apparaît dans le message Path. L'ERO est composé d'une liste ordonnée de sous-objets, chacun pouvant être de type strict ou loose.
Le format de l'objet ERO est le suivant :
Class = 20, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 20 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le format de chaque sous-objet est le suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
où le bit L (bit Loose) indique si le sous-objet est de type loose (L=0) ou strict (L=1).
Les types de sous-objets définis dans l'ERO incluent :
- Type 1 : préfixe IPv4
- Type 2 : préfixe IPv6
- Type 3 : numéro de système autonome (ASN)
- Type 4 : LSPID version 4 (obsolète)
- Type 5 : interface non numérotée (Unnumbered Interface)
- Type 6 : préfixe IPv4 (avec indicateur de préfixe)
- Type 7 : préfixe IPv6 (avec indicateur de préfixe)
- Type 8 : numéro de système autonome (4 octets)
- Type 9 : LSPID version 4 (étendu)
- Type 10 : SRLG (groupe de risque de liaison partagé)
- Type 11 : type de protection de nœud ou de liaison
- Type 12 : type de protection de bande passante
4.3.1 Sous-objet préfixe IPv4
Le sous-objet préfixe IPv4 est utilisé pour spécifier un préfixe d'adresse IPv4 comme élément de routage. Son format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 1 | Length | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved (zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2 Sous-objet préfixe IPv6
Le sous-objet préfixe IPv6 est utilisé pour spécifier un préfixe d'adresse IPv6 comme élément de routage. Son format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 2 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| IPv6 address (16 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.3 Sous-objet numéro de système autonome
Le sous-objet numéro de système autonome (ASN) est utilisé pour spécifier un système autonome comme nœud abstrait. Son format est le suivant (ASN sur 2 octets) :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 3 | Length | Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.4 Traitement de l'ERO dans le message Path
Lorsqu'un LSR reçoit un message Path transportant un ERO, il examine le sous-objet au sommet de l'ERO pour déterminer le prochain saut. Pour un sous-objet strict, le prochain saut doit être un nœud directement adjacent ; pour un sous-objet loose, le prochain saut peut être un nœud joignable via le routage IGP. Après traitement du sous-objet au sommet, le LSR le retire (dépile) de l'ERO et propage l'ERO modifié vers l'aval.
4.3.5 Boucles dans l'ERO
Le traitement de l'ERO doit pouvoir détecter les boucles. Lorsqu'un LSR détecte qu'un ERO entraînera une boucle, il doit produire un message PathErr et rejeter le tunnel LSP. L'objet RECORD_ROUTE (RRO) peut également être utilisé pour aider à détecter les boucles.
4.4 Objet SESSION_ATTRIBUTE
L'objet SESSION_ATTRIBUTE est utilisé pour transporter les attributs de session du tunnel LSP, incluant le nom de session, les priorités d'établissement et de maintien, le souhait de protection locale, le souhait d'enregistrement de label, etc. Son format est le suivant :
Class = 207, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=207 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les bits du champ Flags sont définis comme suit :
- 0x01 : protection locale souhaitée (Local protection desired)
- 0x02 : enregistrement de label souhaité (Label recording desired)
- 0x04 : style SE souhaité (SE Style desired)
- 0x08 : protection de bande passante (Bandwidth protection)
- 0x10 : protection de nœud (Node protection)
4.5 Objet RECORD_ROUTE (RRO)
L'objet RECORD_ROUTE (RRO) est utilisé pour enregistrer le chemin réel du tunnel LSP. Le RRO est transporté à la fois dans les messages Path et Resv. Le RRO est composé d'une suite de sous-objets, chacun enregistrant un nœud ou une liaison sur le chemin. Le RRO peut être utilisé pour la détection de boucles, le calcul de diversité de chemin et le diagnostic de panne.
4.6 Objet SESSION
L'objet SESSION est utilisé pour identifier la session du tunnel LSP. Pour un tunnel LSP, l'« adresse du point terminal du tunnel » (Tunnel Endpoint Address) dans l'objet SESSION est fixée à l'adresse du LSR de sortie, le « Tunnel ID » est attribué par le LSR d'entrée, et l'« Extended Tunnel ID » est généralement fixé à l'adresse du LSR d'entrée.
4.7 Objet SENDER_TEMPLATE
L'objet SENDER_TEMPLATE est utilisé pour identifier l'émetteur (c'est-à-dire le LSR d'entrée) du tunnel LSP. Pour un tunnel LSP, l'objet SENDER_TEMPLATE transporte le « Tunnel ID » et le « LSP ID ». Le LSP ID est utilisé pour distinguer les anciens et nouveaux LSP lors d'un routage (make-before-break).
5. Extension Hello
Le présent document définit l'extension RSVP « Hello » utilisée pour tester l'accessibilité entre des voisins RSVP. Le mécanisme Hello complète le mécanisme de rafraîchissement basé sur l'état souple et peut déclencher une détection de défaillance de voisin plus rapide que la détection de défaillance IGP, soutenant ainsi une protection ou un routage plus rapide des tunnels LSP.
Le format du message RSVP Hello est le suivant :
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
Le format de l'objet HELLO est le suivant :
Class = 8, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 8 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Instance | Destination Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les messages Hello sont échangés périodiquement entre les voisins RSVP adjacents. Si, pendant un intervalle configurable, aucun message Hello de la part de l'homologue n'est reçu, ce voisin est considéré comme inaccessible et déclenche le traitement d'erreur correspondant (par exemple, la révocation de tous les états Path et Resv passant par ce voisin, et le déclenchement du routage du tunnel LSP).
6. Considérations de sécurité
Les messages RSVP sont utilisés pour établir et maintenir des tunnels LSP, affectant directement l'état de transfert et les ressources du réseau. Par conséquent, le plan de contrôle RSVP-TE est confronté à plusieurs menaces de sécurité, notamment :
- de faux messages Path ou Resv entraînant une liaison de label erronée ou un épuisement des ressources ;
- un routage explicite non autorisé dirigeant le trafic à travers des liaisons sensibles ;
- des attaques par messages de rafraîchissement ou par état provoquant l'épuisement du CPU du plan de contrôle ;
- la fuite d'informations de topologie du réseau via l'objet RECORD_ROUTE.
Pour atténuer ces menaces, le déploiement DEVRAIT (should) utiliser l'authentification RSVP (par exemple l'objet RSVP INTEGRITY ou IPsec), filtrer les pairs du plan de contrôle (par exemple en limitant les voisins RSVP via des ACL) et limiter l'exposition de la base de données d'ingénierie de trafic. De plus, une limitation de débit devrait être mise en œuvre pour résister aux attaques par déni de service. Pour le modèle de menace détaillé et les mesures d'atténuation, voir les documents de sécurité connexes et les BCP ultérieurs.
7. Traitement des messages RSVP par les routeurs de commutation de labels (LSR)
La présente section décrit les règles détaillées du traitement par un LSR à capacité MPLS des messages RSVP pour l'établissement de tunnels LSP.
7.1 Traitement du message Path
Lorsqu'un LSR reçoit un message Path, il effectue les opérations suivantes :
- Si le message Path contient l'objet LABEL_REQUEST, le LSR doit attribuer un label pour le tunnel LSP (sauf s'il s'agit du LSR de sortie, auquel cas le label est déterminé par la sortie en fonction du L3PID).
- Si le message Path contient l'objet EXPLICIT_ROUTE, le LSR sélectionne le prochain saut selon les règles de l'ERO.
- Si le message Path contient l'objet RECORD_ROUTE, le LSR ajoute sa propre adresse ou son identificateur d'interface au RRO.
- Le LSR propage le message Path modifié (avec l'ERO dépilé/mis à jour et le RRO auquel ce nœud a été ajouté) vers l'aval.
7.2 Traitement du message Resv
Lorsqu'un LSR reçoit un message Resv, il effectue les opérations suivantes :
- Le LSR extrait du message Resv, depuis l'objet LABEL, le label attribué par son voisin aval.
- Le LSR attribue un label pour lui-même (destiné à son voisin amont) et le place dans l'objet LABEL pour le propager vers l'amont.
- Si le message Resv contient l'objet RECORD_ROUTE, le LSR ajoute son propre enregistrement de label au RRO (lorsque le drapeau « enregistrement de label souhaité » de SESSION_ATTRIBUTE est positionné).
- Le LSR envoie le message Resv vers l'amont le long du chemin inverse de l'état Path.
7.3 Démantèlement d'un tunnel LSP
Un tunnel LSP peut être démantelé en envoyant un message PathTear ou ResvTear. Le message PathTear est envoyé dans le sens de l'état Path et supprime tous les états Path le long du chemin. Le message ResvTear est envoyé dans le sens de l'état Resv et supprime tous les états Resv le long du chemin. Lorsque le LSR d'entrée n'a plus besoin du tunnel LSP, il envoie un message PathTear ; lorsque le LSR de sortie décide de terminer le tunnel LSP, il envoie un message ResvTear.
7.4 Traitement des erreurs
Lorsqu'un LSR rencontre une erreur (par exemple, ERO non satisfaisable, échec d'attribution de label, ressources insuffisantes ou objet inconnu) lors du traitement d'un message RSVP, il doit générer un message d'erreur correspondant (PathErr ou ResvErr) et y transporter le code d'erreur et les informations sur le nœud en erreur. Le LSR d'entrée peut utiliser ces informations pour sélectionner un chemin alternatif ou prendre d'autres mesures correctives. Les règles détaillées de traitement des erreurs sont données à l'annexe A.
8. Options pour la signalisation des tunnels LSP
La présente section décrit plusieurs mécanismes optionnels pouvant être utilisés pour renforcer les capacités de signalisation des tunnels LSP, notamment :
- la préemption et le traitement des priorités ;
- l'affinité de classe de ressources (groupes d'administration et exclusion de groupes d'administration) ;
- l'ingénierie de trafic sensible à la différenciation de services (DiffServ) ;
- la signalisation LSP point-à-multipoint (P2MP) (définie dans des documents ultérieurs).
Ces options sont réalisées en fixant les drapeaux et champs correspondants dans l'objet SESSION_ATTRIBUTE et d'autres objets étendus.
9. Compatibilité ascendante avec RSVP
Les extensions RSVP définies dans le présent document sont conçues pour être compatibles ascendamment avec les implémentations RSVP existantes. Un nœud RSVP ne prenant pas en charge les extensions de tunnel LSP traitera les nouveaux objets selon la sémantique des deux bits de poids fort de la classe d'objet (class-num) :
- si les deux bits de poids fort sont 0b01 (ignorable), le nœud peut ignorer l'objet inconnu et continuer le traitement du message ;
- si les deux bits de poids fort sont 0b10 (reconnaissable), le nœud doit renvoyer une erreur (PathErr ou ResvErr), car l'objet inconnu peut affecter le bon fonctionnement.
Les objets LABEL_REQUEST, LABEL et EXPLICIT_ROUTE appartiennent tous à la classe « reconnaissable » (0b10), aussi les nœuds qui ne les prennent pas en charge renvoient une erreur, empêchant ainsi l'établissement d'un tunnel LSP incomplet.
10. Orientations futures
La présente spécification pourrait être étendue dans les domaines suivants :
- la prise en charge des LSP point-à-multipoint (P2MP) et multipoint-à-multipoint (MP2MP) ;
- la prise en charge du MPLS générique (GMPLS), incluant les liaisons à multiplexage temporel (TDM), à commutation de longueur d'onde et à commutation de fibre optique ;
- des mécanismes renforcés de reroutage rapide (Fast Reroute, FRR) ;
- une intégration plus étroite avec la différenciation de services (DiffServ) et l'ingénierie de trafic.
11. Références
11.1 Références normatives
- [RFC 2119] Bradner, S., « Mots clés pour les niveaux d'exigence des RFC », BCP 14, RFC 2119, mars 1997.
- [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. et S. Jamin, « Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification », RFC 2205, septembre 1997.
- [RFC 2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. et J. McManus, « Requirements for Traffic Engineering Over MPLS », RFC 2702, septembre 1999.
- [RFC 3031] Rosen, E., Viswanathan, A. et R. Callon, « Multiprotocol Label Switching Architecture », RFC 3031, janvier 2001.
11.2 Références
- [RFC 3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. et A. Conta, « MPLS Label Stack Encoding », RFC 3032, janvier 2001.
- [RFC 3212] Jamoussi, B. et al., « Constraint-Based LSP Setup using LDP », RFC 3212, janvier 2002.
- autres RFC ultérieures (documents définissant le reroutage rapide, GMPLS, P2MP, etc.).
Annexe A. Traitement des erreurs
La présente annexe décrit les règles de traitement des erreurs lors de l'établissement d'un tunnel LSP.
A.1 Message PathErr
Lorsqu'un LSR rencontre une erreur lors du traitement d'un message Path, il génère un message PathErr contenant :
- le code d'erreur (par exemple, classe d'objet inconnue, ERO non satisfaisable, ressources insuffisantes, échec d'attribution de label) ;
- le sous-code d'erreur (fournissant des informations plus détaillées) ;
- l'identificateur du nœud en erreur (généralement l'adresse du LSR ayant produit l'erreur).
Le message PathErr est envoyé le long du chemin inverse du message Path et atteint finalement le LSR d'entrée.
A.2 Message ResvErr
Lorsqu'un LSR rencontre une erreur lors du traitement d'un message Resv, il génère un message ResvErr contenant des codes d'erreur, sous-codes et informations de nœud en erreur similaires. Le message ResvErr est envoyé le long du chemin inverse du message Resv et atteint finalement le LSR de sortie.
A.3 Codes d'erreur courants
Le tableau suivant répertorie les codes d'erreur courants lors de l'établissement d'un tunnel LSP.
| Code d'erreur | Signification |
|---|---|
| Classe d'objet inconnue | réception d'un objet reconnaissable inconnu |
| ERO non satisfaisable | impossible d'établir le LSP selon le routage spécifié par l'ERO |
| Ressources insuffisantes | bande passante ou ressources de labels insuffisantes |
| Échec d'attribution de label | impossible d'attribuer le label demandé |
| L3PID non pris en charge | protocole L3 demandé non pris en charge |
Annexe B. Traitement des messages RSVP dans les LSR à prise en charge multiprotocole
La présente annexe décrit les considérations particulières pour le traitement des messages RSVP dans les LSR possédant à la fois une capacité de commutation de paquets (PSC) et une capacité de commutation de circuit (telle qu'ATM, Relais de trame).
B.1 Codage des labels sur interface ATM
Pour une interface ATM, la valeur de label de l'objet LABEL est codée comme une paire VPI/VCI. L'objet LABEL_REQUEST utilise C-Type = 2 et transporte la plage VPI/VCI.
B.2 Codage des labels sur interface Relais de trame
Pour une interface Relais de trame, la valeur de label de l'objet LABEL est codée comme un DLCI. L'objet LABEL_REQUEST utilise C-Type = 3 et transporte la plage DLCI.
B.3 Interfaces non numérotées
Pour les interfaces non numérotées (Unnumbered), un sous-objet spécial (type 5) est utilisé dans l'ERO et le RRO pour identifier l'interface. Une interface non numérotée est identifiée par son « Router ID » et son « index d'interface ».
12. Remerciements
Les auteurs remercient les nombreux relecteurs pour leurs contributions et leurs retours sur le présent document, y compris plusieurs membres du groupe de travail MPLS.
13. Adresses des auteurs
Daniel O. Awduche
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Lou Berger
MPLS Network Working Group
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
Tony Li
Procket Networks
1100 Cadillac Court
Milpitas, CA 95035
Vijay Srinivasan
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
14. Avis de droit d'auteur
Copyright (C) L'Internet Society (2001). Tous droits réservés.
Le présent document et ses traductions peuvent être copiés et fournis à d'autres personnes, et sont considérés comme ne pas entraîner de frais lorsqu'ils sont copiés, présentés, cités ou utilisés à d'autres fins, à condition que toutes les copies et œuvres dérivées susmentionnées contiennent cet avis de droit d'auteur et les droits, restrictions et clauses de non-responsabilité énoncés dans le présent document. Toutefois, le document lui-même ne peut être modifié de quelque manière que ce soit, par exemple en supprimant l'avis de droit d'auteur ou les références à l'Internet Society ou à d'autres organisations Internet, sauf lorsque cela est nécessaire aux fins du processus des normes Internet, auquel cas les procédures de droit d'auteur définies dans les normes Internet doivent être suivies, ou lorsque cela est requis pour le traduire dans une langue autre que l'anglais.
Les permissions limitées accordées ci-dessus sont permanentes et ne seront pas révoquées par l'Internet Society ou ses successeurs ou ayants droit.
Le présent document et les informations qu'il contient sont fournis « EN L'ÉTAT » (AS IS) et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRESSES OU IMPLICITES, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE SELON LAQUELLE L'UTILISATION DES INFORMATIONS CONTENUES DANS LE PRÉSENT DOCUMENT NE PORTERA ATTEINTE À AUCUN DROIT OU TOUTE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.
Remerciements
Le financement de la fonction d'édition des RFC est actuellement assuré par l'Internet Society.