DE60302051T2 - Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln - Google Patents

Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln Download PDF

Info

Publication number
DE60302051T2
DE60302051T2 DE60302051T DE60302051T DE60302051T2 DE 60302051 T2 DE60302051 T2 DE 60302051T2 DE 60302051 T DE60302051 T DE 60302051T DE 60302051 T DE60302051 T DE 60302051T DE 60302051 T2 DE60302051 T2 DE 60302051T2
Authority
DE
Germany
Prior art keywords
rule
network element
content
rule specification
specified
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
DE60302051T
Other languages
English (en)
Other versions
DE60302051D1 (de
Inventor
Chan Wah Ng
Pek Yew Tan
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.)
Panasonic Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
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 Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Application granted granted Critical
Publication of DE60302051D1 publication Critical patent/DE60302051D1/de
Publication of DE60302051T2 publication Critical patent/DE60302051T2/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0869—Validating the configuration within one network element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • 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
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • 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
    • H04L63/0281—Proxies
    • 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
    • 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/102—Entity profiles
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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/14—Session management
    • 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
    • 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/306—User 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • 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/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Description

  • Technisches Gebiet
  • Die Erfindung bezieht sich auf das Gebiet des Lieferns von Inhalten in einem Datenkommunikationsnetzwerk. Weiter insbesondere betrifft diese Erfindung die verteilte Steuerung eines Datenpaketstroms, welcher durch ein zwischengeschaltetes Netzwerkelement fließt, und die verteilte Steuerung und Konfiguration von Netzwerkressourcen an einer Hierarchie der Zwischenstationen. Die hauptsächlich gewünschte Verwendung dieser Erfindung ist, als ein Proxy für Inhaltsstreaming zu dienen und in einer verteilten Weise Inhaltsanpassungsdienste zur Verfügung zu stellen.
  • Stand der Technik
  • Über das letzte Jahrzehnt hat das Internet und weiter insbesondere das auf dem Internet-Protokoll (IP) basierende Netzwerk ein großartiges Wachstum erlebt. Die Ausbreitung des Internet und die ansteigende Zahl von Internet-Nutzern hat zu Erweiterungs- und Skalierproblemen für Anwendungen geführt. Dies ist insbesondere für Anwendungen richtig, die für Endnutzer entworfen sind, wie etwa das World Wide Web (WWW) und audiovisuelles Streaming. Die Anstiege in Netzwerkbandbreite und Verarbeitungsstärke können kaum mit den Forderungen der steigenden Zahl von Internet-Nutzern mithalten. Dies hat zu einer längeren Ladezeit für eine www-Seitenanfrage geführt und zu einem Verlust von Qualität bei einer audiovisuellen Echtzeitwiedergabe über das Internet geführt. Der Versuch, derartige unerwünschte Effekte zu reduzieren, hat zu einer weiten Verbreitung von intelligenten Netzwerkelementen an dem Netzwerkrand (d.h. näher an den Endnutzern) geführt.
  • Die am meisten verbreitete Verwendung derartiger zwischengeschalteter Netzwerkelemente ist es, als Cache Proxies zu dienen, wie etwa Hypertexttransfer protokoll (http) Proxies und/oder Caches, wie sie in einem Artikel „Hypertexttransferprotokoll – HTTP/1.1", IETF RFC 2616, Juni 1999, von Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., und T. Berners-Lee beschrieben sind. Diese waren erfolgreich beim Reduzieren der Netzwerkbelastung an dem WWW-Server und einer Beschleunigung von einem Liefern von WWW-Inhalten an die Endnutzer. Da jedoch die Zahl von Endnutzern ansteigt, weitet sich die Vielzahl von Netzbrowserkonfigurationen und Plattformen aus. Auf ähnliche Weise verbreitert sich auch die Bandbreite von Netzinhalten. Es kann nicht davon ausgegangen werden, dass ein einfaches Replizieren von statischen Netzinhalten die immer weiter ansteigenden Forderungen der Endnutzer trägt.
  • Darüber hinaus besteht auch ein merklicher Anstieg bei der Verbreitung von Multimedia-Streaming über das Internet. Dieses verwendet normalerweise das Echtzeit-Streaming-Protokoll (RTSP) als Sitzungsprotokoll, um einen Kommunikationskanal aufzubauen und abzubauen, und ein Echtzeittransportprotokoll und ein Echtzeitsteuerprotokoll (RTP/RTCP) für die tatsächliche Übertragung von Inhaltsdaten. Das RTSP ist beispielsweise in „Real-Time Streaming Protocol (RTSP)", IETF RFC 2326, April 1998, von Schulzrinne, H., Rao, A., und Lanphier, R. offenbart. Das RTP/RTCP ist beispielsweise in „RTP: A Transport Protocol for Real-Time Applications", IETF RFC 1889, Januar 1996, von Schulzrinne, H., Casner, S., Frederi ck, R., und Jabcobson, V. offenbart. Aufgrund der vielfältigen Natur des Internet-Verkehrs ist eine Anpassung des Multimedia-Stroms an die fluktuierenden Verkehrsbedingungen notwendig, um für den Endnutzer eine glatte Präsentation zu sichern. Obwohl RTCP ein Mittel für Endnutzer zur Verfügung stellt, um deren Kommunikationsstatus zurück an den Sender zu berichten, können Maßnahmen, die durch den Sender auf der Basis eines Empfängerberichts vorgenommen werden, nur schwer effektiv sein, da der Abstand (Netz-Abfrage) zwischen dem Empfänger und dem Sender oft groß ist. Da die meisten Endnutzer mit dem Internet über eine Zwischenstation beliebiger Sorte, beispielsweise Firewall Gateways, Netzwerkadressenübersetzer (NAT) oder Proxies in Verbindung treten, bietet die Zwischenstation eine gute Wahl, um Anpassungsdienste für den den Inhalt ursprünglich zur Verfügung stellenden durchzuführen.
  • Ebenso wie das Internet wächst darüber hinaus auch die Bandbreite von Vorrichtungen, die verwendet werden, um von dem Netz auf Inhalte zuzugreifen. Diese Diversifikation von Browser-Typen wurde mit kürzlichen Fortschritten bei der drahtlosen Internet-Technologie beschleunigt, wodurch kleine Handgeräte, wie etwa digitale persönliche Assistenten (PDA) und Mobiltelefone eingebaute Mikro-Browser aufweisen, die das Netz absuchen, oder audio-visuelle Ströme wiedergeben. Inhaltsautoren können nicht länger Inhalte mit der Annahme entwickeln, dass der entwickelte Inhalt nur durch Nutzer angesehen werden wird, die herkömmliche Desktop Computer verwenden. Vorrichtungsunabhängigkeit ist nunmehr eine kritische Überlegung, wie etwa in „Device Independence Principles", W3C Working Draft, http://www.w3.org/TR/di-princ/, September 2001, von Gimson, R., et. al. offenbart.
  • Eine Anzahl von internationalen Standardisierungsorganisationen hat den Bedarf erkannt, Dienste, die ursprünglich nur an dem Netzwerkkern (wo sich die Server befinden) zur Verfügung standen, dem Netzwerkrand (wo sich die Endnutzer befinden) zur Verfügung zu stellen. Die Internet Engineering Task Force (IETF) hat beispielsweise kürzlich einige Arbeitsgruppen eingesetzt, die sich darauf konzentrieren, Dienste an den Netzwerkrändern zur Verfügung zu stellen. Die Open Pluggable Extensible Services (OPES) Arbeitsgruppe ist ein solcher Versuch. Die OPES-Arbeitsgruppe fokussiert sich auf eine Erweiterung der derzeitigen HTTP-Proxies von einem Ausführen von einfachen Cache-Aufgaben zu einer ganzen Gesamtheit von Anwendungsdiensten. Das Grundgerüst von OPES ist in „A Model for Open Pluggable Edge Services", IETF Internet Draft, Work in Progress, http://www.ietf.org/internet-drafts/draft-tomlinson-opes-model-01, November 2001, von Tomlison, G., Chen, R., und Hofmann, M. spezifiziert. Es besteht auch eine Content Distribution Internetworking (CDI) Arbeitsgruppe, die sich auf die Zusammenarbeit zwischen verschiedenen Inhaltsverteilungsnetzwerken (CDN) konzentriert. Von derartigen Verteilungsanstrengungen wird angenommen, dass sie in der Lage sind, das Liefern von Inhalten an den Endnutzer weiter zu beschleunigen.
  • Die derzeitige Verbindung von Zwischenstationen bei einem Liefern von Inhalten ist zumeist auf ein Liefern einer einfachen Funktionalität, wie etwa einem HTTP cache-Vorgang, einem HTTP Proxy oder einem RTSP Proxy beschränkt. Dabei kann nicht erwartet werden, dass das von den Nutzern des heutigen Internets geforderte Service-Niveau aufrechterhalten werden kann, da die Anzahl von Endnutzern exponentiell ansteigt. Da sich darüber hinaus die Bandbreite von Hardwarevorrichtungen und Softwareagenten, die durch verschiedene Nutzer verwendet werden, um Inhalte aufzufinden, ebenfalls verbreitert, finden es Inhaltslieferanten schwierig, den Nutzern einen kohärenten Satz von Inhalten zur Verfügung zu stellen, der der Vorrichtung und den Vorlieben des Nutzers angepasst ist.
  • Obwohl verschiedene internationale Vereinigungen die obigen Probleme erkannt haben und gewirkt haben, um Resolutionen zur Verfügung zu stellen, könnte deren Arbeit weiterhin verbessert werden. Das beschriebene OPES-Grundgerüst konzentriert sich auf die Operationen einer einzelnen Zwischenstation, den derzeitigen Trend von Kollaborationen zwischen Inhaltslieferungsnetzwerken ignorierend. Obwohl die Idee des OPES-Grundgerüsts ist, eine Inhaltsanpassung durchzuführen, um so die Erfahrung des Nutzers beim Auffinden von Inhalt zu verbessern, fokussierte es darüber hinaus nur auf Parameter des HTTP. Dies ist nicht nur nicht adäquat für eine Vorrichtungsunabhängigkeit, es ist auch nicht auf die steigende Anzahl von audiovisuellen Streaming-Anwendungen zugeschnitten.
  • Beck A. Hofmann, M.: "IRML: A Rule Specification Language for Intermediate Services; Version 02" IETF INTERNET DRAFT; [Online] 21 November 2001 (2001-11-21), Seiten 1-17 offenbart Netzdienste als eine neue Klasse von Anwendungen, die auf vernetzten Computern in einer verteilten Umgebung laufen. Diese Dienste werden entweder direkt durch Anwendungsendpunkte oder durch Zwischenstationen aufgerufen, die für Anwendungsendpunkte wirken. Solche Zwischenstationen können in der Form von Caches, Proxies, Gateways, Schaltern usw. auftreten, und sie werden auch als Dienstverteiler, Anwendungs-Broker, Dienst-Broker usw. bezeichnet. IRML (Zwischenstations-Regel-Mark-up-Sprache (englisch = Intermediary Rule Mark-up Language)) ist ausgebildet, um als eine einfache und effiziente aber mächtige Sprache zu dienen, um die Dienstausführungsvorschriften von Anwendungsendpunkten auszudrücken. IRML-Regeln werden typischerweise durch Zwischenstationen verarbeitet, die die Ausführung von Netzdiensten gemäß diesen Regeln und Vorschriften auslösen (englisch = tricker).
  • Srisuresh P et al: „Middlebox communication architecture and framework;" INTERNET ENGINEERING TASK FORCE, 28 February 2002 (2202-02-28), Seiten 1-35, offenbart, dass heute eine Vielzahl von Zwischenstationsvorrichtungen im Internet besteht, die für ihren Betrieb Anwendungsintelligenz benötigen. Diagramme, die Echtzeit-Streaming-Anwendungen betreffen, wie etwa SIP und H.323, und eine Peer-to-Peer-Anwendung, wie etwa Napster und NetMeeting, können nicht durch ungefähres Überprüfen von Paketköpfen identifiziert werden.
  • Offenbarung der Erfindung
  • Um das in Abschnitt 3.3 aufgeführte Problem zu lösen, erlaubt es die vorliegende Erfindung, Inhaltslieferanten, Zugriffslieferanten und/oder Endnutzern, Regeln zu spezifizieren, die das Liefern von Inhalt über zwischengeschaltete Netzwerkelemente regeln. Diese Regeln können zu anderen Zwischenstationen entlang des Inhaltsfließweges verteilt werden, um eine maximale Effizienz und eine leichtere Steuerung von Netzwerkressourcen zu erreichen. Sie ist geeignet für einen Einsatz durch verschiedene Inhaltslieferungsnetzwerke und kann untereinander kooperieren. Zusätzlich erlaubt es die vorliegende Erfindung, dass Regeln spezifiziert werden, die speziell auf Echtzeitinhaltsstreaming zugeschnitten sind. Die vorliegende Erfindung definiert auch einen Mechanismus, um Regeln zu erweitern, die auf der Basis von Benutzervorlieben und Vorrichtungsleistungsfähigkeiten konstruiert sind. Solch eine Einrichtung erlaubt es dem Regelautor Regeln zu konstruieren, die Inhalte besser anpassen können, um eine Vorrichtungsunabhängigkeit zu erreichen.
  • Diese Erfindung ist durch die anhängenden Ansprüche definiert und beinhaltet die Operationen von einem oder mehreren zwischengeschalteten Netzwerkelementen, die eine Lieferung von Inhalt ausführen und eine Anpassung zwischen Endnutzern und den Inhaltslieferanten durchführen. Das zwischengeschaltete Netzwerkelement (auch als Zwischenstation bekannt) wird ein Parsing jedes zwischen dem Endnutzer und dem Inhalt der Lieferanten transferierten Datenpakets durchführen. Wenn die Datenpakete bestimmten Kriterien entsprechen, wie sie in einem Satz von Regeln spezifiziert sind, welcher in der Zwischenstation registriert ist, werden Aktionen durchgeführt, die in den Regeln spezifiziert sind, was normalerweise zu der Modifikation der Datenpakete führt. Regeln in einer Zwi schenstation können zu anderen Zwischenstationen verteilt werden, welche besser geeignet sind, um die Regel zu evaluieren und/oder die Anpassungen durchzuführen. Zusätzlich können Regeln auch speziell auf ein Echtzeit-Streaming-Protokoll zugeschnitten werden, oder sie können mit Lieferungskontextparametern konstruiert werden, um eine Vorrichtungsunabhängigkeit zu erreichen.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Grundgerüst eines zwischengeschalteten Netzwerkelements, welches die funktionale Architektur des zwischengeschalteten Netzwerkelements zeigt, wie in der Erfindung verwendet.
  • 2 zeigt Knoten entlang des Inhaltsweges und illustriert einen typischen Inhaltsfließweg von dem Inhaltsserver zu dem Inhaltsnutzer über eine einzelne oder mehrere Zwischenstationen.
  • 3 zeigt ein Beispiel einer Inhaltswegstruktur, insbesondere die Werte zeigend, die in einer Inhaltswegstruktur der Zwischenstation foo4.com gespeichert sind, wie durch Bezugszeichen 204 in 2 markiert.
  • 4 zeigt ein Verfahren zum Extrahieren von Zwischenstationsinformation aus einer eingebetteten Signatur in Datenpaketen, insbesondere das Flussdiagramm des Verfahrens zum Extrahieren von Zwischenstationssignaturen in den Datenpaketen zeigend, um die Inhaltswegstruktur zu konstruieren/auf den neuesten Stand zu bringen.
  • 5 zeigt ein Verfahren des Bestimmens der entfernten Zwischenstation, um eine Regel zu verbreiten, insbesondere den Algorithmus zeigend, der verwendet wird, um die entfernte Zwischenstation dazu zu bestimmen, zu der eine Regel zu verteilen ist, wobei die Verteilungsanzeige vorgegeben ist.
  • 6 zeigt ein Verfahren, eines Durchführens eines Parsing einer Regel mit einer verteilten Regelunterstützung, insbesondere den Algorithmus zeigend, der verwendet wird, um eine Regel einem Parsing zu unterziehen, mit dem Fokus auf Unterstützen von verteilten Regeln. Das tatsächliche Verfahren einer Durchfüh rung eines Parsing der Regel, um auf eine syntaktische Gültigkeit hin zu überprüfen und einer Evaluation der Regel liegt außerhalb des Bereichs dieses Dokuments.
  • 7 zeigt ein Verfahren zum Bestimmen der entfernten Zwischenstation zur Verteilung einer Regel in einem Server-Client-Modell, insbesondere den Algorithmus zeigend, der verwendet wird, um die entfernte Zwischenstation zu bestimmen, um zu der eine Regel zu verteilen ist, wobei die Verteilungsanzeige vorgegeben wird, in einem Server-Client-Modell.
  • Bester Weg die Erfindung auszuführen
  • Eine Vorrichtung und Verfahren zum verteilten Netzwerkressourcen-Management wird offenbart. Um ein Verständnis der Erfindung zu erleichtern, werden die folgenden Definitionen verwendet:
    Ein „Paket" ist eine in sich abgeschlossene Einheit von Daten jedes möglichen Formats, welches über ein Datennetzwerk geliefert werden könnte.
  • Eine „Zwischenstation" und ein „zwischengeschaltetes Netzwerk" sind äquivalent und werden austauschbar verwendet, wenn es nicht anderweitig spezifiziert ist, um ein Gateway, einen Router oder eine intelligente Netzwerkverteilstation zu bezeichnen, auf welche sich diese Erfindung bezieht.
  • Der Begriff „aktuelle Zwischenstation" oder „aktuelles zwischengeschaltetes Netzwerkelement" bezieht sich auf ein zwischengeschaltetes Netzwerkelement, welches ein Datenpaket verarbeitet, oder eine Regelspezifikation, in Abhängigkeit von dem Kontext, in dem der Begriff verwendet wird.
  • Die Begriffe „Inhaltsserver" und „Inhaltsnutzer" werden mit Bezug auf ein Server-Client-Modell eines Informationsaustauschs verwendet. Der Inhaltsnutzer, welcher der Client ist, wird ein einzelnes oder eine Mehrzahl von Datenpaketen zu dem Inhaltsserver senden, welche eine Anfrage enthalten. Derartige Datenpakete sind als Anfragepakete bekannt. Beim Verarbeiten der Anfrage würde der Inhaltsserver mit einem einzelnen oder einer Mehrzahl von Datenpaketen antwor ten, welche die Antwort enthalten. Derartige Datenpakete werden als Antwortpakete bezeichnet.
  • Beim Verteilen von Regeln wird der Begriff „Zielzwischenstation" oder „zwischengeschaltetes Zielnetzwerkelement" für das zwischengeschaltete Netzwerkelement der vorliegenden Erfindung verwendet, welches die verteilte Regel empfängt. Der Begriff „verteilende Zwischenstation" oder „verteilendes zwischengeschaltetes Netzwerkelement" bezieht sich auf das zwischengeschaltete Netzwerkelement der vorliegenden Erfindung, welches die Regeln zu anderen Zwischenstationen verteilt.
  • In der folgenden Beschreibung werden zum Zwecke einer Erklärung bestimmte Zahlen, Zeiten, Strukturen und andere Parameter ausgeführt, um ein tiefgreifendes Verständnis der vorliegenden Erfindung zur Verfügung zu stellen. Es ist jedoch jedem Fachmann der Technik klar, dass die vorliegende Erfindung ohne diese spezifischen Details durchgeführt werden kann.
  • Das zwischengeschaltete Netzwerkelement, auf welches die vorliegende Erfindung angewendet wird, besteht aus der funktionalen Architektur, wie sie in 1 dargestellt ist. Die Zwischenstation besteht aus einem Gateway-Modul (101), einer Regelverarbeitung (102), einem einzelnen oder einer Mehrzahl von speziellen Paketen (103) und aus dem Regelinjektionsmodul (104).
  • Das Gateway-Modul (101) ist die Sammlung von funktionalen Blöcken, die Gateway oder Proxy-Funktionalitäten implementieren. Diese können HTTP-Proxies und/oder Caches, RTSP-Proxies, RTP/RTCP-Mixer und/oder Übersetzer, und Anwendungsniveau-Gateways (ALG) umfassen, sind jedoch nicht darauf beschränkt. Beispielsweise betrachten wir eine Zwischenstation, die die Rolle eines HTTP-Proxies ausführt. Das Gateway-Modul (101) würde somit die funktionale Komponente implementieren, um HTTP-Verbindungen von der Client-Seite handzuhaben, die funktionalen Komponenten implementieren, um mit dem Server oder einem anderen HTTP-Proxy eine HTTP-Verbindung zu etablieren, basierend auf einer Anfrage der Client-Seite, und die funktionale Komponente implementieren, um Antworten von dem Server zurück auf die Client-Seite zu schalten. Das Gateway-Modul (101) ist tatsächlich die funktionale Komponente, die die Protokolle (beispielsweise HTTP, RTSP) implementiert, für welche die Zwischenstation ein aktiver Teilnehmer ist.
  • Das Regelverarbeitungsmodul (102) führt ein Parsing mit allen oder einem Teil der Datenpakete durch, die das zwischengeschaltete Netzwerkelement passieren, und gleicht diese Datenpakete mit einem Satz von Kriterien ab, die durch eine einzelne oder eine Mehrzahl von Regeln spezifiziert sind. Dies ist als Evaluierung von Regeln bekannt. Diese Regeln werden in einer logischen Einheit spezifiziert, die als Regelspezifikation bekannt ist. Eine Regelspezifikation kann eine einzelne oder ein Mehrzahl von Regeln enthalten. Wenn eine Übereinstimmung aufgefunden wird, dann wird (werden) die entsprechende (entsprechenden) Aktion(en), die in den Regeln spezifiziert ist (sind), getriggert. Dies ist als das „Abfeuern einer Regel" bekannt. Diese ausgeführt Aktion kann ein Einfügen von Inhalten in die Datenpakete, ein Entfernen von einem Teil oder des gesamten Inhalts aus den Datenpaketen und ein Modifizieren von Inhalten in den Datenpaketen umfassen, ist jedoch nicht darauf beschränkt. Dieses Einfügen, Entfernen und Modifizieren von Paketinhalten kann auf der Zwischenstation oder anderen entfernten Maschinen ausgeführt werden, die bestimmt sind, um Pakettransformationen durchzuführen.
  • Beispiele von Regeln, die durch eine Regelverarbeitung (102) einem Parsing unterzogen werden, schließen eine Regel ein, welche die Bandbreite bestimmt, die dem Datenstrom zuzuordnen ist, die der Client anfordert. Beispielsweise kann eine Regel in der folgenden, ein hohes Niveau aufweisenden Form spezifiziert werden:
    „Wenn Netzwerkkanal von Client <= 1 Mbps, dann ordne 10 kBit für Datenstrom zu". (Regel 1)
  • Das Regelverarbeitungsmodul (102) implementiert die Funktionalität, um solche Regeln einem Parsing zu unterziehen, und bestimmt, ob eine Übereinstimmung (d.h. ob der Netzwerkkanal des Endnutzers eine Kapazität aufweist, die kleiner ist oder gleich 1 Mbps) auftritt. Das obige Beispiel zeigt auch, wie die Regeln die Netzwerkressourcenzuordnungsentscheidungen steuern.
  • Ein anderes Beispiel von Regeln, die durch das Regelverarbeitungsmodul (102) einem Parsing unterzogen werden, wird sein, die nächste Zwischenstation, oder den nächsten Server zu bestimmen, der in Antwort auf eine Anfrage eines Klienten, welche von dem Gateway-Modul (101) empfangen wurde, zu kontaktieren ist. Hier kann, auf der Basis der Parameter der Anfrage, die Anfrage zu einem anderen Server/einer anderen Zwischenstation geleitet werden. Beispielsweise seien die folgenden Regeln eines hohen Niveaus betrachtet:
    „Wenn die angefragten Daten nur audio sind, dann leite Anfrage zu foo3.bar.com" (Regel 2a)
    „Wenn angefragte Daten audio und video sind, dann leite Anfrage zu foo4.bar.com" (Regel 2b)
  • Das Regelverarbeitungsmodul (102) ist verantwortlich für das Durchführen eines Parsing und das Interpretieren derartiger Regeln, und für das Bestimmen, ob eine Bedingung erfüllt ist. Wenn eine erfüllt ist, wird das Regelverarbeitungsmodul (102) das Gateway-Modul (101) informieren, welche nächste Zwischenstation/welcher nächster Server ausgewählt ist, und das Gateway-Modul (101), welches die tatsächliche Funktionalität implementiert, um unter Verwendung des spezifischen Protokolls mit anderen zu kommunizieren, würde voranschreiten, um die Anfrage an die ausgewählte nächste Zwischenstation/den ausgewählten nächsten Server zu leiten.
  • Die Zwischenstation in der vorliegenden Erfindung kann null, ein einziges oder mehrere von speziellen Paketen (103) aufweisen. Diese speziellen Pakete (103) sind Module, die entworfen sind, um das Regelverarbeitungsmodul (102) zu verstärken, indem sie spezialisierte Funktionalitäten zur Verfügung stellen. Beispielsweise kann ein spezielles Paket „Qualität-des-Service" (QoS) verwendet werden, um das Regelverarbeitungsmodul (102) beim Verstehen und Evaluieren von Regeln zu unterstützen, was QoS-Parameter und Bedingungen und beinhaltet. Das Regelverarbeitungsmodul (102) kann selbst nur ein Parsing von Regeln durchführen und versuchen, eine Übereinstimmung mit den durch die Regelspezifikationen ausgesprochenen Bedingungen zu finden. Unter Verwendung des obigen Beispiels der (Regel 1a) wird das Regelverarbeitungsmodul (102) Hilfe benötigen, um die tatsächliche Kapazität des Netzwerkskanals des Client zu bestimmen. Ein spezielles Paket (103) zum Evaluieren von QoS-Parametern kann in der Zwischenstation installiert werden, um einen derartigen Ausdruck zu evaluieren. Das Regelverarbeitungsmodul (102) würde das spezielle QoS-Paket (103) anfragen, wenn es ein Parsing einer Regelspezifikation durchführt, welche einen QoS-Parameter (wie etwa Bandbreite, Verzögerung usw.) spezifiziert. Das spezielle QoS-Paket (103) evaluiert den Wert des fraglichen Parameters und gibt ihn zurück an das Regelverarbeitungsmodul (102). Von da an kann dann das Regelverarbeitungsmodul (102) voranschreiten, um zu prüfen, ob eine Übereinstimmung mit der Bedingung, die durch die Regelspezifikation spezifiziert wurde, aufgetreten ist. Auf diesem Weg kann ein modulares Design der Zwischenstation erreicht werden. Das Regelverarbeitungsmodul (102) führt den Job einer Durchführung eines Parsing von Regelspezifikationen aus. Es verwendet verschiedene spezielle Pakete (103), um den Wert eines Parameters zu evaluieren, der in einer Regelspezifikation spezifiziert ist, und von diesen Werten bestimmt es, ob eine Bedingung erfüllt ist. Bei der vorliegenden Erfindung wird ein spezielles Paket zum Evaluieren von Regeln auf der Basis eines Lieferkontexts ausgeführt.
  • Das Regelinjektionsmodul (104) ist ein Modul, welches dynamisch Regeln lädt und entlädt, in und aus dem Regelverarbeitungsmodul (102). Es liefert auch die Schnittstelle für entfernte Teilnehmer, um dynamisch Regeln zu registrieren, zu aktivieren oder zu deaktivieren. Dieses Modul ist unerlässlich beim Unterstützen einer Verteilung von Regeln durch verschiedene Zwischenstationen.
  • Am Anfang, wenn die Zwischenstation hochfährt, wird das Regelinjektionsmodul (104) einen Anfangssatz von Regelspezifikationen laden, basierend auf einer Konfigurationsdatei oder anderweitig, aus dem Speicher der Zwischenstation. Die Regelspezifikationen werden in das Regelverarbeitungsmodul (102) geladen. Wenn eine Client-Anfrage (oder Server-Antwortdaten) ankommt, wird das Gateway-Modul die Anfrage des Client (oder Server-Antwortdaten) verarbeiten, und sie an das Regelverarbeitungsmodul (102) zum Durchführen eines Parsing weiterleiten. Das Regelverarbeitungsmodul (103) wird das Parsing der Regelspezifikationen durchführen und versuchen, eine Übereinstimmung mit den spezifizierten Bedingungen gegenüber der Anfrage (oder Antwort) zu suchen. Während das Parsing dieser Regeln durchgeführt wird, kann das Regelverarbeitungsmodul (102) eine Unterstützung von speziellen Paketen (103) benötigen, um den Wert der Parameter zu evaluieren.
  • Das Regelinjektionsmodul (104) erlaubt auch, dass Regeln dynamisch in die Zwischenstation geladen werden. Beispielsweise kann ein Administrator einen neuen Satz von Regelspezifikationen, der auf der Zwischenstation zu installieren ist, aus der Entfernung transferieren. Alternativ kann der Administrator wünschen, eine Regelspezifikation aus der Entfernung von der Zwischenstation zu entfernen. Das Regelinjektionsmodul (104) verarbeitet derartige Operationen aus der Entfernung. Darüber hinaus sind diese Operationen nicht beschränkt auf menschliche Administratoren. Tatsächlich beschreibt der erste Abschnitt der vorliegenden Erfindung detailliert den Mechanismus, der es erlaubt, Regelspezifikationen zwischen Zwischenstationen dynamisch zu laden und zu entladen. Das Regelinjektionsmodul (104) spielt hier die Rolle des Akzeptierens von Verbindungen von anderen Zwischenstationen und verarbeitet Anfragen, um eine Regelspezifkation in das Regelverarbeitungsmodul (102) zu laden oder aus dem Regelverarbeitungsmodul (102) zu entladen.
  • Eine Verteilung von Regeln impliziert, dass (eine) Regelspezifikation(en), die auf eine Zwischenstation geladen wird (werden) zu einer anderen Zwischenstation, um evaluiert zu werden, geleitet werden können. Das ganze oder ein Teil der Regelspezifikation kann bezeichnet werden, um verteilt zu werden. Diese Bezeichnungen schlagen auch vor, zu welcher Zwischenstation entlang des Datenflussweges zu verteilen ist. 2 zeigt einen typischen Inhaltsflussweg. Es ist zu beachten, dass andere Netzwerkelemente, die ein Vermittlungsziel entlang des Inhaltsweges durchführen, vorhanden sind, die nicht in 2 dargestellt sind. Entlang des Weges von dem Inhalts-Server (201) zu dem Inhaltsnutzer (207) können eine einzelne oder mehrere Zwischenstationen (202-206) vorhanden sein, wobei die vorliegende Erfindung verwendet wird.
  • Autoren der Regelspezifikation können anzeigen, welche Zwischenstation entlang des Inhaltsflussweges die Regelspezifikation teilweise oder insgesamt zu verteilen hat. Da es für Autoren unlogisch wäre, zu wissen, wie Zwischenstationen in einer tatsächlichen realen Situation verteilt sind, spezifizieren Autoren die bevorzugte Zwischenstation, zu welcher die Regel zu verteilen ist, indem die Richtung der Verteilung, d.h. in Richtung auf einen Quellenknoten oder in Richtung eines Zielknotens, angezeigt wird. Der Begriff „Quelle" (englisch = source) und „Ziel" (englisch = destination) werden mit Bezug auf die Datenpakete verwendet. Der Quellenknoten ist der Knoten, der das Datenpaket erzeugt, und der Zielknoten ist der Knoten, der das Datenpaket konsumiert. In einem Server-Client-Modell können die Richtungen als „in Richtung auf den Server" oder „in Richtung auf den Client" bezeichnet werden.
  • Beispielsweise wird bei Verwendung des Verteilungsszenarios, wie es in 2 dargestellt ist, eine Regelspezifikation zu dem zwischengeschalteten Netzwerkelement foo4.bar.com (204) übertragen. Ein Teil der Regel ist indiziert, um in Richtung des „Ziels" verteilt zu werden. Wenn ein Anfragepaket verarbeitet wird, d.h. ein Paket, welches von dem Inhaltsnutzer (207) zu dem Inhaltsserver (201) gesandt wurde, kann dieser Abschnitt der Regelspezifikation an die Zwischenstation f002.bar.com (202) oder die Zwischenstation foo3.bar.com (203) verteilt werden. Im Gegensatz dazu kann, wenn ein Antwortpaket verarbeitet wird, der gleiche Abschnitt der Regelspezifikation zu dem zwischengeschalteten Netzwerkelement foo6.bar.com (206) oder dem Netzwerkelement foo5.bar.com (205) verteilt werden. Ähnlich kann, wenn ein Teil der Regel indiziert ist, um in Richtung des „Servers" verteilt zu werden, diese zu der Zwischenstation foo2.bar.com (202) oder der Zwischenstation foo3.bar.com (203) verteilt werden. Im Gegensatz dazu kann, wenn ein Abschnitt der Regelspezifikation indiziert ist, um in Richtung des „Client" verteilt zu werden, dieser Abschnitt der Regelspezifikation zu dem zwischengeschalteten Netzwerkelement foo6.bar.com (206) oder dem Netzwerkelement foo5.bar.com (205) verteilt werden.
  • Ein Ziel der vorliegenden Erfindung ist es, es Regelautoren zu erlauben, in der Lage zu sein, eine Regelhierarchie zu spezifizieren, wobei das höchste Niveau der Regelspezifikation auf einer Zwischenstation liegt, und die niedrigeren Niveauabschnitte der Regelspezifikation auf anderen Zwischenstationen liegen. Dies erlaubt eine effiziente Steuerung der Operationen der Zwischenstationen. Zusätzlich zum Spezifizieren der Richtung, in welche die verteilten Regeln fließen sollen (d.h. nach vorne, nach hinten, in Richtung auf einen Inhalts-Server oder in Richtung auf einen Inhaltsnutzer), erlaubt es die vorliegende Erfindung Regelau toren auch, den ungefähren Ort in dieser Richtung zu spezifizieren, wo die Regel verteilt werden soll.
  • Das obige Beispiel verwendend kann ein Regelautor den verteilten Abschnitt der Regelspezifikation spezifizieren, um zu der Zwischenstation so nah wie möglich an dem Inhaltsnutzer verteilt zu werden. In 2 impliziert dies die Zwischenstation foo6.bar.com (206). Alternativ kann ein Abschnitt der Regel spezifiziert werden, um zu der Zwischenstation verteilt zu werden, die eine Station weg von dem Element ist, welches am nächsten zu dem Inhaltsnutzer liegt. In 2 impliziert dies das zwischengeschaltete Netzwerkelement foo5.bar.com (205). Auf ähnliche Weise ist es für den Autor möglich, zu spezifizieren, dass ein Abschnitt der Regel, zu der nächsten Zwischenstation in Richtung auf den Inhalts-Server zu verteilen ist. Unter Verwendung des vorstehenden Beispiels, wo die Regelspezifikation zu foo4.bar.com (204) übertragen wird, bedeutet dies, dass der Regelautor den wollte, dass der Abschnitt der Regel zu dem Netzelement foo3.bar.com (203) zu verteilen ist.
  • Die vorliegende Erfindung deckt alle zuvor erwähnten Mittel des Markierens der Regelspezifikation für eine Verteilung ab. Als eine Illustration werden die folgenden auf Zeichen basierenden Indizierungsverfahren vorgestellt. Es sollte für jeden Fachmann der Technik klar sein, dass andere Formen der Indizierung verwendet werden können, um einen gleichen Effekt zu erreichen, wie etwa eine Verwendung von numerischen oder alphanumerischen Codes. Bei den auf Zeichen basierenden Indizierungen ist jede Indizierung in der Form vom <Zielrichtung>-<ungefährer Ort vom Ziel weg>, oder in der Form <ungefährer Ort in Richtung auf das Ziel>-<Zielrichtung>, wobei <Zielrichtung> der Begriff Quelle (englisch = source), Ziel (englisch = destination), Server oder Client ist, und <ungefährer Ort vom weg> und <ungefährer Ort in Richtung auf das Ziel> numerische Werte sind, die die Anzahl von Zwischenstationen weg von dem spezifizierten Ziel anzeigen.
  • Um beispielsweise den Abschnitt der Regel zu indizieren, die zu der Zwischenstation zu verteilen ist, die am nächsten zu dem Inhalts-Server liegt, kann der Regelautor eine Indizierung Server-1 verwenden, um zu zeigen, dass die Regel zu der Zwischenstation zu verteilen ist, die eine Station weg von dem Inhalts- Server liegt. Wenn die Indizierung 2-Server verwendet wird, dann drückte der Regelautor den Wunsch aus, die Regel zu einer Zwischenstation zu verteilen, die zwei Stationen weg von der Zwischenstation liegt, wo die Regel geladen ist, in Richtung auf die Richtung des Inhalts-Servers. Auf ähnliche Weise zeigt die Indizierung Client-2 an, dass die Regel zu dem zwischengeschalteten Netzwerkelement zu verteilen ist, die zwei Stationen weg von dem Inhaltsnutzer liegt, und die Initiierung 1-Client zeigt an, dass die Regel zu der nächsten Zwischenstation in der Richtung des Inhaltsnutzers zu verteilen ist.
  • Damit Zwischenstationen Regelspezifikationen unter sich selbst verteilen können, müssen die Zwischenstationen in der Lage sein, zunächst die Existenz von anderen Zwischenstationen auf einem gegebenen Inhaltsflussweg zu entdecken. Jede Zwischenstation kann auch mit mehreren Inhaltsservern, Inhaltsnutzern und anderen Zwischenstationen verbunden sein, so dass eine Entdeckung wahrscheinlich nicht statisch unter Verwendung von Konfigurationsdateien durchgeführt werden kann, noch mit einem Schuss, wenn das System hochfährt.
  • Die vorliegende Erfindung verlangt, dass eine Zwischenstation eine Indizierung ihres Vorhandenseins in dem Inhalt einbettet, wenn Datenpakete von dem Inhaltsnutzer zu dem Inhalts-Server und umgekehrt fließen. Solch eine Indizierung ist als die Signatur der Zwischenstation bekannt. Diese Signaturen sollten Information der Zwischenstation, wie etwa einen auflösbaren Host-Rechnernamen und die Fähigkeiten der Zwischenstation enthalten. Die Fähigkeit der Zwischenstation sollte klar anzeigen, dass die Zwischenstation verteilte Regeln unterstützt, und sollte auch Informationen enthalten, wie etwa die in der Zwischenstation installierten speziellen Pakete.
  • In den HTTP- und RTSP-Protokollen können Zwischenstationen beispielsweise ihre Signaturen an den in den Anfrage- und Antwortköpfen enthaltenen allgemeinen „Via" Kopf anhängen. Eine Zwischenstation des Host-Rechnernamens foo4.bar.com mit installiertem speziellem QoS-Paket kann das folgende „Via" Kopffeld als ihre Signatur einsetzen:
    Via: 1.1 foo4.bar.com (OPES = standard, gos, verteilt)
  • Für andere Protokolle, die keinen eingebauten Mechanismus für Zwischenstationen aufweisen, um ihre Signatur einzubetten, kann nach anderen Mitteln gesucht werden. Beispielsweise liefern Protokolle normalerweise die Funktionalität für Maschinen, um optionale Information in die Datenpakete (normalerweise unter Verwendung von optionalen Verlängerungsköpfen) einzubetten. Dies kann verwendet werden, um Signaturen der Zwischenstation zu tragen. Zusätzlich verwendete das obige Beispiel Zeichenketten als Signatur zum Erleichtern des Verständnisses. Es sollte jedoch jedem Fachmann der Technik klar sein, dass andere Formen der Signatur verwendet werden können, um den gleichen Effekt zu erzielen, wie etwa eine Verwendung von numerischen oder alphanumerischen Codes, solange eine externe Entität den Host-Rechnernamen und Fähigkeiten der Zwischenstation aus der Signatur extrahieren kann.
  • In beiden Fällen, in denen der in das Protokoll eingebaute Mechanismus verwendet wird oder eine optionale Verlängerung verwendet wird, sollten mehrere Signaturen erlaubt sein, so dass eine Signatur jeder nachfolgenden Zwischenstation angehängt werden kann. Wenn ein Datenpaket ein gegebenes zwischengeschaltetes Netzwerkelement in dem Inhaltsflussweg erreicht, weiß das zwischengeschaltete Netzwerkelement mit anderen Worten um die anderen Zwischenstationen, die das Datenpaket vorher passiert hat. Dies ermöglicht es der Zwischenstation auch, die Reihenfolge der Zwischenstationen zu kennen, die das Paket passiert hat.
  • Bei einer typischen Operation wird eine Anfrage von dem Inhaltsnutzer zu dem Inhalts-Server fließen, und die Antwort wird von dem Inhalts-Server zu dem Inhaltsnutzer fließen. Zwischenstationen werden somit alle anderen Zwischenstationen entlang des Inhaltsflussweges kennen, wenn einmal ein Paar eines Anfrage- und Antwortdatenpakets diese passiert hat. Unter Verwendung des Szenarios, welches in 2 dargestellt ist, wird beispielsweise die Zwischenstation foo4.bar.com (204) die Existenz der Zwischenstationen foo6.bar.com (206) und foo5.bar.com (205) kennen, wenn sie die Anfrage von dem Inhaltsnutzer (207) erreicht. Wenn die Inhaltsantwort von dem Inhalts-Server die foo4.bar.com (204) erreicht, wird die Zwischenstation die Existenz der zwischengeschalteten Netzwerkelemente foo2.bar.com (202) und foo3.bar.com (203) entdecken. Somit wird die Zwischenstation foo4.bar.com (204) in der Lage sein, das Vorhandensein von anderen zwischengeschalteten Netzwerkelementen in dem gesamten Inhaltsflussweg zu erkennen.
  • Zwischenstationen werden einen Cache-Speicher eines bekannten Netzwerkes aus Zwischenstationen entlang jedes vorgegebenen Inhaltsflussweges aufrechterhalten. Der Grund hierfür wird unten erklärt. Wenn eine Zwischenstation eine Anfrage erhalten hat, kann es für sie notwendig sein, in Richtung des Inhalts-Servers eine Regel zu einem anderen zwischengeschalteten Netzwerkelement zu verteilen. Wenn die Zwischenstation sich nur auf die eingebildete Signatur verlässt, um andere zwischengeschaltete Netzwerkelemente zu entdecken, kann sie nicht vorher andere Zwischenstationen in Vorwärtsrichtung in Richtung auf den Inhalts-Server kennen, bis sie die Inhaltsantwort erhält. Sollte solche eine Situation aufkommen, sollte das Regelverarbeitungsmodul (102) prüfen, ob es Information über Zwischenstationen aus seinem Cache entnehmen kann. Wenn es dies kann, dann kann die Regel zu einer in Vorwärtsrichtung liegenden Zwischenstation verteilt werden; sonst sollte die Regel lokal evaluiert werden.
  • Um das Cache aufrechtzuerhalten, können die Datenformate verwendet werden, wie sie unten in Datenformat 1 und Datenformat 2 dargestellt sind. Datenformat 1 wird verwendet, um die Host-Rechneridentifikation (in dem Feld Hostname gespeichert) und Fähigkeiten (gespeichert im Feld Capabilities) der Zwischenstation aufzuzeichnen. Datenformat 2 wird verwendet, um die Liste von bekannten Zwischenstationen entlang eines gegebenen Inhaltsflussweges aufzuzeichnen. Der Inhaltsflussweg ist einzigartig spezifiziert durch das Triplet Quelle (gespeichert in dem Feld source), Ziel (gespeichert in dem Feld destination), und Protokoll (gespeichert in dem Feld protocol), ausgedrückt als {source, destination, protocol}. Das Feld num_nodes speichert die Anzahl von zwischengeschalteten Zweckelementen, die ein Datenpaket von dem Quellenknoten passieren muss, bevor es den Zielknoten erreicht, startend (jedoch nicht ausschließend) von der aktuellen Zwischenstation, und das Knotenfeld speichert die Information jedes solchen zwischengeschalteten Netzwerkelements. 3 illustriert ein Paar von Inhaltsweg (in 3 als ContentPath bezeichnet)-Datenformaten, die in der Zwischenstation foo4.bar.com (204) in dem in 2 dargestellten Szenario gespeichert sind.
  • Figure 00180001
    Datenformat 1: Zwischenstationseintrag
  • Figure 00180002
    Datenformat 2: Datenflussweginformation
  • 4 zeigt das Verfahren, erdacht um die in den Datenpaketen eingebetteten Signaturen der Zwischenstationen zu extrahieren und die Struktur des Inhaltsweges (in der Fig. als ContentPath bezeichnet) zu konstruieren/auf den neuesten Stand zu bringen. Wenn ein Datenpaket ankommt, prüft die Zwischenstation zunächst, ob eine Signatur eingebettet ist, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 401 bezeichnet ist. Wenn eine vorhanden ist, wird eine Inhaltswegstruktur von dem Cache gesucht, welches mit dem Triplet {destination, source, protocol} übereinstimmt, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 402 bezeichnet ist. Es ist zu beachten, dass die Quelle des Daten pakets gegenüber dem Inhaltswegziel geprüft wird und umgekehrt. Der Grund dafür ist, dass die Inhaltswegstruktur verwendet wird, um die Liste von Zwischenstationen in Richtung auf den Zielknoten zur Verfügung zu stellen, wobei die Zwischenstationen von dem Quellenknoten vorgegeben werden, wenn Signaturen von den Datenpaketen extrahiert werden. Somit besteht ein Bedarf dafür, ein Swapping mit den Ziel- und Quellenknoten durchzuführen, wenn eine Übereinstimmung gesucht wird.
  • Wenn keine gefunden werden kann, wird eine neue Inhaltswegstruktur zugeordnet, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 403 bezeichnet ist. Wenn eine in das Cache verbrachte Inhaltswegstruktur lokalisiert ist, werden die Felder num_nodes und nodes gelöscht, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 404 bezeichnet ist. Ein last-in-first-out Stapel, um die Signaturen temporär zu speichern, wird dann initialisiert, um leer zu sein, und der Zähler n wird auf null gesetzt, in dem Schritt, der mit dem Bezugszeichen 405 bezeichnet ist. In dem Schritt, der mit dem Bezugszeichen 406 bezeichnet ist, wird jede eingebettete Struktur extrahiert und zu dem Stapel verschoben. Zusätzlich wird der Zähler n inkrementiert, um die Anzahl von extrahierten Signaturen aufzuzeichnen. Wenn alle Signaturen extrahiert sind, wird der Zähler n die Anzahl von Zwischenstationen vor dem aktuellen Netzwerkelement in dem Inhaltsflussweg enthalten. Diese wird in dem Feld num_nodes gespeichert. Signaturen in dem Stapel werden dann herausgeholt, um das Knotenfeld auf den neuesten Stand zu bringen, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 406 bezeichnet ist.
  • Die vorstehende Beschreibung hat das Verfahren für Zwischenstationen präsentiert, um andere Zwischenstationen entlang des Inhaltsflussweges zu entdecken. Wenn ein Regelverarbeitungsmodul ein Parsing mit einer Regelspezifikation durchführt und feststellt, dass ein Abschnitt der Regelspezifikation markiert ist, um verteilt zu werden, dann kann es dann die angemessene Inhaltswegstruktur (durch Verwenden des Triplets aus Inhalts-Server, Inhaltsnutzer und Protokoll) prüfen und bestimmen, zu welchen entfernten Zwischenstationen die Regel zu verteilen ist.
  • 5 zeigt den Algorithmus, verwendet, um die entfernte Zwischenstation zu bestimmen, um dorthin die Regel zu verteilen, wobei die Indizierung der Verteilung in der Form
    <Zielrichtung>-<ungefährer Ort vom Ziel aus>
    oder
    <ungefährer Ort in Richtung auf das Ziel>-<Zielrichtung>,
    wie zuvor beschrieben. Der Begriff Ziel wird verwendet, um den numerischen Wert von <ungefährer Ort in Richtung auf das Ziel> oder <ungefährer Ort vom Ziel aus>, zu bezeichnen. Der Begriff Richtungssinn enthält den Wert „von", wenn die erste Form verwendet wird, und den Wert „zu", wenn die zweite Form verwendet wird. Der Begriff Richtung ist der Wert „Quelle" oder der Wert „Ziel". Die Begriffe src, dst und protocol beziehen sich auf die Quelle, das Ziel bzw. das Protokoll, welche von dem Datenpaket extrahiert wurden.
  • Der Algorithmus sucht zunächst für das Inhaltswegdatenformat, wie es in den Schritten dargestellt ist, die mit 501 bis 504 bezeichnet sind. Wenn die Richtung einer Verteilung in Richtung auf das Ziel vorliegt, wird das Triplet {src, dst, protocol} verwendet, um den Inhaltsweg zu lokalisieren, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 502 markiert ist. Andererseits wird das Triplet {dst, src, protocol} stattdessen verwendet, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 503 bezeichnet ist. Wenn kein Inhaltsweg gefunden werden kann, gibt der Algorithmus NULL zurück, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 512 bezeichnet ist. In den Schritten, die mit 505 und 506 bezeichnet sind, wird das Ziel geprüft, um zu verhindern, dass es die Zahl von entfernten Zwischenstationen in der Richtung der Verteilung übersteigt. In dem Schritt, der mit dem Bezugszeichen 507 markiert ist, wird die Verteilungsindizierung überprüft, um zu sehen, ob sie in der Form
    <Zielrichtung>-<ungefährer Ort vom Ziel aus>
    oder
    <ungefährer Ort in Richtung auf das Ziel>-<Zielrichtung>
    vorliegt.
  • Für die erste Form zeigt der numerische Wert die Zahl der Zwischenstationen von den am Ende liegenden Hostrechner (Inhalts-Server oder Inhaltsnutzer) an. Die Zwischenstationen sind jedoch in einem Knotenfeld in der Reihenfolge der Richtung in Richtung auf den Endknoten gelistet. Somit wird in dem Schritt, der mit dem Bezugszeichen 508 bezeichnet ist, eine temporäre Variable x auf die Zahl von Zwischenstationen minus dem numerischen Wert des Ziels gesetzt. Im Gegensatz dazu wird dann die temporäre Variable x auf den numerischen Wert des Ziels minus 1 gesetzt, wenn die Indizierung in der zweiten Form vorliegt, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 509 bezeichnet ist. Der Grund, eins abzuziehen liegt darin, das dass erste Element in dem Knotenfeld als Knoten[0] (englisch = nodes[0]) angenommen wird. Jeder Fachmann der Technik kann leicht die obigen Formeln modifizieren, um sie an andere Arten von Feldanordnungen anzupassen. In dem Schritt, der mit dem Bezugszeichen 510 bezeichnet ist, wird die Variable x geprüft, um zu sehen, ob sie außerhalb des Bereichs liegt. Wenn dies der Fall ist, gibt der Algorithmus NULL zurück, um anzuzeigen, dass keine passende entfernte Zwischenstation aufgefunden werden kann, wie in dem Schritt dargestellt, der mit dem Bezugszeichen 512 bezeichnet ist. Sonst gibt die Funktion die entfernte Zwischenstation zurück, die in Knoten[x] (englisch = nodes[x]) vorgegeben ist, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 511 bezeichnet ist.
  • 6 zeigt das Verfahren des Durchführen eines Parsing einer Regelspezifikation unter Berücksichtigung eines Verteilens von Regeln. Die Regelspezifikation wird zuerst einem Parsing unterzogen, um sie auf syntaktische Gültigkeit zu prüfen, und es werden ungültige Regeln zurückgewiesen, wie in den Schritten dargestellt, die mit 601, 602 und 603 bezeichnet sind. Die Regel wird als nächstes geprüft, um zu sehen, ob sie markiert ist, um verteilt zu werden, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 604 bezeichnet ist. Wenn sie nicht markiert ist, wird die Regel lokal evaluiert (605). Sonst wird der in 4 dargestellte Algorithmus verwendet, um die entfernte Zwischenstation zu identifizieren, um die Regel zu dieser zu verteilen, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 606 bezeichnet ist. Wenn der Algorithmus NULL zurückgibt, das heißt, dass keine passende entfernte Zwischenstation gefunden werden kann, dann wird die Regel lokal evaluiert, wie in den Schritten dargestellt ist, die mit 607 und 605 markiert sind. Wenn eine entfernte Zwischenstation aufgefunden wird, wird sie geprüft, um zu sehen, ob sie das durch die Regel geforderte spezielle Paket unterstützt, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 608 bezeichnet ist. Wenn sie es nicht tut, wird die Regel lokal evaluiert (605). Wenn sie es tut, wird die Regel dann verteilt (609). Der gesamte Prozess wird für die nächste Regel wiederholt, die einem Parsing zu unterziehen ist (610).
  • Wenn ein Server-Client-Modell verwendet wird, wo die Zielrichtung durch in Richtung auf den „Server" oder stattdessen in Richtung auf den „Client" spezifiziert werden kann, dann kann das Verfahren des Lokalisierens der Zielzwischenstation gemäß 5 nicht mehr verwendet werden. 7 zeigt das Verfahren für ein Server-Client-Modell. Der einzige Unterschied zwischen dem Algorithmus in der 7 und dem in der 5 liegt in den Schritten, die mit dem Bezugszeichen 701 bis 703 markiert sind, und in den Schritten, die mit den Bezugszeichen 501 bis 503 markiert sind. In dem Schritt, der mit dem Bezugszeichen 701 markiert ist, wird die Zielrichtung zunächst geprüft, ob sie in Richtung auf den Server oder auf den Client liegt. Wenn die Zielrichtung der Server ist, dann wird der Inhaltsweg abgesucht unter Verwendung des Triplets {Knotenidentifikation des Client, Knotenidentifikation des Servers, Protokoll} (englisch = {node identification of client, node identification of server, protocol}), wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 702 markiert ist. Wenn die Zielrichtung der Client ist, dann wird der Inhaltsweg unter Verwendung des Triplets {Knotenidentifikation des Servers, Knotenidentifikation des Clients, Protokoll} (englisch = {node identification of server, node identification of client, protocol}) abgesucht, wie in dem Schritt dargestellt ist, der mit dem Bezugszeichen 703 markiert ist. Die verbleibenden Schritte, die mit dem Bezugszeichen 704 bis 712 markiert sind, sind identisch zu den Schritten, die mit dem Bezugszeichen 504 bis 512 markiert sind.
  • Um die Regel zu verteilen, muss die Zwischenstation die Empfangszwischenstation signalisieren. Zur Vereinfachung der Erklärung wird das in 2 dargestellte Szenario verwendet. Für die folgende Diskussion ist die Zwischenstation foo4.bar.com (204) das Netzwerkelement, welches die Regel lädt, und sie hat bestimmt, dass die Regel zu der Zwischenstation foo6.bar.com (206) zur Evaluierung zu verteilen ist.
  • Um foo6.bar.com (206) zu signalisieren kann foo4.bar.com (204) ein Signal in das Datenpaket einbetten. Die vorliegende Erfindung erfordert, dass das eingebettete Signal den Identifizierer der Zwischenstation enthält, die die Regel verteilt, den Identifizierer der gewünschten Zwischenstation enthält, die die Regel empfängt, und den Regelidentifizierer enthält, der die Regel, die zu verteilen ist, eindeutig identifiziert. Der Regelidentifizierer muss den Abschnitt der Regelspezifikation auf einer vorgegebenen Zwischenstation eindeutig identifizieren, der zu verteilen ist, und der Identifizierer sollte sich mit der Zeit nicht verändern.
  • Beispielsweise können in den HTTP- und RTSP-Protokollen Zwischenstationentoken an den allgemeinen „Pragma"-Kopf in den Anfrage- und Antwortköpfen anhängen. Die vorliegende Erfindung kann somit von diesem Gebrauch machen, um die benötigten Signale einzubetten. Beispielsweise kann foo4.bar.com den folgenden Token
    OPES-distributed = "foo6.bar.com:XYZABC@foo4.bar.com";
    an den allgemeinen „Pragma" Kopf der Antwort anhängen. Der verwendete Token ist von der Form
    OPES-verteilt = "<Ziel>:<Regelidentifizierer>@<Verteiler>",
    wobei <Ziel> den Hostrechnernamen der Zwischenstation bezeichnet, die die verteilte Regel empfängt, <Regelidentifizierer> den eindeutigen Identifizierer bezeichnet, um die verteilte Regel zu identifizieren, und <Verteiler> die Zwischenstation bezeichnet, die die Regeln verteilt.
  • Für andere Protokolle, die keinen eingebauten Mechanismus für Zwischenstationen aufweisen, um Signale einzubetten, könnte nach anderen Mitteln gesucht werden. Beispielsweise stellen Protokolle normalerweise die Funktionalität für Maschinen zur Verfügung, um optionale Information in die Datenpakete (normalerweise unter Verwendung von optionalen Verlängerungsköpfen) einzubetten.
  • Dies kann verwendet werden, um für die Zwischenstation Signale zu transportieren. Zusätzlich verwendete das obige Beispiel Zeichenketten als die Signatur für ein leichteres Verständnis. Es sollte jedem Fachmann der Technik klar, dass andere Formen von Signatur verwendet werden können, um einen gleichen Effekt zu erzielen, wie etwa eine Verwendung von numerischen oder alphanumerischen Codes, solange eine externe Entität den Hostrechnernamen der verteilenden Zwischenstationen, einen Hostrechnernamen der Zielzwischenstation und den Regelidentifizierer von dem Signal extrahieren kann.
  • In beiden Fällen, in denen das Protokoll mit eingebautem Mechanismus verwendet wird oder eine optionale Verlängerung verwendet wird, sollten mehrere Signale erlaubt sein, so dass zwei oder mehr Sätze von Regeln bei einem einfachen Passieren eines Datenpakets verteilt werden können. Jede Zwischenstation muss die Datenpakete inspizieren, um derartige Signale zu erfassen, und prüfen, ob das Signal für sie vorgesehen ist. Wenn sie bestimmt hat, dass das Signal für sie vorgesehen ist, kann die Zwischenstation optional das Signal von dem Datenpaket entfernen.
  • Der Regelidentifizierer wird verwendet, um die tatsächliche Regel von der verteilenden Zwischenstation unter Verwendung eines separaten Kommunikationskanals zu erhalten. Das Regelinjektionsmodul (104) ist verantwortlich für eine Etablieren eines solchen Kommunikationskanals und ein Auffinden/Durchleiten jeder verteilten Regel. Die vorliegende Erfindung spezifiziert das Format eines solchen Kommunikationskanals nicht. Da der Regelidentifizierer einzigartig für eine spezifizierte Zwischenstation ist, sollten Zwischenstationen die wiedergewonnene verteilte Regel unter Verwendung des Regelidentifizierers und des Hostrechnernamens der verteilenden Zwischenstation als ein Cache-Schlüssel in einem Cache-Speicher speichern. Dies eliminiert die Notwendigkeit, die gleiche verteilte Regel wiederzugewinnen, sollte eine nachfolgende Verteilung erneut auftreten.
  • Die obigen Mechanismen können für Inhaltsverteilung eingesetzt werden, wenn eine Mehrzahl von sendenden und empfangenden Knoten vorhanden ist. Eine solche Situation wird in mehrere Datenflusswege aufgeteilt, wobei jeder einen sendenden Knoten und einen empfangenden Knoten enthält. Es sei festgehalten, dass diese Dekomposition nur für die Konstruktion der Inhaltswegstruktur, wie zuvor beschrieben, verwendet wird. Wenn tatsächliche Daten an einer Zwischenstation ankommen, die zu einer Mehrzahl von empfangenden Knoten gesandt werden, dann kann die Zwischenstation auf der Basis jeder Inhaltswegstruktur für jedes entsprechende Paar aus Sendeknoten (d.h. Quelle) und Empfangsknoten (d.h. Ziel) über die Regelverteilung entscheiden. Wenn die Zielzwischenstation, die eine Regel zu verteilen hat, die gleiche ist, dann kann eine einzelnes Signal in den Inhalt eingebettet werden. Wenn mehr als eine Zielzwischenstation identifiziert wird (da der Inhaltsweg sich irgendwo entlang der Leitung aufteilt), dann kann ein separates Signal für jede Zielzwischenstation in den Inhalt eingebettet werden.
  • In den vorstehenden Beschreibungen wird das Zwischenstationsnetzwerk für ein Verteilen einer Regel offenbart. Dieses Dokument wird in den folgenden Diskussionen zu dem nächsten Abschnitt der vorliegenden Erfindung übergehen, welche den Einsatz der vorliegenden Erfindung auf eine Situation eines Echtzeitinhalts-Streaming fokussiert. In dieser Situation sendet der Inhaltsnutzer eine Anfrage an den Inhaltsserver, über eine einzelne Zwischenstation oder über mehrere Zwischenstationen, welche das (die) Objekt(e) der vorliegenden Erfindung ist (sind), um eine Echtzeitsitzung aufzubauen. Wenn der Inhaltsserver die Anfrage mit einer angemessenen Antwort akzeptiert, wird ein Kommunikationskanal zwischen dem Inhalts-Server und dem Inhaltsnutzer durch die Zwischenstation(en) aufgebaut. Dieser Kommunikationskanal zwischen dem Inhalts-Server und dem Inhaltsnutzer wird im folgenden als die Inhaltssitzung bezeichnet. Der Inhalts-Server beginnt ein Übertragen von Datenpaketen durch die Inhaltssitzung zu dem Inhaltsnutzer ohne eine aktive Anfrage von dem Inhaltsnutzer, bis der Inhaltsnutzer eine Anfrage über die Zwischenstation sendet, um die Inhaltssitzung abzubrechen. Derartige Datenpakete, die spontan durch den Inhalts-Server gesendet werden, werden im Folgenden als Inhaltspakete bezeichnet. Während der Verlauf der Übertragung der Inhaltspakete durch den Inhalts-Server kann der Inhaltsnutzer Information über die Übertragungsstatistik zurück an den Inhalts-Server übertragen, oder kann dies auch nicht tun. Derartige Statistiken werden im Folgenden als Feedback-Pakete bezeichnet.
  • Eine existierendes Protokoll, welches zu der obigen Beschreibung passt, ist das Echtzeit-Streaming-Protokoll (RTSP). Die vorliegende Erfindung kann jedoch auf andere Protokolle angewendet werden, die das gleiche Verhalten zeigen, welches zuvor beschrieben wurde, wie jedem Fachmann der Technik klar sein sollte.
  • Für den Stand der Technik sind für alle Anfrage- und/oder Antwortpakete, die die Zwischenstation passieren, Regeln entwickelt. Die vorliegende Erfindung erweitert dies durch Zurverfügungstellen der Fähigkeit für Regelautoren, Regeln zu spezifizieren, die evaluiert werden, wann immer ein Inhaltspaket die Zwischenstation passiert, Regeln, die evaluiert werden, wann immer eine spezifizierte Mehrzahl von Inhaltspaketen die Zwischenstation passiert, Regeln, die evaluiert werden, wenn ein Feedback-Paket die Zwischenstation passiert, und Regeln, die in einem spezifizierten regelmäßigen Intervall während der Dauer evaluiert werden, während der die Inhaltssitzung etabliert ist. Um eine solche Maßnahme zu erreichen, wird Regelautoren erlaubt, jede Regel mit einem speziellen Attribut zu kennzeichnen. Zum Zwecke der Erklärung wird das Attribut als das „evaluateOn" Attribut bezeichnet. Tabelle 1 zeigt unten die möglichen Werte der Attribute „evaluateOn". Jeder Fachmann der Technik sollte erkennen, dass die vorliegende Erfindung unter Verwendung von anderen Namen eingesetzt werden kann.
  • Figure 00270001
    Tabelle 1: „evaluateOn"-Attribute
  • Der letzte Teil der vorliegenden Erfindung betrifft den Einsatz von speziellen Paketen (103). Wie zuvor beschrieben, sind spezielle Pakete (103) Module, die das Regelverarbeitungsmodul (102) in die Lage versetzen, Regel unter Einbeziehung unterschiedlicher Sätze von Parametern (wie etwa eines die Qualität des Service betreffenden Parameters) zu evaluieren. Die vorliegende Erfindung definiert ein neues spezielles Paket, bekannt als spezielles Paket „Delivery Context". Dieses Paket wird es dem Regelverarbeitungsmodul (102) erlauben, Regeln zu interpretieren, die auf der Basis eines Auslieferungskontexts konstruiert sind. Vier Hauptklassen von Auslieferungskontexten sind definiert, wie in Tabelle 2 unten dargestellt ist. Dieses sind Benutzervorlieben (englisch = User Preferences), Agentenfähigkeiten (englisch = Agent Capabilities), Vorrichtungsfähigkeiten (englisch = device capabilities) und natürliche Umgebung (englisch = Natural Envi ronment). Nutzervorlieben bezieht sich auf Information über den menschlichen Nutzer, einschließlich Surf-Vorlieben, Sprachvorlieben, Anzeigevorlieben, QoS-Vorlieben, Altersgruppe und Geschlecht. Agentenfähigkeiten liefern Informationen über den Software-Agenten, wie etwa den Agententyp, unterstützte Formate, unterstützte Sprachen, und unterstützte Transportprotokolle. Vorrichtungsfähigkeiten bezieht sich auf die Information über die Hardware-Vorrichtung, welches den Vorrichtungstyp, die Prozessorgeschwindigkeit und -typ, die Speicherkapazität, die Bildschirmauflösung und -tiefe, und Operationssysteme einschließt. Natürliche Umgebung liefert Information über die natürliche Umgebung, die den Endnutzer umgibt, einschließlich der Information, ob der Endnutzer in einem Gebäude oder außerhalb ist, die Geschwindigkeit des Endnutzers, der Ort des Endnutzers und Beleuchtungseigenschaften.
  • Figure 00290001
    Tabelle 2: Auslieferungskontextparameter
  • Das Spezialpaketauslieferungskontext interpretiert Regeln, die unter Verwendung von Parametern konstruiert sind, die aus dem Auslieferungskontext stammen. Es gibt verschiedene Verfahren, wodurch das spezielle Paket des Auslieferungskontexts die aktuellen Werte der Parameter erhalten kann. Ein Verfahren ist es, einen Kommunikationskanal mit einer externen Entität zu etablieren, die ein Wissen über derartige Parameter zur Verfügung stellt, beispielsweise mit dem Inhaltsnutzer. Für Parameter, wie etwa die Vorrichtungsfähigkeiten, kann es notwendig sein, diese von dem Inhaltsnutzer direkt zu erhalten. Ein alternatives Verfahren ist es, sie von einem anderen Modul zu erhalten, welches sich auf der Zwischenstation befindet. Dieses Modul kann die Werte lokal aufnehmen, die Werte von einer Speichervorrichtung laden, oder die Werte von einer externen Entität abfragen. Für Parameter, wie etwa natürliche Umgebung, kann die Zwischenstation in der Lage sein, die Information eigenständig abzuleiten, insbesondere dann, wenn die Zwischenstation in der Nähe des Inhaltsnutzers lokalisiert ist. Für Parameter wie etwa die Nutzervorlieben, kann der menschliche Nutzer einen Satz von Profilen registriert haben, welches auf der Zwischenstation zu speichern ist.
  • Die Erfindung erlaubt es zwischengeschalteten Netzwerkelementen entlang eines Inhaltsflussweges bei ihren Inhaltsauslieferungsbemühungen aktiv zusammenzuarbeiten, um die Nutzererfahrungen beim Auffinden von Inhalt zu verbessern. Mit mehr und mehr Inhaltsauslieferungsnetzwerken (CDN), die im Internet eingesetzt sind, erlaubt es die Erfindung, die in diesem Dokument offenbart ist, Zwischenstationen, wie etwa CDNs, ihre Bemühungen durch das zur Verfügung stellen von verteilten Regeln zu orchestrieren. Regeln, die auf ein Netzwerkelement geladen sind, können zu anderen Zwischenstationen in Echtzeit verteilt werden, sodass eine Adaptierung von Dateninhalten und Inhaltsanfrage an einen passenderen Knoten durchgeführt werden kann. Sie erlaubt eine bessere Steuerung der Operationen bei einer Inhaltsauslieferung.
  • Zusätzlich enthält die offenbarte Erfindung Verfahren und Mittel, welche spezifisch für das Ausliefern in Echtzeit von audiovisuellem Inhalt in einem Paketschaltungsnetzwerk sind. Dies erlaubt es Regelautoren, Regeln zu kreieren, die auf Fluktuationen in den Netzwerkbedingungen des Inhaltsstreaming schneller reagieren können. Autoren können auch Regeln kreieren, die auf den Vorrich tungsfähigkeiten und Nutzervorlieben der Inhaltskonsumenten basieren. Wenn derartige Regeln vorsichtig mit passenden Anpassungsdiensten entworfen werden, wird die Gesamterfahrung des Nutzers beim Auffinden von Inhalt signifikant verbessert.

Claims (21)

  1. Netzwerksteuergrundstrukturvorrichtung zum Steuern von Ressourcen an einem zwischengeschalteten Netzwerkelement, welches zwei oder mehr Kommunikationsnetzwerke verbindet, mit: a) einem Gatewaymodul (101), welches Gatewayfunktionalität zur Verfügung stellt, b) einem Regelverarbeitungsmodul (102), um auf der Basis von spezifizierten Regeln eine Netzwerkressourcensteuerentscheidung zu erbringen, wobei die Regeln in einem Regelspezifikationsformat spezifiziert sind, welches im folgenden als eine Regelspezifikation bezeichnet ist, c) mindestens einem speziellen Paket (103), welches dem Regelverarbeitungsmodul hinzugefügt ist, dem Regelverarbeitungsmodul spezialisierte Funktionalität anbietend, d) einem Regelinjektionsmodul (104), um eine Regelspezifikation in das Regelverarbeitungsmodul zu injizieren oder aus dem Regelverarbeitungsmodul zu entfernen, und e) einem Mittel zum Verteilen der Regelspezifikation an mindestens ein zwischengeschaltetes Netzwerkelement, aufweisend i. Mitteln zum Verteilen von Hinweisen in der Regelspezifikation, um anzuzeigen, dass ein Teil der Regelspezifikation oder die ganze Regelspezifikation zu verteilen ist, ii. Mitteln zum Verteilen einer in Datenpaketen eingebetteten Signatur, um die Fähigkeiten der zwischengeschalteten Netzwerkelemente zu melden, die die Datenpakete durchquert haben, iii. Mitteln zum Durchführen eines Parsing der Regelspezifikation, um zu bestimmen, ob ein Teil der spezifizierten Regelspezifikation oder die ganze spezifizierte Regelspezifikation verteilt wird, iv. Mitteln zum Identifizieren des Zielnetzwerkelements, um einen Teil einer Regelspezifikation oder eine ganzen Regelspezifikation zu verteilen, v. Mitteln zum Verteilen einer in Datenpakete eingebetteten Signalgebung, um ein Zielnetzwerkelement über die Verteilung eines Teils einer Regelspezifikation oder einer ganzen Regelspezifikation zu informieren, vi. Mitteln zum Wiedergewinnen des Teils der Regelspezifikation oder der ganzen Regelspezifikation, die an das Zielnetzwerkelement verteilt wurde, von dem zwischengeschalteten Netzwerkelement, welches den Teil der Regelspezifikation oder die ganze Regelspezifikation verteilt hat.
  2. Vorrichtung nach Anspruch 1, wobei das Format der Hinweise zur Verteilung eines Teils einer Regelspezifikation oder einer ganzen Regelspezifikation aufweist i. Mittel zum Verteilen Hinweisen in der Regelspezifikation, um anzuzeigen, dass ein Teil der Regelspezifikation oder die ganze Regelspezifikation zu verteilen ist, ii. die Spezifikation der Richtung einer Verteilung durch Spezifizieren des Endpunkts der spezifizierten Richtung, iii. die Spezifikation der Anzahl der zwischengeschalteten Netzwerkelemente in Richtung auf den spezifizierten Endpunkt, iv. die Spezifikation der Anzahl der zwischengeschalteten Netzwerkelemente von dem spezifizierten Endpunkt, und/oder v. der spezifische Inhalt, der an den zwischengeschalteten Netzwerkelementen verteilt wird.
  3. Vorrichtung nach Anspruch 1, wobei das Format der in den Datenpaketen eingebetteten Signatur aufweist i. die Identifikation des zwischengeschalteten Netzwerkelements, zu der die Signatur gehört, ii. die speziellen Pakete, die auf dem zwischengeschalteten Netzwerkelement, zu dem die Signatur gehört, installiert sind, und iii. die Fähigkeit eines Akzeptierens oder eines Erzeugens von einem Teil einer Regelspezifikation oder einer ganzen Regelspezifikation für eine Verteilung.
  4. Vorrichtung nach den Ansprüchen 1 oder 3, wobei die Signaturen der zwischengeschalteten Netzwerkelemente, die die Datenpakete durchquert haben, mit den Start- und Endpunkten gespeichert werden, zwischen denen die Datenpakete gewandert sind, in der Reihenfolge, in der die Datenpakete gewandert sind, und des Übertragungsprotokolls, zu dem die Datenpakete gehören.
  5. Vorrichtung nach den Ansprüchen 1, 3 oder 4, wobei das Format der Signatur die Identifikation des zwischengeschalteten Netzwerkelements und des installierten mindestens einen speziellen Pakets an dem zwischengeschalteten Netzwerkelement aufweist.
  6. Vorrichtung nach den Ansprüchen 1, 3, 4 oder 5, wobei das Format der Signaturen aufweist i. die Identifikation des Endpunkts, zu welchem die Datenpakete fließen, ii. die Identifikation des Startpunkts, von dem die Datenpakete fließen, iii. das Übertragungsprotokoll, zu dem die Datenpakete gehören, iv. die Anordnung von Signaturen der zwischengeschalteten Netzwerkelemente in der Ordnung, in der die Datenpakete von dem zwischengeschalteten Netzwerkelement, wo das Datenformat gespeichert ist, zu dem Endpunkt wandern, und v. die Anzahl von Signaturen der zwischengeschalteten Netzwerkelemente in der Ordnung, in der die Datenpakete von dem zwischengeschalteten Netzwerkelement, wo das Datenformat gespeichert ist, zu dem Endpunkt wandern.
  7. Vorrichtung nach einem der vorstehenden Ansprüche, weiterhin aufweisend Mittel zur Signalgebung, um dem zwischengeschalteten Netzwerkelement ein Signal zu geben, um den Wunsch auszudrücken, eine Sammlung von Regeln in einer Regelspezifikation an das zwischengeschaltete Netzwerkelement zu verteilen, aufweisend i. die Identifikation des zwischengeschalteten Netzwerkelements, wohin die Sammlung von Regeln in einer Regelspezifikation verteilt wird, ii. die Identifikation des zwischengeschalteten Netzwerkelements, von wo aus die Sammlung per mindestens einer Regel in einer Regelspezifikation verteilt wird, und iii. die Identifikation der Sammlung der mindestens einen Regel in einer Regelspezifikation.
  8. Vorrichtung nach einem der vorstehenden Ansprüche, weiterhin aufweisend ein Mittel zum Wiedergewinnen der Sammlung von Regeln in einer Regel spezifikation von dem zwischengeschalteten Netzwerkelement, welches die Sammlung von Regeln verteilt, durch das zwischengeschaltete Netzwerkelement, wohin die Sammlung von Regeln verteilt ist, aufweisend i. Mittel zum Etablieren eines Kommunikationskanals zwischen dem zwischengeschalteten Netzwerkelement, wohin die Sammlung von Regeln verteilt ist, und dem zwischengeschalteten Netzwerkelement, von wo die Sammlung von Regeln verteilt wird, ii. Mittel zum Liefern der Identifikation der Sammlung von Regeln, die über die Kommunikationskanäle verteilt ist, durch das zwischengeschaltete Netzwerkelement, wohin die Sammlung von Regeln verteilt ist, und iii. Mittel zum Übertragen der Sammlung von Regeln, welche über die Kommunikationskanäle verteilt ist, durch das zwischengeschaltete Netzwerkelement, von wo die Sammlung von Regeln verteilt wird.
  9. Vorrichtung nach einem der vorstehenden Ansprüche, wobei die Kommunikationsnetzwerke einen im folgenden als einen Clientknoten bezeichneten Endpunktknoten aufweisen, um eine Anfrage zu den im folgenden als einen Serverknoten bezeichneten anderen Endpunktknoten über mindestens ein zugeschaltetes Netzwerkelement zu senden, wobei der Serverknoten angepasst ist, um die Anfrage mit einer angemessenen Antwort zu akzeptieren, wobei die Kommunikationsnetzwerke weiterhin Mittel zum Einstellen eines Kommunikationskanals zwischen dem Serverknoten und dem Clientknoten durch die zwischengeschalteten Netzwerkelemente aufweisen, und wobei der Serverknoten angepasst ist, um eine Übertragung von Datenpaketen durch den Kommunikationskanal zu dem Clientknoten zu beginnen, bis der Clientknoten über die zwischengeschalteten Netzwerkelemente eine Anfrage sendet, um den Kommunikationskanal zu schließen, und wobei der Clientknoten angepasst ist, um Information über die Übertragungsstatistiken zurück zu dem Serverknoten zu übertragen.
  10. Vorrichtung nach Anspruch 9, weiterhin aufweisend ein Mittel zum Liefern des Autors einer Regelspezifikation, um eine einzelne oder eine Mehrzahl von Regeln an einem zwischengeschalteten Netzwerkelement zu triggern, auf der Basis der folgenden Steuerverfahren i. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement ein Anfragepaket von dem Clientknoten zu dem Serverknoten empfangen hat, ii. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement ein Antwortpaket von dem Serverknoten zu dem Clientknoten empfangen hat, iii. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement ein Datenpaket empfangen hat, welches Inhalte enthält, welche durch den Serverknoten zu dem Clientknoten durch den zwischen dem Serverknoten und dem Clientknoten etablierten Kommunikationskanal gesandt wurden, iv. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement ein die Übertragungsstatistiken von dem Clientknoten zu dem Serverknoten enthaltendes Datenpaket empfangen hat, v. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement eine spezifizierte Anzahl von Datenpaketen erhalten hat, die Inhalte enthalten, die durch den Serverknoten zu dem Clientknoten durch den zwischen dem Serverknoten und dem Clientknoten etablierten Kommunikationskanal gesandt wurden, und vi. die Regel, die auszuwerten ist, wenn das zwischengeschaltete Netzwerkelement ein Datenpaket empfangen hat, welches Inhalte enthält, die durch den Serverknoten durch den zwischen dem Serverknoten und dem Clientknoten etablierten Kommunikationskanal zu dem Clientknoten gesandt wurden, nach dem Ablauf eines periodischen Zeitgebers eines spezifizierten Zeitgeberwertes.
  11. Vorrichtung nach einem der vorstehenden Ansprüche, mit einem Steuermittel zur Verwendung eines Satzes von Parametern in der Regelspezifikation, um mindestens einen Inhalt oder Inhaltsauslieferungssitzungen zu steuern, um eine Bauelementunabhängigkeit in der Auslieferung des Inhalts zu erreichen, aufweisend i. den Satz von Parametern von Benutzervorlieben, bestehend aus den Vorlieben des menschlichen Benutzers, der den Inhalt konsumiert, ii. den Satz von Parametern von Agentenfähigkeiten, der aus den Fähigkeiten des Softwareagenten besteht, der durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, iii. den Satz von Parametern von Bauelementfähigkeiten, der aus den Fähigkeiten der Hardware besteht, die durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, und iv. den Satz von Parametern der natürlichen Umgebung, der aus der Information über die Umgebung besteht, in welcher der menschliche Benutzer den Inhalt gewinnt.
  12. Vorrichtung nach Anspruch 13, wobei der Satz von Parametern von Benutzervorlieben aufweist i. die Vorlieben des Benutzers bezüglich des Verfahrens des Gewinnens des Inhalts, ii. die Vorlieben des Benutzers bezüglich der in den gewonnenen Inhalten verwendeten Sprache, iii. die Vorlieben des Benutzers bezüglich der Präsentation des gewonnenen Inhalts, iv. die Altersgruppe des den Inhalt gewinnenden menschlichen Benutzers, v. das Geschlecht des den Inhalt gewinnenden menschlichen Benutzers, und vi. der Beschäftigungsstatus des den Inhalt gewinnenden menschlichen Benutzers.
  13. Vorrichtung nach Anspruch 11, wobei der Satz von Parametern von Agentenfähigkeiten aufweist i. den Typ des Softwareagenten, der durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, ii. die Inhaltsformate, die durch den Softwareagenten unterstützt werden, der durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, iii. die Inhaltssprachen, die durch den Softwareagenten unterstützt werden, der durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, und iv. die Übertragungsprotokolle, die durch den Softwareagenten unterstützt werden, der durch den menschlichen Benutzer verwendet werden, um den Inhalt zu gewinnen.
  14. Vorrichtung nach Anspruch 11, wobei der Satz von Parametern von Bauelementfähigkeiten aufweist i. den Typ der Hardware, die durch den menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, ii. die Prozessorgeschwindigkeit und Prozessorfamilie der Hardware, die von dem menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, iii. die Speicherkapazität des physikalischen und sekundären Speichers der Hardware, die von dem menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, iv. die Anzeigetiefe und -auflösung der Hardware, die von dem menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen, und v. das Betriebssystem, welches auf der Hardware läuft, die von dem menschlichen Benutzer verwendet wird, um den Inhalt zu gewinnen.
  15. Vorrichtung nach Anspruch 11, wobei der Satz von Parametern über die natürliche Umgebung aufweist i. die Information bezüglich des Ortes, wo der menschliche Benutzer den Inhalt gewinnt, ii. die Information bezüglich der Mobilität des menschlichen Benutzers, der den Inhalt gewinnt, und iii. die Information bezüglich der Beleuchtungsbedingungen, unter welchen der menschliche Benutzer den Inhalt gewinnt.
  16. Vorrichtung nach einem der Ansprüche 11 bis 14, wobei das mindestens eine spezielle Paket in der Lage ist, die Regelspezifikation zu interpretieren und zu ermitteln.
  17. Netzwerksteuergrundstrukturverfahren zum Steuern von Ressourcen an einem zwischengeschalteten Netzwerkelement, welches zwei oder mehr Kommunikationsnetzwerke verbindet, mit den Schritten: a) Liefern einer Gatewayfunktionalität durch ein Gatewaymodul, b) Liefern einer Netzwerkressourcensteuerentscheidung durch ein Regelverarbeitungsmodul auf der Basis von spezifizierten Regeln, wobei die Regeln in einem Regelspezifikationsformat spezifiziert sind, welches im folgenden als eine Regelspezifikation bezeichnet wird, c) dem Regelverarbeitungsmodul wird durch mindestens ein spezielles Paket, welches dem Regelverarbeitungsmodul hinzugefügt wird, eine spezialisierte Funktionalität angeboten, d) eine Regelspezifikation wird den Regelverarbeitungsmodul durch ein Regelinjektionsmodul injiziert oder von diesem entfernt, und e) Verteilung der Regelspezifikation zu mindestens einem zwischengeschalteten Netzwerkelement, mit den Schritten i. Verteilung von Hinweisen in der Regelspezifikation, um anzuzeigen, dass ein Teil der Regelspezifikation oder die ganze Regelspezifikation zu verteilen ist, ii. Verteilung einer Signatur, eingebettet in Datenpaketen, um auf die Fähigkeiten der zwischengeschalteten Netzwerkelemente hinzuweisen, die das Datenpaket durchquert hat, iii. Durchführen eines Parsing der Regelspezifikation, um zu bestimmen, ob ein Teil der spezifizierten Regelspezifikation oder die ganze spezifizierte Regelspezifikation verteilt ist, iv. Identifizieren des Zielnetzwerkelements, um einen Teil einer Regelspezifikation oder die ganze Regelspezifikation zu verteilen, v. Verteilung einer Signalgebung, eingebettet in Datenpakete, um ein Zielnetzwerkelement über die Verteilung eines Teils einer Regelspezifikation oder einer ganzen Regelspezifikation zu informieren, vi. Gewinnen des Teils der Regelspezifikation oder der ganzen Regelspezifikation, die zu dem Zielnetzwerkelement verteilt wurde, von dem zwischengeschalteten Netzwerkelement, welches den Teil der Regelspezifikation oder die ganze Regelspezifikation verteilt.
  18. Verfahren nach Anspruch 17, weiterhin einen Schritt des Extrahierens der Signatur von zwischengeschalteten Netzwerkelementen aufweisend, die in mindestens einem Datenpaket eingebettet ist, mit den Schritten i. Prüfen, ob sich in den Datenpaketen eingebettete Signaturen befinden, ii. Prüfen, ob eine Signatur in einem vorbestimmten Datenformat existiert, das zuvor mit den gleichen Start- und Endpunkten und Übertragungsprotokoll gespeichert wurde, iii. Zuordnen eines neuen Datenformats, wenn kein Datenformat existiert, welches zuvor mit den gleichen Start- und Endpunkten und Transmissionsprotokoll gespeichert wurde, iv. Löschen von den in dem Datenformat gespeicherten Daten, die zuvor mit dem gleichen Startpunkt, Endpunkt und Transmissionsprotokoll existierten, v. Präparieren einer leeren last-in-first-out Datenstruktur, vi. Extrahieren jeder eingebetteten Signatur in dem Datenpaket und Einschieben derselben in die last-in-first-out Datenstruktur, vii. Entfernen jedes Elements in der last-in-first-out Datenstruktur und Aufzeichnen derselben in dem vorbestimmten Datenformat, und viii. Aufzeichnen der Anzahl eingebetteter Signaturen, die in dem vorbestimmten Datenformat extrahiert wurden.
  19. Verfahren nach einem der Ansprüche 17 oder 18, weiterhin einen Schritt einer Durchführung eines Parsing einer Regelspezifikation aufweisend, um zu bestimmen, ob ein Teil der Regelspezifikation oder die ganze Regelspezifikation zu verteilen ist, mit den Schritten i. Prüfen jeder Regel in der Regelspezifikation auf ihre Gültigkeit hinsichtlich einer Syntax, ii. Ausstoßen der Regel, wenn Syntaxfehler vorhanden sind, iii. Prüfen der Regel bezüglich eines Hinweises auf Verteilung, iv. lokales Ermitteln der Regel, wenn kein Hinweise auf eine Verteilung existiert, v. Bestimmen des entfernten zwischengeschalteten Netzwerkelements, um die Regel dorthin zu verteilen, vi. lokales Ermitteln der Regel, wenn kein passendes entferntes zwischengeschaltetes Netzwerkelement gefunden werden kann, um die Regel zu verteilen, vii. Prüfen, ob das entfernte zwischengeschaltete Netzwerkelement das spezielle Paket oder spezielle Pakete aufweist, die in der Regel benötigt werden, viii. lokales Ermitteln der Regel, wenn das entfernte zwischengeschaltete Netzwerkelement das benötigte spezielle Paket oder die benötigten speziellen Pakete nicht aufweist, und ix. Verteilen der Regel zu dem entfernten zwischengeschalteten Netzwerkelement.
  20. Verfahren nach Anspruch 17, weiterhin aufweisend ein Verfahren, um das entfernte zwischengeschaltete Netzwerkelement zu bestimmen, dass eine Regel zu diesem zu verteilen ist, einen vorbestimmten Verteilungshinweis vorausgesetzt, mit den Schritten i. Lokalisieren einer Signatur in einem vorbestimmten Datenformat mit dem passenden Startpunkt, Endpunkt und Übertragungsprotokoll, ii. es wird keine passendes entferntes zwischengeschaltetes Netzwerkelement erklärt, wenn kein vorbestimmtes Datenformat lokalisiert werden kann, iii. Einstellen einer temporären Variable auf die spezifizierte Anzahl der Zwischenstationen in Richtung auf oder von dem spezifizierten Endpunkt in dem vorgegebenen Verteilungshinweis, iv. Einstellen der temporären Variable auf den Wert der Anzahl von Zwischenstationen, wie in dem lokalisierten vorbestimmten Datenformat vorgegeben, wenn die spezifizierte Anzahl von zwischengeschalteten Netzwerkelementen auf den spezifizierten Endpunkt in dem vorgegebenen Verteilungshinweis oder von dem spezifizierten Endpunkt aus in dem vorgegebenen Verteilungshinweis größer ist als die Anzahl von zwischengeschalteten Netzwerkelementen in Richtung auf den spezifizierten Endpunkt in dem vorgegebenen Verteilungshinweis oder von dem spezifizierten Endpunkt aus in dem vorgegebenen Verteilungshinweis, v. wobei der spezifizierte Verteilungshinweis aus der Spezifikation des Endpunkts und der Spezifikation der Anzahl von zwischengeschalteten Netzwerkelementen in Richtung auf den spezifizierten Endpunkt besteht, wobei die temporäre Variable auf einen Wert gesetzt wird, der der Anzahl der zwischengeschalteten Netzwerkelemente entspricht, die in dem lokalisierten vorbestimmten Datenformat vorgegeben sind, minus dem Originalwert in der temporären Variablen, vi. wobei der spezifizierte Verteilungshinweis aus der Spezifikation des Endpunkts und der Spezifikation der Anzahl von zwischengeschalte ten Netzwerkelementen von dem spezifizierten Endpunkt aus besteht, wobei die temporäre Variable auf einen Wert gesetzt wird, der dem Originalwert in der temporären Variable minus 1 entspricht, vii. Erklären des entfernten zwischengeschalteten Netzwerkelementes als das Netzwerkelement, welches in einer Signatur spezifiziert ist, die in dem lokalisierten vorbestimmten Datenformat gespeichert ist, wobei die Signatur einen Index in der Anordnung von Signaturen in dem lokalisierten vorbestimmten Datenformat aufweist, welcher dem Wert entspricht, der in der temporären Variable gespeichert ist, falls ein solcher Index existiert, und viii. es wird kein passendes entferntes zwischengeschaltetes Netzwerkelement erklärt, sollte der Index, der gleich dem Wert ist, der in der temporären Variable gespeichert ist, nicht in der Anordnung von Signaturen in dem lokalisierten vorbestimmten Datenformat existieren.
  21. Kommunikationsnetzwerk mit einer Netzwerksteuergrundstrukturvorrichtung nach einem der Ansprüche 1 bis 16 zum Steuern von Ressourcen an einem zwischengeschalteten Netzwerkelement, welches zwei oder mehr Kommunikationsnetzwerke verbindet.
DE60302051T 2002-03-18 2003-03-17 Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln Expired - Lifetime DE60302051T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US36458502P 2002-03-18 2002-03-18
US364585P 2002-03-18
PCT/JP2003/003140 WO2003078459A2 (en) 2002-03-18 2003-03-17 Method and apparatus for configuring and controlling network resources in content delivery with distributed rules

Publications (2)

Publication Number Publication Date
DE60302051D1 DE60302051D1 (de) 2005-12-01
DE60302051T2 true DE60302051T2 (de) 2006-07-20

Family

ID=28041938

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60302051T Expired - Lifetime DE60302051T2 (de) 2002-03-18 2003-03-17 Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln

Country Status (6)

Country Link
US (1) US7734746B2 (de)
EP (1) EP1487871B1 (de)
CN (1) CN1643878B (de)
AU (1) AU2003214651A1 (de)
DE (1) DE60302051T2 (de)
WO (1) WO2003078459A2 (de)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7644172B2 (en) 2002-06-24 2010-01-05 Microsoft Corporation Communicating via a connection between a streaming server and a client without breaking the connection
US7162237B1 (en) 2002-07-26 2007-01-09 Bellsouth Intellectual Property Corporation System for automatic selection of profile based on location
US7224698B2 (en) * 2002-11-27 2007-05-29 Bellsouth Intellectual Property Corporation Edge side assembler
US7379464B2 (en) * 2002-11-27 2008-05-27 At&T Bls Intellectual Property, Inc. Personal digital gateway
US7263102B2 (en) * 2002-11-27 2007-08-28 At&T Intellectual Property, Inc. Multi-path gateway communications device
US7409454B2 (en) * 2003-06-02 2008-08-05 Microsoft Corporation Automatic detection of intermediate network device capabilities
US20050071663A1 (en) * 2003-09-26 2005-03-31 General Instrument Corporation Separation of copy protection rules for digital rights management
WO2006042424A1 (en) * 2004-10-19 2006-04-27 Eidgenössische Technische Hochschule Zürich Distributed internet traffic control system
US7657536B2 (en) * 2005-02-28 2010-02-02 International Business Machines Corporation Application of resource-dependent policies to managed resources in a distributed computing system
US7739687B2 (en) * 2005-02-28 2010-06-15 International Business Machines Corporation Application of attribute-set policies to managed resources in a distributed computing system
US8166547B2 (en) * 2005-09-06 2012-04-24 Fortinet, Inc. Method, apparatus, signals, and medium for managing a transfer of data in a data network
US20070208860A1 (en) * 2006-03-02 2007-09-06 Zellner Samuel N User specific data collection
US20070208861A1 (en) * 2006-03-02 2007-09-06 Zellner Samuel N User preference interpretation
US7747246B2 (en) 2006-03-02 2010-06-29 At&T Intellectual Property I, L.P. Environment independent user preference communication
US9386327B2 (en) 2006-05-24 2016-07-05 Time Warner Cable Enterprises Llc Secondary content insertion apparatus and methods
US8280982B2 (en) 2006-05-24 2012-10-02 Time Warner Cable Inc. Personal content server apparatus and methods
US8024762B2 (en) 2006-06-13 2011-09-20 Time Warner Cable Inc. Methods and apparatus for providing virtual content over a network
US20080037518A1 (en) * 2006-07-26 2008-02-14 Parameswaran Kumarasamy Method and apparatus for voice over internet protocol call signaling and media tracing
US8539065B2 (en) 2006-07-26 2013-09-17 Cisco Technology, Inc. Method and apparatus for providing access to real time control protocol information for improved media quality control
US8181206B2 (en) 2007-02-28 2012-05-15 Time Warner Cable Inc. Personal content server apparatus and methods
US10321528B2 (en) * 2007-10-26 2019-06-11 Philips Lighting Holding B.V. Targeted content delivery using outdoor lighting networks (OLNs)
US8041656B2 (en) 2007-10-31 2011-10-18 Alcatel Lucent Method and apparatus for leveraging end user terminals in self-learning networks
US9503691B2 (en) 2008-02-19 2016-11-22 Time Warner Cable Enterprises Llc Methods and apparatus for enhanced advertising and promotional delivery in a network
US10015158B2 (en) 2008-02-29 2018-07-03 Blackberry Limited Methods and apparatus for use in enabling a mobile communication device with a digital certificate
US9479339B2 (en) * 2008-02-29 2016-10-25 Blackberry Limited Methods and apparatus for use in obtaining a digital certificate for a mobile communication device
CN101291337B (zh) * 2008-05-30 2012-11-07 同济大学 一种网格资源管理系统及管理方法
US20100241690A1 (en) * 2009-03-20 2010-09-23 Microsoft Corporation Component and dependency discovery
US8923293B2 (en) * 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
KR101310907B1 (ko) * 2009-12-21 2013-09-25 한국전자통신연구원 통합형 브이오디 서비스 시스템
US20110264530A1 (en) 2010-04-23 2011-10-27 Bryan Santangelo Apparatus and methods for dynamic secondary content and data insertion and delivery
KR101868180B1 (ko) * 2010-10-22 2018-06-15 어펌드 네트웍스, 인크. 다수의 기능들을 단일 플랫폼으로 취합하는 방법
US9252916B2 (en) 2012-02-13 2016-02-02 Affirmed Networks, Inc. Mobile video delivery
US20140052793A1 (en) * 2012-08-15 2014-02-20 Microsoft Corporation Message synchronization with extended properties
US20140282786A1 (en) 2013-03-12 2014-09-18 Time Warner Cable Enterprises Llc Methods and apparatus for providing and uploading content to personalized network storage
US9264890B2 (en) * 2013-09-05 2016-02-16 Htc Corporation Mobile device configuration system and method
MX351053B (es) * 2014-01-30 2017-09-29 Ericsson Telefon Ab L M Un método, nodos y un dispositivo de comunicación para manejar información de retroalimentación.
KR102178142B1 (ko) 2014-04-30 2020-11-13 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 모바일 네트워크의 용량 확장 최적화
US10855645B2 (en) 2015-01-09 2020-12-01 Microsoft Technology Licensing, Llc EPC node selection using custom service types
US9667683B2 (en) * 2015-05-28 2017-05-30 Alcatel-Lucent Usa Inc. Scalable architecture for media mixing
US10540628B2 (en) * 2015-09-17 2020-01-21 International Business Machines Corporation Hierarchical business rule model
US10382208B2 (en) * 2016-04-29 2019-08-13 Olympus Sky Technologies, S.A. Secure communications using organically derived synchronized processes
EP4178242A1 (de) 2017-05-05 2023-05-10 Microsoft Technology Licensing, LLC Verfahren und systeme von auf dienstleistungsfähigkeitsexpositionsfunktion (scef) basierenden internet-der-dinge (iot)-kommunikation
KR102530337B1 (ko) 2017-05-31 2023-05-08 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 Ipsec 지오그래픽 리던던시에 대한 분리 제어 및 데이터 평면 동기화
US10856134B2 (en) 2017-09-19 2020-12-01 Microsoft Technolgy Licensing, LLC SMS messaging using a service capability exposure function
WO2019152804A1 (en) 2018-02-02 2019-08-08 Affirmed Networks, Inc. Estimating bandwidth savings for adaptive bit rate streaming
US11051201B2 (en) 2018-02-20 2021-06-29 Microsoft Technology Licensing, Llc Dynamic selection of network elements
DE102018202626A1 (de) 2018-02-21 2019-08-22 Siemens Aktiengesellschaft Verfahren zur rechnergestützten Parametrierung eines technischen Systems
WO2019183206A1 (en) 2018-03-20 2019-09-26 Affirmed Networks, Inc. Systems and methods for network slicing
CN113169988A (zh) 2018-07-23 2021-07-23 微软技术许可有限责任公司 用于智能地管理移动网络中的会话的系统和方法
WO2020150315A1 (en) 2019-01-15 2020-07-23 Affirmed Networks, Inc. Dynamic auto-configuration of multi-tenant paas components
US10623275B1 (en) * 2019-02-27 2020-04-14 Bank Of America Corporation Network operational decision engine
US11403849B2 (en) 2019-09-25 2022-08-02 Charter Communications Operating, Llc Methods and apparatus for characterization of digital content
CN115831248B (zh) * 2023-02-20 2023-06-06 新疆独山子石油化工有限公司 一种反应规则的确定方法、装置、电子设备及存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5781534A (en) * 1995-10-31 1998-07-14 Novell, Inc. Method and apparatus for determining characteristics of a path
CN1206526A (zh) * 1995-12-28 1999-01-27 德纳克公司 管理网络资源的方法和设备
US6973488B1 (en) * 2000-03-31 2005-12-06 Intel Corporation Providing policy information to a remote device
US6718361B1 (en) * 2000-04-07 2004-04-06 Network Appliance Inc. Method and apparatus for reliable and scalable distribution of data files in distributed networks
EP1305924B1 (de) 2000-04-07 2010-03-31 Network Appliance, Inc. Verfahren und gerät zur sicheren und skalierbaren übertragung von datendateien in verteilten netzwerken
US7099932B1 (en) * 2000-08-16 2006-08-29 Cisco Technology, Inc. Method and apparatus for retrieving network quality of service policy information from a directory in a quality of service policy management system
US6983326B1 (en) * 2001-04-06 2006-01-03 Networks Associates Technology, Inc. System and method for distributed function discovery in a peer-to-peer network environment
US7080141B1 (en) * 2002-04-12 2006-07-18 Cisco Technology, Inc. Arrangement for automated fault detection and fault resolution of a network device
JP4324428B2 (ja) * 2003-07-28 2009-09-02 富士通株式会社 メール送信方法、メール送信プログラムおよびメール送信サーバ
US7376154B2 (en) * 2003-08-29 2008-05-20 Agilent Technologies, Inc. Non-intrusive method for routing policy discovery
US7496649B2 (en) * 2004-02-20 2009-02-24 Microsoft Corporation Policy application across multiple nodes

Also Published As

Publication number Publication date
CN1643878A (zh) 2005-07-20
CN1643878B (zh) 2011-05-11
WO2003078459A3 (en) 2004-04-15
AU2003214651A1 (en) 2003-09-29
WO2003078459A2 (en) 2003-09-25
AU2003214651A8 (en) 2003-09-29
EP1487871B1 (de) 2005-10-26
US20050111467A1 (en) 2005-05-26
DE60302051D1 (de) 2005-12-01
US7734746B2 (en) 2010-06-08
EP1487871A2 (de) 2004-12-22

Similar Documents

Publication Publication Date Title
DE60302051T2 (de) Verfahren, netzwerk und gerät zur konfiguration und steuerung von netzressourcen beim zurverfügungstellen von inhalten mit verteilungsregeln
DE60215117T2 (de) Mehrbenutzeranwendungen in multimedia-netzwerken
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE60216918T2 (de) Verfahren und computersystem zur auswahl eines randservercomputers
DE602005000779T2 (de) Kommunikationsvorrichtung and Verfahren um Musiksoundkontrolldaten über das Internet zu erhalten und zu übertragen.
DE602005000984T2 (de) Verfahren und Vorrichtung zur Speicherung von Eingangs-Filterkriterien und zur Spezifizierung von Triggerpunkt-Vorlagen zum Zeitpunkt der Diensteimplementierung
EP1826956B1 (de) Anpassung von virtuellen und physikalischen Netzwerkschnittstellen
DE60104532T2 (de) Proxy-vorrichtung und -verfahren
DE602004008099T2 (de) Verfahren, system und artikel zur dynamischen echtzeit-stream-aggregation in einem netzwerk
DE60036021T2 (de) System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
DE69913953T2 (de) Verfahren und vorrichtung zur verarbeitung von elektronischen post
DE102005020098B4 (de) Verfahren und System zum Zuweisen von Teilnehmeridentifizierungsdaten zu Netzwerkübertragungsereignissen und Computerprogrammprodukt
DE602005003668T2 (de) Verbesserungen in nachrichtenorientierten kommunikationen
DE10116640A1 (de) Auf URL beruhende Token für schwierige Verteilungen, die einen serverseitigen Cookiebehälter benutzen
DE602005005727T2 (de) Verfahren und Vorrichtung zur Verbindung von Knoten mit heterogenen Kommunikationsprotokollen
EP1597892B1 (de) Verfahren zur übertragung von Daten in einem WLAN-Netz
DE60128745T2 (de) Verfahren und Vorrichtung zur Bereitstellung einer Zwischenschicht für den VOIP-Verbindungsaufbau
EP1597861B1 (de) Verfahren zur übertragung von daten in einem wlan-netz
DE60006821T2 (de) Zugangskontrolle in einem gateway-server
DE102014009495B4 (de) Verfahren zum Aufbau einer für die Übermittlung von Medienströmen geeigneten Kommunikationsverbindung von einem ersten RTC-Client zu einem zweiten RTC-Client
DE60219263T2 (de) Überwachung und Übertragung von QOS-Daten in einem Telekommunikationsnetzwerk
DE202008006243U1 (de) Vorrichtung zum Benachrichtigen eines Adressaten einer Kommunikationssitzung
DE60303745T2 (de) Mehrschichtiges Verfahren zum Verwalten von Multicast Teilnehmern
EP1920573A1 (de) Verfahren zur manipulation von sprachpaketen in einem ip-gateway

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: PANASONIC CORP., KADOMA, OSAKA, JP