Network Working Group M

Modificateur de bande passante indépendant du transport pour le protocole de description de session (SDP)

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document définit un modificateur de bande passante à maximum spécifique de l’application indépendant du transport (TIAS, Transport Independent Application Specific) du protocole de description de session (SDP, Session Description Protocol) qui ne comporte pas de redondance de transport ; à la place, un attribut supplémentaire de débit de paquet est défini. La valeur de débit binaire indépendante du transport conjointement au débit maximum de paquet peut alors être utilisée pour calculer le débit binaire réel sur le transport effectivement utilisé.

Les modificateurs de bande passante SDP existants et leurs valeurs incluent la bande passante nécessaire pour les couches transport et IP. Lorsque on utilise SDP avec des protocoles comme le protocole d’annonce de session (SAP, Session Announcement Protocol) le protocole d’initialisation de session (SIP, Session Initiation Protocol) et le protocole de flux directs en temps réel (RTSP, Real-Time Streaming Protocol) et lorsque les hôtes impliqués ont des redondances de transport différentes, par exemple dues aux versions IP différentes, l’interprétation des bandes passantes de couche inférieure qui sont incluses n’est pas claire.

Table des Matières

1. Introduction 2

1.1 Attribut Bande passante 2

1.2 IPv6 et IPv4 3

1.3 Autres mécanismes qui changent l’utilisation de la bande passante 3

2. Définitions 4

2.1 Glossaire 4

2.2 Terminologie 4

3. Problèmes de signalisation de la bande passante 4

3.1 Quelle version IP est utilisée 4

3.2 Prise en compte d’autres mécanismes 5

3.3 Conversion des valeurs de bande passante 5

3.4 Problèmes de RTCP 5

3.5 Futur développement 6

3.6 Conclusion du problème 6

4. Portée du problème 6

5. Exigences 7

6. Solution 7

6.1 Introduction 7

6.2 Modificateur de bande passante TIAS 7

6.3 Paramètre de débit de paquets 8

6.4 Conversion en valeurs dépendantes du transport 9

6.5 Déduction de la bande passante RTCP 9

6.6 Définitions ABNF 10

6.7. Exemple 10

7. Interaction de protocole 11

7.1 RTSP 11

7.2 SIP 11

7.3 SAP 11

8. Considérations pour la sécurité 11

9. Considérations relatives à l’IANA 11

10. Remerciements 12

11. Références 12

11.1 Références normatives 12

11.2 Références pour information 12

12. Adresse de l’auteur 13

13. Déclaration complète de droits de reproduction 13

La présente spécification est structurée de la façon suivante : dans cette section, on donne des informations concernant les modificateurs de bande passante SDP, et différents mécanismes qui affectent la redondance de transport. Dans la Section 3, on décrit les problèmes rencontrés, y compris des problèmes qui ne sont pas résolus par cette spécification. Dans la Section 4 est présentée la portée des problèmes que résout la présente spécification. La Section 5 contient les exigences applicables à la portée du problème. La Section 6 définit la solution, qui est un nouveau modificateur de bande passante, et un nouvel attribut de débit maximum. La Section 7 regarde les interactions de protocole pour SIP, RTSP, et SAP. Les considérations sur la sécurité sont discutées dans la Section 8. Les sections restantes sont les nécessaires considérations relatives à l’IANA, les remerciements, la liste des références, l’adresse de l’auteur, et les notices de droit de reproduction et de droits de propriété intellectuelle.

Aujourd’hui, le protocole de description de session (SDP) [RFC2327] est utilisé dans plusieurs types d’applications. L’application d’origine est l’information et la configuration de session pour des sessions en diffusion groupée annoncées avec le protocole d’annonce de session (SAP) [RFC2974]. SDP est aussi un composant vital dans la négociation du support pour le protocole d’initialisation de session (SIP) [RFC3261] en utilisant le modèle d’offre/réponse [RFC3264]. Le protocole de flux directs en temps réel (RTSP) [RFC2326] utilise aussi SDP pour déclarer au client quels supports et quels codecs comporte une présentation multimédia.

Dans SDP [RFC2327] il existe un attribut Bande passante, qui a un modificateur utilisé pour spécifier à quel type de débit binaire se réfère la valeur. L’attribut a la forme suivante :

Le total de conférence est indiqué en donnant le modificateur "CT". Total de conférence donne la bande passante maximum qu’une session de conférence va utiliser. Son objet est de décider si cette session peut coexister avec d’autres sessions, définies dans la [RFC2327].

La bande passante maximum spécifique d’une application est indiquée par le modificateur "AS". L’interprétation de cet attribut dépend de la notion de bande passante maximum de l’application. Pour une application RTP, cet attribut est la bande passante de session RTP telle que définie dans la [RFC3550]. La bande passante de session inclut celle que va consommer le trafic de données RTP, incluant les couches inférieures, jusqu’à la couche IP. Donc, dans la plupart des cas la bande passante est calculée sur la charge utile RTP, l’en-tête RTP, UDP, et IP, définis dans la [RFC2327].

Dans la [RFC3556], deux modificateurs de bande passante sont définis. Ces modificateurs, "RS" et "RR", définissent la quantité de bande passante qui est allouée pour, respectivement, les rapports RTCP par les envoyeurs de données actifs et les rapports RTCP par les autres participants (receveurs).

Il y a aujourd’hui deux versions d’IP, IP version 4 [RFC0791] et IP version 6 [RFC2460], utilisées en parallèle sur l’Internet, ce qui crée des problèmes. Cependant, il existe un certain nombre de mécanismes de transition possibles.

- Les nœuds qui souhaitent communiquer doivent partager la version IP ; cela est normalement fait en déployant des nœuds à double pile de protocoles. Par exemple, un hôte IPv4 seul ne peut pas communiquer avec un hôte IPv6 seul.

- Si la communication entre les nœuds qui ne partagent pas une version de protocoles est requise, l’utilisation d’un mécanisme de traduction ou de mandatement sera nécessaire. Des travaux sont en cours pour spécifier un tel mécanisme à cette fin.

- Les nœuds IPv6 qui appartiennent à des domaines IPv6 différents, mais qui manquent de connexité IPv6 entre eux, résolvent ce problème en tunnelant sur le réseau IPv4, voir la Figure 2. À la base, les paquets IPv6 sont envoyés comme charge utile dans les paquets IPv4 entre les points d’extrémité du tunnel à la bordure de chaque domaine IPv6. La bande passante requise sur le domaine IPv4 sera différente de celle des domaines IPv6. Cependant, comme le tunnelage n’est normalement pas effectué par le point d’extrémité d’application, ce scénario ne peut généralement pas être pris en compte.

IPv4 a une taille minimum d’en-tête de 20 octets, tandis que la partie fixe de l’en-tête IPv6 est de 40 octets.

La différence des tailles d’en-tête signifie que le débit binaire requis pour les deux versions IP est différent. La signification de la différence dépend du débit de paquets et de la taille de charge utile de chaque paquet.

Il existe un certain nombre d’autres mécanismes qui peuvent aussi changer la redondance aux couches en dessous du support de transport. On va traiter brièvement quelques uns d’entre eux.

IPsec [RFC2401] peut être utilisé entre les points d’extrémité pour assurer la confidentialité à travers l’application de l’encapsulation de charge utile de sécurité IP (ESP, Encapsulating Security Payload) [RFC2406] ou la protection de l’intégrité en utilisant l’en-tête d’authentification IP (AH, Authentication Header) [RFC2402] du flux de support. L’ajout des en-têtes ESP et AH augmente la taille de chaque paquet.

Pour fournir des réseaux privés virtuels, des paquets IP complets peuvent être encapsulés entre un nœud d’extrémité et la passerelle de sécurité du réseau privé, fournissant ainsi un tunnel sûr qui garantit la confidentialité, l’intégrité des données, et l’authentification du flux de paquets. Dans ce cas, les en-têtes IP et ESP supplémentaires vont significativement augmenter la taille du paquet.

Un autre mécanisme qui altère la redondance réelle sur les liaisons est la compression d’en-tête. La compression d’en-tête utilise le fait que la plupart des en-têtes de protocole réseau ont des valeurs statiques ou prévisibles de leurs champs au sein d’un flux de paquets. La compression n’est normalement faite que bond par bond, c’est-à-dire, sur une seule liaison. La raison normale de la compression d’en-tête est que la liaison a une bande passante très limitée et qu’un gain significatif de débit est réalisé.

Il existe plusieurs normes différentes de compression d’en-tête. Pour la compression des en-têtes IP seuls, il y a la [RFC2507]. Pour la compression des paquets avec des en-têtes IP/UDP/RTP, CRTP [RFC2508] a été créé en même temps. Plus récemment, le groupe de travail Compression d’en-tête robuste (ROHC, Robust Header Compression) a développé un cadre et des profils [RFC3095] pour compresser certaines combinaisons de protocoles, comme IP/UDP, et IP/UDP/RTP.

RTSP (Real-Time Streaming Protocol) : protocole de flux direct en temps réel [RFC2326]

SDP (Session Description Protocol) : protocole de description de session [RFC2327].

SAP (Session Announcement Protocol) : protocole d’annonce de session [RFC2974].

SIP (Session Initiation Protocol) : protocole d’initialisation de session [RFC3261].

TIAS (Transport Independent Application Specific maximum bandwidth modifier) : modificateur de bande passante à maximum spécifique de l’application indépendant du transport.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC 2119].

Lorsque une application veut utiliser SDP pour signaler la bande passante requise pour cette application, certains problèmes deviennent évidents dus à l’inclusion des couches inférieures dans les valeurs de bande passante.

Si on signale la bande passante dans SDP, par exemple, en utilisant "b=AS:" comme dans une application fondée sur RTP, on ne peut pas savoir si la redondance est calculée pour IPv4 ou IPv6. Une indication du protocole qui a été utilisé lors du calcul des valeurs de bande passante est donnée par la ligne d’adresse de connexion "c=". Cette ligne contient soit une adresse de groupe de diffusion groupée, soit une adresse d’envoi individuel de la source ou réservoir des données. Le type d’adresse de la ligne "c=" peut être supposé du même type que celui utilisé dans le calcul de la bande passante, bien qu’il semble n’exister aucun document qui spécifie ce point.

Dans les cas de SDP transporté par RTSP, ceci est encore moins clair. L’utilisation normale d’une session de flux direct à la demande en envoi individuel est de régler l’adresse de connexion des données à l’adresse nulle. Cette adresse nulle n’a pas de type d’adresse, qui pourrait être utilisée comme indication. Cependant, ceci n’est précisé nulle part.

La Figure 1, illustre un scénario de connexion entre un serveur de flux directs A et un client B sur un traducteur. Lorsque B reçoit le SDP de A sur RTSP, il lui sera très difficile de savoir ce que la valeur de bande passante dans le SDP représente. Les possibilités suivantes existent :

1. Le SDP est inchangé et l’adresse nulle "c=" est de type IPv4. La valeur de bande passante représente celle nécessaire dans un réseau IPv4.

2. Le SDP a été changé par une passerelle de niveau application (ALG). L’adresse "c=" est changée en un type IPv6. La valeur de bande passante est inchangée.

3. Le SDP est changé et le type d’adresse "c=" et la valeur de bande passante sont tous deux convertis. Malheureusement, cela peut rarement être fait (voir le paragraphe 3.3).

Dans le cas 1, le client peut comprendre que le serveur est situé dans un réseau IPv4 et qu’il utilise la redondance IPv4 lorsque il calcule la valeur de bande passante. Le client ne peut presque jamais convertir la valeur de bande passante (voir le paragraphe 3.3).

Dans le cas 2, le client ne sait pas que le serveur est dans un réseau IPv4 et que la valeur de la bande passante n’est pas calculée avec la redondance de IPv6. Dans les cas où un client utilise ces valeurs pour déterminer si son extrémité du réseau a des ressources suffisantes, le client va sous estimer le débit binaire requis, d’où résulte potentiellement de mauvaises performances d’application.

Dans le cas 3, tout fonctionne correctement. Cependant, ce cas va être très rare. Si on essaye de convertir la valeur de bande passante sans autre information sur le débit de paquet, des erreurs significatives peuvent être introduites dans la valeur.

Les paragraphes 1.2 et 1.3 énumèrent un certain nombre de raisons, comme la compression d’en-tête et les tunnels, qui changeraient les tailles des en-têtes de couche inférieure. Pour ces mécanismes, il existe différentes possibilités de les prendre en compte.

Utiliser IPsec directement entre les points d’extrémité devrait bien être connu de l’application, lui permettant ainsi de prendre en compte les en-têtes supplémentaires. Cependant le même problème existe aussi avec les modificateurs de bande passante SDP actuels où un receveur n’est pas capable de convertir ces valeurs pour prendre en compte les en-têtes IPsec.

Il est moins probable qu’une application soit au courant de l’existence d’un réseau privé virtuel. Donc la généralité du mécanisme de tunnel de tout le trafic peut empêcher l’application d’examiner même si il serait possible de convertir les valeurs.

Lorsque on utilise la compression d’en-tête, la redondance réelle sera moins déterministe, mais dans la plupart des cas, une redondance moyenne peut être déterminée pour une certaine application. Si un nœud de réseau sait que certain type de compression d’en-tête est employé, cela peut être pris en considération. Pour RSVP [RFC2205], il existe une extension [RFC3006], qui permet à l’envoyeur des données d’informer les nœuds du réseau de la possibilité de compresser le flux de données. Pour être capable de faire cela avec une certaine précision, le facteur de compression et le débit ou la taille de paquet est nécessaire, comme le déclare la [RFC3006].

Si on veut convertir une valeur de bande passante calculée en utilisant le rapport de la redondance IPv4 à la redondance IPv6, le débit de paquets est nécessaire. La nouvelle valeur de bande passante pour IPv6 est normalement "Bande passante IPv4" + "débit de paquets" * 20 octets, où 20 octets est la différence habituelle entre les en-têtes IPv6 et IPv4. La différence de redondance peut être d’une autre valeur lorsque des options IPv4 [RFC0791] ou des en-têtes d’extension IPv6 [RFC2460] sont utilisés.

Comme la conversion exige le débit de paquets du flux, ce n’est pas possible dans le cas général. De nombreux codecs ont soit plusieurs débits de paquet/trame possibles, soit peuvent effectuer une agrégation de format de charge utile, résultant en de nombreux débits possibles. Donc, des informations supplémentaires sont nécessaires dans la SDP. Le paramètre "a=ptime:" est un candidat possible. Cependant, ce paramètre n’est normalement utilisé que pour des codecs audios. Sa définition [RFC2327] est qu’il n’est qu’une recommandation que l’envoyeur peut ignorer. Un meilleur paramètre est nécessaire.

Lorsque RTCP est utilisé entre des hôtes dans des réseaux IPv4 et IPv6 avec un traducteur, il existe des problèmes similaires. Le trafic RTCP qui vient du domaine IPv4 va résulter en un débit binaire RTCP supérieur à celui prévu dans le domaine IPv6 du fait de plus gros en-têtes. Il peut en résulter une augmentation allant jusqu’à 25 % de la bande passante requise pour le trafic RTCP. La plus grosse augmentation sera pour les petits paquets RTCP lorsque le nombre d’hôtes IPv4 est beaucoup plus grand que celui des hôtes IPv6. Heureusement, comme RTCP a une bande passante limitée par rapport à RTP, il va seulement en résulter une augmentation maximum de 1,75 % de la bande passante de session totale lorsque la bande passante RTCP fait 5 % de la bande passante RTP. Les aléas de RTCP peuvent facilement résulter en effets à court terme de la même magnitude, de sorte que cette augmentation peut être considérée comme tolérable. L’augmentation de bande passante sera moindre dans la plupart des cas.

En même temps, il en résulte une inégalité dans les rapports des nœuds IPv4 et IPv6. Dans le pire des cas, le nœud IPv6 peut rapporter avec des intervalles plus longs de 25 %.

Ces problèmes ont été considérés comme assez insignifiants pour ne pas mériter de solutions complexes. Donc, un simple algorithme pour déduire la bande passante RTCP est seulement défini dans la présente spécification.

Il y a aujourd’hui des travaux dans l’IETF pour concevoir un nouveau protocole de transport de datagrammes convenable pour les supports en temps réel. Ce protocole est appelé protocole de contrôle d’encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol). Il va très probablement avoir une taille d’en-tête différente de celle d’UDP, qui est le protocole le plus souvent utilisé aujourd’hui pour les supports en temps réel. Il va en résulter encore plus de combinaisons de transport possibles. Cela peut devenir un problème si on a la possibilité d’utiliser des protocoles différents, qui ne seront pas déterminés avant le protocole SETUP actuel. Donc, le pré-calcul de cette valeur ne sera pas possible, ce qui est un motif de plus de la nécessité d’un modificateur de bande passante indépendant du transport.

Les algorithmes de contrôle d’encombrement de DCCP vont contrôler combien de bande passante peut réellement être utilisé. Cela peut exiger d’autres travaux pour spécifier des modificateurs de bande passante SDP qui déclarent les possibilités dynamiques du flux de supports d’une application. Par exemple, le minimum et maximum de bande passante de supports que l’application est capable de produire en tout, ou pour les codecs capables seulement de produire certains débits, d’énumérer les débits possibles. Cependant, ceci fera l’objet d’études à venir et sort du domaine d’application de la présente solution.

Un défaut du modificateur de bande passante SDP actuel est qu’il inclut aussi la bande passante nécessaire pour les couches inférieures. Il est difficile dans de nombreux cas de déterminer quelles couches inférieures et quelles versions ont été incluses dans le calcul, en particulier en présence de traduction ou de mandatement entre différents domaines. Cela empêche un receveur de déterminer si la bande passante donnée doit être convertie sur la base des couches inférieures réellement utilisées.

Ensuite, un attribut pour donner au receveur une détermination explicite du débit de paquet maximum qui sera utilisé n’existe pas. Cette valeur est nécessaire pour une conversion précise des valeurs de bande passante si la différence de redondance est connue.

Les problèmes décrits dans la Section 3 sont courants et affectent la signalisation de niveau application qui utilise SDP, d’autres protocoles de signalisation, et aussi les protocoles de réservation de ressources. Cependant, le présent document vise le problème spécifique de la signalisation du débit binaire dans SDP. Les problèmes doivent être considérés dans les autres protocoles affectés et dans les nouveaux protocoles à concevoir. Dans le groupe de travail MMUSIC, on travaille à un remplacement de SDP appelé SDP-NG. Il est recommandé que les problèmes soulevés dans le présent document soient pris en considération lors de la conception de solutions pour spécifier la bande passante dans le SDP-NG [17].

Comme la présente spécification vise seulement à porter dans SDP les informations de débit binaire, elle aura une applicabilité limitée. Comme les informations de SDP sont normalement transportées de bout en bout par un protocole d’application, les nœuds entre les points d’extrémité n’auront pas accès aux informations de débit binaire. C’est seulement les points d’extrémité qui sont capables de prendre en compte ces informations. Un nœud intérieur devra recevoir les informations par des moyens autres que SDP, et ceci sort du domaine d’application de la présente spécification.

Néanmoins, les informations de débit binaire fournies dans cette spécification sont suffisantes pour les cas tels que la réservation de ressource et le contrôle d’admission de premier bond. Elle fournit aussi des informations sur le débit maximum de codec, qui sont indépendantes des protocoles de niveau inférieur.

La présente spécification N’essaye PAS de résoudre le problème de la détection des NAT ou autres boîtiers de médiation.

Les problèmes exposés dans les sections précédentes et avec l’applicabilité mentionnée, devraient satisfaire l’exigence suivante :

- La valeur de bande passante DEVRA être donnée d’une façon telle qu’elle puisse être calculée pour toutes les combinaisons possibles de redondances de transport.

Cette section décrit une solution aux problèmes soulevés dans le présent document pour le modificateur de bande passante spécifique d’application (AS, Application Specific) permettant ainsi la déduction du débit binaire requis pour une application, ou les données d’une session RTP et le trafic RTCP. La solution se fonde sur la définition d’un nouveau modificateur de bande passante spécifique de l’application et indépendant du transport (TIAS, Transport Independent Application Specific) et un nouvel attribut SDP pour le débit maximum de paquet (maxprate).

Le CT est un modificateur de niveau session et il ne peut pas être traité facilement. Pour régler les problèmes avec des redondances différentes, il est RECOMMANDÉ que la valeur du CT soit calculée en utilisant un pire cas de redondance raisonnable. Un exemple de calcul de pire cas de redondance raisonnable est de prendre la redondance du plus grand protocole de transport (en utilisant une taille moyenne si elle est variable), d’y ajouter la plus grande redondance IP attendue, plus le débit de trafic de données. Faire cela pour chaque flux de supports individuel utilisé dans la conférence et les additionner ensemble.

Les modificateurs RR et RS [RFC3556] seront utilisés comme défini et incluront la redondance de transport. La petite inégalité entre hôtes est réputée acceptable.

Un nouveau modificateur de bande passante est défini pour être utilisé pour les raisons suivantes :

Réservation de ressources. Un seul débit binaire peut suffire pour une réservation de ressource. Certaines caractéristiques peuvent être déduites du flux, du type de codec, etc. Dans les cas où plus d’informations sont nécessaires, un autre paramètre de SDP sera exigé.

Débit maximum de codec de supports. Avec la définition de "TIAS" ci-dessous, le débit binaire donné sera principalement issu du codec de supports. Donc, il donne une bonne indication du débit binaire maximum du codec dont la prise en charge est exigée du décodeur.

Débit binaire de communication exigé pour le flux. La valeur du "TIAS" peut être utilisée avec celle de "maxprate" pour déterminer le débit binaire maximum de communication qu’exigera le flux. En utilisant les valeurs de niveau session ou en ajoutant ensemble tous les débits binaires maximum provenant du flux d’une session, un receveur peut déterminer si ses ressources de communication sont suffisantes pour traiter le flux. Par exemple, l’utilisateur d’un modem peut déterminer si la session convient aux capacités de son modem et de la connexion établie.

Déterminer la bande passante de session RTP et déduire la bande passante RTCP. L’attribut dérivé dépendant du transport sera la bande passante de session RTP dans le cas de transport fondé sur RTP. La valeur du TIAS peut aussi être utilisée pour déterminer la bande passante RTCP à utiliser lorsque on utilise une allocation implicite. RTP [RFC3550] spécifie que si elle n’est pas déclarée explicitement, la bande passante supplémentaire, égale à 5 % de la bande passante de session RTP, devra être utilisée par RTCP. La bande passante RTCP peut être explicitement allouée par l’utilisation des modificateurs RR et RS définis dans la [RFC3556].

Un nouveau modificateur de bande passante de session et de niveau supports est défini :

b=TIAS:<valeur de bande passante> ; voir au paragraphe 6.6 la définition en ABNF.

Le modificateur de bande passante à maximum spécifique de l’application indépendant du transport (TIAS, Transport Independent Application Specific Maximum) a une valeur d’entier de débit binaire en bits par seconde. Une valeur fractionnaire de bande passante DEVRA toujours être arrondie à l’entier supérieur. La valeur de bande passante est le maximum nécessaire pour l’application (niveau de session SDP) ou le flux de supports ( niveau supports SDP) sans compter les couches IP ou autres couches de transport comme TCP ou UDP.

Au niveau session SDP, la valeur du TIAS est la quantité maximale de bande passante nécessaire lorsque tous les flux de supports déclarés sont utilisés. Cela PEUT être moins que la somme de toutes les valeurs de flux de supports individuels. Cela est dû à la possibilité que tous les flux ne soient pas à leur maximum au même moment. Cela ne peut normalement être vérifié que pour les flux de supports mémorisés.

Pour les flux de supports transportés sur RTP, TIAS au niveau supports SDP peut être utilisé pour déduire la "bande passante de session" RTP, définie au paragraphe 6.2 de la [RFC3550]. Dans le contexte du transport RTP, la valeur de TIAS est définie comme :

Seule la charge utile RTP comme définie dans la [RFC3550] DEVRA être utilisée dans le calcul du débit binaire, c’est-à-dire, en excluant les en-têtes des couches inférieurs (IP/UDP) et RTP y compris les en-têtes RTP et leurs extensions, les listes de CSRC, et autres champs spécifiques de profil RTP. Noter que la charge utile RTP inclut à la fois l’en-tête de format de charge utile et les données. Cela peut permettre d’utiliser la même valeur pour les supports de transport fondé sur RTP, de transport non RTP, et les supports mémorisés.

Note : l’utilisation de bit/s n’est pas en accord avec la [RFC2327]. Ce changement n’a pas d’implication pour l’analyseur ; c’est seulement l’interprète de la valeur qui doit en être averti. Le changement est fait pour permettre une meilleure résolution, et a aussi été utilisé pour les modificateurs de bande passante RR et RS, voir la [RFC3556].

Note : la bande passante RTCP n’est pas incluse dans la valeur de bande passante. Dans les applications qui utilisent RTCP, la bande passante utilisée par RTCP est soit 5 % de la bande passante de session RTP incluant les couches inférieures ou comme spécifié par les modificateurs RR et RS [RFC3556]. La spécification de la façon de déduire le débit binaire RTCP en utilisant le TIAS est présentée au paragraphe 6.5.

Le "TIAS" est principalement destiné à être utilisé au niveau support SDP. L’attribut de bande passante "TIAS" PEUT être présent au niveau session dans une SDP, si tous les flux de supports utilisent le même transport. Dans les cas où la somme des valeurs de niveau supports pour tous les flux de supports est supérieure à la bande passante maximum réelle nécessaire pour tous les flux, il DEVRAIT être inclus au niveau session. Cependant, si il est présent au niveau session, il DEVRAIT être aussi présent au niveau supports. Le "TIAS" NE DEVRA PAS être présent au niveau session sauf si les mêmes protocoles de transport sont utilisés pour tous les flux de supports. Le même transport est utilisé tant que la même combinaison de protocoles est utilisée, comme IPv6/UDP/RTP.

Pour permettre la rétro compatibilité avec les applications de SDP qui ne mettent pas en œuvre "TIAS", il est RECOMMANDÉ d’inclure aussi le modificateur "AS" lors de l’utilisation de "TIAS". La présence d’une valeur incluant la redondance de couche inférieure, même avec ses problèmes, est préférable à pas de valeur du tout. Cependant, une application SDP qui met en œuvre TIAS DEVRAIT ignorer la valeur "AS" et utiliser "TIAS" à la place lorsque les deux sont présentes.

Lorsque on utilise TIAS pour un flux transporté par RTP, l’attribut "maxprate" défini plus loin DEVRA, si possible, être inclus au niveau SDP correspondant.

Pour être capable de calculer la valeur de bande passante incluant les couches inférieures réellement utilisées, un attribut de débit de paquet est aussi défini.

La session SDP et l’attribut débit maximum de paquet au niveau supports sont définis comme :

Le débit de paquets> est une valeur à virgule flottante pour le débit maximum de paquets du flux en paquets par seconde. Si le nombre de paquets est variable, la valeur donnée DEVRA être le maximum que l’application peut produire dans le cas d’un flux en direct, ou pour les flux mémorisés à la demande, comme produit. Le débit de paquets est calculé en ajoutant le nombre de paquets envoyés dans une fenêtre d’une seconde. Le maxprate est la plus grande valeur produite lorsque la fenêtre glisse sur le flux de supports entier. Dans les cas où cela ne peut pas être calculé, c’est-à-dire, d’un flux en direct, une valeur estimée de débit maximum de paquets que le codec peut produire pour une certaine configuration et un certain contenu DEVRA être utilisée

Note : le calcul de la fenêtre glissante va toujours donner un nombre entier. Cependant le champ des attributs est une valeur à virgule flottante parce que le débit maximum de paquets estimé ou connu par seconde peut être fractionnaire.

Au niveau de la session SDP, la valeur "maxprate" est le débit maximum de paquets calculé sur les flux de supports déclarés. Si il ne peut pas être mesuré (supports mémorisés) ou estimé (direct) la somme de toutes les valeurs de niveau supports donne une valeur plafond.

Note : la valeur au niveau session peut être inférieure à la somme des flux de supports individuels à cause de la distribution temporelle des maximum de flux de supports. L’attribut "maxprate" NE DOIT PAS être présent au niveau session si les flux de supports utilisent des transports différents. L’attribut PEUT être présent si les flux de supports utilisent le même transport. Si l’attribut est présent au niveau session, il DEVRAIT aussi être présent au niveau supports pour tous les flux de supports.

"maxprate" DEVRA être inclus pour tous les transports où un débit de paquets peut être déduit et TIAS est inclus. Par exemple, si on utilise TIAS et un transport comme IP/UDP/RTP, pour lequel le débit maximum de paquets (réel ou estimé) peut être déduit, alors "maxprate" DEVRA être inclus. Cependant, si soit (a) le débit de paquets pour le transport ne peut pas être déduit, soit (b) TIAS n’est pas inclus, alors, il n’est pas exigé que "maxprate" soit inclus.

Pour convertir la valeur de bande passante (bw-value) indépendante du transport en une valeur dépendante du transport qui inclut les couches inférieures, on DOIT faire ce qui suit :

1. Déterminer quelles couches inférieures seront utilisées et calculer la somme des tailles des en-têtes en bits (h-size). Dans les cas de tailles d’en-tête variables, la taille moyenne DEVRA être utilisée. Pour les supports transportés sur RTP, les couches inférieures DEVRONT inclure l’en-tête RTP avec les extensions d’en-tête, si elles sont utilisées, la liste de CSRC, et toutes les extensions spécifiques du profil.

3. Calculer la redondance de transport en multipliant les tailles d’en-tête par le débit de paquet

(t-over = h-size * prate) (redondance de transport = taille d’en-tête multipliée par débit de paquets).

4. Arrondir la redondance de transport à l’entier supérieur en bits (t-over = CEIL(t-over)).

5. Ajouter la redondance de transport à la valeur de bande passante indépendante du transport

(total bit-rate = bw-value + t-over) (débit binaire total = valeur de bande passante + redondance de transport)

Lorsque le calcul ci-dessus est effectué en utilisant le "maxprate", la valeur du débit binaire sera le maximum absolu que le flux de supports peut utiliser sur le transport supposé dans le calcul.

Ce paragraphe ne résout pas les problèmes d’équité et d’éventuels changements de débit binaire introduits par la traduction d’IPv4 en IPv6. Ces différences sont considérées comme assez petites, et les solutions connues introduisent des changements de code à la mise en œuvre de RTP/RTCP. Ce paragraphe donne un moyen cohérent de calculer le débit binaire à allouer à RTCP, si il n’est pas donné explicitement.

D’abord, le débit binaire de session RTP dépendant du transport est calculé, conformément au paragraphe 6.4, en utilisant les couches de transport réelles utilisées au point d’extrémité où le calcul est fait. Le débit binaire RTCP est alors déduit comme d’habitude, sur la base de la bande passante de session RTP, c’est-à-dire, normalement égal à 5 % de la valeur calculée.

Donner l’exacte même valeur de débit binaire RTCP aux hôtes IPv4 et IPv6 a pour résultat que l’hôte IPv4 a un débit d’envoi RTCP supérieur. Le débit d’envoi représente le nombre de paquets RTCP envoyés durant un intervalle de temps donné. L’envoi de RTCP est limité selon les règles définies dans la spécification RTP [RFC3550]. Pour un paquet RTCP de 100 octets (incluant UDP/IPv4) l’envoyeur IPv4 a un taux d’envoi d’approximativement 20 % de plus. Ce taux baisse avec de plus grands paquets RTCP. Par exemple, des paquets de 300 octets vont seulement donner à l’hôte IPv4 un taux d’envoi supérieur de 7 %.

La règle ci-dessus pour déduire la bande passante RTCP donne le même comportement que les allocations fixes lorsque la session RTP a des paramètres de trafic qui donnent un grand ratio TIAS/maxprate. Les deux hôtes seront à égalité lorsque le ratio TIAS/maxprate est approximativement de 40 octets/paquet, étant donnés des paquets RTCP de 100 octets. Pour un ratio TIAS/maxprate de 5 octets/paquet, l’hôte IPv6 va pouvoir envoyer approximativement 15-20 % de paquets RTCP en plus.

Plus les paquets RTCP deviennent grands, plus cela va favoriser l’hôte IPv6 dans son taux d’envoi.

La conclusion est que, au sein de la combinaison utile normale de débits binaires indépendants du transport et de débits de paquets, la différence d’égalité de traitement entre hôtes des différentes versions IP avec des redondances différentes est acceptable. Pour la différence de 20 octets de redondance entre en-tête IPv4 et IPv6, la bande passante RTCP réellement utilisée dans le cas d’une connexion en envoi individuel ne sera pas supérieure à approximativement 1 % de la bande passante totale de session.

Ce paragraphe définit l’ABNF d’après la [RFC2234] du modificateur de bande passante et de l’attribut de débit de paquet.

définition de TIAS de bande passante = "b" "=" "TIAS" ":" valeur de bande passante CRLF

Dans cet exemple de SDP d’une session de direct, il y a deux flux de supports, un flux audio codé avec AMR et un flux vidéo codé avec le codeur vidéo MPEG-4. AMR est utilisé ici pour produire un flux de supports à taux constant et utilise une mise en paquets donnant 10 paquets par seconde. Il en résulte un débit de bande passante d’un TIAS de 8480 bits par seconde, et une revendication de 10 paquets par seconde. Le flux vidéo est plus variable. Cependant, il a un taux de charge utile maximum mesuré de 42 300 bits par seconde. le flux vidéo a aussi un débit de paquets variable, en dépit du fait que la vidéo est de 15 trames par seconde, et au moins une instance d’une fenêtre longue d’une seconde contient 18 paquets.

Les paramètres "TIAS" et "maxprate" peuvent être utilisés avec RTSP comme actuellement spécifié. Pour être capable de calculer la bande passante dépendante du transport, certains des paramètres d’en-tête de transport seront requis. Il ne devrait pas y avoir de problème pour qu’un client calcule la ou les bandes passantes requises avant un SETUP RTSP. La raison en est qu’un client prend en charge un nombre limité d’établissements de transport. Celui qui est réellement offert à un serveur dans une demande SETUP va dépendre du contenu de la description SDP. La ou les lignes "m=" vont signaler le profil de transport désiré au client.

L’usage de "TIAS" avec "maxprate" ne devrait pas être différent du traitement du modificateur "AS" actuellement utilisé. Les paramètres de transport nécessaires seront disponibles dans le champ transport dans la ligne "m=". La classe d’adresse peut être déterminée à partir du champ "c=" et de la connectivité du client.

Dans le cas de SAP, toutes les informations disponibles pour calculer le débit binaire dépendant du transport devraient être présents dans la SDP. Les informations "c=" donnent la famille d’adresses utilisée pour la diffusion groupée. La couche transport, par exemple RTP/UDP, pour chaque support est évidente dans la ligne media ("m=") et son champ transport.

La valeur de bande passante qui est fournie par les paramètres définis ici peut être altérée, si son intégrité n’est pas protégée. En altérant la valeur de bande passante, on peut tromper un receveur pour lui faire réserver plus ou moins de bande passante que nécessaire. Réserver trop peut résulter en des dépenses non voulues par l’utilisateur, tout en bloquant aussi des ressources que d’autres parties auraient pu utiliser. Si il n’a pas été réservé assez de bande passante, la qualité de l’usager receveur peut être affectée. Faire confiance à une trop grande valeur de TIAS peut aussi résulter en le rejet de la session par le receveur à cause de ressources insuffisantes de communication et de décodage.

Du fait de ces risques pour la sécurité, il est fortement RECOMMANDÉ que l’intégrité de la SDP soit protégée et que sa source soit authentifiée afin qu’on ne puisse pas l’altérer, et qu’on puisse faire confiance à sa source. Il est aussi RECOMMANDÉ que tout receveur de la SDP effectue une analyse de la valeur de bande passante reçue pour vérifier que ce sont des valeurs raisonnablement attendues pour l’application. Par exemple, un seul canal codé en AMR de flux vocal prétendant utiliser 1000 kbit/s n’est pas raisonnable.

Noter que certaines des exigences de sécurité ci-dessus entrent en conflit avec celles requises pour faire fonctionner les protocoles de signalisation qui utilisent SDP à travers un boîtier de médiation, comme exposé dans les considérations sur la sécurité de la [RFC3303].

Le présent document enregistre un nouvel attribut de session SDP et de niveau support "maxprate", voir le paragraphe 6.3.

Un nouveau modificateur de bande passante SDP [RFC2327] (bwtype) "TIAS" est aussi enregistré conformément aux règles qui exigent une RFC en cours de normalisation. Le modificateur est défini au paragraphe 6.2.

L’auteur tient à remercier Gonzalo Camarillo et Hesham Soliman de leur travail de relecture du présent document. Un grand merci à Stephen Casner qui a revu et aidé à corriger le langage, et a identifié des erreurs des versions précédentes. Merci de leurs suggestions d’améliorations à Colin Perkins, Geetha Srikantan, et Emre Aksu.

L’auteur tient aussi à remercier toutes les personnes qui ont commenté la présente spécification sur la liste de diffusion du groupe de travail MMUSIC.

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

[RFC2402] S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)

[RFC2460] S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564 ; D.S)

[RFC2974] M. Handley, C. Perkins, E. Whelan, "Protocole d'annonce de session (SAP)", octobre 2000. (Expérimentale)

[RFC3264] J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002.

[17] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation," Non publiée, mars 2003.

Copyright (C) The Internet Society (2004). 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 qui y sont 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient ê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 le 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 .

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	M. Westerlund, Ericsson
Request for Comments : 3890	septembre 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle