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.