Multimédia sur IP les protocoles RTP et RSVP
[email protected] CNRS/UREC
Protocoles RTP et RSVP ■
1996 Jean-Paul GAUTIER
Multimedia : concepts et protocoles ■
L'IETF a développé un certain nombre de standards (RFC et drafts) qui sont requis pour supporter les communications multicast ◆
Les adresses de classe D ✦ ✦
◆
L’enregistrement dynamique des utilisateurs : IGMP ✦
◆
224.0.0.0 a 239.255.255.255 allocation dynamique
Internet Group Management Protocol
Le routage multicast ✦ ✦ ✦
DVMRP MOSPF PIM
Distance vector Multicast Routing protocol Multicast Open Shortest Path First Protocol Protocol-Independent Multicast
Multimedia : les protocoles de bases ◆
Le transport temps réel ✦ ✦ ✦
◆
RTP Real-time Transport Protocol RTCP Real-time Transport Control Protocol Des profils : format de données pour les différents types de flux.
La réservation de ressources ✦
RSVP Resource Rservation Protocol
Les acteurs Application temps réel
RTP et RTCP Serveur temps réel
UDP
Routeur
Routeur
RSVP
RSVP
RTP et RSVP Client Application
Les acteurs $ANS UNE SESSION MUTIM©DIA CHAQUE M©DIA EST TRANSPORT© DANS DES SESSIONS 240 DISTINCTES AVEC SES PROPRES PAQUETS 24#0 DE CONTR´LE DE LA QUALIT© DE LA SESSION
!PPLICATION TEMPS R©EL
240 ET 24#0
Serveur temps réel
,ES ROUTEURS COMMUNIQUENT VIA 2360 POUR INITIALISER ET G©RER LA BANDE PASSANTE R©SERV©E AUX SESSIONS
5$0
Routeur RTP
RTP
RTP RSVP
RTCP Information de contrçole RTCP
Routeur RTP
RTCP
RSVP
RSVP
RTP
Information de contrôle RSVP
240 ET 2360 Client !PPLICATION
RTP Les documents ◆ ◆
◆ ◆ ◆
RFC 1889 RTP A transport Protocol for Real-Time Applications RFC 1890 RTP Profile for Audio and Video Conferences with Minimal Control #ES 2 ONT ©T© PROPOS©S 3TANDARDS 4RACK EN JANVIER ET DEVRAIENT ªTRE FINALIS©S EU D©BUT RFC 2032 RTP Payload Format for H261 Video Streams RFC 2035 RTP Payload Format for JPEG-compressed video RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video #ES 2 ONT ©T© PROPOS©S 3TANDARDS 4RACK EN OCTOBRE
RTP Real Time Protocol ■
But : fournir des fonctions de transport de bout en bout pour les applications temps réel sur des services réseaux multicast ou unicast. ◆ ◆ ◆
■ ■ ■ ■
conférence audio, vidéo interactive diffusion vidéo, audio simulation
RTP est un protocole de transport. RTP est fortement couplé avec les applications. RTCP est intégré dans RTP. Implémentations de RTP. ◆ ◆
au-dessus de UDP pour l’instant. dans le futur, indépendance vis à vis des couches réseaux.
RTP ✦
■
A travers des exemples
Applications et RTP , les scénarios : ◆ ◆ ◆
■
Fonctionalités de base
Simple audio-conférence multicast Conférence audio et video Les participants ne sont pas tous égaux
Principes de base pour les scénarios: ◆
◆
Utilisation du profile auxilaire et des formats de données pour adapter RTP aux applications RTP tourne au-dessus de UDP.
Simple audio-conférence multicast ■
Par un mécanisme d'allocation l'application serveur obtient ◆ ◆
une adresse multicast un couple de numéros de ports UDP ✦ ✦
■
L'adresse et les ports sont communiqués aux participants ◆
■
1 pour les flux de données audio 1 pour les paquets de contôle (RTCP)
l’encryptage est prévu (distribution de la clé) mais les mécanismes ne sont pas décrits dans le RFC 1889
L'application audio utilisée par chaque participant à la conférence envoie des données qui correspondent à 20 ms en taille. données = 20 ms
Simple audio-conférence multicast header UDP ◆
header RTP
données = 20 ms
header RTP
données = 20 ms
Header RTP ✦
type d'encodage audio => permet a l'émetteur de changer l'encodage en cours de conférence : • pour prendre en compte des participants qui ont de plus faible bande passante. • pour répondre à des indications de congestion.
✦
information sur le rytme d'émission, numéro de séquence • permet aux receveurs de reconstruire le rythme de la source, cela est fait pour chaque émetteur de paquets RTP de la conférence. • le numéro de séquence peut être utilisé pour estimer le nombre de paquets perdu par UDP et IP.
◆
Qui arrive où quitte la conférence => paquets RTCP envoyés ✦
périodiquement par chaque instance de l'application audio de la conférence.
Conférence audio et video ■
Deux sessions RTP séparées ◆
◆
■
Au niveau RTP il n’y pas de couplage direct entre les sessions audio et vidéo ◆
■
utilisation de 2 couples différents de ports UDP et/ou d'adresses multicast. permet aux paticipants ce ne rececoir qu'un média.
néanmoins un participant au deux sessions utilisera le même nom canonique (CNAME) dans les paquets RTCP afin que les sessions puissent être assoçiées.
La synchronisation des sources audio et vidéo est réalisée en utilisant les informations de 'timing' des paquets RTCP pour les deux sessions.
Egalité des participants ■
Un petit nombre participe a travers un lien bas-débit alors que la majorité dispose d'un lien haut-débit. ◆
Mise en place d'un relais au niveau RTP près de la zone bas-débit appelé "Mixer" ✦
✦ ✦ ✦
re-synchronisation des paquets audio pour reconstruire l’espacement de 20 ms, combine des flux audios reconstruits dans un simple flux , change l'encodage initial par un qui soit approprié au bas-débit,, envoie le flux sur les liens bas-débits • unicast vesr un seul destinataire • multicast sur une adresse différente vers de multiples destinataires
◆
Le header RTP inclut un moyen permettant au "mixer" d’identifier les sources dans le paquet "mixer"
Egalité des participants ■
Certains participants ne sont pas atteignables directement en multicast IP ◆ ◆
ils sont derrière un firewall par exemple mise en place d'un relais au niveau RTP applelé "Translator" ✦
2 "translators" sont installés : • 1 "translator" transmet tous les paquets multicast reçus de l'extérieur à travers une liaison sécurisée vers le "translator" à l'intérieur du firewall. • ce dernier les renvoie comme des paquets multicast à un groupe restreint au réseau interne.
Header RTP 0
7
V PX
CC
M
Champs fixes
15
PT
31
sequence number
timestamp
12 premiers octets toujours présents
Synchronisation Souce (SSRC) Identifier Contributing Souce (CSRC) Identifier(s) • • • • • •
isérés par un mixer
version (V), 2 bits. V=2 padding (P), 1 bit. Si bit a 1 alors il y des octets de padding. extension (X) 1 bit. Si bit a 1 : le header fixe est suivi par une extension. CSRC count (CC) 4 bits nombre de CSRC identifiers qui suivent le header. marker (M) 1 bit Son interprétation est définie par un profil. payload type (PT) 7 bits Identifie le format des données contenues dans le paquet RTP. Un profil définie de façon statique la correspondance entre un type de données et le format des données (voir RFC 1890). • sequence number 16 bits Incrémenté de 1 pour cahque paquet RTP. Sa valeur initiale est aléatoire.
Header RTP
Champs fixes
• timestamp 32 bits Instant d'échantillonnage du 1er octet du paquet RTP, Celui-ci est liée est à une horloge qui s'incrémente de façon monotone et linéaire, permet de gérer la synchronisation et la gigue ( jitter). La fréquence de l'horloge est dépendante du format des données, elle est spécifiée de manière statique (RFCXXXX). La valeur initiale du "timestamp" est aléatoire. • SSRC 32 bits Synchronisation Source Identifier(s) Identifie la source sur laquelle les données du paquet sont synchronisées. Choisi de manière aléatoire dans l'intention de ne pas avoir 2 SSRC identiques dans la même session RTP. Néanmoins les implémentations de RTP doivent pouvoir gérer les collisions. • CSRC 0 à 15 items de 32 bits, c'est une liste Identifie les sources qui ont des données dans le paquet RTP. Les CSRC sont insérés par les "mixers
Header RTP ■
Extension
Autorise des implémentations particulières pour des nouveaux formats de données ◆
dans un cadre expérimental par exemple
si bit X a 1 dans le header RTP 0
15
identificateurs ou paramètres du profil
header extension
31
nombre de mots de 32 bits de l’extension
RTCP ■
Fonctionalités
Basé sur la transmission périodique de paquets de contrôle à tous les participants dans une session. • Utilise le même mécanisme de distribution que les paquets de données.
■
Quatre fonctions ◆
Fournir des informations sur la qualité de la session. • information en retour pour une source (feedback) • permet à une source de changer de politique • met en évidence des défauts de distribution individuels, collectifs
◆
Garder une trace de tous les participants à une session • CNAME (Canonical Name) : identifiant unique et permanent pour un participant • SSRC (Synchronisation Source Identifier)
◆
Contrôler le débit auquel les participants à une session RTP transmettent leurs paquets RTCP • Plus il y a de participants, moins la fréquence d'envoie de paquets RTCP par un participant est grande. • Il faut garder le trafic RTCP en dessous de 5% du trafic de la session
◆
Transmettre des informations de contrôle sur la session (optionnel) • exemple : identifier un participant sur les écrans des participants
Paquets RTCP ■
Types de paquets RTCP ◆
SR ✦
◆
statistiques de transmission et réception par les participants qui sont des expéditeurs actifs.
RR ✦
◆
"Sender report"
"Receiver report" statistiques de réception statistiques par les participants passifs
SDES
"Source description"
• CNAME, EMail, Phone number, Localisation géographique... ◆ ◆
■
BYE APP
Quitter une session Fonctions spécifiques de l'application
Paquet RTCP ◆ ◆ ◆
Partie fixe similaire au header fixe des paquets RTP Suivie d'éléments structurés qui peuvent être de longueur variable. Plusieurs paquets RTCP peuvent être concaténés sans séparateur pour être envoyés dans un seul paquet UDP (paquet composé)
Paquets RTCP ◆
Contraintes sur les paquets composés ✦
Les paquets de type SR et RR doivent être envoyés aussi fréquemment que les containtes sur la bande passante le permette afin de maximiser les infos statistiques. • chaque paquet composé RTCP doit contenir un paquet SR ou RR
✦
les nouveaux participants à une session doivent reçevoir dès que possible le CNAME pour une source • chaque paquet composé RTCP doit contenir un paquet SDES
[ ------- paquet ----------------] [ -------------------------paquet ----------------] [ -- paquet ----] R [SR # sender # site 1#site2] [SDES | #Cname PHONE| #CNAME LOC ] [BYE ## why] report encrypté = entier 32 bits aléatoire -------------------------------------------- datagramme UDP -----------------------------------------------# : SSRC/CSRC
RTP "Mixers" et "Translators" ◆
"Translator" ✦ ✦ ✦
✦
◆
envoie les flux de différentes sources séparément transmet les paquets RTP avec leur identificateur SSRC intact certains "translators" peuvent changer l'encodage des données, il assigne alors de nouveaux numeros de séquences aux paquets. un destinataire ne peut détecter la présence d'un "translator" a moins de se procurer les caractéristiques de la source
"Mixer" ✦ ✦
combine les flus de différentes sources pour former un nouveau flux il devient la source de synchronisation • tous les paquets RTP émis sont marqués avec le propre identificateur SSRC du "mixer" • pour préserver l'identité des sources originales il inclut la liste des différents identificateurs SSRC derrière le header RTP (liste CSRC) – CSRC : Contributing source Identifiers
Exemple de réseau RTP E6
E1
E6 : 15
E1 : 17 M1
E2 : 1
E4 : 47 E4
E2
E3
M3
M2 E3 : 64
T2
T1
E5 : 45 E5
source : SSRC (listeCSRC)
Exemple de réseau RTP E6
E1
E6 : 15
E1 : 17 M1 : 48 (1,17) M1
E2 : 1
T2
T1 E4 : 47 E4
E2
M3 : (64,45) M3
M2
E3 E3 : 64
M2 : 12 (64)
E5 : 45 E5
source : SSRC (listeCSRC)
Exemple de réseau RTP E6
E1
E6 : 15
E1 : 17 M1 : 48 (1,17) M1
E2 : 1
T2
T1 M1 : 48(1,17) E4 : 47
E4 : 47
M1 : 48 (1,17) E4 : 47
M3 : 89 (64,45) E6 : 15
E4
E2
M3 : 89 (64,45) M3
M2
E3 E3 : 64
M2 : 12 (64)
E5 : 45 E5
source : SSRC (listeCSRC)
Profil RTP Audio et Vidéo RFC 1890 ■
■
■
■
■
But : Décrire un profil pour l'utilisation de RTP et de RTCP pour une conférence multi-participants audio et video avec un minimum de contrôle. Définition d'un "mapping" par défaut des valeurs du champ PT avec le type d'encodage Le document décrit également comment le son et l'image doivent être transportés par RTP Dans ce profil il n'y a pas de négociations de paramètres, ni de contrôle sur les participants Ports assignés ◆ ◆
1 port pair pour les données RTP le prochain port impair supérieur pour RTCP
Audio ◆
Recommandations indépendantes de l'encodage ✦
✦
✦
Une application qui n’envoie pas de paquets pendant les silences positionne le bit M (marker bit) a 1 dans le header RTP Une application envoie des paquets pendant les silences positionne le bit M (marker bit) a 0 dans le header RTP L'horloge RTP est indépendante du nombre de canaux utilisés et de l'encodage • Si N canaux alors N echantillons pendant une période
✦
Les fréquences d'échantillonnage utilisables (Hz) : • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000
✦
Sessions multi-canaux : les échantillons d'un même instant doivent être dans le même paquet RTP canaux | 2 3 4 4 5 6
1 l l Fl l Fl l
canal 2 3 r r Fr c Fr lc
4
5
6 légende :
c Rl r Fc c
Rr S Sl r
Sr rc
S
l r c S F R
left right center surround front rear
Audio ◆
Encodage basé sur l'échantillonage (numérique) ✦ ✦ ✦ ✦
◆
Encodage type codec (digital) ✦ ✦
◆
Tous les échantillons sont représentés par un nombre constant de bits. Un paquet RTP peut contenir un nombre quelconque d'échantillons. La durée d'un paquet audio est déterminée par le nombre d'échantillons Si muli-canaux, exemple N=2, la séquence d'octets est : (l, 1er echantillon) (r, 1er echntillon) (l, 2ème echantillon) ... un bloc audio de longueur fixe compressé l'expéditeur peut choisir de mettre plusieurs blocs dans un paquet RTP
Encodage audio encodage sample/frame
1016 DVI4 G721 G722 G728 GSM L8 L16 LPC MPA PCMA PCMU VDVI F
bits/sample ms/frame
30
S
S
S
4
4
8
F
2.5
F
20
S
S
8
16
F
20
F
S
S
S
8
8
var.
Vidéo ■
Encodages définis actuellement : ◆ ◆ ◆ ◆ ◆ ◆
Cell-B JPEG H261 MPV MP2T NV
propriétaire Sun ISO 10918-1,10918-2 CCITT/ITU-T MPEG-I et MPEG-II. ISO 11172 et 13818-2 utilisation de flux Mpeg2 pour la vidéo et l'audio. encodage du programme nv (Xerox)
Champ PT, mapping statique ✦
✦
Une source peut émettre un certain type de données (identifié par PT) a n'importe quel moment Le multiplexage de plusieurs types de données dans une session RTP est interdite, mais plusieurs sessions parallèles RTP peuvent être utilisées pour envoyer différents médias. PT 0 1 2 3 5 6 7 8 9 10 11 14 15 25 26 28 31 32 33
encodage
A/V
PCMU 1016 G721 GSM DVI4 DVI4 LPC PCMA G722 L16 L16 MPA G728 CelB JPEG nv H261 MPV MP2T
A A A A A A A A A A A A A V V V V V V
Clock (Hz) canaux 8000 8000 8000 8000 8000 16000 8000 8000 8000 44100 44100 90000 8000 90000 90000 90000 90000 90000 90000
1 1 1 1 1 1 1 1 1 2 1 1
RSVP ◆
draft-ietf-rsvp-spec-13 ✦
◆
◆
◆
RSVP est une méthode pour allouer dynamiquement de la bande passante aux applications orientées réseaux dans des environnements traditionnellement datagramme. RSVP est particulièrement utile pour les applications multimédias de type CBR RSVP rend obligatoire la demande de QoS par le récepteur (l'application participante) plutôt que par l'émétteur (l'application source). ✦
✦ ✦
◆
Resource ReServation Protocol- Version 1 Functional Specification
le récepteur apprend les spécifications du flux multimédia par un mécanisme hors-bande. le récepteur peut ainsi faire les réservations qui lui sont appropriées. résoud ainsi le problème de l'hétérogénéité des réseaux
Les équipements d'interconnexions (routeurs) répondent aux requêtes RSVP , établissent et maintiennent les connexions.
RSVP ◆
RSVP fait des réservation de ressources ✦ ✦
◆
pour les applications unicast et multicast et s’ adaptate dynamiquement aux évolutions (participants, cahngements de routes)
RSVP est utilisé par un "host" pour le compte d'une application, ✦
◆
Fonctionnalités
demander une QoS au réseau (bande passante garanti, débit crête,..)
RSVP est utilisé par les routeurs ✦ ✦ ✦
contrôle de la QoS. établissement et maintient du service demandé. passe de façon transparente les routeurs non RSVP
RSVP ◆
RSVP demande des ressources dans une seule direction ✦
◆
✦
occupe la place d'un protocole de transport dans la pile des protocoles. mais ne transporte pas de données utilisateurs
Rsvp n’est pas un protocole de routage ✦
◆
traite l'émetteur et le récepteur de manière différente.
RSVP travaille au dessus de IP (IPv4 ou IPv6) ✦
◆
Fonctionnalités
il est censé travailler avec les protocoles de routage unicast et multicast
RSVP fourni plusieurs modèles de réservations ✦
utilisables dans la plupart des situations
RSVP
Réservation de ressources
HOST
ROUTEUR
RSVP daemon
RSVP daemon
Application
Policy Control
Routing Protocol daemon
Admission Control
Admission Control
Packet Classifier
Packet Scheduler
Policy Control
Packet Classifier
Le récepteur envoie la requête de QoS au démon RSVP local
Packet Scheduler
RSVP
Réservation de ressources
HOST
ROUTEUR
RSVP daemon
RSVP daemon
Application
Policy Control
Routing Protocol daemon
Admission Control
Admission Control
Packet Classifier
Packet Scheduler
Policy Control
Packet Classifier
Packet Scheduler
La requête Qos est passée à 2 modules de décision Admission Control : qui détermine si les ressources sont suffisantes Policy Control : qui vérifie que l'utilisatuer a l'autorisation administrative de faire cette réservation Si un des modules a une réponse négative alors envoie d'une notification d'erreur au demandeur
RSVP
Réservation de ressources
HOST
ROUTEUR
RSVP daemon
RSVP daemon
Application
data
Policy Control
Routing Protocol daemon
Admission Control
Admission Control
Packet Classifier
Packet Scheduler
Policy Control
data
Packet Classifier
Packet Scheduler
Envoie des paramètres de QoS au Packet Classifier et au Packet Scheduler Le packet Classifier déterminera la route et la classe de QoS pour chaque paquet entrant Le Packet Scheduler prendra la décision de transmettre chaque paquet.
RSVP HOST
Réservation de ressources ROUTEUR
upstream
RSVP daemon
RSVP daemon
Application
data
Policy Control
Routing Protocol daemon
Admission Control
Admission Control
Packet Classifier
Packet Scheduler
Policy Control
data
Packet Classifier
Packet Scheduler
Le scénario se reproduit pour le "hop" suivant Un cache pour le contrôle du trafic est construit dans chaque routeur. Pour répondre aux modifications des sessions multicast par exemple, RSVP envoie des messages de rafraichissement le long du chemin. En l'absence de messgages de rafraichissement, le cache relatif a une réservation est détruit.
RSVP ◆
Réservation de ressources
Session = flot de données avec une destination particulière et un protocole de transport ✦
DestAdress • groupe d'adresses Ip pour le multicast • adresse unicast pour un destinataire unique
✦ ✦
◆
ProtocolId : protocole de transport DestPort : port UDP/TCP
Une requête élémentaire de réservation ✦
requête de QoS
FLOWSPEC
• positionne les paramètres du PACKET SCHEDULER • classe de service + 2 jeux de paramètres numériques ✦
indication de sélection
FILTER SPEC
• positionne les paramètres du PACKET CLASSIFIER • dans la version actuel : @IP émetteur, port UDP/TCP ✦
La paire &LOWSPEC et FILTER SPEC est nommée FLOW DESCRIPTOR
RSVP ◆
Modèles de réservation
"reservation style" = jeu d’options inclu dans la requête de réservation de ressources ✦
quelle réservation pour différents émetteurs dans la même session ? • reservation DISTINCTE pour chaque émetteur. • réservation PARTAG©ESHARED par tous les paquets des émetteurs.
✦
sélection des émetteurs • liste EXPLICITE • sélection implicite de tous : WILDCARD
◆
modèles définis à l'heure actuelle Sender Selection Explicit Wildcard
reservations : Distinct Fixed-Filter (FF) style none defined
Shared Shared-Explicit (SE) Style Wildcard-Filter (WF) Style
RSVP
Réservation : exemple
upstream
downstream
a
( S1 )
c
( R1 )
Routeur ( R2 ) b
( S2 )
d
LAN Eth
( R3 )
QoS = multiple d’une ressource de base B Chaque flux des émetteurs Si est envoyé sur les interfaces (c)et (d)
Emis
Réservé
Reçu
(a) (c)
(c)
(b)
(d)
(d)
Wildcart-Filter (WF)
WF (*{4B} )
WF ( *{3B} ) WF ( *{2B} )
RSVP
Réservation : exemple
upstream
downstream
a
( S1 )
c
( R1 )
Routeur ( R2 ) b
( S2 )
d
LAN Eth
( R3 )
QoS = multiple d’une ressource de base B Chaque flux des émetteurs Si est envoyé sur les interfaces (c)et (d)
Emis
Réservé
(a) (c)
(b)
(d)
*{4B}
*{3B}
Reçu
(c)
(d)
Wildcart-Filter (WF)
WF (*{4B} )
WF ( *{3B} ) WF ( *{2B} )
RSVP
Réservation : exemple
upstream
downstream
a
( S1 )
c
( R1 )
Routeur ( R2 ) b
( S2 )
d
LAN Eth
( R3 )
QoS = multiple d’une ressource de base B Chaque flux des émetteurs Si est envoyé sur les interfaces (c)et (d)
Emis
WF ( *{4B} )
WF ( *{4B} )
Réservé
(a) (c)
(b)
(d)
*{4B}
*{3B}
Reçu
(c)
(d)
Wildcart-Filter (WF)
WF (*{4B} )
WF ( *{3B} ) WF ( *{2B} )
RSVP Taille des groupes multicast ◆
RSVP sait prendre en charge de très grands groupes multicast ✦
◆
la demande de réservation d'un récepteur fusionne avec celles d'autres récepteurs aux noeuds de l'arbre multicast
RSVP utilise les protocoles de routages classiques ✦
il s'adapte aux changements de topologies. Emetteur
downstream
upstream
Le modèle de réservation de base se fait en 1 seul passage = difficulté pour un récepteur d'avoir le résultat sur un service de bout en bout Pour remédier, il ya OPWA : One Path With Advertising
R1
R2
R3
RSVP
Mécanismes
Upstream
Previous Hop
Downstream
Incoming Interface
Outgoing Interface
data
A
data
a
c
path resv
Next Hops
C
path resv
ROUTER
B
D
data
b
path
B'
data
d
resv
path resv
D'
la fusion imlplique lecalcul d’un nouveau &LOWSPEC
◆
2ESV ✦
◆
arrivent jusqu'à l'émetteur
0ATH ✦
messages de réservations vers les émetteurs état de chemin dans chaque routeur
au moins l’adresse IP unicast du "Previous Hop"
RSVP ◆
Police et sécurité à la charge des domaines administratifs de l'Internet ✦
pour prévenir les abus de réservation • règles administratives • facturation d'un coût de réservation
✦
◆
Le rôle de RSVP est de transporter les infos de police et de sécurité
Nuages Non-RSVP ✦ ✦
Les messages 0ATH traversent ces réseaux les messgages 2ESV est envoyé directement au prochain routeur RSVP en direction de l'émetteur.