DE602004011689T2 - Verfahren und System zur Handhabung der Übermittlung von Inhalten in Kommunikationsnetzen - Google Patents

Verfahren und System zur Handhabung der Übermittlung von Inhalten in Kommunikationsnetzen Download PDF

Info

Publication number
DE602004011689T2
DE602004011689T2 DE602004011689T DE602004011689T DE602004011689T2 DE 602004011689 T2 DE602004011689 T2 DE 602004011689T2 DE 602004011689 T DE602004011689 T DE 602004011689T DE 602004011689 T DE602004011689 T DE 602004011689T DE 602004011689 T2 DE602004011689 T2 DE 602004011689T2
Authority
DE
Germany
Prior art keywords
request
server
content
requester
gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE602004011689T
Other languages
English (en)
Other versions
DE602004011689D1 (de
Inventor
Eugenio Maria Maffione
Giovanni Gambaro
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telecom Italia SpA
Original Assignee
Telecom Italia SpA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telecom Italia SpA filed Critical Telecom Italia SpA
Publication of DE602004011689D1 publication Critical patent/DE602004011689D1/de
Application granted granted Critical
Publication of DE602004011689T2 publication Critical patent/DE602004011689T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1021—Server selection for load balancing based on client or server locations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die Erfindung betrifft die Übermittlung von Inhalten in Kommunikationsnetzen.
  • Die Erfindung wurde unter besonderem Augenmerk auf die mögliche Anwendung in einem Internet-Szenario entwickelt, zum Beispiel zum Kontrollieren des Zugangs zu medialen Inhalten in solchen operativen Kontexten, in denen eine oder mehrere "vertikale" Technologien zum Übermitteln von medialen Inhalten und zum Zugreifen auf mediale Inhalte in einem Mobilfunk- und/oder Festnetz verwendet werden.
  • BESCHREIBUNG DES STANDES DER TECHNIK
  • In den zurückliegenden Jahren haben Dienste, die im Internet und/oder in Firmen-Intranets verfügbar sind und auf der Übermittlung medialer Inhalte (insbesondere des multimedialen Typs) basieren, eine besondere Bedeutung erlangt. Dies wird sowohl durch die Verfügbarkeit größerer Übertragungsbandbreiten für den Zugang als auch durch die stete Zunahme der Anzahl und der Arten der zur Übermittlung zur Verfügung stehenden Inhalte belegt.
  • Neben den traditionellen Web-Inhalten stellen inzwischen auch andere datenintensive multimediale Inhalte wie zum Beispiel Videostreaming (sowohl als Archivabruf als auch als Direktübertragung) Dienste bereit, die für die Nutzer von besonderer Bedeutung sind ("elektronisches Lernen", Internet-Rundfunk, Video-on-Demand usw.). Dieses Szenario wird immer reichhaltiger aufgrund der neuen Arten von Inhalten, die in der Regel durch vertikale Plattformen unterstützt werden, die durch spezielle und spezialisierte Provider angeboten werden. Zu Beispielen dafür gehören Plattformen für Gaming-on-Demand und Application-on-Demand.
  • Die Inhalte werden von einem Service-Center eines Inhalte-Anbieters (Content Provider – CP) für einen Nutzer-Standort (User Site – US) bereitgestellt, wo sich ein über ein Netzwerk N (Zugang + Metro + Transport) zugeschalteter Inhalte-Anforderer (Content Requester – CR) befindet.
  • Um einen Dienst zur Übermittlung verfügbar zu machen, müssen der Inhalt, der Inhalteserver CP und der Inhalte-Anforderer CR generell bestimmte Vorgaben im Hinblick auf die Kompatibilität erfüllen. In der Praxis müssen die Komponenten, die sich an den Endpositionen befinden (das heißt der Server CP und der Anforderer CR) Software-Einrichtungen verwenden, die einer gemeinsamen Technologie entsprechen bzw. mit einer gemeinsamen Technologie kompatibel sind.
  • Aus diesem Grund gibt es, wenn man allein nur von Streaming-Inhalten spricht, unterschiedliche Arten von Technologien, wie zum Beispiel jene, die im "Windows Media 9 Series Deployment Guide", Microsoft, Dezember 2002, Seiten 47–51, oder im "Helix Universal Server Administration Guide, Version 9.0", Real Networks, 29. Mai 2003, Seiten 247–299, beschrieben sind.
  • Jede dieser Technologien ist durch spezielle Merkmale im Hinblick auf die verfügbaren Software-Plattformen (zum Beispiel mobiles Endgerät, PC, PDA, Set-Top-Box), die Software, die auf dem Server verfügbar ist, und die entsprechenden Autorisierungsmechanismen gekennzeichnet.
  • Eine solche Verfahrensweise ist als eine "vertikale" bezeichnet worden, weil, obgleich ein Endnutzer zwar auf seinem System eine native Software installiert haben kann, die geeignet ist, mindestens eine Inhalte-Technologie zu "lesen", die relevanteste Aufgabe im Service-Center CP angeordnet ist. Genauer gesagt, muß das Service-Center mit Übermittlungsservern sowie Autorisierungsverfahren und -systemen ausgestattet sein, die speziell für jede Technologie ausgelegt sind, die durch das Center unterstützt werden soll.
  • Eine typische Anordnung, die als eine "zentralisierte" Architektur bezeichnet wird, ist in 1 gezeigt. Diese enthält im Wesentlichen zwei Funktionsblöcke, die physisch an verschiedenen Punkten angeordnet sind:
    • – auf der einen Seite enthält der Inhalte-Anforderer CR ein Nutzer-Endgerät und zugehörige Software, die auf das Nutzer-Endgerät geladen ist, wobei sich beide Komponenten an dem Nutzer-Standort befinden (möglicherweise einschließlich eines Mobiltelefons), und
    • – auf der anderen Seite enthält das Service-Center CP Batterien von Servern 10, 12, die jeweils dafür konfiguriert sind, einen bestimmten Satz Dienste in Bezug auf eine bestimmte Technologie in Abhängigkeit von der Anzahl gleichzeitiger Anforderungen, die verwaltet werden sollen, zu erbringen. Jeder Batterie 10, 12 ist ein jeweiliger Autorisierungsserver 10a, 12a und eine entsprechend zugeordnete Autorisierungsdatenbank 10b, 12b zugeordnet. Jeder Satz, der aus einer Batterie von Servern, dem entsprechenden Autorisierungsserver und der zugeordneten Datenbank besteht, wird derzeit als eine "Inhalte-Farm" bezeichnet.
  • Kurz gesagt, muß das Service-Center CP in der zentralisierten Anordnung, die in 1 gezeigt ist, notwendigerweise eine Anzahl verschiedener Inhalte-Farmen enthalten, die der Anzahl verschiedener Technologien entspricht, die durch das Center unterstützt werden sollen.
  • Durch den ausdrücklichen Verweise auf die Technologien von Microsoft und Real Networks, die oben angesprochen wurden, erfordert eine Anordnung, wie sie in 1 gezeigt ist, verschiedene jeweilige Verfahrensweisen und Mechanismen zum Verwalten einer Autorisierung für das Zugreifen auf die jeweiligen Inhalte. Diese Verfahrensweisen und Mechanismen sind nicht direkt kompatibel. Zum Beispiel können der Zugang und/oder die Autorisierung mittels proprietärer Plug-ins kontrolliert werden, die Steuerungsfunktionen bezüglich des Dateisystems ausführen, das die Inhalte der IP-Adressen der zugreifenden Nutzer speichert.
  • In anderen Technologien stützt sich die Autorisierung auf das Überprüfen einer externen Tabelle, die aus einer einfachen Textdatei, einer Datenbank in einem proprietären Format oder einer offenen SQL(Structured Query Language)-Datenbank bestehen kann.
  • Zusammenfassend gesagt, erfordert eine Anordnung, wie sie zum Beispiel in 1 offenbart ist, daß nicht nur die Batterien oder Bänke von Servern 10, 12 eindeutig einer einzelnen Inhalte-Technologie zugeordnet sind. Die gleiche Teilung gilt praktisch auch für das Verfahren und das System, die die Autorisierungsaufgaben ausführen. Dies erfordert Verwaltungs- und Steuerkomponenten, die für jede einzelne Technologie spezialisiert und eigens vorgesehen sind, wobei praktisch jede Komponente mit homologen Komponenten für die anderen Technologien, die möglicherweise in dem Service-Center vorhanden sind, inkompatibel ist.
  • Das bedeutet unter anderem, daß, wenn dem Center eine neue Technologie zur Übermittlung von Inhalten hinzugefügt wird, keine praktische Möglichkeit besteht, Einrichtungen zu nutzen, die bereit installiert sind, um auf diese Weise von Skalierungsfaktoren zu profitieren.
  • Infolge der sich verbreiternden Perspektive neuer Arten von Inhalten (Gaming-on-Demand, Application-on-Demand und so weiter) und des möglichen Angebotes neuer vertikaler Lösungen durch Technologie-Anbieter laufen die Autorisierungssoftware- und -hardware-Komponenten und -Prozesse Gefahr, ein echtes Problem für Anbieter, die Service-Center betreiben, zu werden.
  • Neben diesen zentralisierten Architekturen, die auf dem Konzept von Dienst-Centern basieren, war in der jüngeren Vergangenheit eine Entwicklung in Richtung der Anordnung zu erkennen, wie sie in 2 gezeigt ist. Dies ist im Wesentlichen eine sogenannte Inhalteverteilungsnetz(Content Distribution Network – CDN)-Anordnung.
  • In einem CDN-Kontext (wie er zum Beispiel offenbart ist in: "Cisco ACNS 5.1 Caching And Streaming Configuration Guide, Release 5.1", 2003, Cisco, Seiten 227–270, Textteil N.OL-4070-01) treten periphere Server, die als "Surrogat"-Server 14 bezeichnet werden, an die Stelle der zentralisierten Server der Anordnung von 1. Die Surrogat-Server befinden sich physisch näher am Nutzer (wobei das in 2 gezeigte Netzwerk N im Wesentlichen aus dem Zugangs- und Metropolitan-Netzwerk besteht und allgemein nicht mehr das eigentliche Transportnetzwerk umfaßt). Auf diese Weise sind die Surrogat-Server 14 in der Lage, die Inhalte durch Ausnutzen einer größeren Bandbreite zu übermitteln.
  • In der in 2 gezeigten Anordnung wird jede Anforderung, die durch den Inhalte-Anforderer CR vorgelegt wird, über ein zentrales System (als Inhalte-Router CDNCR bezeichnet) in Richtung eines Servers 14, in dem die angeforderten Inhalte verfügbar sind, umgeleitet. Ein solcher Server 14 wird im Hinblick auf die verfügbaren Ressourcen und die "Distanz" über das Netzwerk als der geeignetste ausgewählt. Nach einem solchen Umleitungsprozeß (Inhalte-Routing) ist der Prozeß des Zugreifens auf die Inhalte auf dem ausgewählten Surrogat-Server im Wesentlichen analog dem Prozeß, der in der Anordnung von 1 stattfindet.
  • In einer typischen Ausführungsform gehört die CDN-Architektur einem Netzwerkbetreiber – und wird durch einen Netzwerkbetreiber verwaltet –, der mehreren Inhalte-Anbietern die Möglichkeit bietet, die CDN-Infrastruktur zu nutzen, um die Verteilung und Übermittlung der jeweiligen Inhalte zu unterstützen.
  • Ein typisches Merkmal der Surrogat-Server 14 in einem CDN ist, daß sie nicht speziell für eine einzelne Inhalte-Technologie ausgelegt sind. Sie sind genauer gesagt dafür ausgelegt, gleichzeitig Anforderungen für verschiedene Arten von Inhalten zu bedienen (zum Beispiel Real, Windows Media und so weiter). Folglich verhalten sie sich infolge ihrer Fähigkeit, die Dienst-Komponenten der verschiedenen Technologien zu integrieren, im Wesentlichen als Multitechnologie-Server, wodurch jene Komponenten in einem einzelnen Surrogat-Server 14 nebeneinander bestehen.
  • Die in 2 gezeigte CDN-Architektur ist nicht frei von einem gewissen Grad an Komplexität. Neben Skalierungsfaktorproblemen im Zusammenhang mit der Verwaltung der Autorisierungsprozesse für die verschiedenen verwendeten Technologien (mit der daraus resultierenden Notwendigkeit, ein spezielles Autorisierungsmodul 14a zu haben, das für jede spezielle Technologie verfügbar ist) ergibt sich ein weiteres Problem infolge der Wahrscheinlichkeit, daß die Inhalte auf jedem Surrogat-Server 14 zu verschiedenen Inhalte-Anbietern in Beziehung stehen, für die unterschiedliche Autorisierungs- und Lizenzierungsvorschriften bestehen.
  • Dies vergrößert praktisch noch die Komplexität des Prozesses des Autorisierens des Zugangs, wodurch es praktisch unmöglich gemacht wird, auf eine genaue und "granulare" Weise die Autorisierungskriterien und -verfahren für die Inhalte zu handhaben, die durch verschiedene Inhalte-Anbieter verfügbar gemacht werden. Das Hinzufügen neuer Inhalte-Technologien (wie zum Beispiel Gaming-on-Demand oder Application-on-Demand) zu einer verteilten Architektur, wie in 2 gezeigt, kann sich als noch komplexer als im Fall der zentralisierten Anordnung, die in 1 gezeigt ist, erweisen.
  • In beiden Architekturen, die in den 1 und 2 gezeigt sind, wird die Kontrolle des Zugangs zu den Inhalten zu einer kritischen Frage sowohl für den Netzwerkbetreiber als auch den die Inhalte-Anbieter, insbesondere was die Abrechnung durch den Betreiber anbelangt. Dies zeigt sich ganz besonders, wenn man sich den Fall eines Dienstes vor Augen hält, der auf der Grundlage eines Abonnements für den Dienst selbst einen unterschiedslosen Zugang zu den Inhalten gestattet. Dies kann der typische Fall eines Abonnements für einen in Privathaushalten angebotenen ADSL-Dienst sein. Beim Übergang von diesem Dienst zu einem Zugang auf der Grundlage einer Prepaid-Abrechnung, wobei die Abrechnung in Abhängigkeit von den angeforderten speziellen Inhalten erfolgt (wie es für einen Prepaid-Zugang über ein Mobiltelefon der Fall ist), wird die Möglichkeit, unter Echtzeit-Bedingungen – d. h. zu dem Zeitpunkt, wo die Anforderung erfolgt – mögliche Versuche eines betrügerischen Zugangs zu detektieren, zu einem strategischen, wenn nicht gar überlebensnotwendigen, Problem.
  • Eine mögliche Echtzeit-Kontrolle hat nicht an sich eindeutig etwas mit einem Echtzeit-Intervenieren im Fall eines betrügerischen Zugangsversuchs zu tun. Ein Betreiber kann sich unter besonderen Umständen entschließen, einen betrügerischen Zugangsversuch eine bestimmte Zeit zu tolerieren, während er sich das Recht vorbehält, die geeignetsten Maßnahmen im Hinblick zum Beispiel auf bestimmte Marketing-Vorgehensweisen zu ergreifen.
  • In dieser Hinsicht basieren die jüngsten zum Stand der Technik gehörenden Anordnungen auf Herangehensweisen, wobei eine Steuervorrichtung vorhanden ist, die dafür geeignet ist, in einer transparenten Weise auf den Datenfluß zwischen dem Nutzer und dem Server, der den Dienst anbietet, einzuwirken, während eine Zugangskontrolle auf der Grundlage bestimmter interner Regeln ausgeführt wird.
  • Zum Beispiel ist im "Cisco Content Service Switch Basic Configuration Guide, Version 7.20", März 2003, Cisco, Kapitel 3 und 5, Textteil Nummer 78-13886-05, ein Satz Vorrichtungen, die als CSS (Content Service Switch) bezeichnet werden, offenbart, die dafür geeignet sind, auf den Datenfluß zwischen einem Client und einem Server einzuwirken. Die Vorrichtungen definieren statische Regeln, die auf den Client/Server-Verkehr Anwendung finden. Diese sind dafür geeignet, auf Gruppen von Clients (die bestimmte Teilnetz- oder IP-Adressen haben, oder Server, die eine bestimmte IP-Adresse oder DNS-Domänen haben) und Inhalte-Arten (zum Beispiel Dateinamen-Endungen oder URL) auf der Grundlage zuvor festlegbarer Listen, die auf verschiedenen Vorrichtungen konfiguriert sind, angewendet zu werden. Auf der Grundlage solcher Regeln (die von außerhalb programmiert werden) analysiert die Vorrichtung den Verkehr und entscheidet, wie mit ihm zu verfahren ist, das heißt, ob ein bestimmter Verkehr unmodifiziert weiterzuleiten ist, zu filtern ist, um seinen Durchgang zu sperren, oder zu alternativen Bestimmungsorten umzuleiten ist (dies ist in der Regel der Fall, wenn der Dienst nicht in der Lage ist, zu bestimmten Inhalten zu gelangen).
  • Solche Vorrichtungen erfordern zwangsläufig, daß die Autorisierungsregeln in den Vorrichtungen selbst voreingestellt werden. Dies erweist sich aus mindestens zwei Gründen als eine kritische Lösung.
  • Ein erster Grund hat mit der maximalen Anzahl von Autorisierungen zu tun, die konfiguriert werden können. Diese Zahl erreicht wahrscheinlich einen sehr hohen Wert, im Allgemeinen höher als die Kapazität des Systems selbst (insgesamt 25.000 Regeln), wobei alle möglichen Nutzer/Inhalte-Kombinationen zu berücksichtigen sind. In einer typischen Ausführungsform können 100 Zugangslisten, die als Zugangskontrollisten (Access Control Lists – ACL) bezeichnet werden, definiert werden, die jeweils dafür geeignet sind, maximal 254 "Klauseln" aufzunehmen. Innerhalb jeder Klausel besteht die Möglichkeit, einen einzelnen Nutzer und einen einzelnen Inhalt oder Gruppen von Nutzern und/oder Inhalten zu definieren. In der Praxis sind alle diese Gruppen an sich statisch, und sie sind in keiner Weise beim Aufstellen von Regeln hilfreich.
  • Ein zweiter kritischer Faktor liegt darin, daß das Vorab-Konfigurieren solcher Regeln keine dynamische Kontrolle von Autorisierungen zuläßt. Es ist nicht möglich, einen bestimmten Nutzer in Bezug auf bestimmte Inhalte in Abhängigkeit von Bedingungen, die sich sehr rasch und außerhalb der Vorrichtung selbst ändern können, zum Beispiel infolge der Aktivierung eines neuen Abonnements, eines erschöpften Guthabens, einer Erneuerung des Guthabens oder von Sonderaktionen, freizugeben oder zu sperren.
  • WO-A-99/57866 offenbart ein Datenumleitungssystem zum Umleiten der Daten eines Nutzers auf der Grundlage eines gespeicherten Regelsatzes. Die entsprechende Herangehensweise basiert auf einem Anwendungs-Proxy. Dies ist besonders im Hinblick auf die Geräteanforderungen aufwendig, weil es ein Emulationsanwendungsmodul für jeden Dienst bzw. jede Technologie erfordert, der bzw. die durch das System unterstützt wird. Darum wird für jede zu handhabende Technologie ein dediziertes technologieabhängiges Softwaremodul benötigt. Ein weiteres Problem liegt darin, daß ein solches spezielles Softwaremodul möglicherweise nicht zur Integration in das System zur Verfügung steht. Dies kann der Fall sein, wenn die involvierten Inhalteverteilungstechnologien proprietäre Technologien sind, was eine recht aktuelle Situation zum Beispiel für Gaming-on-Demand oder Application-on-Demand ist.
  • Eine weitere alternative Anordnung ist in einer Reihe von Dokumenten offenbart, die an Nomadix, Inc. erteilt wurden, wie zum Beispiel US-B-6 130 892 , US-B-6 636 894 , WO-A-01/31886 oder WO-A-02/35797 .
  • Die Nomadix-Lösung kann auf das Zugangsnetz zum Filtern der Inhalte angewendet werden, die durch eine Inhalteübermittlungs-architektur übermittelt werden, indem drei Grundanforderungen erfüllt werden:
    • – Analysieren des Anforderungspaketes von dem Inhalte-Anforderer, ohne daß zusätzliche Softwaremodule benötigt werden, die speziell für das Protokoll oder die Inhalteübermittlungstechnologie vorgesehen sind,
    • – Weiterleiten und Empfangen der Autorisierungsanforderung, die in Richtung eines externen Servers versandt wurde, und
    • – Umsetzen der Autorisierung durch eventuelles Verweigern oder Umleiten der ursprünglichen Anforderung von dem Nutzer (was jedoch spezielle Softwaremodule zur Anwendungsumleitung erfordert).
  • Neben dem Problem der Anwendungsskalierbarkeit, das mit dem Umleiten in Beziehung steht, weist die Nomadix-Vorrichtung eine Reihe kritischer Punkte in Bezug auf die Verwendung von Inhalteverteilungsdiensten in den Kontexten auf, die oben besprochen wurden.
  • Als ein erster Punkt befindet sich die Nomadix-Vorrichtung in dem Zugangsnetz des Telekommunikationsbetreibers. Das erweist sich als ein schwerwiegendes Implementierungsproblem für den Betreiber. Das gilt besonders im Fall eines Festnetzes, weil es eine hohe Anzahl von Vorrichtungen im Vergleich mit anderen Anordnungen erfordert, wo sich der Standort näher bei der Übermittlungsquelle befindet (das heißt mit dem Inhalte-Standort des CDN oder mit dem Dienst-Center in einer zentralisierten Architektur).
  • Zweitens kontrolliert und sperrt die Nomadix-Vorrichtung die von dem Client kommende Anforderung. Infolge dessen kann die Zeit, die der Prozeß des Empfangens der Client-Anforderung, des Erhaltens der Autorisierung bei einem zentralisierten System, des Bereitstellens einer anschließenden Antwort und des tatsächlichen Weiterleitens der Anforderung in Anspruch nimmt, so lange dauern, daß es zu einem Anwendungs-Timeout beim Inhalte-Anforderer oder beim Inhalteserver kommt. Eine solche Anordnung ist nicht zur Verwendung in einem mobilen Kontext geeignet, wo die Einhaltung von Echtzeitanforderungen unverzichtbar ist, um einen Schutz vor betrügerischen Verhaltensweisen zu gewährleisten, während andererseits Übertragungslatenzen möglicherweise nicht unbedeutend sind.
  • Wenn schließlich die Nomadix-Vorrichtung eine Dienst-Berichterstattung unterstützt, so gibt sie einen Berichtsdatensatz aus, der ausschließlich auf der Inhalte-Anforderung beruht. Im Fall einer Anomalie in der Antwort durch den Übermittlungsserver kann dies zu einer falschen Zeichengabe (und einer falschen Abrechnung) führen, während es keine Möglichkeit gibt, die Zeit zu zählen, die die Inhalte tatsächlich übermittelt wurden, weil das Ende der Übermittlung nicht detektiert wird.
  • AUFGABE UND ZUSAMMENFASSUNG DER ERFINDUNG
  • Es besteht darum ein offenkundiger Bedarf an Anordnungen, die dafür geeignet sind, die Beschränkungen der oben betrachteten Anordnung des Standes der Technik zu überwinden, indem zum Beispiel zusätzliche Funktionen hinzugefügt werden, die für eine Berichterstattung geeignet sind, während ein Echtzeit-Autorisierungs-(und -Berichterstattungs-)Mechanismus bereitgestellt wird, der dafür geeignet ist, den Zugang zu Inhalten zu kontrollieren. Insbesondere besteht ein offenkundiger Bedarf an Anordnungen, bei denen technologieunabhängige, dynamische Kontrollkriterien einen hohen Freiheitsgrad bei der Auswahl der "Granularität" der Kontrollaktion gestatten. Dies macht es möglich, in dieser Hinsicht frei auf Parameter wie zum Beispiel Teilnetz/URL/Nutzer/Logik-Gruppierungen von Inhalten in einer Kombination zuzugreifen, die frei ausgewählt wird, indem unterschiedslos sowohl auf den Anforderungsfluß als auch auf den Antwortfluß (die übermittelten Inhalte) eingewirkt wird, indem parallel eine umfassendere Unterstützung für Berichterstattungszwecke bereitgestellt wird.
  • Die Aufgabe der vorliegenden Erfindung ist die Bereitstellung einer Anordnung, die diesen Erfordernissen genügt.
  • Gemäß der vorliegenden Erfindung wird diese Aufgabe mittels eines Verfahrens erfüllt, das die Merkmale aufweist, die in den folgenden Ansprüchen dargelegt sind. Die Erfindung betrifft des Weiteren ein entsprechendes System, ein zugehöriges Netzwerk sowie ein zugehöriges Computerprogrammprodukt, das in den Speicher von mindestens einem Computer geladen werden kann und Softwarecodeabschnitte zum Ausführen der Schritte des erfindungsgemäßen Verfahrens, wenn das Produkt auf einem Computer abläuft, enthält. Im Sinne des vorliegenden Textes soll ein Verweis auf ein solches Computerprogrammprodukt gleichbedeutend sein mit einem Verweis auf ein computerlesbares Speichermedium, das Anweisungen zum Steuern eines Computersystems zum Koordinieren der Ausführung des erfindungsgemäßen Verfahrens enthält. Ein Verweis auf "mindestens einen Computer" soll selbstredend die Möglichkeit hervorheben, daß die vorliegende Erfindung auf eine verteilte oder modulare Weise implementiert werden kann.
  • Eine bevorzugte Ausführungsform der Erfindung ist somit ein System zur Handhabung von Transaktionen in einem Kommunikationsnetz, wobei die Transaktionen mindestens eine technologieabhängige Anforderung für einen bestimmten Inhalt enthalten, die durch einen Anforderer an mindestens einen Server gestellt wird. Das System arbeitet auf der Grundlage einer Zugangsinhalteliste, die Klauseln für das Zulassen oder Verwehren des Zugangs, die den Zugang der Anforderer zu den durch den Server bereitgestellten Inhalten regeln, enthält. Ein Verarbeitungsmodul ist bereitgestellt, das dafür konfiguriert ist, die technologieabhängige Anforderung zu detektieren und daraus Informationen zu extrahieren, die den Anforderer, der die Anforderung stellt, und die angeforderten Inhalte identifizieren. Es kann somit ein entsprechender technologieunabhängiger Zugangsinhalteeintrag erzeugt werden, der anhand der Zugangsinhalteliste überprüft werden kann, um Zulassungs- und Verweigerungsinformationen bezüglich der detektierten Anforderung abzuleiten. Die Anforderung wird in Abhängigkeit von den abgeleiteten Zulassungs- und Verweigerungsinformationen gehandhabt und somit zum Beispiel i) in Richtung des Servers weitergeleitet oder ii) entweder abgeworfen oder zu einem alternativen Zielort weitergeleitet. Der Zugang zu den verschiedenen übermittelten Inhalten wird somit in einer Weise kontrolliert, die unabhängig von den konkreten Technologien ist, die zum Übermitteln der medialen Inhalte verwendet werden.
  • Die im vorliegenden Text beschriebene Anordnung ist somit dafür geeignet, eine Kontrollaktion in Bezug auf Folgendes auszuführen:
    • – den Inhalte-Typ (Bild, Datei, Videostream, Web-Seiten),
    • – den Typ des Protokolls, das zum Übermitteln der Inhalte in Richtung des Nutzer verwendet wird (http, https, http progressive, mms, rtsp, ftp usw.),
    • – die Übermittlungsarchitektur (zentralisierter Server, Surrogat-Server oder CDN),
    • – den Typ des Client, der die Übermittlung von Inhalten anfordert (Set-Top-Box, Personalcomputer, Mobiltelefon usw.),
    • – den Typ der IP-Konnektivität (drahtlos, GPRS, Ethernet usw.).
  • Eine besonders bevorzugte Ausführungsform der Erfindung beinhaltet das Vorhandensein einer zentralisierten Steuerungskomponente (die als ein Inhalte- und Sicherheitsvorschriften-Server fungiert), die dafür geeignet ist, in Echtzeitbedingungen die Nutzer/Inhalte-Autorisierungen zu verifizieren, um in einer einheitlichen Weise die Autorisierungen für alle Technologien und Inhalte-Arten (derzeitige und künftige) zu verwalten. Dies basiert überwiegend auf dem Nutzeridentifikator und auf einem Verweis auf die angeforderten Inhalte, wodurch das Autorisierungsverfahren vereinheitlicht wird.
  • Darüber hinaus ist vorzugsweise mindestens eine Netzwerkvorrichtung bereitgestellt, die als ein dynamischer bedingter Inhaltezugangs-Gateway (Dynamic Conditional Content Access – DCCA) fungiert. Ein solcher Gateway kann dafür geeignet sein, für alle (derzeitigen und künftigen) Inhalte-Technologien die folgenden Funktionen auszuführen:
    • – transparente Verkehrsanalyse durch Erzwingen einer beidseitigen Steuerlogik für die Anforderung, die auf die Anforderungen selbst einwirkt oder auf den Rückverkehr in Richtung des Nutzers einwirkt, während ebenfalls auf allen Ebenen (Datenstrecke, Netzwerk, Transport und Anwendung) die davon ableitbaren Informationen berücksichtigt werden. Diese Analyse wird als "transparent" bezeichnet, weil sie ohne Modifizieren der IP-Architektur ausgeführt wird und in einer geschalteten/überbrückten Anordnung ablaufen kann (Ebene 2 des OSI-Stapels);
    • – Empfangen und Weiterleiten von Autorisierungsanforderungen in Richtung der zentralen Steuerungskomponente auf der Grundlage eines einheitlichen Formats für alle Arten von Inhalten durch Identifizieren der angeforderten Inhalte und des Nutzers in einer Weise, die ganz und gar unabhängig von den speziellen Charakteristika der Technologien ist, die für das Verteilen von Inhalten geeignet sind (Typ von Inhalten, Protokoll, Client, Server, Architektur, Konnektivität);
    • – Erzwingen der Autorisierung für den Fluß mit einem beidseitigen Ansatz durch Stoppen des Anforderungsflusses, ohne ihn zu dem Inhalteserver weiterzuleiten (zum Beispiel In-line-Kontrolle, die auf die Anforderung einwirkt), oder durch Sperren des Rückfluß in Richtung des Inhalte-Anforderers (zum Beispiel verzögerte Kontrolle, die auf die Antwort einwirkt), während der Fluß selbst zum Unterstützen der Berichtsfunktion gesteuert wird;
    • – eventuelles Umleiten der Anforderung, wenn eine Steuerung an der Anforderung vorgenommen wird, auf der Grundlage der gleichen transparenten Kriterien, die für Analysezwecke in Betracht gezogen werden, wodurch ein Verweis auf die angeforderten Inhalte, die in den Paket-Nutzdaten enthalten sind, modifiziert wird, während die Kommunikationssitzung aktiv gehalten wird, die mit dem Inhalteserver hergestellt wurde, ohne daß ein Softwaremodul eingreift, das speziell für eine bestimmte Technologie ausgelegt ist.
  • Eine bevorzugte Ausführungsform der im vorliegenden Text beschriebenen Anordnung sieht vor, die betreffende Netzwerkvorrichtung in der Verbindung in Richtung der Batterie oder Bank von Inhalteservern des Service-Centers zu verwenden, entweder indem sie sich am selben Standort wie diese befindet oder indem sie in der Verbindung in Richtung der Surrogat-Server an jedem Standort in der CDN-Architektur angeordnet wird, indem sie am selben Standort angeordnet wird. Auf diese Weise ist die resultierende Anordnung im Vergleich zu jenen Anordnungen, die auf einer Positionierung an einem Zugangspunkt zu dem Netzwerk selbst basieren, deutlich effizienter. Diese letztere Anordnung kann jedoch bei Bedarf trotzdem implementiert werden.
  • Zusammenfassend ausgedrückt, erfüllt die im vorliegenden Text beschriebene Anordnung alle möglichen Erfordernisse für eine dynamische Kontrolle des Zugangs zu Inhalten, die oben angeführt wurden.
  • Genauer gesagt, stellt die im vorliegenden Text beschriebene Anordnung eine Lösung bereit, die:
    • – in Bezug auf die Inhalteübermittlungsarchitektur, den Client und die Inhalte sowie die verwendete IP-Architektur vollständig transparent ist, was unter anderem der Möglichkeit zu verdanken ist, als eine geschaltete bzw. überbrückte Anordnung zu arbeiten;
    • – skalierbar ist, weil der Abschnitt, der speziell für die Verarbeitung der Autorisierung (in einer zentralisierten Weise) vorgesehen ist, von dem Teil abgesondert ist, der speziell für die Auslöse- bzw. Filterungsaktion vorgesehen ist;
    • – in ihrer Art hoch-granular ist, weil sie eine Definition der Zugangsgenehmigungen für die Inhalte auf der Grundlage von Informationen gestattet, die auf der Datenstrecken-, der Netzwerk-, der Transport- und der Anwendungsebene abgeleitet werden können;
    • – hoch-konfigurierbar ist, weil sie eine Echtzeitverwaltung von Zugangsautorisierungen sowohl auf der Grundlage der Inhalte-Anforderung als auch in einer verzögerten Weise durch Einwirken auf den Rückfluß gestattet, wodurch sie mit Inhalte-basierten Diensten neuer Arten kompatibel ist, die eine Echtzeitabrechnung erfordern, wie zum Beispiel jene, die auf einer Prepaid-Abrechnung basieren, während nicht-vernachlässigbare Konnektivitätslatenzen ermöglicht werden; und
    • – Anbieter-unabhängig ist, weil sie problemlos neue Protokolle und Inhalte-Technologien unterstützen kann, ohne zusätzliche Softwaremodule zu erfordern, während sie in der Lage ist, sämtliche Anforderungsprotokolle (und den zugehörigen Rückfluß) abzufangen sowie in einer einheitlichen Weise die Anforderungen für eine Autorisierung und die Berichtsereignisse in Richtung eines zentralisierten Servers zu verwalten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird nun lediglich beispielhaft unter Bezug auf die beiliegenden Zeichnungsfiguren beschrieben, wobei:
  • die 1 und 2 oben bereits kurz beschrieben wurden,
  • 3 ein Blockschaubild ist, das unter Verwendung von im Wesentlichen dem gleichen Layout wie in den 1 und 2 die Grundstruktur der im vorliegenden Text beschriebenen Anordnung darstellt,
  • die 4 bis 6 schematisch die Anwendung des in 3 gezeigten Grundlayouts auf verschiedene Betriebskontexte darstellen,
  • 7 ein Flußdiagramm einer Grundsteuerlogik ist, die dafür geeignet ist, in der im vorliegenden Text beschriebenen Anordnung implementiert zu werden,
  • 8 ein Blockschaubild ist, das den Datenfluß entsprechend dem Flußdiagramm von 7 darstellt,
  • 9 ein weiteres Flußdiagramm ist, das eine alternative Steuerlogik darstellt, die dafür geeignet ist, in der im vorliegenden Text beschriebenen Anordnung implementiert zu werden,
  • 10 ist ein Blockschaubild, das den Datenfluß entsprechend dem Flußdiagramm von 9 darstellt,
  • die 11 und 12 Logikblockschaubilder sind, die eine Genehmigungssteuerung darstellen, wie sie im Rahmen der im vorliegenden Text beschriebenen Anordnung implementiert ist,
  • die 13 bis 17 verschiedene Blockschaubilder sind, die den Betrieb verschiedener Module darstellen, die an verschiedenen Betriebsphasen der im vorliegenden Text beschriebenen Anordnung beteiligt sind,
  • 18 eine Zugangsinhaltestruktur darstellt, die dafür geeignet ist, eine Inhalte-Anforderung und ihre mögliche Umleitung innerhalb der im vorliegenden Text beschriebenen Anordnung zu verwalten, und
  • die 19 und 20 Beispiele möglicher praktischer Ausführungsformen der im vorliegenden Text beschriebenen Anordnung sind.
  • DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN DER ERFINDUNG
  • 3 der angehängten Zeichnung zeigt eine mögliche Position der Komponenten eines im vorliegenden Text beschriebenen Systems mit Bezug auf andere Objekte und Elemente, die an dessen Betrieb beteiligt sind. Allgemein sind Teile, Komponenten oder Elemente, die mit homologen Teilen, Komponenten oder Elementen, die bereits in Verbindung mit den 1 und 2 beschrieben wurden, identisch oder ihnen ähnlich oder gleichwertig sind, mit den gleichen Bezugsbuchstaben und/oder -zahlen gekennzeichnet.
  • Genauer gesagt, enthält die Anordnung von 3 einen Gateway 20 (im Weiteren als ein dynamischer bedingter Inhaltezugang oder DCCA-Gateway [Dynamic Conditional Content Access] bezeichnet), der in dem Verbindungspfad zwischen dem Inhalte-Anforderer CR am Nutzer-Standort US und einer Inhalteserveranordnung 26 (die entsprechend verschiedenen Anordnungen konfiguriert werden kann, wie im Folgenden noch ausführlicher dargestellt), die sich am Inhalteübermittlungsstandort 24 befindet, angeordnet ist.
  • Der Gateway 20 ist dafür konfiguriert, eine Anzahl von Funktionen auszuführen, wie zum Beispiel Auslösen, Konformitätsüberwachung, Filterung, Rangieren und Neueinspeisung mit Bezug auf den Verkehr, der durch den Gateway 20 fließt. Der Gateway 20 ist dafür konfiguriert, mit einem Server 22 zusammenzuarbeiten, der die Rolle eines Inhaltevorschriften- und -sicherheitservers spielt. Dieser ist auf der Steuerungsebene des Netzwerks angeordnet, zum Beispiel in einem Service-Center des Telekommunikationsbetreibers, der das Netzwerk verwaltet. Die Hauptaufgabe des Servers 22 ist das Validieren der ankommenden Anforderungen und eventuell das Aktivieren spezieller Berichtsmechanismen.
  • Die Blöcke, die den Inhalte-Anforderer CR und das Inhalteserversystem 26 darstellen, sind in Strichlinien dargestellt, da sie Architekturelemente darstellen, die es bereits gibt.
  • Die 4 bis 6 zeigen, wie die in 3 dargestellten Grundelemente unterschiedlich innerhalb verschiedener Architekturen, die für die Übermittlung medialer Inhalte geeignet sind, angeordnet sein können.
  • Genauer gesagt, bezieht sich die in 4 gezeigte Anordnung auf eine zentralisierte Architektur, wobei der DCCA-Gateway 20 "vor" den Batterien/Bänken von Inhalteservern 10, 12, die bereits in Verbindung mit 1 besprochen wurden, angeordnet ist.
  • Der Gateway 20 und der Inhaltevorschriften- und -sicherheitserver 22 sind zwei Komponenten, die in dem Service-Center 24 des Inhalte-Anbieters angeordnet sind, d. h. dem Service-Center zum Übermitteln der Inhalte. In diesem Fall besteht das Konnektivitätselement, das durch das Netzwerk N dargestellt ist, gewöhnlich aus dem Zugangsnetz (mit dem der Inhalte-Anforderer CR und der Inhalte-Anbieter 24 verbunden sind), dem Metropolitan-Netzwerk und dem Transportnetzwerk im Fall von Fernverbindungen.
  • Im Gegensatz dazu bezieht sich 5 auf eine CDN-gestützte Übermittlungsarchitektur. In diesem Fall ist der Gateway 20 vor den Surrogat-Servern 14 angeordnet, die an jedem Standort des Inhalteübermittlungsnetzwerks (zum Beispiel an den Metropolitan-Präsenzpunkten) angeordnet sind. Umgekehrt befindet sich der Inhaltevorschriften- und -sicherheitserver 22 in dem Service-Center des Betreibers des Inhalteübermittlungsnetzwerks, eventuell zusammen mit den anderen Steuerungskomponenten dieses Netzwerks, wie zum Beispiel dem CDN-Inhalterouter 23.
  • In diesem Fall befindet sich der optimale Positionspunkt für den Gateway 20, wie angedeutet, vor dem Surrogat-Server (oder der Batterie/Bank von Surrogat-Servern), welche die Inhalte übermitteln. Es sind auch andere Positionen möglich, aber diese führen im Allgemeinen leicht dazu, daß das Kontrollsystem anfälliger für die Versuche von Nutzern wird, durch Umgehen des Kontrollgateways Betrugshandlungen vorzunehmen.
  • 6 bezieht sich auf eine "generische" Architektur, die Server 28 enthält, die an verschiedenen Positionen in dem Netzwerk angeordnet sind und zu verschiedenen Eigentümern gehören. In diesem Fall hat der Gateway 20 die Aufgabe des Filters und Steuerns allen Verkehrs an der Quelle, und zwar in der Nähe des Zugangspunktes zu dem Netzwerk, das durch den Inhalte-Anforderer CR verwendet wird.
  • Die im vorliegenden Text beschriebene Anordnung ist in keiner Weise auf die mögliche Verwendung einer CDN-fähigen Architektur oder einer Architektur, die die Verwendung eines Service-Centers vorsieht, beschränkt. Die im vorliegenden Text beschriebene Anordnung ist dafür geeignet, in Verbindung mit "gemischten" Architekturen zu arbeiten, wo die Notwendigkeit besteht, einen Nutzer zu autorisieren bzw. in die Lage zu versetzen, einen Dienst zu empfangen, der durch einen oder mehrere Server erbracht wird, während die erforderliche Unterstützung für eine Berichterstattung bereitgestellt wird.
  • Die folgende Beschreibung einer bevorzugten Ausführungsform der im vorliegenden Text beschriebenen Anordnung bezieht sich vor allem auf eine mögliche Implementierung in einem CDN-Szenario, d. h. auf einen generischen CDN-Architektur-Kontext. In dieser Hinsicht ist – unter Bezug auf 5 – das Konzept des Surrogat-Servers in seinem allgemeineren Sinn eines "Satzes" Server zu verstehen, die einen Inhalte-Dienst erbringen, während der Inhalte-Router 23 durch andere Systeme, zum Beispiel einen DNS (Domänennamenserver), ersetzt werden kann oder weggelassen werden kann.
  • Die Grundelemente der im vorliegenden Text beschriebenen Anordnungen, und zwar der Gateway 20 (der die Aktionen des Auslösens, Filters und Umleitens ausführt) und der Inhaltevorschriften- und -sicherheitserver 22 (der die Zugangsrechte zu den Inhalten in Echtzeitbedingungen bei einer Anforderung durch den Gateway 20 überprüft und das Ergebnis des Gateways 20 selbst bereitstellt), sind unabhängig vom Typ der Architektur und – genauer gesagt – der Technologie, die in der Inhalte-Anforderer CR/Inhalteserver 24-Kette verwendet wird. Das bedeutet, daß – jeder – Zugang zu dem Surrogat-Server 14 durch den Gateway 20 abgefangen und durch Ausführen der oben betrachteten Funktionen verarbeitet werden kann.
  • Die durch den Gateway 20 implementierten Auslöse- und Filterungsmechanismen können auf der Grundlage einer Beschreibung konfiguriert werden und einen Granularitätsgrad auf der Ebene eines Domänennamens oder eines einzelnen Inhalts erreichen. Dieser Mechanismus wird mittels Listendeskriptoren implementiert, die als Zugangsinhaltelisten (Access Content Lists – ACL) bezeichnet werden und die im Folgenden anhand von 18 noch näher beschrieben werden.
  • Ein ACL-Filter steuert mittels Zulassungs- und Verweigerungsklauseln die folgenden Dinge: die IP-Quellen-Adresse und die Zielortadresse + Teilnetzmaske + VPN-ID, die Art des Transportprotokolls (TCP/UDP), den Kommunikationsport (Quelle/Zielort) und einen Verweis auf die angeforderten Inhalte.
  • Der ACL-Filter wird auf der Ebene des Gateways 20 gehalten, der auf der Grundlage des Abfangens der Nutzer-Anforderung arbeitet, und wird (in einem Zulassungs- und Verweigerungsmodus) im Ergebnis der Validierung der durch den Server 22 ausgeführten Freigabe aktiviert. Dies basiert auf dem Senden der Identifikatorattribute des Nutzers (zum Beispiel der IP-Adresse), der Inhalte des Dienstes (zum Beispiel die URL) und eventuell der entsprechenden Attribute des Surrogat-Servers 14, der den Dienst erbringt.
  • Der Gateway 20 von 5 fängt den Verkehr des Nutzers (eine Anforderung für multimediale Inhalte, die in der Regel "technologieabhängig" ist) in einem transparenten Modus ab, das heißt, ohne ihn zu beeinflussen oder zu modifizieren. Der Gateway extrahiert aus jeder technologieabhängigen Anforderung die Inhalte, für die eine Verwaltung konfiguriert wurde, d. h. die IP-Adresse des Anforderers CR, die URL, die zu den angeforderten Inhalten gehört, die IP-Adresse des Surrogat-Servers und die Charakteristika des verwendeten Protokolls.
  • Diese Daten werden verwendet, um (wie im Folgenden anhand von 18 noch näher beschrieben wird) einen "technologieunabhängigen" Zugangsinhalte(ACL)-Eintrag zu erzeugen, für den eine Validierung angefordert wird, indem auf den Server 22 zugegriffen wird. Der Server 22 überprüft den Berechtigungsnachweis des Nutzers in Bezug auf die gestellte Anforderung und leitet entsprechende Zulassungs- und Verweigerungsinformationen ab.
  • Wenn der Nutzer die Freigabe erhält ("Zulassen"), so bleibt der Datenfluß von dem Nutzer zu dem Surrogat-Server und von dem Surrogat-Server zu dem Nutzer unverändert.
  • Wenn der Nutzer keine Freigabe erhält ("Verwehren"), die angeforderten Inhalte zu empfangen, so können mindestens zwei verschiedene Interventionen stattfinden.
  • Als eine erste Option kann die Anforderung des Client gesperrt werden, d. h. die Anforderung wird nicht an den Surrogat-Server 14, der den Dienst erbringt, weitergeleitet.
  • Als eine alternative Option kann der stromabwärtige Fluß (von dem Surrogat-Server zu dem Client) gesperrt werden.
  • Genauer gesagt – wobei wir uns dem Flußdiagramm von 7 zu wenden –, bezeichnet die Bezugszahl 100 einen Schritt, bei dem der Gateway 20 aus dem Verkehr, der durch den Inhalte-Anforderer CR in Richtung des Servers 14 gesendet wird (der Verkehr ist in 8 mit 1 bezeichnet), die IP-Adresse (ES) und die URL(s) extrahiert. Diese extrahierten Daten werden in einem Schritt 102 einer Überprüfung auf Nutzerfähigkeit unterzogen.
  • Das Ergebnis einer solchen Überprüfung wird in einem Schritt 104 abgewartet, und in einem Schritt 106 wird ein Abschlußtest vorgenommen. Wenn der Test zu einem positiven Ergebnis führt (der Nutzer erhält die Freigabe – "Zulassen"), so wird die jeweilige Anforderung zu dem Surrogat-Server 14 in einem Schritt 108 weitergeleitet.
  • Falls die Überprüfung in Schritt 106 zu einem negativen Ergebnis führt (der Nutzer erhält keine Freigabe – "Verwehren"), so wird die Anforderung in einem Schritt 110 abgeworfen oder umgeleitet.
  • Genauer gesagt, kennzeichnen die Bezugszahlen 1 bis 6 in 8 die zeitliche Abfolge der verschiedenen Verkehrsflüsse. Genauer gesagt, sieht diese Abfolge die folgenden Schritte vor:
    • – die Anforderung von dem Inhalte-Anforderer CR wird an den Gateway 20 gesendet (Fluß 1),
    • – der Gateway 20 fängt die Anforderung ab (während der übrige Verkehr unverändert durchgelassen wird) und versetzt die Anforderung in einen Bereitschaftszustand, ohne sie in Richtung des Surrogat-Servers 14 weiterzuleiten. Derweil bereitet der Gateway 20 eine Anforderung für den Server 22 vor, welche die Verweise für den Anforderer (IP-Adresse) und die angeforderten Inhalte enthält und die dann zu dem Server 22 weitergeleitet wird (Fluß 2);
    • – der Server 22 führt die Überprüfung der Nutzerfähigkeit mit Bezug auf die angeforderten Inhalte aus und antwortet dem Gateway 20 mittels einer Zulassungs- oder Verweigerungsmeldung (Fluß 3);
    • – wenn das Ergebnis positiv ist, so leitet der Gateway 20 die ursprüngliche Anforderung an den Surrogat-Server 14 weiter (Fluß 4); anderenfalls kann er die Anforderung entsorgen oder sie in einer modifizierten Weise (im Rahmen derselben TCP-Sitzung) weiterleiten. Darüber hinaus kann er eine interne ACL erstellen, um anschließende Anforderungen zu optimieren;
    • – der Surrogat-Server antwortet auf die empfangene Anforderung (Fluß 5), und
    • – der Antwortfluß passiert den Gateway 20 in Richtung des Inhalte-Anforderers (Fluß 6). Diese Art des Betriebes ermöglicht eine In-line-Umleitung der Inhalte.
  • Die 9 und 10 beschreiben die alternative Herangehensweise, die bereits oben betrachtet wurde.
  • In diesen Fall veranlaßt die alternative Anordnung, die in den 9 und 10 betrachtet wurde, nach dem Extrahieren (in Schritt 100) der Informationen bezüglich der Nutzerfähigkeit und ihrer Weiterleitung zu dem Server 22 zur Verifizierung (in einem Schritt 102), daß die Nutzeranforderung (in einem Schritt 112) als ein Nutzerpaket an den Server 14 gesendet wird, ohne in irgend einer Weise verändert zu werden. Auf diese Weise kann der Server 14 beginnen, für den Nutzer den angeforderten Dienst zu erbringen. Dies geschieht in einem Schritt 114, der (mindestens) so lange fortgesetzt wird, bis das Ergebnis der Überprüfung aus Schritt 102 von dem Server 22 kommend empfangen wird.
  • An diesem Punkt wird die Nutzerfähigkeit in einem Schritt 116 getestet.
  • Wenn der Schritt 116 zu einem positiven Ergebnis führt, so schreitet das System in Richtung eines "aktivitätenfreien" Schrittes 118 voran, wodurch man den Server 14 zum Schritt 114 voranschreiten läßt, wodurch die Inhalte an den Anforderer CR übermittelt werden.
  • Wenn umgekehrt die Überprüfung des Schrittes 116 ein negatives Ergebnis erbringt, so wird ein Sperrsignal an den Server 114 gesendet, wodurch die Übermittlung des Dienstes in Richtung des Anforderers CR unterbrochen wird.
  • Auch hier sind in dem Schaubild von 10 die verschiedenen Informationsflüsse mit Bezugszahlen bezeichnet, die ihre zeitliche Abfolge kennzeichnen.
  • Genauer gesagt, geschieht in der Anordnung von 10 Folgendes:
    • – die Anforderung des Nutzers wird zu dem Gateway 20 gesendet (Fluß 1);
    • – der Gateway 20 fängt die Anforderung ab (während der übrige Verkehr unverändert durchgelassen wird) und versetzt die Anforderung in einen Bereitschaftszustand, ohne die in Richtung des Surrogat-Servers 14 weiterzuleiten. Derweil bereitet der Gateway eine Anforderung für den Server 22 vor, welche die Verweise für den Anforderer (IP-Adresse) und die angeforderten Inhalte enthält und dann an den Server 22 weitergeleitet wird (Fluß 2);
    • – derweil wird die Anforderung (unverändert) in Richtung des endgültigen Zielortes weitergeleitet, das heißt zum Server 14 (Fluß 3),
    • – der Server 14 beginnt, die Anforderung zu erfüllen, indem er Antwortverkehr zurücksendet (Fluß 4),
    • – der Antwortverkehr wird unverändert von dem Gateway 20 in Richtung des Inhalte-Anforderers CR weitergeleitet (Fluß 5);
    • – nach der Überprüfung der Freigabe des Nutzers in Bezug auf die angeforderten Inhalte antwortet der Server 22 dem Gateway 20 über eine Zulassungs- oder Verweigerungsmeldung (Fluß 6).
  • Im Fall der Zulassung führt der Gateway 20 keiner Operation aus. Umgekehrt fügt er im Fall der Verweigerung einen Filter ein, der den Antwortfluß von dem Surrogat-Server 14 zu dem Inhalte-Anforderer CR sperrt (wodurch die Flüsse 4 und 5 unterbrochen werden).
  • Der Vorteil dieser alternativen Anordnung liegt darin, daß sie das Steuern der Freigabe des Nutzers auch in jenen Situationen gestattet, wo die Übertragungslatenz und der Anwendungs-Timeout, der eventuell daraus abgeleitet wird, kritisch sind. Dies kann in der Regel in einem Mobilfunknetz der Fall sein.
  • 11 ist ein beispielhaftes Blockschaubild einer möglichen internen Struktur des Servers 22. In der gezeigten beispielhaften Ausführungsform ist der Server 22 im Wesentlichen ein System, das auf verschiedene Datenbanken zugreift, um auf der Grundlage von Datenbankverbindungsoperationen die Vorschriften zu identifizieren, die für einen bestimmten Nutzer mit Bezug auf einen bestimmten Inhalt anzuwenden sind.
  • Es ist natürlich möglich, auch andere Implementierungen für diese Art von Server zu ersinnen. Alternative Ausführungsformen können auf Servern des Authentifizierungs/Autorisierungs/Berichterstattungs(Authentication, Authorization, Accounting – AAA)-Typs basieren, wie zum Beispiel jene, die als "RADIUS-", "TACACS-", "TACACS+"-, "DIAMETER"- oder sonstige Systeme bekannt sind, wie zum Beispiel LDAP-Server, die dafür geeignet sind, das Nutzerprofil zu detektieren und zu entscheiden, ob eine bestimmte Anforderung, die von einem Gateway kommt, autorisiert werden kann oder nicht.
  • In der gezeigten beispielhaften Ausführungsform enthält der Server 22 Baumdatenbanken, und zwar:
    • – eine Nutzeridentitätsdatenbank 30, welche die Informationen bezüglich der Nutzer verwaltet (online oder nicht),
    • – eine Inhalte-Datenbank 32, welche die Informationen bezüglich der Inhalte verwaltet, die verfügbar sind und durch das System verwaltet werden (zum Beispiel die jeweilige URL, verwaltete Domäne, Inhalte-Anbieter, Kosten, Dauer und so weiter), und
    • – einen Inhaltevorschriftendatenbank 34, welche die Freigabeinformationen für die Inhalte für die einzelnen Nutzer (oder Gruppen von Nutzern) verwaltet.
  • Wie in 11 gezeigt, kann ein einzelner Server 22 mit verschiedenen Gateways 20, die in einem CDN enthalten sind, zusammenarbeiten. Wie oben erläutert, ist der Gateway 20 dafür konfiguriert, die Informationen bezüglich des Anforderers (wie zum Beispiel die IP-Adresse), der angeforderten Inhalte (wie zum Beispiel die jeweilige URL) und eventuell der Adresse des Surrogat-Servers, an den die Anforderung gerichtet war, zu detektieren.
  • Die Bezugszahl 36 bezeichnet als Ganzes die Hauptlogik des Servers 22, die unter anderem ein ACL-Überprüfermodul 38 sowie einen Gateway-Controller 40 enthält.
  • Auf der Grundlage der Informationen, die von dem oder jedem Gateway 20 kommend empfangen werden, wird das ACL-Überprüfermodul 38 abgefragt, um die "Übereinstimmung" des Zugangs zu den Inhalten mit Bezug auf die dem Nutzer gewährte Fähigkeit festzustellen.
  • Folglich führt das Überprüfungsmodul 38 die folgenden Aufgaben aus:
    • – Identifizieren des Nutzers auf der Grundlage der jeweiligen Attribute, die von dem Gateway 20 aus weitergeleitet werden (zum Beispiel unter Nutzung der IP-Adresse, um aus einer Tabelle den Benutzernamen des freigegebenen Nutzers abzuleiten; diese Funktion ist derzeit in einer Reihe von AAA-Systemen verfügbar); dies geschieht im Ergebnis des Zugreifens auf die Nutzeridentitätsdatenbank 30,
    • – Identifizieren möglicher Makrofamilien, zu denen die angeforderten Inhalte gehören, sowie zusätzlicher relevanter Informationen (zum Beispiel die Dauer oder die angeforderte Bandbreite) durch Zugreifen auf die Inhalte-Datenbank 32, und
    • – Verifizieren der Freigaben, die dem Nutzer mit Bezug auf die Inhalteaggregationen, die sich auf die angeforderten Inhalte beziehen, zugewiesen sind, durch Zugreifen auf die Inhaltevorschriften-Datenbank 34.
  • Das Ergebnis einer solchen Operation, die vom Zulassungstyp oder vom Verweigerungstyp kann sein, wird von dem Gateway-Controller 22 in Richtung des anfordernden Gateways 20 gesendet.
  • Zum Beispiel enthalten in einem solchen Fall die zugehörigen Baumdatenbanken: Nutzeridentität DB 30
    IP-Adresse Benutzername Guthaben
    10.10.10.10 User1 10 Euro
    10.10.10.11 User2 1 Euro
    10.10.10.12 User3 1 Euro
    Inhalt DB 32
    Inhalte-Verweis Dauer Kosten Makrofamilien
    www.milan.es/ultimigoal.rm 120 1 EUR Sport, Fußball
    www.rai.it/montalbanol.rm 2500 2 EUR Fiktion
    www.formula1.it/monza.rm 500 1 EUR Sport, Autorennen
    Inhaltevorschriften DB 34
    Benutzernamenschlüssel (UserNameKey) Makrofamilie
    User1 Fiktion
    User2 Fußball
    User3 Sport
  • Die folgenden Anforderung/Antwort-Paare können von dem bzw. zu dem anfordernden Gateway 20 resultieren:
    Anf(10.10.10.10,www.milan.it/ultimigoal.rm) ⇒ Antw(Verwehren: Inhalte nicht zugelassen)
    Anf(10.10.10.11,www.milan.it/ultimigoal.rm) ⇒ Antw(Zulassen, für 120 Sekunden)
    Anf(10.10.10.12,www.milan.it/ultimigoal.rm) ⇒ Antw(Verwehren, wegen unzureichendem Guthaben)
    Anf(10.10.10.12,www.formulal.it/monza.rm) ⇒ Antw(Zulassen, für 500 Sekunden)
  • Folglich kann der Server 22, zusammen mit der Antwort, an den oder jeden Gateway 20 einige zusätzliche Informationen senden, die aus den abgefragten Datenbanken gewonnen wurden. Dazu können zum Beispiel die Dauer der Inhalte (was die Lebensdauer der ACL selbst darstellt), das Restguthaben oder andere nützliche Informationen zum Steuern der Übermittlung des Dienstes gehören.
  • Generell reicht es im Allgemeinen sogar aus, in Richtung des anfordernden Gateway 20 lediglich die Zulassungs- oder Verweigerungsmeldung zu senden, die der ursprünglichen Anforderung korrekt zugeordnet ist.
  • Gleichermaßen kann der Schritt, in dem die Inhalteaggregationen in Makrofamilien überprüft werden, weggelassen werden, wenn die Inhaltevorschriften-Datenbank 34 Vorschriften auf der Ebene des einzelnen Inhalts (URL) und nicht auf der Ebene von Makrofamilien verwaltet. Auf diese Weise kann ein maximaler Grad an Granularität beim Kontrollieren des Zugangs zu den Inhalten erreicht werden.
  • Es versteht sich, daß vorzugsweise die Verwaltungsfunktion der aktiven ACLs und deren Speicherung nicht in dem Server 22 ausgeführt werden, sondern vielmehr an dem jeweiligen Gateway 20, indem lediglich zwei Grundformen implementiert werden:
    • – GetACL durch den Gateway 20, und
    • – SetACL durch einen Server 22.
  • In anderen Ausführungsformen kann es hilfreich sein, einen Server 22 zu implementieren, der dafür geeignet ist, die erzeugten ACLs in einer zentralisierten Weise zu speichern, um eine anschließenden Rücksetzung im Fall von Störungsereignissen durch den Gateway 20 zu ermöglichen. Vorzugsweise wird bei dieser Art von Architektur eine zusätzliche Grundform folgenden Typs bereitgestellt:
    • – RealignACL sowohl durch den Gateway 20 als auch durch den Server 22, wodurch veranlaßt wird, daß von dem Gateway 20 in Richtung des Servers 22 jene ACLs gesendet werden, die lokal verfügbar sind (zum Beispiel, um eine Rücksetzung nach einer Störung in dieser Komponente zu gewährleisten), oder umgekehrt (wahlweise von dem Server 22 in Richtung jedes Gateways 20).
    • – DropACL von dem Gateway 20 in Richtung des Servers 22 bei Ablauf der Lebensdauer der ACL selbst.
  • 12 verdeutlicht die interne Struktur des Gateways 20, während die anschließenden 13 bis 17 der detaillierten Erläuterung seines Betriebes dienen.
  • In der gezeigten beispielhaften Ausführungsform ist der Gateway 20 als eine separate Komponente implementiert. Jedoch wird unter Beachtung dessen, was oben beschrieben wurde, und des Weiteren im Hinblick auf den übrigen Teil dieser Beschreibung deutlich werden, daß die dadurch ausgeführten Funktionen, und zwar Auslösen, Filterung, Konformitätsüberwachung und Umleitung (Rangieren + Neueinspeisung) von Paketen, in Form von Zusatzmodulen implementiert werden können, die anderen Netzwerkvorrichtungen zugeordnet sind, zum Beispiel einem Netzwerkschalter, einem Inhalte-Schalter, einer Router-Vorrichtung oder direkt einem oder mehreren Surrogat-Servern.
  • Das System ist über mehrere Schichten hinweg angeordnet, von denen zwei (die niedrigste und die höchste) im Wesentlichen aus Netzwerkschnittstellen 50 und 52, die mit dem Inhalte-Anforderer CR bzw. dem Surrogat-Server zusammenwirken, und einer zusätzlichen Schnittstelle 54 in Richtung des Servers 22 bestehen.
  • Die Zwischenschichten enthalten im Wesentlichen eine untere Schicht 56 auf der Kernebene und eine höhere Ebene 58 auf der Anwendungsinhalte-Ebene.
  • In der Kernschicht 56 ist die Grundfunktion eines Unix-artigen Kerns hinsichtlich Vernetzung, Überbrückung und Filterung auf der IP-Ebene (bis zur Ebene 4) bereitgestellt.
  • Eine typische Implementierung der Schicht 56 enthält alle typischen Funktionen, die sich derzeit in einer FreeBSD-Anordnung befinden, wie sie in der IPFW (IP-Firewall) einer FreeBSD-Anordnung zur Verfügung stehen.
  • Genauer gesagt, sind die folgenden Elemente enthalten:
    • – ein IP-Filtermodul 60, dem ein entsprechendes Steuerungsteilmodul 60a zugeordnet ist, das mit der Filterungsaufgabe (bis zur Ebene 4) von IP-Paketen betraut ist. Dieses Modul arbeitet mit Paketen, die zwischen den zwei Netzwerkschnittstellen, die durch die untere Ebene hervorgehoben sind, und einem Umleitungs-Teilmodul 62 und einem Neueinspeisungs-Teilmodul 64 überbrückt werden. Das Modul 62 hat die Aufgabe des Umleitens von Ethernet-Paketen (Frames) in Richtung einer Systemanwendung auf der Nutzerebene für deren Verarbeitung. Das Modul 64 hat die Aufgabe des Neueinspeisens, immer durch eine Systemanwendung auf der Nutzerebene, mit Neuberechnung des zyklischen Korrekturcodes (Cyclical Correction Code – CRC) für ein korrektes Weiterleiten in Richtung des Netzwerks. Diese Module 62 und 64, die derzeit für überbrückte Schnittstellen nicht zur Verfügung stehen, können auch für den überbrückten Verkehr freigegeben werden, indem der Grundkern von FreeBSD entsprechend verändert wird.
  • Die Bezugszahlen 66 und 68 bezeichnen zwei Datenbanken, die statische IP-Regeln bzw. dynamische IP-Regeln verwalten.
  • Unter Verwendung von FreeBSD als die Basis für dieses Betriebssystem des Gateways 20 hat eine Reihe von Vorteilen.
  • Zunächst einmal gestattet es einen transparenten IP-Firewallschutz mittels Überbrückung. Darüber hinaus führt es die Filterungs- und Auslöse-Aktionen auf der Kernebene mit verbesserter Leistung aus. Es besteht die Möglichkeit der Implementierung selektiver Umleitungsmechanismen, die zu den Firewallschutzregeln in Beziehung stehen, um bestimmte Pakete in Richtung eines oder mehrerer Kernsockel, die mit einer Nutzerraumanwendung verbunden sind, zu senden.
  • Darüber hinaus besteht bei FreeBSD die Möglichkeit, einen Paketneueinspeisungsmechanismus mittels der oben angesprochenen Kernsockel auszuführen. Dies macht es möglich, daß eine Nutzerraumanwendung ausschließlich jene Pakete, die speziell durch die Firewallschutzregeln identifiziert wurden, durch Akzeptieren, Modifizieren, Zurückweisen oder verzögerte Handhabung des Rückflusses handhabt.
  • Darüber hinaus ist FreeBSD eine frei verfügbare Software, wodurch der Firewallschutzabschnitt den derzeitigen Entwicklungen von Offenquellensoftware folgt, während der Abschnitt auf der Anwendungsebene unangetastet bleibt. Die möglichen Änderungen, die in der Kernvernetzung erforderlich sind, damit die Umleitungs- und Neueinspeisungsfunktionen auch für die überbrückten Pakete zur Verfügung stehen, lassen sich problemlos vornehmen.
  • Schließlich werden die TCP-Implementierungen des BSD derzeit als der zuverlässigste TCP-Stapel angesehen, den es in einem Unix-Kontext gibt.
  • Das Hauptlogikmodul 58 enthält eine Reihe von Anwendungsteilmodulen. Dazu gehören ein Analysemodul 70, das die (Ebene 7) Analyse jener Pakete ausführt, die von dem Kern-Umleitungsmodul 62 kommend empfangen werden, indem es die IP-Adresse und die URL (oder allgemeiner: die Verweise, die für die Autorisierung nützlich sind) extrahiert, während es des Weiteren die Anforderung für die Autorisierung, die an den Server 22 (über die Schnittstelle 54) gesendet wird, instanziiert und die entsprechende Antwort handhabt, indem es die Filterungsvorschrift mittels Befehlen, die in Richtung des Kernsteuerungsteilmoduls 60a gesendet werden, erzwingt. Dies beinhaltet im Wesentlichen das Vorhandensein eines Vorschriftencontroller-Teilmoduls 72 und eines Vorschriftenanforderer-Teilmoduls 76. Eine mögliche Manipulation des Anforderungspaketes und eine Steuerung des Kern-Neueinspeisungsteilmoduls 64 werden durch ein Paketrangierer-Teilmodul 74 ausgeführt. Genauer gesagt, führt das Vorschriftencontroller-Teilmodul 72 die Zeitsteuerungsaktion für die ACLs und ihre mögliche Herausnahme bei Ablauf der durch den Server 22 eingestellten verbleibenden Zeit aus.
  • Die Hauptlogikschicht 58 des Gateways 20 arbeitet des Weiteren mit zwei Informationsverwahrungsstellen 78 und 80 zusammen.
  • Die erste Verwahrungsstelle, mit 78 bezeichnet, enthält im Wesentlichen die Konfigurationseinstellungen des Gateways 20. Diese finden sind im Wesentlichen in:
    • – statischen Regeln zum Auslösen der Anforderungen und Bestimmen der Protokolle, der Ports und der Attribute, die für die Pakete kennzeichnend sind, über die die Inhalte- Informationen untersucht werden (wie durch das IP-Filter 60 für eine Ebene 4-Filterung verwendet);
    • – Analysierregeln des Ethernet-Rahmens zum Auffinden der IP- und URL-Informationen, die durch die Teilmodule 70 für Analysezwecke verwendet werden sollen; und
    • – mögliche Umleitungsregeln auf der Grundlage des Protokoll-, Domänen- oder Verwehrungstyps (zum Beispiel nicht-ausreichendes Guthaben, Freigabe nicht verfügbar, und so weiter) für eine mögliche Verwendung durch das Paketrangierer-Teilmodul 74, um die URL oder die ursprüngliche Anforderung vom Nutzer durch einen alternativen Zielort zu ersetzen. Es versteht sich, daß ein solcher alternativer Zielort innerhalb derselben TCP-Sitzung zu dem Surrogat-Server weitergeleitet wird. Andererseits gewährleistet dies sein Vorhandensein auf dem Server, während andererseits die Effizienz des Systems selbst verbessert wird.
  • Die Verwahrungsstelle 80 enthält im Wesentlichen die lokalen Zugangsinhaltelisten (ACLs), die dazu dienen, auf der Ebene 7 die aktive Filterung in einem bestimmter Moment zu beschreiben und eine Abbildung mit den entsprechenden Regeln auf der Ebene 4 der IP-Filtermodule 60, die in der dynamischen IP-Regeldatenbank 68 gespeichert sind, vorzunehmen.
  • Die Konfigurationsphase des Gateways 20 ist in 13 ausführlicher dargestellt, wo die direkt beteiligten Module bzw. Teilmodule in Strichlinien hervorgehoben sind.
  • Im Wesentlichen vollzieht sich der Hauptabschnitt der Konfigurationsphase in dem Gateway 20, bevor das System verwendet wird. Genau genommen, ist die Konfiguration des Servers 22 darauf beschränkt, die Verweise für die Verbindung mit dem Gateway oder den Gateways und den Datenbanken, die verwendet werden, anzuzeigen. Es wird allgemein angenommen, daß diese bereits mit den erforderlichen Informationen vorgeladen wurden, wie zuvor betont.
  • Im Wesentlichen beinhaltet die Konfigurationsphase des Gateways 20 eine Reihe von Konfigurationseinstellschritten.
  • Ein erster Konfigurationsschritt beinhaltet das Einstellen der Adresse des Servers 22 und der entsprechenden Ports für die Informationen zum Anfordern der Autorisierung (mindestens die IP-Adresse und die URL eines Nutzers) und Empfangen der entsprechenden Antworten (wie zum Beispiel Verwehren oder Zulassen oder Timeout). Dies ist im Wesentlichen symmetrisch mit der Konfiguration, die auf dem Server 22 ausgeführt wird. Beispielhaft dafür ist Folgendes:
    CP&SSERVER=10.10.15.156
    ServerCommPort=22222
    NetworkCommPort=33333
  • Ein anschließender Konfigurationseinstellschritt beinhaltet die Definition der physischen Schnittstellen für Steuerung und Überbrückung, und zwar jene Schnittstellen, mit denen der Gateway 20 empfängt und mit dem Server 22 und dem Inhalte-Anforderer CR sowie dem Surrogat-Server kommuniziert.
  • Beispielhaft dafür sind:
    DCCAControlIf=fxp2
    TowardsUserIf=fxp0
    TowardsContentIf=fxp1
  • Anschließend wird die statische Filterungs-/Auslöse-Logik auf der Ebene 4 (statische IP-Regeln) so eingestellt, wie sie durch das IP-Filtermodul 60 für die Pakete zwischen den zwei überbrückten Schnittstellen implementiert werden soll. Dies beinhaltet vorzugsweise alle interessierenden Frames zum Erfassen der Anforderung des Nutzers (und vorzugsweise nur diese Frames) für jedes Protokoll, über das die Funktion implementiert werden soll. Dabei wird ebenfalls der Umleitungsport auf der Kernebene angezeigt, wo die Module 70 (E7-Analyse) und 74 (Paketrangierer) Pakete auf der Brücke zwischen dem Inhalte-Anforderer CR und dem Surrogat-Server empfangen und ablehnen können. Solche Einstellungen können auch jene Einstellungen enthalten, die mit dem Sperren der momentanen Antworten für das Protokoll zu tun haben. Zum Beispiel kann diese Konfiguration im Fall des Real-Protokolls von Real Networks Folgendes enthalten:
    TriggerL4DivertRule=divert 11111 tcp from any to any 554,7070,7071 in via fxp1 established
    InitL4FilterRule=deny udp from any to any 6979-7170 in via fxp0
  • Anschließend wird die Ebene 7-Analyselogik eingestellt, um den Verweis auf die Inhalte zu extrahieren, der für Autorisierungszwecke zu dem Server 22 zu senden ist. Dies geschieht durch Hervorheben des Präfix-Musters zum Suchen in dem Frame (ohne Berücksichtigung der verwendeten Zeichencodierung), der vor der Zeichenkette angeordnet ist, die über die Inhalte berichtet. Im Fall von Real kann dies folgende Form annehmen:
    TriggerL7PrefixString="PLAY rtsp://"
  • Anschließend wird die Paketrangierlogik für Paketakzeptanz- bzw. -ablehnungszwecke für jedes Protokoll eingestellt, das für jede verwaltete Domäne in einer möglicherweise unterschiedlichen Weise verwaltet wird. Es versteht sich, daß der Gateway 20 in diesem Fall für die angegebenen Protokolle eine Filterungslogik des aktiven Typs auf die Anforderung verwendet, wie in den 7 und 8 angedeutet. Im Fall von Real kann dies Folgendes sein:
    ReinjectAccept=<none>
    ReinjectDeny=sorry.rm (je verwalteter Domäne="rai.cdn.telecomitalia.it"
    ReinjectDeny=please_subscribe.rm (je verwalteter Domäne="cnn.cdn.telecomitalia.it")
  • Als eine Alternative zu der oben angedeuteten Regel wird die Regelschablone auf der Ebene 4 so eingestellt, daß sie automatisch eingesetzt wird, falls Akzeptieren oder Ablehnen eingestellt ist, um die verzögerte aktive Filterungsaktion auf die Antwort zu verwalten. Recht häufig haben diese Regeln einfach die Form der Negation einer Regel, die als InitL4FilterRule eingestellt ist, die entsprechend zwischen der IP-Adresse des Inhalte-Anforderers CR und der IP-Adresse des Surrogat-Server, die in der Anforderung genannt ist, instanziiert wird. Wenn die Schablone eine andere ist, so kann eine brauchbare Definition Folgende sein:
    TemplateAcceptRule=accept udp 6979-7170
    was im Fall des Akzeptierens das Einfügen (durch das Vorschriftencontroller-Modul 72) einer Ebene 4-Regel erzeugt, die durch das IP-Filter 60 des folgenden Typs zu verwalten ist:
    accept udp from <Surrogate Server> to <Content Requester> 6970-7170 in via <TowardsContentIf>
    und in ähnlicher Form für das Verwehren:
    TemplateDenyRule=deny udp 6970-7170
  • In den im vorliegenden Text beschriebenen Konfigurationsbeispielen kann sich dies als überflüssig erweisen, da es in die statischen Regeln der Datenbank 66 fällt.
  • Die 14 bis 16 heben die Komponenten des Gateways 20 hervor, die während der verschiedenen Betriebsphasen des Gateways 20 ins Spiel kommen.
  • Genauer gesagt, hebt 14 die Komponenten des Gateways 20 hervor, welche die Auslöseaktion der Anforderung ausführen.
  • Zunächst wird mittels der in der Datenbank 66 enthaltenen Regeln der ("technologieabhängige") Frame, der von dem Inhalte-Anforderer CR kommt, auf der Ebene 4 durch das IP-Filtermodul 60 analysiert. Wenn das von Interesse ist, wird der Frame nicht direkt (durch das IP-Filter 60) in Richtung der Schnittstelle 52 zu dem Surrogat-Server weitergeleitet, sondern wird abgefangen und über das Teilmodul 62 in Richtung des Analysemoduls 70 auf der Anwendungsebene gesendet.
  • Unter Verwendung der Analysierregeln für das in der Datenbank 78 enthaltene Paket (insbesondere, was den Protokoll-Präfix anbelangt) sendet das Analysemodul 70 in Richtung des Vorschriftenanforderers 76 den Satz, der Folgendes enthält:
    o <die Identifikatorattribute des Inhalte-Anforderers>
    o <die Identifikatorattribute der angeforderten Inhalte>
    o <die Identifikatorattribute des Surrogat-Servers>
  • Dieser Satz kann genau genommen auf die IP-Adresse und die URL des Nutzers sowie die IP-Adresse des Surrogat-Servers beschränkt werden.
  • Es versteht sich, daß auf diese Weise ein einheitlicher Autorisierungsmechanismus ausgeführt wird, der "technologieunabhängig" ist, d. h. vollkommen unabhängig von der in dem Netzwerk verwendeten Inhalteverteilungstechnologie.
  • Das Schaubild von 15 hebt die Komponente des Gateways 20 hervor, welche die Kommunikation in Richtung des Servers 22 implementiert. Diese Aktivität wird vollständig durch das Vorschriftenanforderer-Modul 76 verwaltet, das folgende Aufgaben ausführt:
    • – Paketisieren der Anforderung unter Verwendung der in dem Analysemodul 70 enthaltenen Daten, und
    • – Senden der Anforderung unter Verwendung des Kommunikationsports 52 in Richtung des Servers.
  • Gleichzeitig verwaltet das Modul 76 die Antworten, die von dem Server kommen. Diese Antworten (in der Regel in Form von Akzeptanz- oder Zurückweisungsmeldungen, denen eventuell einige zusätzliche Charakteristika zugeordnet sind, die zu den Inhalten gehören, wie zum Beispiel Dauer, angeforderte Bandbreite und so weiter) werden in Richtung der Anwendungsmodule weitergeleitet. Diese Module verwalten die Erstellung dynamischer Filterungsvorschriften (über das Vorschriftencontroller-Modul 72) und die Pakethandhabung (über das Paketrangierer-Modul 74).
  • Bei Ausbleiben einer Antwort von dem Server 22 innerhalb eines bestimmten Timeout-Zeitraums erzwingt das Vorschriftenanforderer-Modul 76 Standardvorschriften, die durch den Administratorvorgegeben wurden, wie zum Beispiel jene, die auf das Vermeiden einer Übermittlung der Inhalte abzielen.
  • Eine anschließende Filterungsphase veranlaßt, daß die Informationen von dem Inhalte-Anforderer CR zu dem Surrogat-Server und umgekehrt weitergeleitet oder nicht weitergeleitet werden. Aus diesem Grund führen die Elemente, die in 16 hervorgehoben sind (auch hier erfolgt das Hervorheben mittels Strichlinien), zu einer internen Unterstützungsstruktur, die in der Datenbank 80 enthalten ist, die momentan als die Zugangsinhalteliste (ACL) benannt ist. Diese Struktur beschreibt die Zulassungs- und Verweigerungsklauseln, die für einen bestimmten Nutzer und bestimmte Inhalte aktiv sind, und weitere Attribute, die für eine Ebene 7-Filterung nützlich sind. Diese Klauseln beziehen sich zusätzlich auf eine Ebene 4-Klausel, die durch das IP-Filtermodul 60 und die zugehörigen Teilmodule verwaltet werden.
  • 18 beschreibt die mögliche Verfolgung zum Speichern der Zugangsinhaltelisten (ACLs) innerhalb des Gateways 20. Eine solche Struktur kann auch innerhalb des Servers 22 zum Zentralisieren der Speicherung der vorhandenen ACLs verwendet werden.
  • Wie oben beschrieben, definiert eine ACL-Liste Parameter für eine Verbindung oder Anforderung. Auf der Basis dessen können Regeln zum Gewähren oder Verweigern des Zugangs zu bestimmten Netzwerkressourcen definiert werden.
  • 18 ist ein Beispiel für Informationsfelder, die zum Implementieren der Entscheidungslogik (Filterungslogik) innerhalb des Gateways 20 verwendet werden. In dem beispielhaften Fall, der in 18 gezeigt ist, haben die angegebenen Felder die folgende Bedeutung bzw. Funktion:
    • – Aktion: beschreibt die Aktion, die in Gegenwart bestimmter Verbindungsparameter auszuführen sind (Akzeptieren/Verwehren);
    • – Src-IP und Dst-IP: Diese stellen die IP-Adresse der Entitäten dar, welche die Verbindung herstellen, und enthalten erforderlichenfalls Informationen bezüglich der ID des entsprechenden Virtuellen Privaten Netzwerks (VPN) und die entsprechende Teilnetzmaske;
    • – Protokoll: identifiziert den Typ des Transportprotokolls, das für die Verbindung verwendet wird (TCP/UDP);
    • – IN-Port und OUT-Port: Diese definieren die Logikports, die für die Kommunikation zwischen den Prozessen, welche die Verbindung herstellen, verwendet werden;
    • – V. D.: stellt die verwaltete Domäne dar, auf der die Inhalte angefordert wurden (zum Beispiel cdn.telecomitalia.it);
    • – Inhalt: identifiziert die URL des einzelnen Inhalts im Ergebnis der Verbindung angefordert wird (zum Beispiel: /recent/promo.asf);
    • – TTL: definiert die Gültigkeitszeit der ACL-Klausel, jenseits derer eine solche Klausel automatisch entfernt wird.
  • 16 hebt die Komponenten hervor, die durch den Gateway 20 verwendet werden, um eine Kontrolle der Anforderung zu gestatten, indem ein verzögertes Filter eingestellt wird, das auf die Antwort einwirkt, wie in den 9 und 10 dargestellt.
  • In diesem Fall leitet das Paketrangierer-Modul 74 das Anforderungspaket in Richtung der Ausgabeschnittstelle 52 unmodifiziert weiter. Zu diesem Zweck wird es sofort durch das Vorschriftenanforderer-Modul 76 aktiviert, bevor die Anforderung in Richtung des Surrogat-Servers weitergeleitet wird.
  • Der größte Teil der Aktivität wird durch das Vorschriftencontroller-Modul 72 ausgeführt. Dieses Modul empfängt die Informationen, die von dem Vorschriftenanforderer-Modul 76 benötigt werden, auf der Grundlage der Kriterien, die auf der Konfigurationsebene für ein bestimmtes Protokoll aufgestellt wurden, durch Interagieren mit dem IP-Filtersteuerungsmodul 60. Das Vorschriftencontroller-Modul 72 hat die Aufgabe des Pflegens oder Überarbeitens der in der Datenbank 80 enthaltenen ACLs, insbesondere im Hinblick auf die Verwaltungsfunktion der TTL-Werte für die Regeln.
  • 17 hebt die Komponenten des Gateways 20 hervor, die während der Phase ins Spiel kommen, wo eine modifizierte Anforderung erneut eingespeist wird. Wie oben beschrieben, entspricht dies der alternativen Lösung, die in den 7 und 8 betrachtet wird.
  • Die zwei Optionen können für ein einzelnes Protokoll konfiguriert sein und gestatten den Erhalt unterschiedlicher Merkmale entsprechend den Erfordernissen des Betreibers. Zwei Grundfaktoren in dieser Hinsicht werden durch eine geringere bzw. höhere Empfindlichkeit für die Verzögerungen bei der Antwort durch den Server und dem Anwendungs-Timeout oder die geringere bzw. höhere Personalisierung der Handhabung von Verweigerungen der Anforderung dargestellt.
  • In diesem letzteren Fall führt das Paketrangierer-Modul 74 den größten Teil der zugehörigen Aktivität aus. In Abhängigkeit von der Antwort (Akzeptieren/Verwehren), die von dem Vorschriftenanforderer 76 kommend empfangen wird, bestimmt das Paketrangierer-Modul 74, wann und wie das ursprüngliche Anforderungspaket (immer noch in "Bereitschaft") auf der Kernebene erneut einzuspeisen ist, um in Richtung des Surrogat-Servers weitergeleitet zu werden.
  • In diesem Fall führt die Erstellung einer lokalen ACL zu einer Optimierung jeder anschließenden Anforderung des gleichen Typs durch Erzeugen einer Art von Cache, wodurch kontinuierliche Server-Abfragen vermeiden werden.
  • Ein grundlegender Vorteil dieser Anordnung liegt darin, daß sie eine In-line-Umleitung des Paketes in Richtung sogenannter "Sorry"-Zielorte gestattet (diese haben in Abhängigkeit von dem Typ der Anforderung gewöhnlich die Form von html-Seiten, Filmen oder anderem), während die TCP-Verbindung mit dem Surrogat-Server aktiv gehalten wird, und ohne daß ein Emulationssoftwaremodul für jede Technologie, die verwaltet werden soll, vorhanden sein muß.
  • Praktische Ausführungsformen des Gateways 20 konzentrieren sich auf ein System, bei dem die Auslöse-Aktion und die damit einhergehende Filterungsaktion mit einem hohen Grad an Granularität ausgeführt werden, imaginär in Verbindung mit jedem Inhalt, der durch einen bestimmten Nutzer angefordert wird.
  • In dieser Hinsicht wurden sowohl i) Anordnungen, die sich als Proxies für die Inhalte-Dienste verhalten, als auch ii) Anordnungen, die eine Filterung auf der Überbrückungsebene ausführen, betrachtet, indem ihre Charakteristika im Hinblick auf die Transparenz in Bezug auf die Auswirkung des Agent – oder der Komponente, welche die Rolle des Agent spielt – auf das Netzwerk (ein sogenannter "transparenter" Firewallschutz) beurteilt wurde.
  • Als eine weitere Erweiterung können die Auslöse- und Filterungskomponenten separat betrachtet werden, um die Analyse auch auf jene Paketanalyse- und Paketinspektionssysteme auszuweiten, die in Webfilterungssystemen existieren, die hinreichend konfigurierbar und granular sind.
  • Abschließend werden verschiedene mögliche Modi des Zerhackens oder Neueinspeisens von Paketen betrachtet.
  • Eine erste Beobachtung ist, daß FreeBSD und Linux die Möglichkeit bieten, IP-Pakete bis zur Ebene 4 zu filtern und sie auf einen Kernsockel umzuleiten, während außerdem eine Verwaltung auf der Anwendungsebene ermöglicht wird. Diese Fähigkeit wird durch viele Netzwerkanalysesysteme ausgenutzt. Darüber hinaus gibt FreeBSD die Möglichkeit des Weiterleitens von IP-Paketen, die eine bestimmte Firewallschutzregel in Richtung eines Nutzeranwendung erfüllen, die entscheiden kann, ob diese Pakete zu modifizieren oder in das Netzwerk neu einzuspeisen sind (Umleitungsregel). In diesem Fall besorgt das System die Reassemblierung der Ethernet-Frames in einer korrekten Weise.
  • Darüber hinaus bieten sowohl FreeBDS als auch Linux die Möglichkeit des Konfigurierens eines Paares von Netzwerkschnittstellen in einem überbrückten Modus. Diese Anordnung bietet jedoch keine Möglichkeit des Umleitens der Pakete mehr.
  • Eine Paketanalyse erfordert nicht zwangsläufig die Verfügbarkeit eines Anwendungsschichtproxys. Die Analyse kann über die Analysemechanismen der regulären Ausdrücke (eine sogenannte "Monkey"-Analyse) ausgeführt werden, wie sie in der Regel von Eindringdetektionssystemen verwendet werden. Bestimmte Eindringdetektionssysteme stellen einen Auslösemechanismus bereit, wenn beim Parifizieren des Ethernet-Paketes eine zuvor festgelegte Signatur detektiert wird.
  • Andere Systeme verwenden den Signaturmechanismus zum Ausführen einer intelligenten Formung der Pakete durch Operieren auf der Ebene 7.
  • Das Blockschaubild von 19 hebt die verschiedenen Phasen des Betriebes der im vorliegenden Text beschriebenen Anordnung hervor, ohne ausdrücklich auf die Positionierung der Module innerhalb der verschiedenen Vorrichtungen einzugehen.
  • In einem Schritt 100 tritt ein generisches Paket in den DCCA-Gateway 20 ein.
  • In einem Schritt 102 detektiert eine Ebene 4-Analyse (zum Beispiel Richtung, Protokoll und Ports) bestimmte Pakete, die in Richtung der Ebene 7-Analyse umzuleiten sind. Jene Pakete, die nicht durch die Ebene 4-Regel gefiltert werden, folgen (nach einigen möglichen Steuerungen auf der Grundlage anderer Ebene 4-Regeln für andere Protokolle in Block 102) einem typischen Brückenfluß durch Block 118 hindurch in einer unveränderten Weise.
  • Eine Ebene 7-Analyse wird durch einen Block 106 dargestellt.
  • In der im vorliegenden Text beschriebenen beispielhaften Ausführungsform wird diese Analyse im Nutzerbereich und nicht auf der Kernebene ausgeführt. In jedem Fall bestimmt eine solche Analyse die Charakteristika der Anforderung und leitet die Autorisierungsanforderung zu dem Autorisierungsmodul weiter (Block 108). In der im vorliegenden Text beschriebenen beispielhaften Ausführungsform wird dies durch den Server 22 implementiert. In jedem Fall kann eine Ebene 7-Analyse die zeitweilige Autorisierung der Anforderung erfordern (im Fall des Betriebsmodus' auf der Grundlage verzögerter Autorisierung mit Antwortsteuerung). In diesem Fall kann die Vorrichtung eine Regel festlegen, die sich auf die Zeit stützt.
  • Die Regelaufstellungsphase ist durch einen Block 110 dargestellt. Dies beinhaltet gewöhnlich das Aktivieren von Regeln zum Ermöglichen des Verkehrs in zwei Richtungen und im Allgemeinen von weiteren zugehörigen Regeln, die eine Berichtsverwaltung zu dem Antwortverkehr ermöglichen (dies wird in der Regel durch ein externes Modul ausgeführt, das mit 112 bezeichnet ist).
  • Die Autorisierungsphase, wie sie in dem Modul 108 ausgeführt wird, kann (zum Beispiel im Ergebnis einer Verweigerungsantwort) zu einer In-line-Umleitung der Anforderung führen, indem auf die Umleitungsphase eingewirkt wird (Block 114).
  • Anschließend fügt die Neueinspeisungsphase 104 das Paket, das zuvor einer Umleitungsaktion unterzogen wurde (und das möglicherweise im Ergebnis der Umleitung modifiziert wurde), wieder ein. Schließlich verläßt das Paket (entweder überbrückt oder neu eingespeist) in einem Schritt, der mit 116 bezeichnet ist, die Vorrichtung.
  • 20 zeigt den ankommenden Netzverkehr (Anforderung für multimediale Inhalte), der auf der Kernebene (mittels IP-Firewallregeln) abgefangen und gefiltert und zu einem Nutzerraum verbracht wird. Dort übernehmen JAVA-Module die Aufgabe des Autorisierens von Anforderungen und des Neueinspeisens des Verkehrs auf der Kernebene, um die Anforderung in einer traditionellen Weise zu bedienen.
  • Wie angedeutet, ist eine bevorzugte Position des Gateways 20 vor dem Server. Auf diese Weise kann der Server gesteuert werden, indem gewährleistet wird, daß der Netzwerkpfad, um ihn zu erreichen, ausgehend von einem beliebigen betrachteten Client, zwangsläufig nur ein einziger ist, der durch die Vorrichtung hindurch führt.
  • Anderenfalls kann ein FreeBSD 4.8-Kern modifiziert werden, um zu gewährleisten, daß einige Teilkomponenten des ipfw-Befehls (in Verbindung mit dem Umleiten und Neueinspeisen der Pakete in Richtung zu der – und von der – Anwendungsebene) auch mit den überbrückten Paketen korrekt operieren können.
  • Die Anforderungen von den Endnutzern werden an der Eingangsnetzwerkschnittstelle abgefangen und durch den Netzwerkprotokollstapel hindurch zu dem Kern-Modul (IP-Firewall) zur Paketfilterung geleitet. Ein solches Modul analysiert und filtert den Netzverkehr durch Aufstellen von Regeln des Typs:
    0400 accept from 192.168.0.1 22222 to 192.168.0.2 33333 tcp in via fxp0 established.
  • Dabei stellt der erste Parameter den Identifikator für die IP-Firewallregel dar, der zweite die Aktion, die auszuführen ist (Zulassen/Verwehren/Umleiten), gefolgt von der Quelle- und der Zielort-IP-Adresse und den jeweiligen Logikports, dem Transportprotokoll, der Eingangsschnittstelle für den Verkehr, und, in dem betrachteten Fall, (TCP-Protokoll) die Steuerung der SYN-Markierung zum Steuern, ob die Verbindung hergestellt wird oder nicht.
  • Die IP-Firewall bietet eine zusätzliche Funktion, die das Senden von Verkehr, der die Bedingungen der Regel erfüllt, in Richtung des Nutzerraums unter Verwendung eines speziellen Sockels (DIVERT_SOCKET) gestattet. Auf diese Weise können jegliche Verarbeitungsaufgaben, die zu dem Netzverkehr gehören, auf die Anwendungsebene verschoben werden.
  • Für diesen Zweck reicht es aus, die Option "Umleitung" ("Divert") als das Aktionsfeld in der IP-Firewallregel anzugeben:
    0400 divert 44444 from 192.168.0.1 22222 to 192.168.0.2 33333 tcp in via fxp0 established
  • Dabei wird auch der Logikport des Umleitungssockels (44444) angegeben, in dessen Richtung der Netzverkehr, der die Regel erfüllt, gesendet werden muß.
  • Ein Modul, das in C (C_to_JAVA) entwickelt wurde, gewährleistet eine korrekte Verbindung der Umleitungssockel (Divert_Sockets) mit den JAVA-Anwendungen zum Analysieren und Verarbeiten der Anforderung von der Kernebene.
  • Zum Beispiel kann eine solche Anordnung auf ICMP-Verkehr (vom Echo-Anforderungstyp) angewendet werden, wobei als die IP-Firewallregel zum Abfangen folgende verwendet wird:
    0400 divert 44444 from 192.168.2.2 to 192.168.2.1 icmp in via fxp1 icmptype 8.
  • Dies hat den Zweck des Abfangens der ICMP-Anforderungen von dem Client an der "fxp1"-Schnittstelle, indem solche Paketen zu einem JAVA-Softwaremodul geleitet werden, der auf dem "44444"-Port aus eine Video-Ausgabe der Datenpakete lauscht und den Verkehr an der Ausgabeschnittstelle (fxp0) neu einspeist.
  • Das Filter ist somit für den Anforderer-Client transparent, während die ICMP-Pakete an einem Standardausgang korrekt abgefangen (und möglicherweise gedruckt) werden.
  • Alternative Experimente wurden unter Verwendung des "mmst"-Protokolls (mmst über TCP-Transport) durchgeführt, wobei als die IP-Firewallregel folgende verwendet wurde:
    0400 divert 44444 from 192.168.2.2 to 192.168.2.1 tcp in via fxp 1 established.
  • Dies hat den Zweck des Abfangens aller Datenpakete, die multimediale Inhalte von dem Windows MediaTM-Server anfordern (TCP-Sitzungssatz: SYN=0), die dann für eine Videoausgabe und Neueinspeisung in den Verkehr an der Ausgabeschnittstelle (fxp0) zu einem JAVA-Softwaremodul im Nutzerraum geleitet werden.
  • Der Audio- bzw. Videostrom wurde während des Abfang- und Neueinspeisungsprozesses unverändert gelassen. Während des Betriebes ist es möglich, die URLs, die in den Anforderungen von dem Server enthalten sind, zu visualisieren. Durch Kommunizieren mit dem Sicherheitsserver überprüft das JAVA-Modul in dem Agent, ob die IP-Adresse, die einen bestimmten Inhalt angefordert hat, freigegeben ist, um die Inhalte der angeforderten URL zu empfangen.
  • In diesem Fall wird der Verkehr, der in Richtung eines Nutzerraumes umgeleitet wurde, auf der Kernebene unter Verwendung des Umleitungssockels neu eingespeist, und die Anforderung wird anschließend über die Ausgabeschnittstelle zu der relevanten Speichervorrichtung weitergeleitet.
  • In dem Fall, wo der durch das JAVA-Modul durchgeführte Test zu einem negativen Ergebnis führt, gibt es zwei Möglichkeiten:
    • – der Verkehr wird verworfen oder in Richtung einer Sorry-Seite umgeleitet (positive Logik),
    • – anderenfalls wird der Verkehr auf der Kernebene neu eingespeist, und man läßt ihn die Speichervorrichtungen erreichen, während der Antwortfluß aus den Cache-Speichern anschließend gesperrt wird (negative Logik).
  • Das Umleiten des Netzverkehrs aus dem Kernraum zu dem Nutzerraum über die Umleitungssockel wird durch Modifizieren des Kern-Moduls ermöglicht, das zu der IP-Firewall gehört. Dies führt ursprünglich eine Kontrolle der Übereinstimmung der IP-Pakete aus, bevor die Umleitungsoperation ausgeführt wird (was darum nicht an Nicht-IP-Paketen vorgenommen werden darf). Durch die Modifizierung fällt diese Art von Kontrolle weg, wodurch die Möglichkeit besteht, eine Umleitungsaktion an "reinen" Ethernet-Frames vorzunehmen.
  • Die im vorliegenden Text beschriebene Anordnung autorisiert Anforderungen durch Ausnutzen eines PULL-Paradigmas: Der Nutzer legt die Anforderung vor; diese wird entweder direkt abgefangen, oder der zugehörige Rückfluß wird abgefangen, und es werden abschließend Kontrollisten zu einem Netzsystem erzeugt.
  • Darüber hinaus fängt der Mechanismus die Anforderung ab, oder der Rückfluß identifiziert ein Berichtsbeginn-Ereignis, und zwar den Beginn der Übermittlung. Anschließend veranlaßt die automatische Erzeugung des Eintrags in der Kontrolliste das System in dem Netzwerk, die Aktivität zu überwachen, indem möglicherweise weitere Arten einer Nutzungsaufzeichnung erzeugt werden (Interim und Stopp). Zu den verfügbaren Informationen gehören all jene Dinge, die eine Abrechnung gestatten, und zwar:
    • – eine Abrechnung auf der Grundlage des Verbrauchs, dank der Verkehrsdaten, die aus dem Eintrag der Kontrolliste erfaßt werden,
    • – eine Abrechnung auf der Grundlage der Zeit, dank der Verwaltung der Beginn- und Stopp-Ereignisse,
    • – eine Abrechnung auf der Grundlage von Ereignissen bzw. Inhalten, dank der Angabe des Verweises auf die Inhalte.
  • Auf diese Weise erhält der Betreiber die Möglichkeit, eine Abrechnung auf der Grundlage des Verkehrs durchzuführen, so daß eine Zeit-Abrechnung für Live-Dienste vorgenommen wird, eine Ereignis-Abrechnung für Video-on-Demand-Dienste und dergleichen vorgenommen wird, während aus dem Gesamtbetrag die Verkehrskomponente herausgelöst wird, um doppelte Abrechnungen zu vermeiden.
  • Diese Anordnung kann in einer transparenten Weise auf verschiedene Arten von Inhalteübermittlungsarchitekturen (sowohl zentralisiert als auch dezentralisiert) angewendet werden.
  • Die gleiche Anordnung kann ohne den Auslösemechanismus verwendet werden, um eine Autorisierung auf der Grundlage eines PUSH-Paradigmas vorzunehmen, das heißt mittels Vorab-Bereitstellung durch einen zentralen Server auf der Grundlage einer Steuerlogik, die nicht direkt durch das Netzwerk ausgelöst wird, sondern vielmehr durch externe Anwendungen ausgelöst wird.
  • Das PULL-Paradigma ist insofern signifikant, als es nebenbei bestimmte Verbesserungen an dem Inhalteübermittlungsdienst realisiert. Dies erfolgt in einer Weise, die vollständig transparent mit Bezug auf die zwei beteiligten Endpunkte ist, und zwar den Inhalte-Anforderer CR und den Server, der den Dienst erbringt. Auf der Grundlage der Charakteristika der Auslöse- bzw. Filterungsvorrichtung und der Steuerungsfunktionen, die möglicherweise durch einen externen Server erbracht werden, kann die im vorliegenden Text beschriebene Anordnung auch für andere Zwecke verwendet werden.
  • Beispiele dafür sind folgende.
  • Unterstützen einer dynamischen Dienstqualität (Quality of Service – QoS). Im Anschluß an eine Anforderung für einen Zugang zu bestimmten Inhalten kann der Server 22 die speziellen Vorgaben detektieren und eine Reservierungsanforderung in Richtung eines QoS-Verwaltungssystems für die angeforderte Bandbreite und für die Dauer der Inhalte unter Verwendung des Surrogat-Servers und des Inhalte-Anforderers als dem Endpunkt erzeugen. Alternativ besteht die Möglichkeit einer direkten Kommunikation mit dem Gateway 20, um die Rückframes von dem Inhalteserver mit der konkreten Dienst-Ebene zu markieren.
  • Alternativ kann die gleiche Anordnung zum Unterstützen externer Anwendungsportale verwendet werden, indem auf eine transparente Weise der Zugang durch Dritte zu den Inhalten eines Portals kontrolliert und autorisiert wird, ohne diese Funktion in einer nativen Weise erbringen zu müssen.
  • In einer weiteren Alternative kann die gleiche Anordnung für die kontrollierte Umleitung von Anforderungen in Richtung von mit einem Präfix versehenen Echtzeit-Attributen verwendet werden. Dies führt zu einem Umleitungsmechanismus der Anforderung des Nutzers durch komplette Neukonstruktion der URL. Auf diese Weise kann eine Anforderung gemäß speziellen Attributen des Nutzers und bestimmten Kriterien angepaßt werden, die möglicherweise von externen Systemen abgeleitet werden können, wie zum Beispiel:
    • – Echtzeit-Informationen bezüglich der Lokalisierung, um zum Beispiel eine Anforderung für www.restaurants.it zu restaurants.it/Milan zu ändern;
    • – in Abhängigkeit von der Tageszeit durch mögliches Umwandeln einer Anforderung des Typs www.rai.it/lastnews in eine allgemeinere Anforderung, wie zum Beispiel rai.it/eveningnews;
    • – in Abhängigkeit von der verfügbaren Bandbreite durch Umwandeln einer Anforderung des Typs www.trailer.it/mickey in eine Anforderung www.trailer.it/30Kb/mickey;
    • – in Abhängigkeit von den Charakteristika des Nutzer-Endgerätes. Dies kann zum Beispiel auf dem Detektieren eines Mobilfunknetz-Kontexts mittels der IP-Adresse und des IMEI(International Mobile Equipment Identity)-Identifikators basieren, während daraus spezielle Hardware-Charakteristika (Anzeige, Fähigkeiten und so weiter) abgeleitet werden. Eine generische Anforderung in Richtung eines bestimmten Kontexts kann somit in eine Anforderung umgewandelt werden, die an die Hardware-Charakteristika des Empfängers angepaßt ist.
  • Generell beurteilt der Abfang- und Auslösemechanismus, der in dem Gateway 20 zur Verfügung steht, bestimmte Charakteristika in Echtzeit, während das Treffen einer Entscheidung bezüglich der besten Art und Weise des Übermittelns der angeforderten Inhalte ermöglicht wird.
  • Ein Gateway, wie er oben beschrieben ist, kann optional implementiert werden:
    • – direkt in dem Surrogat-Server (Cluster),
    • – direkt in einem Netzwerkelement, das in dem Verkehrsfluß zwischen dem Nutzer und dem Server (Cluster) enthalten ist,
    • – mittels einer dedizierten Einrichtung, die in einer transparenten Weise in die Netzwerkinfrastruktur in den Verkehrsfluß zwischen dem Nutzer und dem Surrogat-Server (Cluster) eingefügt wird, wobei diese Option als eine bevorzugte Ausführungsform angesehen wird.
  • Der Sicherheitsserver, der den Verifizierungsmechanismus im Moment des Zugangs implementiert, kann optional implementiert werden:
    • – als eine Ableitung eines generischen AAA-Servers mit einem Zugangs-Plug-in in Richtung der Nutzerfähigkeiten für die Inhalte,
    • – als eine Ableitung eines generischen Sicherheitsserver mit einem ähnlichen Plug-in, und
    • – als ein dediziertes System mit der Fähigkeit zum Erkennen von Sicherheitsinhalten, was derzeit als eine bevorzugte Ausführungsform angesehen wird.
  • Die Vorrichtung ist bevorzugt zusammen mit dem Inhalteserver (Service-Center oder CDN-Standorte) angeordnet und befindet sich besonders bevorzugt am selben Ort wie der Inhalteserver (Service-Center oder CDN-Standorte). Als eine Alternative kann sie in dem Zugangsnetz, stromabwärts der ersten vorhandenen IP-Vorrichtung, angeordnet sein.
  • Es ist somit offenbar, daß – unbeschadet der Grundprinzipien der Erfindung – die Details und Ausführungsformen (auch beträchtlich) von dem abweichen können, was hier lediglich beispielhaft beschrieben wurde, ohne den Geltungsbereich der Erfindung, wie er in den folgenden Ansprüchen definiert ist, zu verlassen.

Claims (38)

  1. Verfahren zur Handhabung von Transaktionen in einem Kommunikationsnetz, wobei – die Transaktionen zumindest eine technologieabhängige Anforderung eines gegebenen Inhalts durch einen Anforderer (CR) an zumindest einen Server (14) enthält, wobei – das Verfahren die Schritte enthält: – eine Zugriffsinhaltsliste (80) einschließlich Zulassung/Ablehnungszugriffssätzen, die einen Zugriff des Anforderers (CR) auf durch den zumindest einen Server (14) zur Verfügung gestellte Inhalte verfügbar macht; – Erfassen (56) der technologieabhängigen Anforderung; – Extrahieren (58) von Informationen, die den Anforderer (CR), der die Anforderung macht, und des angeforderten Inhalts aus der technologieabhängigen Anforderung; – aus den aus der technologieabhängigen Anforderung extrahierten Informationen Erzeugen eines entsprechenden technologieunabhängigen Zugriffsinhaltseintrags; – Überprüfen (22) des Eintrags gegen die Liste, um Zulassungs/Ablehnungsinforma-tionen abzuleiten, die die erfasste Anforderung betreffen; und – Handhaben der Anforderung als eine Funktion der abgeleiteten Zulassungs/Ableh-nungsinformationen, dadurch gekennzeichnet, dass die Handhabung der Anforderung unabhängig von den abgeleiteten Zulassungs/Ab-lehnungsinformationen den Schritt eines Weiterleitens (116) der erfassten Anforderung zu dem zumindest einen Server (14) und als eine Funktion der abgeleiteten Zulassungs/Ablehnungsinformationen die alternativen Schritte enthält: – i) Blockieren der zur erfassten Anforderung gehörigen Transaktion, wenn die Zulassungs/Ablehnungsinformationen anzeigen, dass der Anforderer nicht freigegeben ist; oder – ii) Weiterlaufenlassen der zur Anforderung gehörigen Transaktion, wenn die Zulassungs/Ablehnungsinformationen anzeigen, dass der Anforderer freigegeben ist.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Blockierens durchgeführt wird, indem ein Antwortdatenfluss (4, 5) von dem zumindest einen Server (14) zum Anforderer (CR), der die erfasste Anforderung macht, blockiert wird.
  3. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass der Schritt des Blockierens im Hinblick auf ein Ableiten der Zulassungs/Ablehnungsinformationen verzögert wird (114).
  4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass der Zugriffsinhaltseintrag – Identifizierereigenschaften des Anforderers (CR), der die erfasste Anforderung macht, – Identifizierereigenschaften des angeforderten Inhalts; und – Identifizierereigenschaften des zumindest einen Servers (14), an den die Anforderung erfolgt, enthält.
  5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass es den Schritt eines Ausbildens einer Gatewayfunktion (20) zwischen dem Anforderer (CR) und dem zumindest einen Server (14) enthält.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass es die Schritte – Konfigurieren der Gatewayfunktion (20), um zumindest einen der Schritte eines Erfassens, Extrahierens, Erzeugen und Handhabens durchzuführen, und – Verbinden einer Inhaltspolitikserverfunktion (22) mit der Gatewayfunktion (20), um den Schritt des Überprüfen durchzuführen, enthält.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass es den Schritt eines Ausbildens der Gatewayfunktion (20) mit Schnittstellenfunktionen (50, 52; 54) mit den Anforderern (CR) bzw. dem zumindest einen Server (14) ebenso wie im Hinblick auf die Inhaltspolitikserverfunktion (22) enthält.
  8. Verfahren nach Anspruch 5, 6 oder 7, dadurch gekennzeichnet, dass es den Schritt eines Ausbildens einer Mehrzahl von Ebenen in der Gatewayfunktion (20) enthält, einschließlich: – einer niedrigeren Kernebene (56) in der Mehrzahl von Ebenen, die Vernetzungs-, Überbrückungs- und IP-Ebenen-Filterfunktionen zur Verfügung stellt, die sich auf eine Erfassung der Anforderung beziehen, und – einer Anwendungsebene (58) über der niedrigeren Kernebene in der Mehrzahl von Ebenen zur Durchführung der Schritte eines Extrahierens und Erzeugens.
  9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die niedrigere Kernebene (56) durch zumindest einen der Schritte – Filtern (60) von zwischen den Anforderern (CR) und dem zumindest einen Server (14) ausgetauschten Datenflüssen; – Umlenken (62) der Datenflüsse zu der Anwendungsebene; und – wieder Einkoppeln (64) der Datenflüsse in das Netz durchgeführt wird.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass es den Schritt eines Durchführens der Filterung als IP-Paket-Filterung enthält.
  11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass es den Schritt eines Durchführens der IP-Filterung bis hinauf zu einer 4 IP-Paket-Filterung enthält.
  12. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass es auf der Anwendungsebene (58) den Schritt eines Durchführens der Vorgänge – Extrahieren (70) von Informationen, die den Anforderer (CR) und den angeforderten Inhalt identifizieren, aus den Anforderungsinformationen; – Weiterleiten (76) der extrahierten Informationen zu der Inhaltspolitikserverfunktion (22); und – Steuern (72, 60a) der niedrigeren Kernebene (56) enthält.
  13. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass es den Schritt eines Erfassens der Anforderung durch unbeeinflusst Lassen der Anforderung enthält.
  14. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der Schritt eines Extrahierens die Analyse von in der Anforderung enthaltenen Paketen enthält.
  15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass die Analyse in der Form einer Ebene-7-Analyse durchgeführt wird.
  16. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass es den Schritt eines Erzeugens von zumindest einer Reservierungsanforderung zu einem Dienstqualität(QoS)-Verwaltungssystem auf der Grundlage der Zulassungs/Ablehnungsinformationen enthält.
  17. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass es den Schritt eines Weiterleitens der Nutzeranforderung durch ausgewähltes Modifizierens eines dazu gehörigen Identifizierers (URL) enthält.
  18. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass es die Schritte – Erfassen von Informationen bezüglich des zum Anforderer (CR), der die erfasste Anforderung macht, gehörigen Endgeräts; und – Modifizieren der erfassten Anforderung als eine Funktion der Informationen bezüglich des zum Anforderer (CR) gehörigen Endgeräts enthält.
  19. System zur Handhabung von Transaktionen in einem Kommunikationsnetz, wobei die Transaktionen zumindest eine technologieabhängige Anforderung nach einem gegebenen Inhalt, die durch einen Anforderer (CR) an zumindest einen Server (14) gemacht wird, enthält, wobei das System eine Zugriffsinhaltsliste (80) einschließlich Zulassungs/Ablehnungssätzen, die den Zugriff des Anforderers (CR) auf durch den zu mindest einen Server (14) zur Verfügung gestellte Inhalte regeln, und zumindest ein Anforderungsverarbeitungsmodul (20, 22) einschließlich Teilmodulen enthält, die ausgebildet sind für: – Erfassen (56) der technologieabhängigen Anforderung; – Extrahieren (58) von Informationen, die den die Anforderung machenden Anforderer (CR) und den angeforderten Inhalt identifizieren, aus der technologieabhängigen Anforderung; – Erzeugen (58) eines entsprechenden technologieabhängigen Zugriffsinhaltseintrags aus den extrahierten Informationen von der technologieabhängigen Anforderung; – Überprüfen (22) des Eintrags gegenüber der Liste, um Zulassungs/Ablehnungs-informationen betreffend die erfasste Anforderung abzuleiten; und – Handhaben der Anforderung als eine Funktion der abgeleiteten Zulassungs/Ab-lehnungsinformationen, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) ausgebildet ist, um unabhängig von den abgeleiteten Zulassungs/Ablehnungsinformationen den Schritt eines Weiterleitens (116) der erfassten Anforderung zu dem zumindest einen Server (14) und als eine Funktion der abgeleiteten Zulassungs/Ablehnungsinformationen die alternativen Schritte durchzuführen: i) Blockieren der zur erfassten Anforderung gehörigen Transaktion, wenn die Zulassungs/Ablehnungsinformationen anzeigen, dass der Anforderer nicht freigegeben ist; oder ii) Laufenlassen der zur Anforderung gehörigen Transaktion, wenn die Zulassungs/Ablehnungsinformationen anzeigen, dass der Anforderer freigegeben ist.
  20. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Durchführung des Schritts eines Blockierens durch Blockieren eines Antwortdatenflusses (4, 5) von dem zumindest einen Server (14) und dem Anforderer (CR), der die erfasste Anforderung macht, ausgebildet ist.
  21. System nach einem der Ansprüche 19 oder 20, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Durchführung des Schritts eines Blockierens als ein im Hinblick auf ein Ableiten der Zulassungs/Ablehnungsinformationen verzögerter Schritt (114) ausgebildet ist.
  22. System nach Anspruch 19, 20 oder 21, dadurch gekennzeichnet, dass der Zugriffsinhalteintrag – Identifizierereigenschaften des Anforderers (CR), der die erfasste Anforderung macht, – Identifizierereigenschaften des angeforderten Inhalts; und – Identifizierereigenschaften des zumindest einen Servers (14), an den die Anforderung erfolgt, enthält.
  23. System nach einem der Ansprüche 19 bis 22, dadurch gekennzeichnet, dass es ein Gateway (20) zwischen dem Anforderer (CR) und dem zumindest einen Server (14) enthält.
  24. System nach Anspruch 23, dadurch gekennzeichnet, dass das Gateway (20): – ausgebildet ist, zumindest einen der Schritte eines Erfassens, Extrahierens, Erzeugens und Handhabens durchzuführen, und – einen zugehörigen Inhaltspolitikserver (22) zur Durchführung des Schritts eines Überprüfens besitzt.
  25. System nach Anspruch 24, dadurch gekennzeichnet, dass das Gateway (20) mit Schnittstellenfunktionen (50; 52; 54) mit den Anforderern (CR) bzw. dem zumindest einen Server (14) ebenso wie im Hinblick auf die Inhaltspolitikserverfunktion (22) versehen ist.
  26. System nach einem der Ansprüche 23 bis 25, dadurch gekennzeichnet dass das Gateway (20) – eine niedrigere Kernebene (56), die Vernetzungs-, Überbrückungs- und IP-Ebenen-Filterfunktionen bezüglich einer Erfassung der Anforderung zur Verfügung stellt, und – eine Anwendungsebene (58) zur Durchführung der Schritte eines Extrahierens und Erzeugens enthält.
  27. System nach Anspruch 26, dadurch gekennzeichnet, dass die niedrigere Kernebene (56) ausgebildet ist zur Durchführung von zumindest einem der Schritte: – Filtern (60) von zwischen den Anforderern (CR) und dem zumindest einen Server (14) ausgetauschten Datenflüssen; – Umlenken (62) der Datenflüsse zur Anwendungsebene; und – wieder Einkoppeln (64) der Datenflüsse in das Netz.
  28. System nach Anspruch 27, dadurch gekennzeichnet, dass das Gateway (20) ausgebildet ist zur Durchführung der Filterung als IP-Paket-Filterung.
  29. System nach Anspruch 28, dadurch gekennzeichnet, dass die IP-Filterung eine IP-Paket-Filterung bis zur Ebene 4 enthält.
  30. System nach Anspruch 26, dadurch gekennzeichnet, dass die Anwendungsebene (58) ausgebildet ist zum: – Extrahieren (70) von Informationen, die den Anforderer (CR) und den angeforderten Inhalt identifizieren, aus der Anforderung; – Weiterleiten (76) der extrahierten Informationen zu der Inhaltspolitikserverfunktion (22); und – Steuern (72, 60a) der unteren Kernebene (56).
  31. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Erfassung der Anforderung durch unbeeinflusst Lassen der Anforderung ausgebildet ist.
  32. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Analyse von in der Anforderung enthaltenen Paketen ausgebildet ist.
  33. System nach Anspruch 32, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Durchführung der Analyse in der Form einer Ebene-7-Analyse ausgebildet ist.
  34. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) zur Erzeugung von zumindest einer Reservierungsanforderung zu einem Dienstqualität(QoS)-Verwaltungssystem auf der Grundlage der Zulassungs/Ab-lehnungsinformationen ausgebildet ist.
  35. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) ausgebildet ist zum Umleitung der Nutzeranforderung durch ausgewähltes Modifizieren eines dazu gehörigen Identifizierers (URL).
  36. System nach Anspruch 19, dadurch gekennzeichnet, dass das zumindest eine Verarbeitungsmodul (20, 22) ausgebildet ist zum: – Erfassen von Informationen bezüglich des zum Anforderer (CR), der die erfasste Anforderung macht, gehörigen Endgeräts; und – Modifizieren der erfassten Anforderung als eine Funktion der Informationen bezüglich des zum Anforderer (CR) gehörigen Endgeräts.
  37. Kommunikationsnetz einschließlich eines Systems gemäß einem der Ansprüche 19 bis 36.
  38. Computerprogrammprodukt, das in den Speicher zumindest eines Computers ladbar ist und Softwarecodeteile zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 18 enthält.
DE602004011689T 2004-04-14 2004-04-14 Verfahren und System zur Handhabung der Übermittlung von Inhalten in Kommunikationsnetzen Expired - Lifetime DE602004011689T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2004/003925 WO2005101782A1 (en) 2004-04-14 2004-04-14 Method and system for handling content delivery in communication networks

Publications (2)

Publication Number Publication Date
DE602004011689D1 DE602004011689D1 (de) 2008-03-20
DE602004011689T2 true DE602004011689T2 (de) 2009-02-05

Family

ID=34957351

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004011689T Expired - Lifetime DE602004011689T2 (de) 2004-04-14 2004-04-14 Verfahren und System zur Handhabung der Übermittlung von Inhalten in Kommunikationsnetzen

Country Status (7)

Country Link
US (1) US8225377B2 (de)
EP (1) EP1735983B1 (de)
AT (1) ATE385646T1 (de)
DE (1) DE602004011689T2 (de)
ES (1) ES2304251T3 (de)
PT (1) PT1735983E (de)
WO (1) WO2005101782A1 (de)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8438297B1 (en) 2005-01-31 2013-05-07 At&T Intellectual Property Ii, L.P. Method and system for supplying media over communication networks
US7961622B2 (en) * 2005-09-02 2011-06-14 Tekelec Methods, systems, and computer program products for monitoring and analyzing signaling messages associated with delivery of streaming media content to subscribers via a broadcast and multicast service (BCMCS)
US7720463B2 (en) * 2005-09-02 2010-05-18 Tekelec Methods, systems, and computer program products for providing third party control of access to media content available via broadcast and multicast service (BCMCS)
US7860799B2 (en) * 2005-10-25 2010-12-28 Tekelec Methods, systems, and computer program products for providing media content delivery audit and verification services
JP4195480B2 (ja) * 2006-10-04 2008-12-10 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータ端末がネットワークに接続して通信することを管理・制御するための装置および方法。
US20090013407A1 (en) * 2007-02-14 2009-01-08 Brad Doctor Intrusion detection system/intrusion prevention system with enhanced performance
US8984504B2 (en) 2007-06-22 2015-03-17 Red Hat, Inc. Method and system for determining a host machine by a virtual machine
US8127290B2 (en) 2007-06-22 2012-02-28 Red Hat, Inc. Method and system for direct insertion of a virtual machine driver
US8949827B2 (en) 2007-06-22 2015-02-03 Red Hat, Inc. Tracking a virtual machine
US8429748B2 (en) 2007-06-22 2013-04-23 Red Hat, Inc. Network traffic analysis using a dynamically updating ontological network description
US9354960B2 (en) 2010-12-27 2016-05-31 Red Hat, Inc. Assigning virtual machines to business application service groups based on ranking of the virtual machines
US8191141B2 (en) 2007-06-22 2012-05-29 Red Hat, Inc. Method and system for cloaked observation and remediation of software attacks
US9495152B2 (en) 2007-06-22 2016-11-15 Red Hat, Inc. Automatic baselining of business application service groups comprised of virtual machines
US8539570B2 (en) 2007-06-22 2013-09-17 Red Hat, Inc. Method for managing a virtual machine
US8336108B2 (en) 2007-06-22 2012-12-18 Red Hat, Inc. Method and system for collaboration involving enterprise nodes
US9727440B2 (en) 2007-06-22 2017-08-08 Red Hat, Inc. Automatic simulation of virtual machine performance
US9678803B2 (en) 2007-06-22 2017-06-13 Red Hat, Inc. Migration of network entities to a cloud infrastructure
US9569330B2 (en) 2007-06-22 2017-02-14 Red Hat, Inc. Performing dependency analysis on nodes of a business application service group
US20090092057A1 (en) * 2007-10-09 2009-04-09 Latis Networks, Inc. Network Monitoring System with Enhanced Performance
US8661524B2 (en) * 2007-12-14 2014-02-25 Novell, Inc. Selective desktop control of virtual private networks (VPN's) in a multiuser environment
US8832052B2 (en) * 2008-06-16 2014-09-09 Cisco Technologies, Inc. Seeding search engine crawlers using intercepted network traffic
US8670332B2 (en) * 2008-11-07 2014-03-11 Hewlett-Packard Development Company, L.P. Systems and methods for notifying users of a network resource outage
US9357247B2 (en) 2008-11-24 2016-05-31 Time Warner Cable Enterprises Llc Apparatus and methods for content delivery and message exchange across multiple content delivery networks
EP2362990B1 (de) 2008-11-26 2016-08-10 Telecom Italia S.p.A. Anwendungsdatenflussverwaltung in einem ip-netzwerk
US9742821B2 (en) * 2008-12-23 2017-08-22 Verizon Patent And Licensing Inc. Method and system for dynamic content delivery
US8627014B2 (en) * 2008-12-30 2014-01-07 Intel Corporation Memory model for hardware attributes within a transactional memory system
US8627017B2 (en) * 2008-12-30 2014-01-07 Intel Corporation Read and write monitoring attributes in transactional memory (TM) systems
US9785462B2 (en) 2008-12-30 2017-10-10 Intel Corporation Registering a user-handler in hardware for transactional memory event handling
US20100330960A1 (en) * 2009-06-25 2010-12-30 Venkataramaiah Ravishankar Systems, methods, and computer readable media for third party monitoring and control of calls
US20110072129A1 (en) * 2009-09-21 2011-03-24 At&T Intellectual Property I, L.P. Icmp proxy device
US8458769B2 (en) 2009-12-12 2013-06-04 Akamai Technologies, Inc. Cloud based firewall system and service
US8769614B1 (en) 2009-12-29 2014-07-01 Akamai Technologies, Inc. Security framework for HTTP streaming architecture
US9906838B2 (en) * 2010-07-12 2018-02-27 Time Warner Cable Enterprises Llc Apparatus and methods for content delivery and message exchange across multiple content delivery networks
KR102000618B1 (ko) * 2010-09-13 2019-10-21 소니 인터랙티브 엔터테인먼트 아메리카 엘엘씨 부가기능의 관리
US9292329B2 (en) * 2011-02-10 2016-03-22 Microsoft Technology Licensing, Llc Virtual switch interceptor
US9680925B2 (en) 2012-01-09 2017-06-13 At&T Intellectual Property I, L. P. Methods and apparatus to route message traffic using tiered affinity-based message routing
US8938804B2 (en) * 2012-07-12 2015-01-20 Telcordia Technologies, Inc. System and method for creating BGP route-based network traffic profiles to detect spoofed traffic
US8875287B2 (en) 2012-10-04 2014-10-28 Akamai Technologies, Inc. Server with mechanism for reducing internal resources associated with a selected client connection
US9667747B2 (en) 2012-12-21 2017-05-30 Akamai Technologies, Inc. Scalable content delivery network request handling mechanism with support for dynamically-obtained content policies
US9654579B2 (en) 2012-12-21 2017-05-16 Akamai Technologies, Inc. Scalable content delivery network request handling mechanism
US9756485B2 (en) * 2014-10-02 2017-09-05 Deborah Lynn Pinard Methods and systems for walkie-talkie communications
EP3210350B1 (de) 2014-10-21 2020-05-20 Twilio, Inc. Verfahren zur bereitstellung einer mikrodienstkommunikationsplattform
US9772915B2 (en) * 2015-06-30 2017-09-26 International Business Machines Corporation Cluster file system support for extended network service addresses
US10348816B2 (en) 2015-10-14 2019-07-09 Adp, Llc Dynamic proxy server
US11171924B2 (en) * 2015-10-14 2021-11-09 Adp, Inc. Customized web services gateway
US10623528B2 (en) 2015-10-14 2020-04-14 Adp, Llc Enterprise application ecosystem operating system
US9860346B2 (en) 2015-10-14 2018-01-02 Adp, Llc Dynamic application programming interface builder
US10762559B2 (en) * 2016-04-15 2020-09-01 Adp, Llc Management of payroll lending within an enterprise system
US9942767B2 (en) * 2016-07-21 2018-04-10 Global Business Software Development Technologies, Inc. Reducing fraudulent activity associated with mobile networks
CN107612895B (zh) * 2017-09-05 2020-07-10 网宿科技股份有限公司 一种互联网防攻击方法及认证服务器
FR3086493B1 (fr) * 2018-09-20 2020-08-28 Renault Sas Procede de reattribution d’un serveur peripherique de traitement de donnees
CN110995848B (zh) * 2019-12-10 2022-09-06 京东科技信息技术有限公司 一种服务治理方法、装置、系统、电子设备及存储介质
US11671347B2 (en) * 2020-09-30 2023-06-06 Vmware, Inc. On-demand packet redirection

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6130892A (en) 1997-03-12 2000-10-10 Nomadix, Inc. Nomadic translator or router
US6779118B1 (en) * 1998-05-04 2004-08-17 Auriq Systems, Inc. User specific automatic data redirection system
US6636894B1 (en) 1998-12-08 2003-10-21 Nomadix, Inc. Systems and methods for redirecting users having transparent computer access to a network using a gateway device having redirection capability
ES2243319T3 (es) 1999-10-22 2005-12-01 Nomadix, Inc. Sistema y procedimiento para redireccionar a usuarios que intentan acceder a un destino de red.
US7240100B1 (en) * 2000-04-14 2007-07-03 Akamai Technologies, Inc. Content delivery network (CDN) content server request handling mechanism with metadata framework support
WO2002035797A2 (en) 2000-10-20 2002-05-02 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
DE60139883D1 (de) * 2001-11-29 2009-10-22 Stonesoft Oy Kundenspezifische Firewall
US20030217163A1 (en) * 2002-05-17 2003-11-20 Lambertus Lagerweij Method and system for assessing a right of access to content for a user device

Also Published As

Publication number Publication date
WO2005101782A1 (en) 2005-10-27
ES2304251T3 (es) 2008-10-01
US8225377B2 (en) 2012-07-17
DE602004011689D1 (de) 2008-03-20
ATE385646T1 (de) 2008-02-15
EP1735983A1 (de) 2006-12-27
PT1735983E (pt) 2008-05-15
EP1735983B1 (de) 2008-02-06
US20080276304A1 (en) 2008-11-06

Similar Documents

Publication Publication Date Title
DE602004011689T2 (de) Verfahren und System zur Handhabung der Übermittlung von Inhalten in Kommunikationsnetzen
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
DE60104876T2 (de) Prüfung der Konfiguration einer Firewall
DE60029879T2 (de) System zur mehrschichtigen Bereitstellung in Computernetzwerken
DE69825801T2 (de) Vorrichtung und Verfahren zur Ermöglichung gleichranginger Zugangskontrolle in einem Netz
DE19740547B4 (de) Vorrichtung und Verfahren zum Sicherstellen sicherer Kommunikation zwischen einer anfordernden Entität und einer bedienenden Entität
DE60102934T2 (de) Verfahren und system für sitzungsbasierte berechtigung und zugangskontrolle für vernetzte anwendungsobjekte
DE60216218T2 (de) Persönlicher Firewall mit Platzabhängiger Funktionalität
DE60206856T2 (de) Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen
DE602004012870T2 (de) Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung
DE60121755T2 (de) Ipsec-verarbeitung
US20070156898A1 (en) Method, apparatus and computer program for access control
EP1930818A1 (de) Verfahren zum Vorabübertragen strukturierter Datenmengen zwischen einer Clienteinrichtung und einer Servereinrichtung
DE60201716T2 (de) Verfahren und Vorrichtung zum Schutz von E-Commerce-Site gegen Distributed-Denial-of-Service Angriffen
DE60307652T2 (de) Verfahren und System zur gesicherten Inhaltsüberlieferung
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
EP1952604B1 (de) Verfahren, vorrichtung und computerprogramm zur zugangskontrolle
DE10226744B4 (de) Content- und Security Proxy in einem Mobilkommunikationssystem
DE60302003T2 (de) Handhabung von zusammenhängenden Verbindungen in einer Firewall
WO2007096249A1 (de) Verfahren zum sicheren erkennen des endes einer anwender-sitzung
EP4107640B1 (de) Verfahren und systeme zum übertragen von software-artefakten aus einem quellnetzwerk zu einem zielnetzwerk
DE60031004T2 (de) Elektronisches sicherheitssystem und verfahren für ein kommunikationsnetz
EP2773081A1 (de) Kommunikationsgerät für ein industrielles Kommunikationsnetz und ein Verfahren zur Bereitstellung von Daten, insbesondere Dateien, in einem industriellen Kommunikationsnetz mittels File Transfer Protocol
DE102009060904B4 (de) Verfahren zum Steuern eines Verbindungsaufbaus sowie Netzwerksystem
DE60201899T2 (de) Anordnung zur verarbeitung von client-anforderungen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition