Groupe de travail Réseau	J. Polk, Cisco Systems	
Request for Comments : 4495	S. Dhesikan, Cisco Systems	
RFC mise à jour : 2205	mai 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Extension au protocole de réservation de ressource pour la réduction de la bande passante d'un flux de réservation

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2006).

Résumé
Le présent document propose une extension au protocole de réservation de ressource (RSVP, Resource Reservation Protocol) pour réduire la bande passante allouée garantie à une réservation existante. Ce mécanisme peut être utilisé pour affecter les réservations individuelles, les réservations agrégées, ou d'autres formes de tunnels RSVP. La présente spécification est une extension de la RFC 2205.
Table des matières
1. Introduction	1
1.1 Terminologie et conventions	2
2. Scénario de réduction de réservation individuelle	2
3. Vue d'ensemble de l'agrégation RSVP	3
3.1 Scénario de réduction d'agrégation RSVP	5
4. Exigences pour la réduction de réservation	5
5. Solution de la réduction de bande passante RSVP	5
5.1 Code d'erreur de préemption partielle	6
5.2 Descripteur de flux erroné	6
5.3 Réduction de flux de réservation individuels	6
5.4 Réduction par agrégation de flux individuels	6
5.5 Réduction de flux RSVP impliquant des tunnels IPsec	7
5.6 Réduction de flux multiples en une seule fois	7
6. Rétro compatibilité	7
7. Considérations sur la sécurité	8
8. Considérations relatives à l'IANA	8
9. Remerciements	8
10. Références	8
10.1 Références normatives	8
10.2 Références pour information	9
Appendice A. En marche vers la solution	9
Adresse des auteurs	11
Déclaration complète de droits de reproduction	11

 	1.	Introduction
Le présent document propose une extension au protocole de réservation de ressources (RSVP, Resource Reservation Protocol ) [RFC2205] pour permettre à une réservation existante d'être réduite en bande passante allouée au lieu de supprimer cette réservation quand une partie de cette bande passante de la réservation est nécessaire pour d'autres besoins. Plusieurs exemples existent dans lesquels ce mécanisme peut être utilisé.

La bande passante allouée à une réservation individuelle peut être réduite pour diverses raisons comme la préemption, etc. Dans de tels cas, quand toute la bande passante allouée à une réservation n'est pas nécessaire, la réservation n'a pas besoin d'être supprimée. La solution décrite dans le présent document permet aux points d'extrémité de négocier une nouvelle (inférieure) bande passante qui tombe au maximum ou en dessous de la nouvelle bande passante allouée par le réseau. En utilisant comme exemple une session vocale, cette indication dans RSVP pourrait conduire les points d'extrémité, utilisant un autre protocole comme le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261], à signaler un codec de bande passante inférieure et à conserver la réservation.

Avec l'agrégation RSVP [RFC3175], deux flux agrégés avec des niveaux de priorité différents peuvent traverser la même interface de routeur. Si cette interface de routeur atteint la capacité de bande passante et qu'on lui demande ensuite d'établir une nouvelle réservation ou d'augmenter une réservation existante, le routeur doit faire un choix : refuser la nouvelle demande (parce que toutes les ressources sont utilisées) ou préempter une réservation existante de priorité inférieure pour faire de la place pour la réservation nouvelle ou étendue.

Si le flux préempté est un agrégat de nombreux flux individuels, cela a de plus grandes conséquences. Alors que la [RFC3175] ne termine clairement pas les flux individuels si un agrégat est supprimé, cet événement va faire que les paquets vont être éliminés durant le rétablissement de la réservation agrégée. Le présent document décrit une méthode où seulement le minimum requis de bande passante est retiré de la réservation agrégée de priorité inférieure et la réservation entière n'est pas préemptée. Ceci présent l'avantage que seulement certains des micro flux qui constituent l'agrégat sont affectés. Sans cette extension, tous les flux individuels seraient affectés et le désagrégateur devrait tenter la demande de réservation avec une bande passante réduite.

Les tunnels RSVP qui utilisent IPsec [RFC2207] exigent aussi une indication que la réservation doit être réduite d'une certaine quantité (ou moins). L'agrégation RSVP avec des tunnels IPsec est définie dans la [RFC4860], qui devrait être capable de tirer parti du mécanisme créé par la présente spécification.

Noter que quand le présent document se réfère à une interface de routeur qui est "pleine" ou "à capacité", cela n'implique pas que toute la bande passante a été utilisée, mais plutôt que toute la bande passante disponible pour la ou les réservations via RSVP sous la politique applicable a été utilisée. Les politiques pour le trafic en temps réel réservent généralement des capacités pour l'acheminement et des applications non élastiques, et peuvent distinguer entre la voix, la vidéo, et les autres applications en temps réel.

La notification explicite d'encombrement (ECN, Explicit Congestion Notification) [RFC3168] est une indication que le point d'extrémité émetteur doit réduire ses émissions. Elle ne fournit pas une indication suffisante pour dire au point d'extrémité de combien la réduction devrait être. Donc, l'application peut avoir à essayer plusieurs fois avant qu'elle soit capable de diminuer son utilisation de la bande passante en dessous de la limite disponible. Donc, alors qu'on considère que ECN est très utile avec les applications élastiques, elle n'est pas suffisante pour les besoins d'une application inélastique lorsque une indication de disponibilité de bande passante est utile pour le choix du codec.

La Section 2 discute du problème du flux de réservation individuelle, la Section 3 discute du problème de l'espace de flux de réservation agrégé. La Section 4 fait la liste des exigences pour cette extension. La Section 5 détaille les changements du protocole nécessaires dans RSVP pour créer une indication de réduction de réservation. Et finalement, l'appendice donne un exemple de la façon dont la présente extension modifie les fonctions de RSVP dans un scénario d'agrégation.

Le présent document met à jour la [RFC2205], car ce mécanisme affecte le comportement des indications ResvErr et ResvTear définies dans ce document.

 	1.1	Terminologie et conventions
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Scénario de réduction de réservation individuelle

La Figure 1 est une topologie de réseau qui est utilisée pour décrire les avantages de la réduction de bande passante dans une réservation individuelle.

               +------------+            +------------+
               |     |Int 1 |            |Int 7 |     |
   Flux 1===>  |     +----- |            |------+     | Flux 1===>
               | R1  |Int 2 |===========>|Int 8 | R2  |
               |     |      |:::::::::::>|      |     |
   Flux 2:::>  |     +----- |            |------+     | Flux 2:::>
               |     |Int 3 |            |Int 9 |     |
               +------------+            +------------+

Figure 1. Flux de réservation simples

Légende :
- priorité du flux 1 = 300
- priorité du flux 2 = 100
- Les deux flux sont montrés dans la même direction (gauche à droite). Les flux correspondants dans la direction inverse ne sont pas montrés pour simplifier le diagramme.

RSVP est un protocole d'établissement de réservations dans une direction seulement. Cette philosophie de chemin séparé est parce que le chemin d'un appareil à l'autre dans une direction peut ne pas être le chemin pour les communications entre les deux mêmes points d'extrémité dans la direction inverse. Les systèmes d'extrémité doivent demander deux réservations unidirectionnelles si c'est ce qui est nécessaire pour une application particulière (comme les appels vocaux). Prière de se référer à la [RFC2205] pour les détails de la façon dont cela fonctionne. Cet exemple décrit seulement le scénario de réservation dans une seule direction par souci de simplicité.

La Figure 1 décrit deux routeurs (R1 et R2) initialement avec seulement un flux (Flux 1). Les flux sont transmis de R1 à R2 via Int 2. Pour cet exemple, disons que Flux 1 et Flux 2 exigent chacun 80 unités de bande passante (comme pour le codec G.711 sans suppression de silence).

Disons aussi que la limite de bande passante RSVP pour Int 2 de R1 est 100 unités.

Comme décrit dans la [RFC3181], une indication de priorité est établie pour chaque flux. En fait, ce sont deux indications de priorité :
1) une pour établir la réservation, 
2) une pour défendre la réservation.

Dans cet exemple, Flux 1 et Flux 2 ont une priorité "d'établissement" et une priorité "de défense" de 300 et 100, respectivement. Le Flux 2 va avoir une priorité d'établissement supérieure à la priorité qu'a le Flux 1 pour sa défense. Cela signifie que quand le Flux 2 est signalé, et si aucune bande passante n'est disponible à l'interface, le Flux 1 va devoir libérer de la bande passante en faveur de la demande de priorité supérieure de Flux 2. Les priorités allouées à une réservation sont toujours de bout en bout, et ne sont pas altérées par les routeurs dans le transit.

Sans le bénéfice de cette spécification, Flux 1 va être préempté. La présente spécification rend possible que le message ResvErr indique que 20 unités sont encore disponibles pour qu'une réservation reste active (les 100 unités maximum de l'interface moins les 80 unités du Flux 2). Le nœud qui initie la réservation (routeur ou système d'extrémité) pour Flux 1 a l'opportunité de renégocier (via la signalisation d'appel) des paramètres acceptables au sein de la bande passante existante et disponible pour le flux (par exemple, il peut décider de passer à l'utilisation d'un codec G.729).

Les problèmes évités avec l'échec partiel du flux sont :
-	une réduction de la perte de paquets, qui résulte des tentatives de Flux 1 de rétablir la réservation sur une bande passante inférieure.
-	l'inefficacité causée par de multiples tentatives jusqu'à ce que Flux 1 soit capable de demander une bande passante égale ou inférieure à ce qui est disponible. Si Flux 1 est établi avec beaucoup moins que ce qui est disponible, cela mène alors à une utilisation inefficace de la bande passante disponible.

 	3.	Vue d'ensemble de l'agrégation RSVP

La vue d'ensemble de réseau suivante est pour aider à visualiser les problèmes que vise à traiter la présente spécification dans les agrégats RSVP. La Figure 2 comporte 10 routeurs (les boîtes) et 11 flux (1, 2, 3, 4, 5, 9, A, B, C, D, et E). Initialement, il y aura 5 flux par agrégat (Flux 9 sera introduit pour causer le problème que traite le présent document) avec 2 agrégats (X et Y) ; les flux 1 à 5 dans l'agrégat X et les flux A à E dans l'agrégat Y. Ces 2 agrégats vont traverser une interface de routeur en utilisant toute la capacité disponible (dans cet exemple).

L'agrégation RSVP (selon la [RFC3175]) n'est pas différente d'une réservation individuelle pour ce qui est d'être unidirectionnelle.

           Agrégateur de X                           Désagrégateur de X
                |                                          |
                V                                          V
             +------+   +------+            +------+   +------+
    Flux 1-->|      |   |      |            |      |   |      |-->Flux 1
    Flux 2-->|      |   |      |            |      |   |      |-->Flux 2
    Flux 3-->|      |==>|      |            |      |==>|      |-->Flux 3
    Flux 4-->|      | ^ |      |            |      | ^ |      |-->Flux 4
    Flux 5-->|      | | |      |            |      | | |      |-->Flux 5
    Flux 9   |  R1  | | |  R2  |            |  R3  | | |  R4  |   Flux 9
             +------+ | +------+            +------+ | +------+
                      |   ||                  ||     |
              Agrégat X-->||      Agrégat X   ||<--Agrégat X
                          ||        |         ||
               +--------------+     |      +--------------+
               |       |Int 7 |     |      |Int 1 |       |
               |       +----- |     V      |------+       |
               |   R10 |Int 8 |===========>|Int 2 | R11   |
               |       |      |:::::::::::>|      |       |
               |       +----- |     ^      |------+       |
               |       |Int 9 |     |      |Int 3 |       |
               +--------------+     |      +--------------+
                          ..        |        ..
             Agrégat Y--->..      Agrégat Y  ..<---Agrégat Y
                     |    ..                 ..     |
            +------+ | +------+            +------+ | +------+
   Flux A-->|      | | |      |            |      | | |      |-->Flux A
   Flux B-->|      | V |      |            |      | V |      |-->Flux B
   Flux C-->|      |::>|      |            |      |::>|      |-->Flux C
   Flux D-->|      |   |      |            |      |   |      |-->Flux D
   Flux E-->|  R5  |   |  R6  |            |  R7  |   |  R8  |-->Flux E
            +------+   +------+            +------+   +------+
               ^                                         ^
               |                                         |
       Agrégateur de Y                              Désagrégateur de Y

Figure 2 : Topologie générique d'agrégat RSVP

Légende :
- priorité de l'agrégat X = 100
- priorité de l'agrégat Y = 200
- toutes les boîtes sont des routeurs
- Les deux agrégats sont montrés dans la même direction (gauche à droite). Les agrégats correspondants dans la direction inverse ne sont pas montrés pour simplifier le diagramme.

Le chemin pour l'agrégat X est : R1 => R2 => R10 => R11 => R3 => R4
où l'agrégat X commence en R1, et se désagrège en R4. Les flux 1, 2, 3, 4, 5, et 9 communiquent à travers l'agrégat A.

Le chemin pour l'agrégat Y est : R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8
où l'agrégat Y commence en R5, et se désagrège en R8. Les flux A, B, C, D, et E communiquent à travers l'agrégat B.

Les deux agrégats partagent une branche ou liaison physique : entre R10 et R11, ils partagent donc une interface de sortie : Int 8 de R10, où un manque de ressources peut exister. Cette liaison a une capacité RSVP de 800 kbit/s. La signalisation RSVP (messages) est en dehors des 800 kbit/s dans cet exemple, tout comme tout protocole de signalisation de session comme SIP.

 	3.1	Scénario de réduction d'agrégation RSVP
La Figure 2 montre un agrégat de réservations (agrégat X) établi entre les routeurs R1 et R4. Cet agrégat de réservations consiste en 5 micro flux (Flux 1, 2, 3, 4, et 5). Pour cette discussion, supposons que chaque flux représente un appel vocal et exige 80 kbit/s (comme pour le codec G.711 sans suppression de silence). La demande de l'agrégat X est pour 400 kbit/s (80  kbit/s * 5 flux). La priorité de l'agrégat est déduite des micro flux individuels dont il est constitué. Dans le cas simple, tous les flux d'une seule priorité sont groupés en un seul agrégat (un autre niveau de priorité serait un autre agrégat, même si ils traversent le même chemin à travers le réseau. Il peut y avoir d'autres façons de déduire la priorité de l'agrégat, mais pour cette discussion il est suffisant de noter que chaque agrégat contient une priorité (priorité à la fois de garde et de défense). Les moyens par lesquels est déduite la priorité sortent du domaine de cette discussion.

L'agrégat Y, dans la Figure 2, consiste en les flux A, B, C, D, et E et exige 400 kbit/s (80 kbit/s * 5 flux) et commence à R5 et se termine à R8. Cela signifie qu'il y a deux agrégats occupant tous les 800 kbit/s de la capacité RSVP.

Quand le flux 9 est ajouté à l'agrégat X, cela va occuper 80 kbit/s de plus que Int 8 sur R10 a de disponible (880 k de charge offerts contre une capacité de 800 k). La [RFC2205] et la [RFC3175] créent un comportement dans RSVP pour refuser l'agrégat Y entier et tous ses flux individuels parce que l'agrégat X a une priorité supérieure. Cette situation est là où le présent document concentre ses exigences et cherche une solution. Il devrait y avoir un moyen de signaler à tous les routeurs affectés de l'agrégat Y que seulement 80 kbit/s sont nécessaires pour traiter un autre agrégat (de priorité supérieure). Une solution qui réalise cette réduction au lieu d'un échec pourrait :
-	réduire de significatives pertes de paquet de tous les flux au sein de l'agrégat Y. Durant la période de demande de re-réservation, aucun paquet ne va traverser l'agrégat jusqu'à ce qu'il soit rétabli.
-	réduire les chances que le rétablissement de l'agrégat réserve une quantité inefficace de bande passante, causant la probable préemption de plus de flux individuels chez l'agrégateur qu'il serait nécessaire si l'agrégateur avait eu plus d'informations (que RSVP ne fournit pas pour l'instant)

Durant le rétablissement de l'agrégation dans la Figure 2 (sans modification de RSVP) R8 devrait deviner combien de bande passante demander dans le nouveau message RESV.  Il pourrait demander trop de bande passante, et devoir attendre l'erreur disant que cette quantité de bande passante n'est pas disponible ; il pourrait demander trop peu de bande passante et avoir cette agrégation acceptée, mais cela voudrait dire que plus de flux individuels que nécessaire devraient être préemptés en dehors de l'agrégat, conduisant à une inefficacité dans la direction opposée.

 	4.	Exigences pour la réduction de réservation

Les exigences suivantes sont nécessaires pour réduire la bande passante d'une réservation. Ceci s'applique aux réservations individuelles et agrégées :

Exigence n° 1 - DOIT avoir la capacité de différentier une réservation d'une autre. Dans le cas des agrégats, il DOIT distinguer un agrégat d'un autre flux.

Exigence n° 2 - DOIT avoir la capacité d'indiquer au sein d'un message d'erreur RSVP (généré au routeur qui a l'interface encombrée) qu'une réservation spécifique (individuelle ou agrégat) est à être réduite en bande passante.

Exigence n° 3 - DOIT avoir la capacité d'indiquer au sein du même message d'erreur la nouvelle quantité maximum de bande passante disponible pour être utilisée dans la réservation existante, mais pas plus.

Exigence n° 4 – Il NE DOIT PAS se produire un cas où les indications de réduction retransmises réduisent encore plus la bande passante d'une réservation. Toute réduction supplémentaire de bande passante pour une réservation spécifiée DOIT être signalée dans un nouveau message.

Les messages RSVP ne sont pas fiables et peuvent être perdus. La présente spécification ne devrait transiger sur aucune erreur dans le réseau. Si un message de réduction est perdu, un autre doit être envoyé. Si le receveur finit pas recevoir deux copies pour réduire la bande passante d'une réservation d'une certaine quantité, il est probable que le routeur va réduire la bande passante de deux fois la quantité qui était réellement demandée. Ceci va être une erreur.

 	5.	Solution de la réduction de bande passante RSVP

Quand une réservation est un échec partiel, un message ResvErr (erreur de réservation) est généré tout comme il est fait actuellement avec les préemptions. L'objet ERROR_SPEC et l'objet PREEMPTION_PRI sont aussi inclus. Très peu d'ajouts/changements sont nécessaires au message ResvErr pour prendre en charge les préemptions partielles. Un nouveau sous code d'erreur est nécessaire et est défini au paragraphe 5.1. L'objet ERROR_SPEC contenu dans le message ResvErr indique la spécification de flux (flowspec) qui est réservée. L'indication de bande passante dans cette flowspec DEVRAIT être inférieure à la demande de réservation d'origine. Ceci est défini au paragraphe 5.2.

Commentaire sur les messages RESV qui n'utilisent pas un transport fiable : le présent document RECOMMANDE que les messages ResvErr soient rendus fiables en mettant en œuvre les mécanismes de la [RFC2961].

Le comportement actuel dans RSVP exige qu'un message ResvTear soit transmis vers l'amont quand le message ResvErr est transmis vers l'aval (selon la [RFC2205]). Ce message ResvTear termine la réservation dans tous les routeurs en amont du routeur où la défaillance s'est produite. Le présent document exige que le ResvTear soit seulement généré quand la réservation est à supprimer complètement. Dans les cas où la réservation est seulement réduite, il exige que les routeurs conformes à la présente spécification NE DOIVENT PAS envoyer le message ResvTear.

L'appendice a été rédigé pour parcourir la solution globale des problèmes présentés aux Sections 2 et 3. Il est fait mention du comportement de transmission de ce ResvTear dans l'appendice.

 	5.1	Code d'erreur de préemption partielle
Le message ResvErr généré à cause d'une préemption inclut l'objet ERROR_SPEC ainsi que l'objet PREEMPTION_PRI. Le format des objets ERROR_SPEC est défini dans la [RFC2205]. Le code d'erreur mentionné dans l'objet ERROR_SPEC pour la préemption [RFC2750] est actuellement comme suit :

Errcode = 2 (échec de contrôle de politique)
ErrSubCode = 5 (ERR_PREEMPT)

Le code d'erreur suivant est suggéré dans l'objet ERROR_SPEC pour la préemption partielle :

Errcode = 2 (échec de contrôle de politique)
ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)

Il y a aussi un code d'erreur dans l'objet PREEMPTION-PRI. Ce code d'erreur prend une valeur de 1 pour indiquer que le flux admis a été préempté [RFC3181]. La même valeur d'erreur de 1 peut aussi être utilisée pour le cas de préemption partielle.

 	5.2	Descripteur de flux erroné
Le descripteur d'erreur de flux est défini dans la [RFC2205] et la [RFC2210]. Dans le cas d'échec partiel, la flowspec contenue dans le descripteur d'erreur de flux indique les plus fortes moyennes et le débit de pointe que le système préempteur peut accepter dans le prochain message RESV. Le désagrégateur doit réduire sa réservation à un nombre inférieur ou égal à cela, soit en changeant de codec, soit en abandonnant des réservations, soit par un autre mécanisme.

 	5.3	Réduction de flux de réservation individuels
Quand un routeur requiert une partie de la bande passante qui a été allouée à une réservation à utiliser pour un autre flux, le routeur engage la réduction partielle de bande passante décrite dans le présent document. Le routeur envoie vers l'aval une ResvErr pour indiquer l'erreur partielle avec le code d'erreur et le sous code décrits au paragraphe 5.1. La flowspec contenue dans le message ResvErr va être utilisée pour indiquer la bande passante actuellement allouée.

Le point d'extrémité demandeur qui reçoit la ResvErr peut alors négocier avec le point d'extrémité transmetteur de diminuer l'exigence de bande passante (en choisissant un autre codec de bande passante inférieure, par exemple). Après la négociation, les deux points d'extrémité vont produire les messages RSVP PATH et RESV avec la nouvelle bande passante diminuée.

 	5.4	Réduction par agrégation de flux individuels
Quand un échec partiel se produit dans un scénario d'agrégation, le désagrégateur reçoit le message ResvErr avec l'indication de réduction de la part d'un routeur sur le chemin de l'agrégat. Il décide alors si un ou plusieurs flux individuels de l'agrégat vont être affectés par ce message ResvErr. Les choix suivants sont possibles :

o	Si ce routeur (désagrégateur) détermine qu'un ou plusieurs flux individuels sont à faire échouer partiellement, il envoie alors un message ResvErr avec une indication de bande passante réduite à ces flux individuels. Ceci suit la description du paragraphe 5.3.

o	Si ce routeur (désagrégateur) détermine que un flux individuel est à préempter pour satisfaire la ResvErr agrégée, il détermine quel flux est affecté. Ce routeur transmet un nouveau message ResvErr vers l'aval selon la [RFC3181]. Ce même routeur transmet un message ResvTear vers l'amont. Ce message ResvTear d'un flux individuel ne supprime pas l'agrégat. Seul le flux individuel est affecté.

o	Si ce routeur (désagrégateur) détermine que plusieurs flux individuels sont à préempter pour satisfaire la ResvErr agrégée, il choisit quels flux sont affectés. Ce routeur transmet un nouveau message ResvErr vers l'aval conformément à la [RFC3181] à chaque flux individuel. Le routeur transmet aussi des messages ResvTear vers l'amont pour le même flux individuel. Ces messages ResvTear d'un flux individuel ne suppriment pas l'agrégat. Seuls les flux individuels sont affectés.

Dans tous les cas, le désagrégateur diminue la bande passante demandée dans le message Resv agrégé pour refléter le changement.

La question du choix des flux ou séries de flux au sein d'un agrégat qui sont pris par le désagrégateur pour la réduction de bande passante ou la préemption sort du domaine d'application de ce document.

 	5.5	Réduction de flux RSVP impliquant des tunnels IPsec
La [RFC2207] spécifie comment les réservations RSVP fonctionnent dans un flux de données IPsec. Les nœuds qui initient des flux IPsec peuvent être un système d'extrémité comme un ordinateur, ou ils peuvent être un routeur entre deux systèmes d'extrémité, ou ils peuvent être un appareil de chiffrement brut en ligne immédiatement adjacent à une interface de routeur ; la [RFC4860] traite directement ce dernier scénario.

Les méthodes d'identification de IPsec avec flux de réservation sont différentes de celles des flux non chiffrés, mais la façon dont fonctionne le mécanisme de réduction spécifié dans ce document ne l'est pas.

Un IPsec avec flux de réservation est, dans tous les cas, considéré comme un flux individuel à l'égard de la façon de réduire la bande passante du flux. Évidemment, un IPsec avec flux de réservation peut être une série de flux individuels ou des paquets au mieux disjoints entre deux systèmes. Mais dans la présente spécification, ce tunnel est une réservation RSVP individuelle.

Partout dans la présente spécification où on mentionne un flux de réservation individuel, les mêmes règles de réduction de bande passante et de préemption DOIVENT s'appliquer.

 	5.6	Réduction de flux multiples en une seule fois
On notera à titre de précaution que la bande passante NE DEVRAIT PAS être réduite sur plusieurs réservations en même temps, en réaction au même événement de réduction. Un routeur qui ignore l'impact de la réduction de réservation de bande passante sur plus d'un flux peut causer plus d'effets néfastes largement étendus qu'il n'est nécessaire.

Ceci ne dit rien sur une politique où la préemption devrait ou non se produire sur plusieurs flux.

 	6.	Rétro compatibilité

La rétro compatibilité avec cette extension va résulter en ce que RSVP fonctionnera comme il le fait sans cette extension, et pas plus mal. Les deux routeurs impliqués dans cette extension sont le routeur qui avait l'interface encombrée et le routeur plus loin vers l'aval qui détermine quoi faire avec l'indication de réduction.

Dans le cas du routeur qui subit l'encombrement ou a par ailleurs besoin de réduire la bande passante d'une réservation existante :
- Si ce routeur prend cette extension en charge :
1 - il génère le message ResvErr avec le code d'erreur indiquant la réduction de bande passante.
2 – il ne génère pas de message ResvTear.
- Si ce routeur ne prend pas en charge cette extension, il génère les deux messages ResvErr et ResvTear conformément à la [RFC2205].

Dans le cas où le routeur le plus en aval d'une réservation qui reçoit le message ResvErr avec l'indication de réduction :
- Si ce routeur prend en charge l'extension :
- il traite ce message d'erreur et applique toute politiques locale qu'il est configuré à appliquer pour déterminer comment réduire la bande passante du flux désigné.
- Si le routeur ne prend pas en charge cette extension :
- il traite le message ResvErr conformément à la [RFC2205] et à toutes les extensions qu'il est capable de comprendre, mais pas l'extension du présent document.

Donc, cette extension ne cause pas d'effets néfastes dans RSVP si un ou plusieurs routeurs prennent en charge cette extension, et si un ou plusieurs routeurs ne la prennent pas en charge.

 	7.	Considérations sur la sécurité

Le présent document ne diminue pas la sécurité globale de RSVP ou des flux de réservation sur un agrégat.

Si cette spécification est mal mise en œuvre – ce qui n'est pas le but recherché, mais est à envisager – les problèmes suivants peuvent se poser :
1) Si les messages ResvTear sont transmis initialement (en même temps que les messages ResvErr indiquant qu'une réduction de bande passante est nécessaire) tous les routeurs en amont vont supprimer la réservation entière. Cela va libérer par inadvertance la quantité totale de bande passante de cette réservation. Cela peut causer l'échec du rétablissement d'une réservation qui serait bonne par ailleurs. Ceci a les plus sévères effets sur un agrégat qui a de nombreux flux individuels qui seraient restés opérationnels.
2) Tout comme RSVP a la vulnérabilité de la terminaison prématurée de réservations valides par des flux félons sans authentification [RFC2747], [RFC3097], ce mécanisme aura la même vulnérabilité. L'usage des mécanismes d'authentification de RSVP est conseillé.

 	8.	Considérations relatives à l'IANA

L'IANA a alloué ce qui suit à partir de la RFC 4495 (le présent document) :

Le code d'erreur suivant a été défini dans l'objet ERROR_SPEC pour l'échec partiel de réservation sous "Errcode = 2 (échec de contrôle de politique)" :

ErrSubCode = 102 (ERR_PARTIAL_PREEMPT)

Le comportement de ce ErrSubCode est défini dans ce document.

 	9.	Remerciements

Les auteurs tiennent à remercier Fred Baker de sa contribution au texte et de ses conseils dans cet effort, ainsi que Roger Levesque et Francois Le Faucheur pour leurs commentaires utiles.

 	10.	Références
 	10.1	Références normatives

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

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC2207]	L. Berger, T. O'Malley, "Extensions RSVP pour flux de données IPSEC", septembre 1997. (P.S.)

[RFC2210]	J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997. (P.S.)

[RFC2750]	S. Herzog, "Extensions à RSVP pour le contrôle de politique", janvier 2000. (P.S.)

[RFC2961]	L. Berger et autres, "Extensions de réduction de redondance de rafraîchissement pour RSVP", avril 2001. (MàJ par RFC5063) (P.S.)

[RFC3175]	F. Baker et autres, "Agrégation de RSVP pour réservations IPv4 et IPv6", septembre 2001. (MàJ par RFC5350) (P.S.)

[RFC3181]	S. Herzog, "Élément de politique de priorité par préemption signalée", octobre 2001. (Remplace RFC2751) (P.S.)

 	10.2	Références pour information

[RFC2747]	F. Baker, B. Lindell, M. Talwar, "Authentification cryptographique RSVP", janvier 2000. (MàJ par RFC3097) (P.S.)

[RFC3097]	R. Braden, L. Zhang, "Authentification cryptographique RSVP – mise à jour de la valeur de type de message", avril  2001. (P.S.)

[RFC3168]	K. Ramakrishnan et autres, "Ajout de la notification explicite d'encombrement (ECN) à IP", septembre 2001. (P.S. ; MàJ par RFC8311)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC4860]	F. Le Faucheur et autres, "Réservations génériques agrégées du protocole de réservations de ressources (RSVP)", mai  2007. (P.S.)

 	Appendice A.	En marche vers la solution

Voici une explication concise de la façon dont RSVP se comporte en gros avec la solution aux problèmes présentés dans les Sections 2 et 3 de ce document. Il n'y a pas de texte normatif dans cet appendice.

Voici un duplicata de la Figure 2 de la Section 3 du corps du document (pour être plus proche de la description détaillée de la solution).

       Agrégateur de X                              Désagrégateur de X
               |                                          |
               V                                          V
            +------+   +------+            +------+   +------+
   Flux 1-->|      |   |      |            |      |   |      |-->Flux 1
   Flux 2-->|      |   |      |            |      |   |      |-->Flux 2
   Flux 3-->|      |==>|      |            |      |==>|      |-->Flux 3
   Flux 4-->|      | ^ |      |            |      | ^ |      |-->Flux 4
   Flux 5-->|      | | |      |            |      | | |      |-->Flux 5
   Flux 9-->|  R1  | | |  R2  |            |  R3  | | |  R4  |-->Flux 9
            +------+ | +------+            +------+ | +------+
                     |    ||                  ||    |
             Agrégat X--->||      Agrégat X   ||<--Agrégat X
                          ||        |         ||
               +--------------+     |      +--------------+
               |       |Int 7 |     |      |Int 1 |       |
               |       +----- |     V      |------+       |
               |  R10  |Int 8 |===========>|Int 2 |  R11  |
               |       |      |:::::::::::>|      |       |
               |       +----- |     ^      |------+       |
               |       |Int 9 |     |      |Int 3 |       |
               +--------------+     |      +--------------+
                          ..        |        ..
             Agrégat Y--->..      Agrégat Y  ..<---Agrégat Y
                     |    ..                 ..     |
            +------+ | +------+            +------+ | +------+
   Flux A-->|      | | |      |            |      | | |      |-->Flux A
   Flux B-->|      | V |      |            |      | V |      |-->Flux B
   Flux C-->|      |::>|      |            |      |::>|      |-->Flux C
   Flux D-->|      |   |      |            |      |   |      |-->Flux D
   Flux E-->|  R5  |   |  R6  |            |  R7  |   |  R8  |-->Flux E
            +------+   +------+            +------+   +------+
               ^                                         ^
               |                                         |
       Agrégateur de Y                              Désagrégateur de Y

Duplicata de la Figure 2  : Topologie générique d'agrégat RSVP

Sur la Figure 2, l'agrégat X (avec cinq flux de 80 kbit/s) traverse : R1 ==> R2 ==> R10 ==> R11 ==> R3 ==> R4

Et l'agrégat Y (avec cinq flux de 80 kbit/s) traverse : R5 ::> R6 ::> R10 ::> R11 ::> R7 ::> R8

Les deux agrégats sont de 400 kbit/s. Cela fait un total de 800 kbit/s à Int 7 dans R10, qui est la bande passante maximum à laquelle RSVP a accès à cette interface. Les messages de signalisation traversent l'interface sans problème. L'agrégat X est à une priorité relative supérieure à celle de l'agrégat Y. La politique locale dans cet exemple est que le flux de priorité relative supérieure préempte les flux de priorité inférieure en période d'encombrement. Les points suivants décrivent les flux quand l'agrégat A est augmenté pour inclure le flux 9.

o	Quand le flux 9 (à 80 kbit/s) est ajouté à l'agrégat X, R1 va initier le message PATH vers le point d'extrémité de destination du flux. Ce message bond par bond va passer à travers R2, R10, R11, R3, et R4, qui est le chemin de l'agrégat X (qui a été construit selon la [RFC3175] à partir de l'établissement initial de l'agrégat) pour le nœud de point d'extrémité.

o	En réponse, R4 va générer le message RESV (réservation) (comportement défini selon la [RFC2205]). Cette RESV provenant du désagrégateur indique une augmentation de bande passante suffisante pour s'accommoder des cinq flux existants (1, 2, 3, 4, et 5) et du nouveau flux (9), comme établi dans la [RFC3175].

o	Comme mentionné précédemment, dans cet exemple, Int 8 dans R10 peut seulement s'accommoder de 800 kbit/s, et les agrégats X et Y ont chacun déjà établi des flux de 400 kbit/s composés des cinq flux individuels de 80 kbit/s. Donc, R10 (l'interface qui détecte un événement d'encombrement dans cet exemple) doit prendre une décision sur cette nouvelle condition qui génère un encombrement à l'égard du message RESV reçu à Int 8.

o	La politique locale dans ce scénario est de préempter les réservations de priorité inférieure pour placer les réservations  de priorité supérieure. Cela devrait normalement causer la préemption de tout l'agrégat Y juste pour s'accommoder de la demande de l'agrégat X pour 80 kbit/s supplémentaires.

o	Le présent document définit comment l'agrégat Y n'est pas complètement préempté, mais réduit en bande passante de 80 kbit/s. Ceci est contenu dans le message ResvErr que R10 génère (vers l'aval) vers R11, R7, et R8. Voir à la Section 5 les détails du message d'erreur.

o	Le fonctionnement normal de RSVP est que le routeur qui génère un message ResvErr vers l'aval génère aussi un message ResvTear vers l'amont (dans la direction opposée, c'est-à-dire, vers R5). Le message ResvTear termine un flux individuel ou un flux agrégé. Le présent document demande que, sur tout échec partiel de réservation, ce message ne soit pas envoyé.

o	R8 est le désagrégateur de l'agrégat Y. Le désagrégateur contrôle tous les paramètres d'une réservation d'agrégat. Ce sera le nœud qui réduit la bande passante nécessaire de l'agrégat en réponse à la réception d'un message ResvErr (provenant de R10) qui indique qu'une telle action est demandée. Dans cet exemple, la réduction de bande passante est accomplie par la préemption d'un flux individuel au sein de l'agrégat (peut-être en prenant sur le flux D pour une préemption individuelle en générant une ResvErr vers l'aval sur ce flux individuel).

o	En même temps, un message ResvTear est transmis vers l'amont sur ce flux individuel (flux D) par R8. Cela ne va pas affecter directement l'agrégat, mais c'est une indication aux routeurs (et au système d'extrémité de source) que le flux individuel va être préempté.

o	Une fois que R8 préempte un des flux individuels (ou la "bande passante" à l'entrée de l'agrégat) il transmet un nouveau message RESV pour cet agrégat (Y), et non pour un nouvel agrégat. Ce RESV du désagrégateur indique une diminution de bande passante suffisante pour s'accommoder des quatre flux restants (A, B, C, et E) qui est maintenant de 320  kbit/s (dans cet exemple).

o	Ces message RESV parcourt le chemin entier de la réservation, réglant tous les routeurs à cette nouvelle valeur de bande passante agrégée. Ceci devrait être ce qui est nécessaire pour empêcher un message ResvTear d'être généré par R10 vers R6 et R5.

R5 ne va pas savoir par ce message RESV quel flux individuel a été préempté. Si dans cet exemple, R8 avait eu plus de bande passante à conserver, il aurait pu transmettre une indication ResvErr de réduction de bande passante au système d'extrémité du flux D. Dans ce cas, un protocole de signalisation de la voix (comme SIP) aurait pu tenter une renégociation de ce flux individuel pour une bande passante réduite (par exemple en changeant le codec vocal de G.711 à G. 729). Cela aurait pu sauver le flux D de la préemption.

 	Adresse des auteurs
James M. Polk	Subha Dhesikan	
Cisco Systems	Cisco Systems	
2200 East President George Bush Turnpike	170 W. Tasman Drive	
Richardson, Texas 75082 	San Jose, CA 95134 	
USA	USA	
mél : jmpolk@cisco.com 	mél : sdhesika@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.