CDNI. CDN Interconnection CDNI. Autor: Prof. Dr.-Ing. Anatol Badach

Transkript

1 Autor: Prof. Dr.-Ing. Anatol Badach Auszug aus dem Werk: Herausgeber: Heinz Schulte WEKA-Verlag ISBN CDNI CDN Interconnection Die beiden Welten unsere reale und die virtuelle Internetwelt sind schon fast untrennbar miteinander verbunden. Das Internet ist für uns inzwischen zu einer weltweiten, universellen und unerschöpflichen Informationsquelle geworden. Sämtliche sich im Internet befindenden Arten digitaler Medien wie Texte, Daten, Bilder, Sprache und Video werden im Allgemeinen als Content, insbesondere die Webseiten als Webcontent bezeichnet. Dieser digitale Content ist zum Kommunikationsmittel des 21. Jahrhunderts geworden und damit man ihn in guter Qualität aus dem Internet abrufen kann, werden von mehreren Anbietern sog. Content Delivery Networks (CDNs) eingerichtet und zum Content-Abruf (Content on Demand) durch die Internetnutzer bereitgestellt. Seit einiger Zeit werden verschiedene Arten des zeitkritischen Content u.a. in Form von sog. Streaming-Medien, wie z.b. Internet Protocol Television (IPTV) oder Over-the-Top Video (OTT-Video), über das Internet zum Abruf angeboten. Um die Möglichkeit zu schaffen, alle Formen dieser Streaming-Medien weltweit so anbieten zu können, dass sie bei den Internetnutzern überall und immer in guter Qualität ankommen, ist in der Regel der gleichzeitige Einsatz mehrerer CDNs nötig, was eine Kooperation der involvierten CDNs und ihrer CDN-Anbieter (CDN-Provider) verlangt. Infolgedessen wird seit einiger Zeit intensiv an Ideen gearbeitet, die bei einer derartigen Kooperation gewährleisten sollen, dass die vernetzten CDNs und ihre Anbieter beim Abruf des zeitkritischen Contents effizient zusammenarbeiten können. In diesem Zusammenhang spricht man von CDN Interconnection (CDNI), auch von Content Distribution Internetworking (CDI) oder auch kürzer von Content Internetworking. Hierbei kann der zeitkritische Content eines Content-Anbieters (Content Service Provider, CSP) auf mehrere kooperierende CDNs quasi auf eine Föderation von CDNs (CDN-Federation) ausgelagert und so zum Abruf bereitgestellt werden. Kooperation setzt im Allgemeinen Interoperabilität zwischen den beteiligten Instanzen voraus. Diese stellen die kooperierenden CDNs 1

2 her, indem sie untereinander verschiedene Informationen über die Art und Weise der Kooperation austauschen und dadurch entsprechend ihren Kooperationsprozess abstimmen. Dazu müssen die auszutauschenden Informationen weltweit eindeutig interpretierbar sein und auch einheitlich spezifiziert werden. Damit verbindet sich die Forderung nach einem international gültigen Rahmenwerk (Framework), das die einzelnen Regeln für die Interoperabilität von CDNs bündelt. Ein solches CDNI-Framework wurde bereits von der Working Group CDNI 1 der Internetorganisation IETF 2 im RFC 7336 in einem ersten Schritt spezifiziert. Weitere Entwicklungen zur Sicherstellung der Interoperabilität von CDNs sind bei der Working Group CDNI eingeleitet und sollen nach Abschluss der Arbeiten in Form von Internetstandards (RFCs) von der IETF veröffentlicht werden. Weitere CDNI betreffende Aktivitäten insbesondere im Hinblick auf die Möglichkeit der Realisierung von IPTV werden gegenwärtig vom europäischen Standardisierungsgremium ETSI 3 koordiniert (siehe hierzu die Auflistung der ETSI-Dokumente am Ende dieses Beitrags). Die beiden Organisationen IETF und ETSI stehen aber bezüglich ihrer laufenden CDNI-Aktivitäten in keinerlei Konkurrenz zueinander. Es sei an dieser Stelle auch hervorgehoben, dass diverse CDNI- Konzepte und -Lösungen bereits in einer Vielzahl von Patenten offenbart sind und folglich dem Patentschutz unterliegen. Die CDNI-relevanten Patente sind am Ende dieses Beitrags aufgelistet. Das Hauptziel dieses Beitrags ist es, sowohl die Ziele und die Einsatzmöglichkeiten der CDNI in fundierter Form zu präsentieren als auch grundlegende Ideen und technische Lösungen für die CDNI, insbesondere das CDNI-Framework, anschaulich darzustellen und kurz auf verschiedene Möglichkeiten der Kooperation von CDNs einzugehen Internet Engineering Task Force 3 European Telecommunications Standards Institute 2

3 Die grundlegende Idee des CDN Zur Einführung in die Begriffswelt der CDNI illustriert Bild das fundamentale Konzept des CDN anhand einer vereinfachten Struktur. Diese verdeutlicht die eigentliche Aufgabe des CDN. Sie besteht in der Vervielfachung des bei den Content-Anbietern auf Ursprungs-Servern (Origin Servers) gespeicherten Contents, also in der Erzeugung von dessen Replikationen (Replicas), und in deren Verteilung mithilfe eines Content Distribution System (CDS) auf eine Vielzahl von im Internet verstreuten und möglichst in der Nähe zu Nutzern installierten Servern. Da auf diesen Servern die Content- Replikationen für den Abruf durch die Internetnutzer vorgehalten werden, bezeichnet man diese Server als Replica-Server. Bild : Die vereinfachte Struktur eines CDN und dessen Basisfunktionen: A) Content Distribution auf zahlreiche Replica-Server, B) Ermittlung der IP-Adresse des Servers, C) Content-Abruf vom bestgeeigneten Replica-Server DNS: RR: UServ: Domain Name System Request Router Ursprungs-Server Anmerkung: Zu Beginn der 2000er-Jahre, also am Anfang der CDN-Ära, waren auch die Bezeichnungen Surrogat-Server oder kurz Surrogat für den heutigen Replica-Server üblich. Mit dem Wort Surrogat wurde damals darauf 3

4 verwiesen, dass es sich entsprechend seiner Funktion um einen sog. Stellvertreter-Server bzw. Ersatz-Server handelt. CDNs wurden zu Beginn der 2000er-Jahre noch hauptsächlich mit dem Ziel installiert, beliebte Webserver mit hohem Verkehrsaufkommen, also Server mit Webcontent, zu entlasten und den Webcontent effizient an die Internetnutzer zu liefern, sodass deren Erwartungen hinsichtlich der sog. Quality of Experience (QoE) 4 erfüllt werden konnten. Aus diesem Grund hat man damals bei CDNs in der Regel von Ursprungs-Webservern und von Replica-Webservern gesprochen. Die Welt der CDNI hingegen beschränkt sich nicht auf Webcontent, sondern impliziert alle Arten von Content (z.b. verschiedene Streaming-Medien), sodass man hier allgemeiner von Ursprungs-Servern oder Replica-Servern spricht. Wie in Bild ersichtlich, verhält sich jedes CDN einerseits als Replikator (Vervielfacher) von Content-Masterkopien und als deren Verteiler auf mehrere Replica-Server, andererseits muss jedes CDN aber auch dafür sorgen, dass der Content als Internetressource unter einer Adresse, d.h. unter einer auf den Ursprungs-Server bei einem Content-Anbieter verweisenden URL 5, nicht vom Ursprungs-Server abgerufen wird, sondern von einem nach bestimmten Kriterien ausgewählten Replica-Server beim CDN-Anbieter. Um solche Umleitungen vom Ursprungs-Server auf einen entsprechenden Replica-Server zu ermöglichen, muss in CDNs das sog. Request Routing realisiert werden. Dieses Prinzip spielt bei der CDNI eine entscheidende Rolle, auf welche im Weiteren noch detaillierter eingegangen wird. Anmerkung: Vergleicht man ein CDN mit den in der realen Welt existierenden Lösungen für die Lieferung von Waren, so stellt man folgende Entsprechungen fest: Ein Ursprungs-Server würde einem zentralen Lager einer Produktionsstätte entsprechen und ein Replica-Server einem lokalen Lager in der Nähe der Konsumenten. 4 Quality of Experience, von engl. experience (Erfahrung, Erleben, Erlebnis), gilt allgemein als Maßstab für die subjektive Zufriedenheit eines Nutzers mit dem von ihm genutzten Dienst oder System somit ein Maß für das Verhältnis von Nutzererwartung und -wahrnehmung. 5 Uniform Resource Locator 4

5 Ein großer Vorteil des CDN aus Sicht des Internetnutzers besteht vor allem darin, dass er den von ihm gewünschten Content von einem in seiner Nähe installierten Replica-Server in bester Qualität ausgeliefert bekommt und nicht in verminderter Qualität von einem weit entfernten Ursprungs-Server. Dies gilt insbesondere für kontinuierliche zeitkritische digitale Medien wie Video und IPTV, deren einzelne Pakete auf langen Übermittlungsstrecken unterschiedliche Netzlaufzeiten aufweisen können, die eine Qualitätsminderung bei der Übermittlung kontinuierlicher Medien verursachen könnten. Dies Qualitätsproblem löst das CDN in der oben beschriebenen Art und Weise, wodurch das Internet in die Lage versetzt wird, zeitkritische Dienste zu erbringen. Den nächsten Schritt, die Unterstützung aller zeitkritischen Dienste und ihre globale Verfügbarkeit, realisiert die CDNI durch die weltweite Kooperation der dienstbeteiligten CDNs. Die Basisfunktionen des CDN Die in Bild dargestellte vereinfachte Architektur eines CDN bringt dessen maßgebliche Funktionen anschaulich zum Ausdruck. Die Realisierung von CDN-Aufgaben kann man zu den drei folgenden Hauptschritten A, B und C zusammenfassen: Schritt A Content Distribution auf zahlreiche Replica-Server Eine wichtige Funktion jedes CDN besteht darin, Masterkopien des auf den bei Content-Anbietern installierten Ursprungs- Servern, die quasi zentrale Content-Lager darstellen, gespeicherten Contents mithilfe eines Content Distribution System (CDS) auf eine Vielzahl von sekundären Servern zu verteilen, um den Content räumlich näher am Internetnutzer zu platzieren. Diese sekundären Server sind sozusagen lokale, in der Nähe von Internetnutzern installierte Content-Auslieferungslager und werden als Replica-Server bezeichnet. Schritt B Ermittlung der IP-Adresse eines Replica-Servers Die Content-Abrufe von Internetnutzern werden normalerweise nur an die Ursprungs-Server gerichtet, d.h. die URL eines Original-Content verweist immer nur auf den Ursprungs-Server mit diesem Content. Daher wird Schritt B auf die zwei Teilschritte B 1 und B 2 aufgeteilt, und zwar auf die DNS-Abfrage in der Do- 5

6 main des Content-Anbieters (B 1 ) und auf die Abfrage der IP- Adresse des bestgeeigneten Replica-Servers in der Domain des CDN-Anbieters (B 2 ). 6 Im ersten Teilschritt B 1 muss der DNS-Server beim Content- Anbieter bei der Abfrage der IP-Adresse des Ursprungs- Servers auf den DNS-Server in der Domain des CDN- Anbieters verweisen, bei dem man den zur Content-Lieferung (Content Delivery) ausgewählten bestgeeigneten Replica-Server und dessen IP-Adresse abfragen kann. Im zweiten Teilschritt B 2 wird der DNS-Server in der Domain des CDN-Anbieters abgefragt. Diesem DNS-Server wird mit dem Request Router (RR) eine zusätzliche Funktionsinstanz vorangestellt. Ihre Aufgabe besteht in der Ermittlung des bestgeeigneten Replica-Servers zur Lieferung des gewünschten Contents nach bestimmten RR 7 -Kriterien und in der Mitteilung von dessen IP-Adresse an den als Client fungierenden Rechner, von dem der Content-Abruf ausgeht. Schritt C Content-Abruf vom bestgeeigneten Replica-Server Nachdem der Client die IP-Adresse des bestgeeigneten Replica- Servers erhalten hat, übermittelt er den Request an diesen, um den gewünschten Content abzurufen. Footprint und Capabilities eines CDN Mit einem CDN kann kontinuierlicher, zeitkritischer Content in einer ausreichend guten Qualität in der Regel nur innerhalb einer begrenzten geografischen Region geliefert werden. Sie lässt sich als Versorgungsgebiet interpretieren, das in diesem Kontext als Footprint des CDN angesprochen wird. Es sei aber angemerkt, dass der Begriff Footprint als geografische Region nicht immer präzise ist. Erfolgt beispielsweise der Zugang zu einem CDN über einen 6 Als bestgeeigneter Replica-Server gilt der Server, von dem man zum Zeitpunkt des Abrufs die beiden Qualitätsindikatoren Quality of Service (QoS) und QoE auf dem höchsten Level aller Server erwarten kann. QoS ist aus technischer Sicht ein Maß für die Dienstgüte und QoE ist ein Maß dafür, wie gut ein Dienst bzw. ein System die Erwartungen von Menschen im Hinblick auf ihre Erfahrungen erfüllt. 7 Request Routing 6

7 Internet Service Provider (ISP), dann bestimmt dessen Internet- Versorgungsgebiet de facto den Footprint des betreffenden CDN. Dank der Kooperation von CDNs kann der Footprint vergrößert werden, somit ist die Footprint-Erweiterung (Footprint Extension) ein wichtiges Ziel der Interconnection von CDNs (CDNI). Zur Umsetzung dieses Ziels müssen die kooperierenden CDNs in der Lage sein, sich gegenseitig über ihre Footprints zu informieren. Die dazu nötigen Informationen können in unterschiedlichen Formen ausgetauscht werden, beispielsweise in Form einer mathematischen Menge von Länder-Identifikationsnummern, von Autonomous System Numbers (ASNs) oder auch von Netzwerk-Präfixen. Mit dem Begriff Footprint werden daher im Allgemeinen die Fähigkeiten eines CDN zum Ausdruck gebracht, den Content innerhalb einer geografischen Region auf der Erdkugel liefern zu können. Daneben ist ein CDN normalerweise in der Lage, weitere spezielle Funktionen (Fähigkeiten) zu erbringen, die an anderer Stelle als Leistungsmerkmale bezeichnet werden. In der CDN-Welt spricht man hingegen von Capabilities, wenn man die erweiterten funktionellen Fähigkeiten eines CDN meint. Im Folgenden werden die beiden Termini Footprint und Capabilities zusammengefasst und als quasi-aggregierte Eigenschaft Footprint and Capabilities (FC) angesehen. Eine Kooperation von CDNs ist nur dann sinnvoll, wenn deren FC sich gegenseitig ergänzen. Demzufolge muss jedes CDN während der Kooperation mit anderen CDNs in der Lage sein, seine FC- Angaben anderen CDNs, mit denen es bereits kooperiert oder kooperieren möchte, zu signalisieren (anzuzeigen). Man bezeichnet diesen Vorgang als FC-Advertisement. Dafür sind mehrere sog. logische FC-Interfaces (FCIs) zwischen kooperierenden CDNs vorgesehen; für Näheres darüber siehe die Bilder und Upstream-CDN und Downstream-CDN Bei der CDNI können die kooperierenden CDNs während des Content-Abrufs unterschiedliche Rollen mit eigenen Aufgaben übernehmen. Dies gilt, wie Bild zeigt, insbesondere beim funktionellen Verbund zweier CDNs. Entsprechend dieser Rollenvertei- 7

8 lung unterscheidet man bei jedem einzelnen Content-Abruf zwischen Upstream-CDN und Downstream-CDN. Upstream-CDN (ucdn) Als ucdn gilt dieses CDN, an welches bei einem Abruf der gewünschte Content vom Ursprungs-Server zur Verteilung auf mehrere Replica-Server übergeben wurde. In der Folge wird jeder Versuch, den Content vom Ursprungs-Server abzurufen, zu der Request-Routing-Instanz (RR-Instanz) im ucdn umgeleitet. Downstream-CDN (dcdn) Als dcdn wird dieses CDN bezeichnet, zu dem vom ucdn A der Content-Request zur Content-Lieferung umgeleitet wird und durch das der gewünschte Content schließlich ausgeliefert wird. Bild : Interconnection von zwei CDNs und deren Rolle als Upstream-CDN oder Downstream-CDN beim Content-Abruf CI: FCI: LI: MI: RI: RR: CDNI Control Interface CDNI Footprint & Capabilities Advertisement Interface CDNI Logging Interface CDNI Metadata Interface CDNI Request Routing Redirection Interface Request Router 8

9 Die in Bild gezeigte Kooperation zwischen ucdn und dcdn verläuft so, dass der Content-Abruf-Versuch, kürzer als Content Request bezeichnet, mehrfach umgeleitet wird, sodass man auch von (Content) Request Redirections spricht. Die Kooperation zwischen ucdn und dcdn beim Content-Abruf besteht im Wesentlichen darin, dass der Content Request zuerst (Schritt A) beim Content Service Provider zum ucdn, dann (Schritt B) im ucdn zum dcdn und letztlich (Schritt C) im dcdn auf den bestgeeigneten Replica-Server umgeleitet wird. Und letztendlich (Schritt D) wird der gewünschte Content vom Replica-Server abgerufen. Beim in Bild gezeigten Verlauf des Content-Abrufs wird die DNS-Anfrage nach der IP-Adresse des Servers mit dem gewünschten Content in den Schritten A, B und C wie folgt umgeleitet: Schritt A: beim Content Service Provider zur RR-Instanz im ucdn, Schritt B: im ucdn zur RR-Instanz im dcdn, Schritt C: im dcdn auf den bestgeeigneten Replica-Server. Schritt D: Im letzten Schritt D erfolgt der Content-Abruf von dem im Schritt C ausgewählten bestgeeigneten Replica-Server. Bild zeigt auch sog. CDNI-Interfaces zwischen den kooperierenden CDNs. Es handelt es sich hier um eine Darstellung fünf wesentlicher Angaben, die zwischen jeweils zwei kooperierenden CDNs ausgetauscht werden müssen. Diese CDNI-Interfaces, die als eine Art CDNI-spezifischer Protokolle zwischen CDNs angesehen werden können, symbolisieren logische Schnittstellen zwischen CDNs. Sie werden als CDNI-Framework angesehen und im RFC 7336 spezifiziert (vgl. Bild ). Die praktischen Einsatzmöglichkeiten der CDNI Nachdem die grundlegende Idee von CDNs dargestellt wurde, soll jetzt kurz auf die praktischen Einsatzmöglichkeiten der Kooperation mehrerer CDNs, also auf CDN Use Cases, eingegangen werden. Wie Bild zeigt, lassen sich sämtliche Einsatzszenarien der CDNI einer der drei folgenden Kategorien zuordnen: Footprint-Erweiterung Da man mit einem CDN den Content nur innerhalb eines begrenzten Gebiets abrufen kann, also dessen Footprint auf eine 9

10 geografische Region beschränkt ist, führt jede Kooperation von CDNs in der Regel zur Vergrößerung der Region, in der man Content in ausreichend guter Qualität abrufen kann; die Kooperation schafft somit die Voraussetzung zur Footprint- Erweiterung. Ermöglichung von Traffic Offload Unter Traffic Offload oder kurz Offload wird bei CDNI eine organisatorische Maßnahme verstanden, die dazu dient, die Datenverkehrslast (Data Traffic) aus einem CDN in normalen Überlastsituationen oft nur teilweise, aber in außergewöhnlichen kritischen Situationen (z.b. bei einem gravierenden Ausfall) vollkommen auf ein anderes CDN zu verlagern bzw. umzuladen. Kurzum: Offload bietet eine Lösung zur Verlagerung von Verkehrslast (Load) aus einem CDN zu einem anderen CDN in außergewöhnlichen Situationen. Erweiterung von Fähigkeiten Jedes CDN kann neben seinen obligatorischen Basisfunktionen zusätzliche spezielle Funktionen (Fähigkeiten) wie die Unterstützung besonderer Medienformate oder Protokolle erbringen, quasi in Form weiterer Capabilities. Falls mehrere CDNs in einem Verbund derart kooperieren, dass sie sich funktionell ergänzen, ist dadurch das Spektrum der aggregierten Fähigkeit Footprint and Capabilities (FC) einer CDN-Gruppe breiter angelegt als das Fähigkeitsspektrum jedes einzelnen CDN aus der Gruppe. Bild : Kategorien von Einsatzmöglichkeiten der CDNI 10

11 Die einzelnen in Bild gezeigten Kategorien von Einsatzmöglichkeiten der CDNI lassen sich etwas detaillierter wie folgt charakterisieren: Footprint-Erweiterung Die Footprint-Erweiterung wird insbesondere mit den folgenden Zielsetzungen angestrebt: Rein geografische Erweiterung Ein größeres CDN ist nötig und dieses kann durch einen Verbund mehrerer bereits existierender kleinerer CDNs verschiedener Anbieter entstehen. So kann die daraus resultierende Struktur eine dieser drei Formen annehmen: - eine direkte Kopplung von zwei CDNs; man bezeichnet diese CDN-Form als Peer-to-Peer-CDN (P2P-CDN) oder als PeerCDN, - eine flache Vernetzung mehrerer quasi gleichberechtigter CDNs, sodass eine CDN-Federation entsteht. - eine mehrstufige (Multi-Levels) Vernetzung mehrerer CDNs, sodass eine hierarchische CDN-Vernetzungsstruktur entsteht. In dieser Struktur fungiert ein CDN quasi als Koordinator und Verteiler von Content Requests auf die ihm untergeordneten CDNs (vgl. Bild b). Technologische Aggregation von CDNs Diese Alternative besteht darin, dass mehrere technologisch nicht vollkommen identisch ausgebaute CDNs eines Anbieters de facto dessen CDN-Zweigstellen so integriert werden, dass sie sich wie ein großes CDN verhalten. Unterstützung nomadischer Nutzer Darunter wird die Möglichkeit verstanden, mobile Internetnutzer, die weltweit unterwegs sind, so zu unterstützen, dass sie den von ihnen abonnierten Content (z.b. IPTV) bei ihren Heimat- CDN-Anbietern von unterwegs mit Tablets standortunabhängig abrufen können. In Zukunft werden wir mit Tablets reisen und an jedem Ort Fernsehprogramme wie ARD und ZDF aus dem Heimatland empfangen können, und das in der gleichen Qualität, wie wir sie von zu Hause aus kennen. Eine solche Vorstellung ist heutzutage keine Utopie mehr. Sie ist nur eine Frage der Zeit und wird durch eine Interconnection mehrerer weltweit verteilter CDNs verwirklicht werden können. 11

12 Overlay-CDN und Access-CDNs Es ist ein Content Service Provider (CSP) vorstellbar, welcher den Content anderer CSPs vermarktet. Dieser CSP nutzt als Content-Makler für die Lieferung von Content ein eigenes CDN, quasi ein Overlay-CDN, und mehrere, ihm sozusagen untergeordnete, bei verschiedenen ISPs installierte CDNs. Auf diese Weise entsteht eine zweistufige Kooperation von CDNs (vgl. Bild b). Ermöglichung von Traffic Offload Die Nachfrage nach Content wie IPTV lässt sich im Allgemeinen nicht genau voraussehen. Folglich lässt sich ein CDN auch nicht im Voraus an die statistisch variierende Datenverkehrslast flexibel anpassen, was eine wirtschaftlich vertretbare Dimensionierung des CDN beeinträchtigt. Als Folge dessen sind Überlastsituationen in CDNs in der Regel nicht zu vermeiden. Hinzu kommen allgemeine Ausfälle und Störungen der Netzressourcen, die sich ebenfalls auf die Verfügbarkeit und Qualität des CDN negativ auswirken. Eine mögliche Abhilfe in solchen unerwünschten Situationen kann darin bestehen, die Datenverkehrslast aus einem betroffenen CDN nur teilweise bzw. in Ausnahmesituationen auch vollständig auf ein anderes CDN im Netzverbund zu verlagern; folglich eine als Traffic Offload oder kurz Offload bezeichnete Maßnahme zu realisieren. Dies kann mit folgenden Zielsetzungen erfolgen: Vermeidung der Überlast Ein Ziel der Kooperation von CDNs kann darin bestehen, ein überlastetes CDN durch Umleitung von Verkehrslastanteilen zu einem benachbarten CDN zu unterstützen. Verbesserung der Resilienz 8 Ein weiteres Ziel der Kooperation von CDNs kann die Verbesserung der Resilienz sein, und zwar im folgenden Sinne: Sollte ein CDN aus irgendeinem Grund (z.b. nach einem Ausfall) nicht vollkommen funktionsfähig sein, dann sollte die Möglichkeit bestehen, dessen Datenverkehr zu einem benachbarten CDN umzuleiten. 8 Als Resilienz (Resiliency) bezeichnet man die Fähigkeit eines Systems, Störungen unterschiedlicher Art zu kompensieren und den korrekten Betriebszustand möglichst schnell wiederherzustellen. 12

13 Erweiterung von Fähigkeiten Die Erweiterung von Fähigkeiten, eine weitere Kategorie von Einsatzmöglichkeiten der CDNI, wird vor allem dann angestrebt, wenn die Footprints von kooperierenden CDNs sich gegenseitig mehr oder weniger überlagern. Dies kann mit folgenden primären Zielsetzungen erfolgen: Verbesserung der QoE Möglichkeiten zur Hebung der subjektiven Zufriedenheit der Nutzer eröffnen sich beispielsweise, wenn zwei ISPs ihre eigenen CDNs so bereitstellen, dass die Replica-Server beider CDNs sich gegenseitig ergänzend in Nutzernähe platziert werden, sodass die Nutzer kontinuierlich Medien in guter Qualität empfangen. Funktionelle Erweiterung Die Chancen dazu bieten sich unter anderem, wenn die Replica- Server von beispielsweise zwei CDNs in keiner Konkurrenz zueinander stehen, sondern in einer Region derartig verteilt sind, dass ihre unterschiedlichen Leistungsmerkmale (Capabilities) zu einem erweiterten Spektrum aggregierter Fähigkeiten (Footprint and Capabilities) fusionieren, das den Nutzern beider CDNs offensteht. Technologische Interoperabilität Ein CDN-Anbieter kann zusätzlich zu seinem alten CDN ein neues, technologisch gesehen modernes CDN installieren, um das alte um neue funktionelle Möglichkeiten so zu ergänzen, dass die beiden CDNs gut kooperieren können. Auf diese Weise lässt sich eine technologische Interoperabilität erreichen. Multi-Vendor Interoperabilität Dank der in den CDNI-Standards (RFCs) spezifizierten Konzepte können CDNs verschiedener Anbieter so miteinander kooperieren, dass ein heterogener Multi-Vendor Service (MVS) 9 in guter Qualität erbracht werden kann. Folglich kann man von der Multi-Vendor-Interoperabilität sprechen. 9 Darunter versteht man im Allgemeinen das Erbringen von Dienstleistungen durch verschiedene Anbieter, insbesondere durch verschiedene Hersteller von Hardware- und Softwarekomponenten. 13

14 Das CDNI-Framework Ein CDNI-Framework (s. Bild ) beschreibt zum einen die notwendigen Arten von Interconnection-spezifischen Informationen, die zwischen CDNs ausgetauscht werden müssen, damit man diese miteinander so zusammenschalten kann, dass sie sich funktionell gegenseitig ergänzen können. Außerdem beschreibt das Framework, auf welche Art und Weise diese Informationen zwischen CDNs ausgetauscht werden können. Bild : CDNI-Framework von der IETF seine logische Struktur CI: FCI: LI: MI: Req: RI: CDNI Control Interface CDNI Footprint & Capabilities Advertisement Interface CDNI Logging Interface CDNI Metadata Interface Request CDNI Request Routing Redirection Interface 14

15 Ein solches CDNI-Framework wurde bereits von der IETF im RFC 7336 spezifiziert. Es definiert fünf Kategorien von Informationen, damit eine effiziente Kooperation mehrerer technisch und nach dem Funktionsumfang unterschiedlicher CDNs in verschiedenen Situationen erreicht werden kann. Um die einzelnen Kategorien dieser Informationen voneinander unabhängig und sogar mithilfe verschiedener Protokolle zwischen CDNs übermitteln zu können, sind im CDNI-Framework der IETF für einzelne Informationskategorien separate logische Interfaces vorgesehen. Bild zeigt die allgemeine Struktur des CDNI-Framework 10 und stellt die Bedeutung der Interfaces heraus. Es sei hier hervorgehoben, dass jedes dieser Interfaces kein physisches Interface darstellt, sondern ein logisches, welches lediglich die Möglichkeit symbolisiert, eine Kategorie Interconnection-spezifischer Informationen zwischen zwei kooperierenden CDNs auszutauschen. Anmerkung: Die in Bild gezeigten Schritte A, B, C und D haben die gleiche Bedeutung wie die gleichnamigen Schritte in Bild Um Interconnection-spezifische Informationen zwischen den funktionellen Instanzen/Komponenten 11 Control, Logging, Request Routing und Content Distribution. in zwei kooperierenden CDNs zu übermitteln, werden die im Bild gezeigten logischen Interfaces im CDNI-Framework vorgesehen und in mehreren, ihnen speziell gewidmeten Internetstandards spezifiziert. Die vorgesehenen Interfaces lassen sich kurz wie folgt charakterisieren (vgl. Bild ): 10 In allen CDN betreffenden Dokumenten der IETF werden die Replica- Server noch als Surrogates bezeichnet. 11 Die genannten Instanzen/Komponenten können unterschiedlich realisiert werden. Bei Content Distribution handelt es sich beispielsweise in der Regel um ein verteiltes System. Die Funktionen von Control und Logging können durch Softwareinstanzen erbracht werden. Die Funktion von Request Routing kann durch Hard- oder Softwarekomponenten realisiert werden. 15

16 CI CDNI Control Interface Dieses Interface zwischen den Control-Instanzen der beiden kooperierenden CDNs dient zur Ansteuerung aller Vorgänge, die sich sowohl auf die Übergabe des abrufbaren Contents vom ucdn zum dcdn als auch auf dessen Auslieferung aus dem dcdn an den Internetnutzer beziehen. LI CDNI Logging Interface Es ermöglicht die Übermittlung von verschiedenen Logging- Informationen. Darunter werden hier jene Informationen verstanden, die in Form von sog. Logdateien (Log Records) gespeichert werden. Diese werden zu unterschiedlichen Zwecken verwendet, so u.a. für Accounting, Performance und Security Evaluation kooperierender CDNs und als spezielle Dateien, um den Ursprungszustand des Systems, von ucdn und dcdn also, nach schweren Systemfehlern und -ausfällen wiederherstellen zu können. Die Logging-Informationen tragen somit u.a. zur Wiederherstellung (Recovery) des Systems bei. RI CDNI Request Routing Redirection Interface Über dieses Interface zwischen den Request-Routing-Instanzen (RR-Instanzen) der kooperierenden CDNs werden alle RRrelevanten Informationen übermittelt, darunter auch jene über deren Footprints. FCI CDNI Footprint & Capabilities Advertisement Interface Die Informationen über Footprints und über weitere besondere technische Fähigkeiten von CDNs werden wie schon ausgeführt als Footprint & Capabilities bezeichnet. Die beiden kooperierenden CDNs müssen sich diese Informationen gegenseitig ankündigen/anzeigen (advertise). In diesem Zusammenhang spricht man von Footprint & Capabilities Advertisements, wofür das Interface FCI vorgesehen ist. MI CDNI Metadata Interface Als Metadaten (Metainformationen) bezeichnet man Daten, die Merkmale/Besonderheiten anderer Daten beschreiben. In diesem Sinn ermöglicht das Interface MI die Übermittlung von Informationen über den abrufbaren Content. Als Metadaten gelten insbesondere folgende Angaben zum Content: - Acquisition Source: Von welchem Server beim ucdn kann der Content abgeholt werden? 16

17 - Delivery Access Protocol: Mit welchem Protokoll kann der Content abgeholt werden? - Delivery Authentication: Nach welchem Verfahren soll die Authentifizierung beim ucdn bei der Content-Beschaffung (Acquisition) erfolgen? - Cache Control: Wie soll der Replica-Server beim dcdn, der de facto als Content Cache fungiert, die Validierung (u.a. Überprüfung der Aktualität) des Content realisieren? Es sei angemerkt, dass die in Bild gezeigten Interfaces zwischen den kooperierenden CDNs auch in verschiedenen anormalen Situationen zuverlässig sein müssen. Um dies möglichst vollständig garantieren zu können, werden im RFC 7337 zahlreiche Anforderungen an das allgemeine CDNI-Konzept die sog. CDNI- Requirements spezifiziert. Wie die oben genannten Interfaces zwischen ucdn und dcdn realisiert und für welche Zwecke sie genutzt werden, soll nun im Folgenden ausführlicher erläutert werden. Für die Fortsetzung siehe: Dreibändiges Loseblattwerk (Print und CD-Version) mit Update-Dienst: "Protokolle und Dienste der Informationstechnologie" Aktualisierungszyklus: 2 Monate, WEKA Media, Kissing ISBN-13: , Bestell-Nr. OL9142J 17