DNS dans les CDNs aujourd'hui, dans les réseaux orientés contenus demain ?

DNS dans les CDNs aujourd’hui,dans les réseaux orientéscontenus demain?10 Juin 2011

Sara OueslatiOrange-FT GroupInternational Backbone Network Factory

2France Telecom Group

Sommaire

CDN (Content Delivery Network)?

Utilisation du DNS pour les CDNs

Nommage & résolution dans ICN, rôle du DNS?

Conclusion


CDN?

Système distribué de caching et de diffusion au plus près del’Internaute

Bénéfices pour le fournisseur de contenus– QoS, réductions de coûts (par l’absorption de pics de charge)

Bénéfices pour l’ISP– QoS, optimisation de la bande passante– Montée dans l’échelle de valeur & revenus associés

Marché mondial existant– Des revenues pas forcément massifs pour la diffusion video

(3,2 milliards € à horizon 2015)– Plus de marge sur l’accélération web

Acteurs majeurs– Traditionnellement, les “pure players” (Akamai, Limelight,

Level3)– Les telcos se positionnent (ATT, BT, Telefonica, Orange, …),

initiative OCX et CDNi (IETF) pour normaliser l’interco de CDNs

le CDN peut être utilisé comme un outil d’ingénierie de trafic– Transparent caching (pas de contrat avec le fournisseur de

contenu)– Ne doit pas briser la logique business du fournisseur de

contenus– Soulève des problèmes légaux et réglementaires

Diffusion de contenus optimisée et extensible


Diffusion de contenu sans CDN

1-4© 2011 Verivue, Inc. All rights reserved.

Serveur “origine”

GET http://www.example.com/video.mp4Example= youtube, arte, dailymotion, …

Capacité “coeur” << Capacités agrégée “accès”


Diffusion de contenu avec un CDN

1-5© 2011 Verivue, Inc. All rights reserved.

OriginServer

Cache

GET http://www.exemple.com/video.mp4(Exemple = youtube, dailymotion, arte, M6, megaupload, …)


Redirection vers le CDN

Le CDN est un système de caching distribué, où la requête del’utilisateur final pour un contenu est redirigée vers le meilleurcache (proximité, charge, …) au lieu de récupérersystématiquement le contenu du serveur “Origine” (géré par le fournisseurde contenu ou de l’hébergeur)

La redirection peut se faire via :

– DNS– HTTP– DNS et HTTP


Aperçu de la redirection via DNS

ISP

Internet

Request Router

Portal

Fournisseur de Contenu

1- Demande de contenu au portail du fournisseur de contenu get http://vww.exemple.com/video.mp4

2- renvoi de l’URL http://exemple.cdn.orange.com/video.mp4

Serveur “Origine”

DNS

3 - DNS resolution ofexemple.cdn.orange.com

6- IP @ du cache 1

7 – Demande de contenuget http://exemple.cdn.orange/video.mp4

Cache 1

4 - DNS resolutionofexemple.cdn.orange.com 5- @IP du cache 1

(critères géographiques + dynamiques)

Le nom du domaine vu par l’internaute peut être celui du fournisseur CDN(example.cdn.orange.com) ou celui du fournisseur de contenu (cdnorange.example.com)

Le Request Router ne voit pas l’adresse de l’internaute, mais celle du resolveur DNS local => limite laprécision de la géolocalisation du cache

Cache 1 peut ne pas être leplus proche (choix basé sur l’@

du résolveur local associé àl’internaute) => nouvelle

redirection http vers cache 2

Cache 2

8- Redirection vers cache 2

+ HTTP


Aperçu de la redirection via DNS

ISP

Internet

Request Router

Portal


Serveur “Origine”

DNSCache 1

Cache 2

9 - Demande de contenu get http://vww.exemple.com/video.mp4

10 – Diffusion du contenu

+ HTTP

Le nom du domaine vu par l’internaute peut être celui du fournisseur CDN(example.cdn.orange.com) ou celui du fournisseur de contenu (cdnorange.example.com)

Le Request Router ne voit pas l’adresse de l’internaute, mais celle du resolveur DNS local => limite laprécision de la géolocalisation du cache


Aperçu de la redirection via HTTP

ISP

Internet

Request Router

Portal


1- Demande de contenu get http://www.exemple.com/video.mp4

2- renvoi de l’URL http://exemple.cdn.orange.com/video.mp4

Origin server

DNS

3 - DNS resolution ofexemple.cdn.orange.com

4- IP @ of the Request Router

6 – redirection http 302 vers le cache optimal

Cache

Le nom du domaine vu par l’internaute peut être celui du fournisseur CDN(example.cdn.orange.com) ou celui du fournisseur de contenu (cdnorange.exemple.com)

Le “Request Routeur” voit l’adresse Ip de l’internaute et est en mesure de choisir le cache le plusproche

5 - Request contentget http://exempel.cdn.orange.com/video.mp4

7 – Demande de contenuhttp://exemple.cdn.orange.com/video.mp4


Cas d’un seul CDN, domaine vu par l’internautetype “fournisseurContenu.[com|tv|…]”

End UserEU

ISPDNS cache

(LDNS)

CP.comAuth DNS

CDN cachePOP1

RequestRouter

(Auth DNSfor CDN)

L’utilisateur final sélectionne une vidéo au niveau du portail du fournisseur de contenu et lui est au final renvoyée une URL: http://exemple.cdn.orange.com/video.mp4

1 - DNS REQ (orangecdn.CP.com)


3 - DNS REP (orangecdn.CP.com IN NS RequestRouter.cdn.orange.com, standard TTL)

4 - DNS REQ(RequestRouter.cdn.orange.com)

5 - DNS REP (IN A 2.2.2.2, standard TTL)


7 - DNS REP (IN A 10.1.0.0 TTL=30) [This is the IP address of the preferred CDN cache]

8 - DNS REP (orangecdn.CP.com IN A 10.1.0.0 TTL=30)

9 - HTTP GET orangecdn.CP.com/video.mpg

ISP DNS servers CDN provider (Orange) Content Provider (CP)

2.2.2.210.1.0.0

cdn.orange.comAuth DNS

NS par lefournisseur de

contenu


Cas d’un seul CDN, domaine vu par l’internaute detype “fournisseurCDN.[com|tv|…]”

End UserEU

ISPDNS cache

(LDNS)

CP.comAuth DNS

CDN cache1

RequestRouter

(Auth DNSfor CDN)

L’utilisateur final sélectionne une vidéo au niveau du portail du fournisseur de contenu et lui est au final renvoyée une URL:http://exemple.cdn.orange.com/video.mp4

1 - DNS REQ (exemple.cdn.orange.com)


3 - DNS REP (exemple.cdn.orange.com IN NS RequestRouter.cdn.orange.com, IN A 2.2.2.2, standard TTL)


7 - DNS REP (IN A 10.1.0.0 TTL=30) [This is the IP address of the preferred CDN cache 1]

8 - DNS REP (exemple.cdn.orange.com IN A 10.1.0.0 TTL=30)

9 - HTTP GET exemple.cdn.orange.com/video.mpg

ISP DNS servers CDN provider (Orange) Content Provider (CP)

2.2.2.210.1.0.0

cdn.orange.comAuth DNS


Cas d’interco CDN – le DNS dans le rôle dumédiateur

DNS peut aussi jouer le rôle de médiateur pour rediriger larequête vers le bon CDN, exploite la fonction “views”

– Ok pour une granularité à l’échelle du pays– Sauf si le LDNS utilisé par l’internaute n’est pas localisé dans

le même pays (fréquent?)– Le serveur DNS utilisé ne sera pas sollicité à chaque requête,

contrairement à un médiateur fonctionnant en mode HTTP


Avantages & limites de la redirection par DNS

Léger

– Résultats mémorisés au niveau du résolveur local, notammentdans le cas d’une médiation entre 2 CDNs

– Transparent pour l’utilisateur Sélection du cache le plus proche basée sur l’@IP du LDNS,

pas suffisamment précis si LDNS non régionalisés

– Peut induire une étape de redirection http supplémentaire Géolocalisation et possibilité de jouer le rôle de “sélecteur

CDN”, mais

– A priori limité à des critères statiques (@IP)– grosse granularité (p.ex. Pays, AS) OK, sauf si LDNS pas

localisé avec l’internaute


ICN (Information-Centric Networking)

l’accès à l’information premier motif d’utilisation de l’Internet– Information = Content, service, personne

L’objet d’information est directement identifié…– et non plus indirectement via “le host” qui l’héberge

Le contenu peut être n’importe où– Caching généralisé (p.ex, dans tous les routeurs)– L’authentification du host ne suffit plus pour garantir l’authenticité du

contenu (via sécurisation de la résolution (DNSSEC) et/ou du transport)

– Le contenu est identifié par un identifiant + dispositif cryptographique(p.ex., hash) qui fait le lien entre l’identifiant et le contenu

Plusieurs approches pour la résolution de nom de contenu– “Networking” => forte adhérence avec les mécanismes réseau– “Overlay” => indépendante des mécanismes réseaux (acheminement,

routage, …)


Résolution de noms dans ICN, DNS rôle?

CCN (Content-Centric Networking), proposition “networking” dePARC– Une structure hiérarchique de nommage de contenu (s’inspirant de la

strcuture des URLs)– Requête de l’utilisateur final nomme le contenu recherché– Résolution couplé au forwarding– Lookup dans les routers au niveau “nom de contenu”– DNS complètement bypassé!

Les approches ”overlay” (plus incrémentales)– Peuvent opérer au dessus de TCP/IP– Localisation de l’information en 2 étapes

– Requête de l’utilisateur pour une information est dirigée vers unrésolveur de noms “sophistiqué” qui indique l’emplacement, unpeu comme dans les CDNs mais bcp plus riche

– L’information est récupérée à partir du meilleur emplacement


Conclusion

CDN & DNS

– DNS avantageusement utilisé pour la redirection, avectoutefois quelques limitations (précision)

– Peut jouer le rôle de mediateur dans une interco de CDNs– => Utilisation non anticipée du DNS pour rediriger vers un

service CDN Dans les réseaux futurs orinentés contenus (ICN)

– Dans les approches “overlay”, pourrait peut être joué un rôledans la chaîne de resolution de nom de contenu

– Dans les approches “networking” (CCN), le DNS seraitcantonné à son rôle actuel (si évolution incrémentale) =>survie en sursis!

thank you

DNS dans les CDNs aujourd'hui, dans les réseaux orientés contenus demain ?

Technology

Transcript of DNS dans les CDNs aujourd'hui, dans les réseaux orientés contenus demain ?