Groupe de travail Réseau	J. Rosenberg, Cisco
Request for Comments : 5390	décembre 2008
Catégorie : Information	
Traduction Claude Brière de L'Isle	

Exigences pour la gestion des surcharges dans le protocole d’initialisation de session (SIP)

Statut du présent mémoire
Le présent mémoire apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune forme de norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Une surcharge se produit dans les réseaux du protocole d’initialisation de session (SIP, Session Initiation ProtocolP) quand les mandataires et agents d'utilisateur ont des ressources insuffisantes pour terminer le traitement d’une demande. SIP fournit une prise en charge limitée du traitement de surcharge par son code de réponse 503, qui dit qu’un élément en amont est surchargé. Cependant, de nombreux problèmes ont été identifiés avec ce mécanisme. Le présent document résume les problèmes du mécanimse 503 existant, et donne des exigences pour une solution.
Table des matières
1. Introduction	1
2. Causes de surcharge	2
3. Terminologie	2
4. Mécanismes SIP actuels	3
5. Problèmes de ce mécanisme	3
5.1 Amplification de charge	3
5.2 Sous utilisation	5
5.3 Problème du réessai après arrêt/marche	5
5.4 Usages ambigus	5
6. Exigences pour une solution	6
7. Considérations sur la sécurité	8
8. Remerciements	8
9. Références	8
9.1 Références normatives	8
9.2 Références pour information	8
Adresse de l’auteur	8

 	1.	Introduction

Une surcharge se produit dans les réseaus de protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] quand des mandataires et agents d'utilisateur ont des ressources insuffisantes pour achever le traitement d’une demande ou réponse. SIP fournit une prise en charge limitée du traitement de surcharge par son code de réponse 503. Ce code permet à un serveur de dire d’un élément en amont qu’il est surchargé. Cependant, de nombreux problèmes ont été identifiés avec ce mécanisme.

Le présent document décrit le problème général de la surcharge SIP et revoit les mécanismes SIP actuels pour traiter de la surcharge. Il explique ensuite certains des problèmes de ces mécanismes. Finalement, le document donne un ensemble d’exigences pour corriger ces problèmes.

 	2.	Causes de surcharge

Une surcharge se produit quand un élément, comme un agent d'utilisateur ou mandataire SIP, a des ressources insuffisantes pour réussir à traiter tout le trafic qu’il reçoit. Les ressources incluent toutes les capacités de l’élément utilisé pour traiter une demande, incluant le traitement de CPU, la mémoire, l’entrée/sortie, ou les ressources de disque. Elles peuvent aussi inclure des ressources externes comme une base de données ou un serveur du DNS, et dans ce cas le traitement de CPU, le processeur, la mémoire, l’entrée/sortie, et les ressources de disque de ces serveurs font effectivement partie de l’élément logique qui traite la demande. Une surcharge peut survenir pour de nombreuses raisons, incluant  :

Faible programmation de capacités : les réseaux SIP doivent être dessinés avec un nombre suffisant de serveurs, matériels, disques, et ainsi de suite, afin de satisfaire les besoins des abonnés qu’ils sont supposés desservir. La programmation de capacités est le processus de détermination de ces besoins. Elle se fonde sur le nombre d’abonnés attendus et les types de flux qu’on s’attend qu’ils utilisent. Si ce travail n’est pas fait correctement, le réseau peut avoir une capacité insuffisante pour traiter les usages prévisibles, incluant des usages réguliers et des usages très prévisibles (comme de forts volumes d’appels vocaux le jour de la fête des mères).

Défaillances de dépendances : un élément SIP peut devenir surchargé parce qu’une ressource dont il dépend est défaillante ou devient surchargée, réduisant largement la capacité logique de l’élément. Dans ce cas, même un trafic minimal pourrait causer une surcharge du serveur. Des exemples de telles surcharges de dépendance incluent des serveurs DNS, des bases de données, des disques, et des interfaces réseau.

Défaillances de composant : un élément SIP peut devenir surchargé quand il est un membre d’une grappe de serveurs qui partagent chacun la charge du trafic, et qu’un ou plusieurs des autres membres de la grappe ont une défaillance. Dans ce cas, les éléments restants effectuent le travail des éléments défaillants. Normalement, la programmation de capacité prend en compte ces défaillances, et les serveurs fonctionnent normalement avec assez de capacités de réserve pour traiter la défaillance d’un autre élément. Cependant, une condition de défaillance inhabituelle peut causer la défaillance de nombreux éléments à la fois. C’est souvent le cas avec des défaillances de logiciel, où un mauvais paquet ou une mauvaise entrée de base de données déclenche la même faute dans un ensemble d’éléments d’une grappe.

Avalanche de rédémarrages : une des sources de surcharge les plus perturbatrices est l’avalanche de redémarrages. Cela se produit quand un grand nombre de clients tentent tous simultanément de se connecter au réseau avec un enregistrement SIP. L’avalanche de redémarrages peut être causée par plusieurs événements. L’un d’eux est le scénario des "réamorçages Manhattan", où il y a eu une panne d’électricité dans une grande zone métropolitaine, comme Manhattan.  Quand le courant est rétabli, tous les téléphones SIP, qu’ils soient dans un ordinateur personnel ou un appareil autonome, se rebranchent simultanément et commencent à s’amorcer. Il vont alors tous se connecter au réseau et s’enregistrer, causant une inondation de messages SIP REGISTER. Une autre cause d’avalanche de redémarrage est la défaillance de la connexion d’un grand réseau, par exemple, le routeur d’accès d’une entreprise. Quand il a une défaillance, les clients SIP vont rapidement détecter la défaillance en utilisant les mécanismes de la [RFC5626]. Quand la connexité est restaurée, c’est détecté, et les clients refont un REGISTER, tous dans une courte période de temps. Une autre source d’avalanche de redémarrage est la défaillance d’un serveur mandataire. Si les clients s’étaient tous connectés au serveur avec TCP, sa défaillance va être détectée, suivie par la re-connexion et le réenregistrement à un autre serveur. Noter que la [RFC5626] donne des remèdes pour ce cas.

Pics de charge soudains : des pics de charge soudains se produisent quand un nombre extrêmement grand d’utilisateurs tentent tous simultanément de faire un appel. Un exemple de la façon dont cela peut arriver est une télévision commerciale qui annonce un numéro à appeler pour recevoir un cadeau. Si le cadeau est attrayant et si beaucoup de gens voient la publicité, beaucoup d’appels peuvent être faits simultanément au même numéro. Cela peut mettre le système en surcharge.

Attaques de déni de service (DoS) :  un attaquant, qui souhaite perturber le service dans le réseau, peut causer une grande quantité de trafic à lancer sur un serveur cible. Cela peut être fait à partir d’une source centrale de trafic ou par une attaque de DoS répartie. Dans tous les cas, le volume de trafic va excéder la capacité du serveur, mettant le système en surcharge.

Malheureusement, le problème de la surcharge tend à se nourrir lui-même. Quand un réseau est en surcharge, cela peut fréquemment causer des défaillances des éléments qui essayent de traiter le trafic. Cela cause encore plus de charge sur les éléments restants. De plus, durant une surcharge, la capacité globale des éléments fonctionnels diminue, car beaucoup de leurs ressources sont utilisées à juste rejeter ou traiter la charge qu’ils ne peuvent en fait pas traiter. La surcharge tend également à causer le retard ou la perte des messages SIP, ce qui cause des retransmissions, augmentant encore la quantité de travail dans le réseau. Ce facteur de multiplication peut avoir un effet substantiel sur la charge du système. Bien sûr, dans le cas de UDP, avec jusqu’à sept retransmissions d’une demande INVITE avant qu’elle soit périmée, la surcharge peut multiplier le volume déjà lourd de messages jusqu’à factoriel 7  !

 	3.	Terminologie

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

 	4.	Mécanismes SIP actuels

SIP a une prise en charge très basique de la surcharge. Il définit le code de réponse 503, qui est envoyé par un élément surchargé. La RFC 3261 le définit ainsi :

"Le serveur est temporairement incapable de traiter la demande du fait d’une surcharge temporaire ou de la maintenance du serveur. Le serveur PEUT indiquer quand le client devrait réessayer la demande dans un champ d’en-tête Retry-After. Si aucun Retry-After n’est donné, le client DOIT agir comme s’il avait reçu une réponse 500 (Erreur interne du serveur).

Un client (mandataire ou UAC) recevant une 503 (Service indisponible) DEVRAIT essayer de transmettre la demande sur un serveur de remplacement. Il NE DEVRAIT PAS transmettre d’autres demandes à ce serveur pour la durée spécifiée dans le champ d’en-tête Retry-After, s’il est présent.

Les serveurs PEUVENT refuser la connexion ou abandonner la demande au lieu de répondre avec 503 (Service indisponible)."

L’objectif est de fournir un mécanisme pour déplacer le travail du serveur surchargé à un autre serveur afin que la demande puisse être traitée. Le champ d’en-tête Retry-After, quand il est présent, est destiné à permettre à un serveur de dire à un élément en amont de retarder les transmissions pendant un certain temps, afin que le serveur surchargé puisse venir à bout de son travail en retard.

La RFC 3261 dit aussi aux mandataires de ne pas transmettre les réponses 503 en amont, de force NE DEVRAIT PAS. C’est pour éviter que le serveur en amont conclut par erreur que le mandataire est surchargé quand, en fait, le problème est sur un élément plus loin en aval.

 	5.	Problèmes de ce mécanisme

En surface, le mécanisme 503 semble fonctionner. Malheureusement, ce mécanisme a eu de nombreux problèmes dans ses déploiements réels. Ces problèmes sont décrits ici.

 	5.1	Amplification de charge
Le principal problème du mécanisme 503 est qu’il tend à amplifier substantiellement la charge dans le réseau quand le réseau est surchargé, causant une escalade de problèmes et introduisant la très réelle possibilité d’un collapsus d’encombrement. Considérons la topologie de la Figure 1.

                                         +------+
                                       > |      |
                                      /  |  S1  |
                                     /   |      |
                                    /    +------+
                                   /
                                  /
                                 /
                                /
                      +------+ /         +------+
            --------> |      |/          |      |
                      |  P1  |---------> |  S2  |
            --------> |      |\          |      |
                      +------+ \         +------+
                                \
                                 \
                                  \
                                   \
                                    \
                                     \   +------+
                                      \  |      |
                                       > |  S3  |
                                         |      |
                                         +------+

Figure 1

Le mandataire P1 reçoit les demandes SIP provenant de nombreuses sources et agit seulement comme équilibreur de charge, relayant les demandes aux serveurs S1, S2, et S3 pour traitement. La charge d’entrée augmente au point que les trois serveurs deviennent surchargés. Le serveur S1, quand il reçoit une nouvelle demande, génère une 503. Cependant, parce que le serveur est chargé, cela peut lui prendre en certain temps pour générer le 503. Si SIP fonctionne sur UDP, cela peut résulter en des retransmissions de demande, qui augmentent encore le travail de S1. Même dans le cas de TCP, si le serveur est chargé et si le noyau ne peut pas envoyer des accusés de réception TCP assez vite, des retransmissions TCP peuvent se produire. Quand la 503 est reçue par P1, il réessaye la demande sur S2. S2 est aussi surchargé et génère éventuellement une 503, mais dans l’intervalle peut aussi être touché par des retransmissions. P1 essaye encore une fois un autre serveur, S3 cette fois, qui la rejette aussi finalement avec une 503.

Donc, le traitement de cette demande, qui a finalement échoué, a impliqué quatre transactions SIP (client à P1, P1 à S1, P1 à S2, P1 à S3) dont chacune peut avoir impliqué de nombreuses retransmissions – jusqu’à sept dans le cas de UDP. Donc, dans des conditions non chargées, une seule demande d’un client génèrerait une demande (à S1, S2, ou S3) et deux réponses (de S1 à P1, puis de P1 au client). Quand le réseau ets surchargé, une seule demande provenant du client, avant la fin de temporisation, pourrait générer jusqu’à 18 demandes et autant de réponses quand UDP est utilisé ! La situation est meilleure avec TCP (ou tout transport fiable en général) mais même si il n’y avait pas de segment TCP retransmis, une seule demande du client peut générer trois demandes et quatre réponses. Chaque serveur doit dépenser des ressources pour traiter ces messages. Donc, plus de messages et plus de travail ont été envoyés dans le réseau au point que les éléments deviennent surchargés. Le mécanisme 503 fonctionne bien quand un seul élément est surchargé. Mais quand le problème est la charge globale du réseau, le mécanisme 503 génère en fait plus de messages et plus de travail pour tous les serveurs, résultant finalement de toutes façons en le rejet de la demande.

Le problème est encore amplifié si on considère les mandataires en amont de P1, comme le montre la Figure 2.

                                +------+
                              > |      | <
                             /  |  S1  |  \\
                            /   |      |    \\
                           /    +------+      \\
                          /                     \
                         /                       \\
                        /                          \\
                       /                             \
            +------+  /         +------+           +------+
            |      | /          |      |           |      |
            |  P1  | ---------> |  S2  |<----------|  P2  |
            |      | \          |      |           |      |
            +------+  \         +------+           +------+
                ^      \                             / ^
                 \      \                          // /
                  \      \                       //  /
                   \      \                    //   /
                    \      \                  /    /
                     \      \   +------+    //    /
                      \      \  |      |  //     /
                       \      > |  S3  | <      /
                        \       |      |       /
                         \      +------+      /
                          \                  /
                           \                /
                            \              /
                             \            /
                              \          /
                               \        /
                                \      /
                                 \    /
                                +------+
                                |      |
                                |  PA  |
                                |      |
                                +------+
                                 ^   ^
                                 |   |
                                 |   |

Figure 2

Ici, le mandataire PA reçoit les demandes et les envoie aux mandataires P1 ou P2. P1 et P2 équilibrent tous deux la charge sur S1 à S3. En supposant encore que S1 à S3 sont tous surchargés, une demande arrive à PA, qui essaye d’abors P1. P1 essaye S1, S2, et ensuite S3, et chaque transaction résulte en de nombreuses retransmissions de demande si UDP est utilisé.  Comme P1 est finalement incapable de traiter la demande, il la rejette. Cependant, comme toutes ses dépendances en aval sont occupées, il décide d’envoyer une 503. Celle-ci se propage à PA, qui essaye P2, qui essaye encore S1 à S3, résultant encore une fois en une 503. Donc, dans ce cas, on a doublé le nombre de transactions SIP et le travail global dans le réseau par rapport au cas pécédent. Le problème est ici le fait que S1 à S3 étaient surchargés était connu de P1, mais cette information n’a pas été repassée à PA, ni ensuite à P2, de sorte que P2 réessaye encore S1 à S3.

 	5.2	Sous utilisation
Il est intéressant de voir qu’il y a aussi des exemples de déploiements où la capacité du réseau a été largement réduite par suite du mécanisme de surcharge. Si on examine à nouveau la Figure 1, malheureusemt la RFC 3261 n’est pas claire sur la portée d’une réponse 503  ; quand elle est reçue de P1, le mandataire cesse t-il d’envoyer des demandes à cette adresse IP ? Au nom d’hôte ? À l’URI ? Certaines mises en œuvre ont choisi le nom d’hôte comme portée. Quand le nom d’hôte pour un URI pointe sur un enregistrement SRV dans le DNS, qui, à son tour, se transpose en une grappe de serveurs en aval (S1, S2, et S3 dans l’exemple) une réponse 503 d’un seul d’entre eux va faire croire au mandataire que la grappe entière est surchargée. Par conséquent, le mandataire P1 va cesser d’envoyer du trafic à tout élément de la grappe, même si il y a des éléments de la grappe qui sont sous utilisés.

 	5.3	Problème du réessai après arrêt/marche
Le mécanisme Retry-After permet à un serveur de dire à un élément en amont d’arrêter d’envoyer du trafic pendant un temps. Le travail qui aurait autrement été envoyé à ce serveur est plutôt envoyé à un autre serveur. Le mécanisme est une technique de tout ou rien. Un serveur peut arrêter tout le trafic vers lui, ou aucun. Il n’y a rien entre. Cela tend à causer un comportement très oscillatoire dans le cas de surcharge même légère. Considérons un mandataire P1 qui équilibre des demandes entre deux serveurs S1 et S2. La charge d’entrée atteint juste le point où S1 et S2 sont tous deux à 100 % de leur capacité. Une demande arrive à P1 et est envoyée à S1. S1 rejette cette demande avec une 503, et décide d’utiliser un Retry-After pour vider son arrièré. P1 arrête d’envoyer du trafic à S1. Maintenant, S2 obtient le trafic, mais est sérieusement surchargé -- à 200 % de sa capacité ! Il décide de rejeter une demande avec un 503 et un Retry-After, qui maintenant force P1 à rejeter tout le trafic jusqu’à ce que le temporisateur Retry-After de S1 arrive à expiration. À ce point, toute la charge est renvoyée sur S1, qui atteint la surcharge, et le cycle se répète.

Il est important de remarquer que ce problème est seulement observé pour les serveurs où il y a un petit nombre d’éléments en amont qui lui envoient du trafic, comme c’est le cas dans ces exemples. Si un mandataire est accédé par un grand nombre de clients, dont chacun envoie une petite quantité de trafic, le mécanisme 503 avec Retry-After est assez efficace quand il est utilisé avec un sous ensemble des clients. C’est parce que l’étalement du 503 sur les clients a pour effet de fournir au mandataire des contrôles de granularité fine sur la quantité de travail qu’il reçoit.

 	5.4	Usages ambigus
Malheureusement, les instances spécifiques où un serveur va envoyer une 503 sont ambiguës. Le résultat est que les mises en œuvre génèrent des 503 pour de nombreuses raisons, dont seules certaine sont en rapport avec la surcharge réelle. Par exemple, la [RFC3398], qui spécifie l’inter fonctionnement de SIP avec le sous système utilisateur RNIS (ISUP, ISDN User Part) définit l’usage de 503 quand la passerelle reçoit certains codes de cause ISUP du commutateur aval. Dans ces cas, la passerelle a une capacité large ; c’est juste que cette demande spécifique n’a pas pu être traitée à cause d’un problème en aval. Toutes les demandes suivantes pourraient réussir si elles prennent un chemin différent dans le réseau téléphonique public commuté (RTPC).

Cela cause deux problèmes. D’abord, durant les périodes de surcharge, cela exacerbe les problèmes ci-dessus parce que cela cause l’injection de 503 supplémentaires dans le système, causant la génération de plus de travail dans des conditions de surcharge. Ensuite, il devient  difficile pour un élément en amont de savoir si il faut réessayer quand une 503 est reçue. Il y des classes de défaillances où un essai avec un autre serveur ne va pas aider, car la raison de la défaillance était l’indisponibilité d’une ressource commune en aval. Par exemple, si les serveurs S1 et S2 partagent une base de données et que la base de données est défaillante, une demande envoyée à S1 va résulter en une 503, mais réessayer sur S2 ne va servir à rien parce que la même base de données est indisponible.

 	6.	Exigences pour une solution

Dans cette section, on propose des exigences pour un mécanisme de contrôle de surcharge pour SIP qui vise ces problèmes.

REQ 1 : Le mécanisme de surcharge devra s’efforcer de maintenir le débit utile global (en prenant en considération les besoins de qualité de service des applications utilisatrices) d’un serveur SIP à des niveaux raisonnables, même quand la charge entrante sur le réseau est loin d’excéder sa capacité. Le débit global en charge est la mesure ultime de la valeur d’un mécanisme de contrôle de surcharge.

REQ 2 : Quand un seul élément de réseau est défaillant, il passe en surcharge, ou souffre d’une capacité de traitement réduite, le mécanisme devrait s’efforcer de limiter l’impact de cela sur les autres éléments du réseau. Cela aide à empêcher qu’une défaillance de petite ampleur devienne une grosse panne.

REQ 3 :	Le mécanisme devrait chercher à minimiser la quantité de configuration requise pour fonctionner. Par exemple, il vaut mieux éviter d’avoir à configurer un serveur avec son débit de messages SIP, car ces sortes de quantités sont difficiles à déterminer.

REQ 4 :	Le mécanisme doit être capable de traiter les éléments qui ne le prennent pas en charge, afin qu’un réseau puisse consister en un mélange d’éléments qui le prennent en charge et d’autres qui ne le font pas. En d’autres termes, le mécanisme ne devrait pas seulement fonctionner dans des environnements où tous les éléments le prennent en charge. Bien sûr, il est raisonnable de supposer qu’il va mieux fonctionner dans de tels environnements. Idéalement, il devrait y avoir des améliorations incrémentaires dans le débit du réseau global lorsque un nombre croissant d’éléments du réseau prend en charge le mécanisme.

REQ 5 :	Le mécanisme ne devrait pas supposer qu’il va seulement être déployé dans des environnements d’éléments complètement de confiance. Il devrait chercher à opérer aussi efficacement que possible dans des environnements où d’autres éléments sont malveillants ; cela inclut d’empêcher les éléments malveillants d’obtenir plus qu’une part équitable de service.

REQ 6 :	Quand une surcharge est signalée au moyen d’un message spécifique, le message doit clairement indiquer qu’il est envoyé à cause d’une surcharge, par opposition à d’autres conditions de défaillance, non fondées sur la surcharge. Cette exigence est destinée à éviter certains des problèmes qui sont survenus de la réutilisation du code de réponse 503 pour divers objets. Bien sûr, la surcharge est aussi signalée par l’absence de réponse aux demandes. Cette exigence s’applique seulement aux signaux explicites de surcharge.

REQ 7 : Le mécanisme devra fournir un moyen pour qu’un élément réduise la quantité de trafic qu’il reçoit d’un élément en amont. Cette réduction devra être graduelle afin que ce ne soit pas un tout ou rien comme avec le mécanisme actuel de 503. Cela reconnaît le fait que la "surcharge" n’est pas un état binaire et qu’il y a des degrés de surcharge.

REQ 8 : Le mécanisme devra assurer que, quand une demande n’a pas été traitée avec succès à cause de la surcharge (ou défaillance) d’un élément en aval, la demande ne va pas être réessayée sur un autre élément qui est aussi surchargé ou dont l’état est inconnu. Cette exigence découle de la REQ 1.

REQ 9 :  Qu’une demande a été rejetée d’un élément surchargé ne devra pas indûment restreindre la capacité de cette demande d’être soumise et traitée à un élément qui n’est pas surchargé. Cette exigence découle de la REQ 1.

REQ 10 : Le mécanisme devrait prendre en charge les serveurs qui reçoivent des demandes provenant d’un grand nombre de differents éléments en amont, où l’ensemble des éléments en amont n’est pas dénombrable.

REQ 11 : Le mécanisme devrait prendre en charge les serveurs qui reçoivent des demandes provenant d’un ensemble fini d’éléments en amont, où l’ensemble des éléments en amont n’est pas dénombrable.

REQ 12 : Le mécanisme devrait fonctionner entre des serveurs de différents domaines.

REQ 13 : Le mécanisme ne doit pas imposer un algorithme spécifique pour donner des priorités au traitement du travail au sein d’un mandataire durant les temps de surcharge. Il doit permettre à un mandataire de donner des priorités aux demandes sur la base d’une politique locale, afin que certains (comme un appel pour des services d’urgence ou un appel avec une valeur spécifique du champ d’en-tête Resource-Priority [RFC4412]) reçoive un traitement préférentiel, comme de ne pas être éliminé, reçoive des retransmissions supplémentaires, ou soit traité avant d’autres.

REQ 14 : Le mécanisme devrait fournir des directives non ambiguës aux clients sur quand ils devraient reessayer une demande et quand ils ne le devraient pas. Cela s’applique particulièrement à l’établissement de connexion TCP et aux enregistrements SIP, afin d’atténuer l’avalanche de redémarrage.

REQ 15: Dans les cas où un élément de réseau est défaillant, est si surchargé qu’il ne peut pas traiter les messages, ou ne peut pas communiquer à cause d’une défaillance du réseau ou d’une partition du réseau, il ne va pas être capable de fournir des indications explicites de la nature de la défaillance ou de son niveau d’encombrement. Le mécanisme doit fonctionner correctement dans ces cas.

REQ 16 : Le mécanisme devrait tenter de minimiser les frais généraux des messages de contrôle de surcharge.

REQ 17 : Le mécanisme de surcharge ne doit pas fournir d’opportinuté d’attaque malveillante, incluant des attaques de DoS et DDoS.

REQ 18 : Le mécanisme de surcharge devrait être sans ambiguïté sur si une indication de charge s’applique à une adresse IP, un hôte, ou URI spécifiques, afin qu’un élément en amont puisse déterminer la charge de l’entité à laquelle la demande est à envoyer.

REQ 19 : La spécification du mécanisme de surcharge devrait donner des directives sur les types de message qu’il pourrait être souhaitable de traiter plutôt que d’autres durant les temps de surcharge, sur la base de considérations spécifiques de SIP. Par exemple, il peut être plus avantageux de traiter un rafraîchissement de SUBSCRIBE avec un Expires de zéro qu’un rafraîchissement de SUBSCRIBE avec une expiration non zéro (car le premier réduit la quantité globale de charge sur l’élément) ou de traiter les re-INVITE plutôt qu’un nouvel INVITE.

REQ 20 : Dans un environnement mixte d’éléments qui mettent en œuvre le mécanisme de surcharge et d’éléments qui ne le mettent pas en œuvre, aucun avantage disproportionné ne devra être attribué aux utilisateurs ou opérateurs des éléments qui ne mettent pas en œuvre le mécanisme.

REQ 21 : Le mécanisme de surcharge devrait assurer que le système reste stable. Quand la charge offerte tombe d’au dessus de la capacité globale du réseau à en dessous de la capacité globale, le débit devrait se stabiliser et devenir égal à la charge offerte.

REQ 22 : Il doit être possible de désactiver le rapport des informations de charge vers les cibles en amont sur la base de l’identité de ces cibles. Cela permet à un administrateur de domaine qui considère que la charge de ses éléments est une information sensible, de restreindre l’accès à ces informations. Bien sûr, dans ce cas, on ne s’attend pas à ce que le mécanisme de surcharge lui-même aide à empêcher la surcharge de cette cible en amont.

REQ 23 : Il doit être possible au mécanisme de surcharge de travaailler dans les cas où il y a un équilibreur de charge devant un groupe de mandataires.

 	7.	Considérations sur la sécurité

Comme tous les mécanimes de protocole, une solution au traitement de surcharge doit empêcher les attaques malveillantes de l’intérieur et l’extérieur. Le présent document inclut des exigences pour de telles fonctions de sécurité.

Tout mécanisme qui améliore le comportement des éléments SIP en charge va résulter en des performances plus prévisibles en face d’attaques de déni de service de couche d"application.

 	8.	Remerciements

L’auteur tient à remercier Steve Mayer, Mouli Chandramouli, Robert Whent, Mark Perkins, Joe Stone, Vijay Gurbani, Steve Norreys, Volker Hilt, Spencer Dawkins, Matt Mathis, Juergen Schoenwaelder, et Dale Worley de leurs contributions à ce document.
 	9.	Références
 	9.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)

 	9.2	Références pour information

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

[RFC3398]	G. Camarillo et autres, "Transposition du SSU RNIS en SIP", décembre 2002. (P.S.)

[RFC4412]	H. Schulzrinne et J. Polk, "Priorité de ressource de communications pour le protocole d'initialisation de session (SIP)", février 2006. (P.S.)

[RFC5626]	C. Jennings, R. Mahy, F. Audet, éd., "Gestion des connexions initiées par le client dans le protocole d'initialisation de session (SIP)", octobre 2009, DOI 10.17487/RFC5626. (MàJ RFC3261, RFC3327) (P. S.)

 	Adresse de l’auteur

Jonathan Rosenberg
Cisco
Edison, NJ
US
mél : jdrosen@cisco.com 
URI : http://www.jdrosen.net