RFC 3209 - RSVP-TE : Extensions à RSVP pour les Tunnels LSP
- Statut: Proposed Standard
- Publié: December 2001
- Stream: IETF
- Errata: Pas d'errata
Résumé (Abstract)
Ce document décrit l'utilisation du protocole de réservation de ressources (RSVP) pour établir des chemins à commutation d'étiquettes (LSP) dans les réseaux MPLS (Multiprotocol Label Switching). Les LSP établis à l'aide de RSVP peuvent être utilisés avec ou sans capacité de routage explicite. Lorsque le routage explicite est utilisé, RSVP-TE permet l'instanciation de LSP qui diffèrent du chemin le plus court calculé par le protocole de routage de la couche réseau. Cette capacité est essentielle pour l'ingénierie de trafic et pour fournir des services différenciés.
1. Introduction
Le Multiprotocol Label Switching (MPLS) [2] est une technologie qui combine le transfert par commutation d'étiquettes avec le routage de la couche réseau. Une application fondamentale de MPLS est l'ingénierie de trafic (TE) [3]. L'ingénierie de trafic permet aux opérateurs de réseau de contrôler le chemin du trafic à travers le réseau pour optimiser l'utilisation des ressources et les performances du réseau.
Pour prendre en charge l'ingénierie de trafic MPLS, un mécanisme est nécessaire pour établir et maintenir des chemins à commutation d'étiquettes (LSP). RSVP [1] est un protocole de signalisation mature qui a été étendu pour prendre en charge l'établissement de LSP. Ce document définit les extensions à RSVP pour prendre en charge l'établissement de LSP MPLS, en particulier pour les applications d'ingénierie de trafic.
Les extensions définies dans ce document permettent d'utiliser RSVP pour :
- Établir des LSP routés explicitement.
- Réacheminer des LSP en utilisant la méthode "make-before-break" (établir avant de rompre).
- Prendre en charge la détection de boucles LSP.
- Prendre en charge la distribution d'étiquettes pendant le processus d'établissement du LSP.
2. Terminologie (Terminology)
Ce document utilise la terminologie définie dans la RFC 3031 [2] et la RFC 2205 [1]. En outre, les termes suivants sont utilisés :
- Tunnel LSP (LSP Tunnel) : Un tunnel établi par un chemin à commutation d'étiquettes dans un réseau MPLS.
- LSP ID : Un identifiant utilisé pour identifier un LSP particulier.
- Tunnel ID : Un identifiant utilisé pour identifier un tunnel d'ingénierie de trafic, qui peut contenir un ou plusieurs LSP.
- Extended Tunnel ID : Un identifiant utilisé pour identifier de manière unique un tunnel globalement.
3. Aperçu des extensions RSVP (Overview of RSVP Extensions)
Le protocole RSVP établit et maintient l'état de réservation des ressources via les messages Path et Resv. Pour prendre en charge les tunnels LSP, plusieurs nouveaux objets ont été introduits :
- Objet LABEL_REQUEST : Transporté dans les messages Path, il demande l'allocation d'une étiquette aux nœuds en aval.
- Objet LABEL : Transporté dans les messages Resv, il distribue l'étiquette allouée aux nœuds en amont.
- Objet EXPLICIT_ROUTE (ERO) : Transporté dans les messages Path, il spécifie le chemin explicite que le LSP doit emprunter.
- Objet RECORD_ROUTE (RRO) : Transporté dans les messages Path et Resv, il enregistre le chemin réel et les étiquettes empruntés par le LSP.
- Objet SESSION_ATTRIBUTE : Transporté dans les messages Path, il contrôle les attributs du LSP tels que la priorité, la préemption et l'affinité.
4. Définitions des objets (Object Definitions)
4.1. Objet LABEL
L'objet LABEL est utilisé pour transporter l'étiquette allouée dans les messages Resv.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Objet LABEL_REQUEST
L'objet LABEL_REQUEST est utilisé pour demander une liaison d'étiquette dans les messages Path.
Class = 19, C_Type = 1 (Sans plage d'étiquettes)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L3PID identifie le protocole de couche 3 transporté sur ce chemin (généralement Ethertype).
4.3. Objet EXPLICIT_ROUTE (ERO)
L'ERO est utilisé pour spécifier des chemins explicites. Il contient une série de sous-objets (Subobjects), chacun représentant un nœud abstrait sur le chemin.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les types de sous-objets incluent :
- Type 1 : Préfixe IPv4
- Type 2 : Préfixe IPv6
- Type 32 : Numéro de système autonome (AS Number)
Chaque sous-objet possède également un bit L (Loose bit). Si L=0, cela indique un saut strict (Strict hop) ; si L=1, cela indique un saut lâche (Loose hop).
4.4. Objet RECORD_ROUTE (RRO)
Le RRO est utilisé pour enregistrer le chemin réel emprunté par le LSP. Il peut également inclure des informations sur les étiquettes.
Class = 21, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5. Objet SESSION_ATTRIBUTE
Cet objet contrôle les attributs de la session, tels que la priorité et l'affinité des ressources.
Class = 207, C_Type = 7 (LSP_TUNNEL)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le champ Flags définit les drapeaux suivants :
- 0x01 : Local protection desired (Protection locale/réacheminement rapide souhaité)
- 0x02 : Label recording desired (Enregistrement d'étiquette souhaité)
- 0x04 : SE Style desired (Style SE souhaité, pour le make-before-break)
4.6. Objets SESSION et SENDER_TEMPLATE
De nouveaux C-Types sont définis pour prendre en charge les tunnels LSP.
- LSP_TUNNEL_IPv4 Session Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Session Object (C-Type = 8)
Contient le Tunnel ID et l'Extended Tunnel ID.
- LSP_TUNNEL_IPv4 Sender Template Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Sender Template Object (C-Type = 8)
Contient le LSP ID.
5. Extension Hello (Hello Extension)
L'extension RSVP Hello permet aux nœuds RSVP de détecter lorsqu'un nœud voisin est inaccessible. Cela fournit un mécanisme de détection de défaillance de nœud à nœud.
Format du message Hello :
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
L'objet HELLO (Class 22) a deux types :
- HELLO REQUEST (C-Type = 1)
- HELLO ACK (C-Type = 2)
Ils contiennent les valeurs d'instance source (Src_Instance) et d'instance de destination (Dst_Instance) pour détecter les redémarrages de nœuds ou les pertes de communication.
6. Considérations de sécurité (Security Considerations)
En principe, ces extensions ne posent pas plus de risques de sécurité que la RFC 2205 [1]. Cependant, il y a un léger changement dans le modèle de confiance. Comme le trafic est transféré en fonction des étiquettes, un administrateur peut souhaiter limiter le domaine sur lequel les tunnels LSP peuvent être établis.
7. Considérations IANA (IANA Considerations)
Ce document définit de nouveaux numéros de classe d'objets (Class Numbers) et types (C-Types), ainsi que des codes d'erreur.
8. Références (References)
[1] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205. [2] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031. [3] Awduche, D., et al., "Requirements for Traffic Engineering over MPLS", RFC 2702.
Note du traducteur : Ce document est une traduction de référence en français de la RFC 3209.